Vaulter

Users and auth

Add sign-in to your app

Every app is born with accounts built in. Choose sign-in providers, control who can register, and manage your users.

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:

  • Open. Anyone can sign up. Right for consumer apps.
  • Invite only. Only people you invite from the App Users list can get in. Right for client portals and internal tools.
  • Domain restricted. Only emails on domains you allow, like @yourcompany.com. Right for company apps.

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.

Changes apply on republish

Provider and access changes affect your published app the next time you publish. When you change something that needs a republish, the Auth panel shows a banner reminding you, so your live app and your settings never silently drift apart.

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 one radio button, covered in Public vs private apps.