Control who can use your published app

A published app is public by default: anyone with the link can use it. The Access panel of a published app lets you change that, from a shared passcode up to real per-person sign-in, without writing a line of authentication code.

What this protects

Access control protects the data your app stores and reads: submissions, lists, counters, uploads, payments. The page itself stays visible to anyone with the link, because a published app is static files. Treat the layout as public and the data as protected, and don’t put secrets in the page itself.

The four access modes

Mode	Who gets in	Plan
Open	Anyone with the link (the default)	All plans
Passcode	Anyone who knows one shared secret	All plans
Email sign-in	Anyone who clicks a one-time link sent to their email, no password	Pro and up
Workspace members only	The same email sign-in, but only addresses belonging to an active member of your workspace	Pro and up

Change the mode from the Access panel of a published app (the panel asks you to publish first if the app isn’t live yet). Changes take effect on the live app immediately, there’s nothing to republish.

You don’t build the sign-in screen

When an app is locked, Onplana injects the passcode or sign-in screen in front of it. You never write a login page, your app’s own code never touches a token or a password, and there is nothing to wire up. If you ask the build agent for a login page, it will tell you to use the Access panel instead, because a hand-rolled gate in a static app would only be decoration.

What email sign-in unlocks that a passcode can’t

A passcode proves someone knows a shared secret. Email sign-in proves who someone is, and that difference is what makes per-person features possible:

• One vote each: counters that count each person once.
• “My submissions”: showing a visitor only their own entries.
• Delete my entry: letting someone remove what they submitted.

Under a passcode these are genuinely impossible, everyone is the same anonymous secret-holder, and the build agent will say so rather than fake them with browser storage.

Changing your mind later is safe

• Visitors who signed in with their email stay signed in when you loosen the mode or open the app up, with one deliberate exception: tightening to Workspace members only immediately cuts off anyone who is not an active member of your workspace. Members keep their session and never see a second sign-in screen.
• Members-only is enforced on every request, not just at sign-in, so removing someone from your workspace ends their access to the app at that moment, not whenever their session would have expired.
• Switching from a passcode to a sign-in mode signs everyone out on purpose: a shared secret never proved who anyone was, so everyone proves their identity once. Leaving passcode mode also clears the stored passcode, so switching back means setting a new one.
• Turning sign-in off never locks out anyone who had access.
• Renaming the app keeps the gate; the protection follows the app, not its link.

Privacy

A visitor’s verified address is stored as a one-way hash, never in the clear. The sign-in link’s code is single-use and expires in 15 minutes; a completed sign-in lasts 14 days per app before the visitor signs in again. Visitors sign in per app: signing in to one of your apps grants nothing on another.

Counting visitors

If your app uses “count each visitor once” counters, they need an identity mode (email sign-in or members only) to know who “once” is. The counters panel warns when that setting is on for an app that can’t identify anyone.

Related

Access mode changes what each of these can do, per-person where identity exists, anonymous otherwise:

• Collect form submissions
• Show collected data in your app
• Take payments in your app
• Accept file uploads in your app
• How your app is kept safe