Add sign-in to your app

Every Vaulter app is born with real user accounts built in. The auth foundation is set up when your project is created, so there is no switch to flip and nothing to provision. Your job is just to decide how sign-in should work for your app.

Two ways to shape it

Ask the agent. Say what you want in chat:

Add a login page, and only show the dashboard to signed-in users.

The agent recognizes when a request involves user accounts and wires the sign-in flow into your app's pages.

Or use the Auth panel. Open Vault → Auth. It has two sections: App Users, where you manage the people who have signed up, and Settings, where you control how sign-in works. A live preview of your sign-in screen sits alongside the settings, so you see what your users will see as you change things.

Sign-in providers

You choose how people sign in, with simple toggles:

• Email one-time code. The default. Users enter their email and type a 6-digit code. There are no passwords to create, forget, or leak.
• Google, Microsoft, and GitHub one-click sign-in.

On paid plans you can also add multi-factor authentication (authenticator app), SMS one-time codes, and single sign-on (SAML and OIDC) for organizations.

Who can register

Separate from how people sign in, you control who may create an account at all:

• Anyone can sign in. Anyone who finds your app can create an account. Right for consumer apps.
• Only people on your list. Only people you invite from the App Users list can get in. Right for client portals and internal tools.

Invite emails are sent in your app's name, with your app's logo, and replies go to an address you set.

Managing your users

The App Users section is your admin view: search users, invite by email, promote someone to admin, suspend and reinstate accounts, and delete a user. A suspended user stays suspended even if they try to sign in again.

Roles: users and admins

Every registered user of your app has one of two roles, user or admin, and the App Users list is where you change it. The role is the backbone of the most common serious-app pattern: pages only some people can open.

• Ask for the gate in role terms. "Add an admin page at /admin where I can see every booking; only admins can open it." The agent builds the page, the gate, and hides the navigation link from everyone else.
• The gate is real, not cosmetic. The role is checked on the server side of every admin action, so a curious user who guesses the address still gets refused; hiding the link is a courtesy, not the security.
• Promote from the list. New sign-ups start as ordinary users. Promote your own account first, then anyone who helps you run the app. A role change takes effect the next time that person's session refreshes, so tell them to sign out and back in if they do not see the new pages immediately.
• Test it like data privacy. Two accounts, one of each role: check the admin can see the admin pages and, more importantly, that the ordinary user cannot.

An admin role in your app grants exactly what your app's admin pages do, nothing more; it is unrelated to roles in your Vaulter workspace, which govern who can build the app.

Changes apply immediately

Provider and access changes take effect on your published app right away, with no republish. Only changes to the app's code itself, like adding a sign-in page or a new protected screen, go live the next time you publish.

What you get

• A hosted sign-in portal, so you never build or secure a login system. See The sign-in portal.
• Per-user data privacy enforced in the database. See How data privacy works.
• A built-in profiles table, so your app can greet users by name from day one.

Choosing who can open the app

Configuring sign-in is separate from deciding whether your whole app requires it. That choice is the "Require sign-in to view" switch, covered in Public vs private apps.

Frequently asked

Do my users pay Vaulter anything?

No. Accounts for your app's users are part of the platform; your plan covers them up to its user limit (20 on Free, more on paid plans).

Can I make one of my users an admin?

Yes, promote them in Vault → Auth → App Users, then ask the agent for the pages that role should unlock. The "Roles: users and admins" section above has the recipe.

Can I try sign-in before publishing?

Yes. The preview runs your real auth, so create a test account and walk the flow there. Two test accounts is the recommended setup for checking data privacy too.

A user is having trouble signing in

Match their exact error message and walk the diagnosis in Debug sign-in problems.