User sign-in for your app

If your app has anything personal, like saved items, orders, bookings or a profile, the people using it need accounts. Buildliy can add sign-up and log-in to your app for you. You describe what you want in the chat, and the AI builds the pages and connects them to your app's own database. There's no separate service to set up and no keys to paste.

This page is about the people who use your app. Signing in to your own Buildliy account is covered in Create your account.

Add sign-in to your app

Ask for it in plain words. Say what people should be able to do once they're signed in.

Let people sign up and log in. Each member has their own saved recipes that only they can see.

Put the dashboard behind a login. Visitors who aren't signed in should see the sign-up page.

The AI adds sign-up and log-in pages, a way to log out, and the checks that keep each person's data to themselves. Your app's database is switched on at the same time if it wasn't already.

If you didn't ask for accounts but the AI works out that your app needs them, it may ask first with a card called Your app needs accounts and saved data. Click Set it up to add them, or Not yet to keep building with clearly labelled sample data.

What your users get

By default, apps on Buildliy hosting come with built-in email and password sign-in:

• Email and password. Passwords must be at least 8 characters. Each email address can only be registered once.
• Staying signed in. People stay signed in on that device for up to 30 days.
• Private passwords. Passwords are scrambled before they're saved, so nobody can read them, not even you.
• Accounts in your own database. Accounts are stored in your app's own database. In Manage → Database, passwords are hidden, and new accounts can only be created through your app itself.

The built-in sign-in doesn't send any emails. People aren't asked to confirm their email address, and there's no "Forgot password?" email. If you need those, see Social login and password reset below.

Keeping each person's data private

When your app has accounts, the AI links everything a person saves to their account, and your app's server code checks who is signed in before it reads or saves it. Visitors' browsers never reach the database directly.

In new apps on Buildliy hosting, the database enforces this too. Your app connects to it with a restricted login, and the database only shows each person their own rows, even if a page forgets to check who's signed in. The launch checklist shows this as Each person's data is locked by the database. If a table with people's own data isn't locked, you see Some people's data isn't locked to them, and you have to fix it before you can publish. You still see everyone's rows in Manage → Database.

In apps made earlier, the check lives only in your app's code, so it relies on every page doing it. The launch checklist reminds you of this with Each person's data is kept apart by your app's code, a suggestion that doesn't stop you from publishing. These apps keep working this way.

Some things are meant for everyone, like a menu, a product list or public profiles. Say so when you ask, and the AI makes that data visible to all visitors while keeping the rest private.

Anyone can browse the class schedule, but only signed-in members can book, and they only see their own bookings.

To check who can do what in your app, open the Workspace menu at the top right and choose Roles. It lists every type of user and what they're allowed to do, in plain English. Before you publish, a safety check also looks for pages and data links that show people's details to visitors who aren't signed in, or to every signed-in account. When it's sure it found one, you have to fix it before you can publish. If your plan says people sign in but the app has no sign-in yet, that blocks publishing too. See Launch checklist.

See who has signed up

Open the Manage tab and choose Users. This is about the people who use your app, not your Buildliy account.

• Sign-in shows how people sign in. Email + password is marked Always on.
• People who signed up lists everyone with an account, with their email address and the date they joined.

To remove someone, click the ... button next to them and choose Remove from app, then confirm. They can't sign in again, but if they're signed in on a device right now they may stay signed in there for up to 30 days. Anything they added to your app, like posts or orders, stays. Ask the AI if you want that removed too. Removing someone can't be undone.

Social login and password reset (beta)

In Manage → Users, the Social login & password reset switch (marked Beta) changes your app to a managed sign-in system. It adds Google and GitHub sign-in, sign-in links sent by email, and password-reset emails. Your users stay in your app's own database.

1. 1

   Build your app first

   The switch needs your app's database. If it isn't ready yet, you'll see "Your app's database isn't ready yet — build the app first, then try again."

2. 2

   Turn on the switch

   Open Manage → Users and turn on Social login & password reset.

3. 3

   Ask the AI to update your sign-in pages

   The switch doesn't change your app's pages by itself. Ask in chat, for example: "Update the sign-in pages to use social login and add a Forgot password link."

4. 4

   Test it, then publish again

   Try signing up and signing in in the preview. Publish again to put the new sign-in on your live site.

If you use your own backend

If you connected your own Supabase or Neon project in Manage → Backend, sign-in works a little differently:

• Your own Supabase. Your app uses Supabase's own sign-in. Supabase asks new users to click a link in a confirmation email before they can sign in, unless you turn that off in your Supabase dashboard (Authentication → Providers → Email). You see and manage your users in your Supabase dashboard.
• Your own Neon. Your app uses the same built-in email and password sign-in described above, with accounts stored in your Neon database.

See Use your own backend.

Related

• Database
• Send email
• Use your own backend
• Security and privacy