Public vs private apps

Who is allowed to use your app? Vaulter answers this with two controls, side by side in the Auth panel. One decides who can sign in, the other decides whether anyone can even look at the app without signing in. Keeping the two apart avoids most confusion about "private."

Who can sign in

In Vault → Auth, under Access, you choose:

• Anyone can sign in. Anyone who finds your published app can create an account. Right for consumer apps, marketplaces, and anything you want the world to use.
• Only people on your list. Only the people you invite can sign in. You manage the list right there: invite by email, and remove anyone who should no longer have access. Your Vaulter teammates are always included. Right for client portals and internal tools.

Flip it whenever you like. The change takes effect on your live app immediately, no republish needed.

The wall: require sign-in to view

The second control is stricter. Turning on Require sign-in to view (a paid feature, and it needs sign-in enabled for your app) means nothing is served to visitors until they sign in. Someone who is not signed in sees your sign-in screen and nothing else, not even the landing page. Walled apps are never indexed by search engines.

Use it for staging, internal review, and apps where nothing is meant to be public. Pair it with Only people on your list and the app is truly members-only: only people you invited can get past the wall.

Which one do you want?

• "My users must log in to use the app, but anyone may join" → Anyone can sign in, with sign-in built into your app's pages.
• "Only people I choose can get in" → Only people on your list.
• "Nobody should even see the app without signing in" → Require sign-in to view.
• "Only my team, and nothing visible to anyone else": use the wall and the invite list together.

What happens to your data

None of these switches expose or delete anything:

• Opening the app up does not expose user data. The per-user privacy model still applies: signed-in users only ever see their own records. Access settings change who can open the app, not who can read whose data.
• Turning the wall off, or switching back to open registration, keeps every account and every row in place. The auth foundation stays ready underneath; if you later tighten access again, everything is still there.

Frequently asked

I switched to "Only people on your list" but an existing user still gets in

Expected: the list governs who may join, and existing members stay members. To actually remove someone, suspend or delete their account in App Users; revoking an invite alone does not end a membership.

Does the wall hide my landing page too?

Yes, everything. "Require sign-in to view" serves nothing to signed-out visitors except the sign-in screen. If you want a public landing page with a members-only inside, leave the wall off and gate the inner pages with sign-in instead.

Is any of this reversible?

Fully. These switches never delete accounts or data; loosening access later finds everything exactly where it was.

Why is the wall a paid feature?

It is the successor of private visibility and rides on the auth substrate, which is part of the paid tier. Invite-only registration, the lighter control, is available everywhere.