Who can see each page of your App

Per-page access, not all-or-nothing

Your published App can be open to everyone on some pages and restricted on others. A storefront's product pages stay public while its admin page requires sign-in; a members' area opens only for people in a group you named.

Each page opens for one of:

• Everyone — open to the public.
• Signed in — the visitor must be signed in to your App; no group is needed.
• Groups — the visitor must be signed in AND be in one of the groups you tick, such as Pro or Staff.
• Default — the page has no rule of its own and follows Other pages, the rule for the rest of your App.

Ticking several groups means any one of them opens the page. "Pro or Staff can see the reports" is one setting, not two rules stacked on top of each other.

Your App's pages

Open Manage › Pages to see a card for every page of your App: a picture of it, its name, its address, and one status — who may open it and, when getting in costs something, what: Everyone, Signed in, or the groups that open it, such as "Pro or Staff · $8.00 / month". A lock mark shows whether the building assistant is allowed to change the page.

Your front page — the page named index.html — is Home, and about.html is /about. The list also shows every page your App routes to in its own code, even one with no file of its own, so a page you gated is never hidden; its card says Routed by app, and its picture stays empty. In an App made with a framework, every card's picture stays empty, because its pages only take shape once the App is built. Pages come from your App's HTML files, so there is no "add a page" button here — ask the AI for a new page, or add the file in Develop › Code.

A card whose rule names a group your App no longer has says Unknown group with that group's ID, so you can fix the rule.

Set a page's access

1. Open Manage › Pages and press a page's settings icon (or its preview icon). The page's window opens.
2. In the window, the page runs on your private Draft at its own address, with your App's data and sign-in, exactly as a visitor will see it. Pick a Size, and step to the Previous page or Next page without closing the window.
3. Under Access, choose who it Opens for: Default, Everyone, Signed in or Groups. Default is tells you what the page would follow without a rule of its own.
4. Under Groups, tick each group that should open the page. Beside each group you see what it costs: a price, Free for your default group, or Hand-out for a group you give to people yourself. As the owner, the pencil beside a group opens its price.
5. Press Save. Everything you changed in the window is saved together.

A rule you change protects your Draft at once and reaches Live the next time you publish — Access says On publish · Live keeps its rule. Untick the last group and the page falls back: the window says Last one off · falls back to Default.

The same window holds the page's Builder lock — turn Locked on to keep the building assistant from changing that page — and its own Search title and description.

One page, every spelling of its address

A page answers at more than one spelling: /about, /about.html and /about/ all open about.html, and /docs/ opens docs/index.html. Its access setting covers every spelling alike, so a page you protect cannot be reached by typing its address a different way. A rule you (or the AI) wrote as /about.html shows on that page's one card.

Files in Assets under a rule

A picture, video or other file in your App's Assets answers at an address of its own — /assets/logo.png — so a rule on the page that shows it does not cover the file: a visitor who knows the address can open it even when the page is gated. The Other pages rule covers every asset along with every page, and a rule written for /assets/*, or for one file's address, covers just those. A file reached under a rule is sent to that visitor alone and never kept in a shared cache.

The "Other pages" card

The last card on Manage › Pages is Other pages. It sets what happens for any address in your App that has no rule of its own — every page left on Default, a page you add later, or one a visitor guesses at. It opens for Everyone, Signed in or Groups; it has no default of its own to follow.

Setting it is the difference between "the pages I remembered to protect are protected" and "my App is protected". Set it deliberately.

Turn on sign-in for your App

Before any page can require a visitor to be signed in, your App needs accounts. Open Manage › Users, press the settings icon on Sign-in, turn Required on, and press Save. Visitors then sign in to your App with an email and password. Sign-in is Free, and it lets your App know who each visitor is. While your App is live, a change to sign-in reaches it at once — the Sign-in container says Live at once; otherwise it says On publish.

Users works on your published App: until you publish once, its controls open Publish first.

People, beside it, is everyone who has signed up — when they Joined, their Last sign-in, how many Records they own and how many groups they hold. As the owner you can search it by email, send a Reset password, or open a person to change their groups or delete their account.

Sign-in applies to your Draft too. The editor's preview shows exactly what a visitor gets, so once sign-in is on you sign in inside the preview like anyone else — with an account you create in your App, or one from People. There is no owner shortcut around it, which is what makes the preview trustworthy: if you can see a page there, so can a signed-in visitor.

Sign-in belongs to your own App. On a copy of your App posted to Slop, and on a co-op's App, each visitor signs in with one press as a guest of their own — Continue as a guest — with no email or password, so every page they're let into opens for them. A posted App's guests join the groups its poster ticked when posting; a co-op's guests join every group. A guest account is deleted, with what it saved, 30 days after its last visit. Their Manage tab holds only Data, Money and Health — there are no pages, groups or people to set on them.

Sign in with Google or Apple

Your App's built-in sign-in also offers Continue with Google and Continue with Apple. Google and Apple don't let their sign-in run inside another page, so wherever your App is shown inside one — the editor's preview, the community, or someone else's site — those buttons open a small sign-in window, and your App is signed in when it closes. If that page doesn't allow windows to open, the sign-in says so and suggests opening your App in its own tab. In its own tab, your App goes to Google or Apple and comes straight back signed in.

Require a verified email for sign-in

When sign-in is Required, people can sign up with an email and password and start using your App right away — by default they do not have to confirm their email address first. A sign-up email is therefore not, on its own, proof that the person owns that address.

If that matters for your App, turn on Verified email, under When required in the Sign-in window. With it on, a new user must click the confirmation link sent to their email before they can sign in — so everyone who gets in has a working, confirmed address. Leave it off and anyone can sign in immediately with any email they type.

The confirmation link is sent automatically when the setting is on. People marks each person Verified or Unverified.

Limit what each person does a day

Under When required, Daily limit caps how many actions each signed-in person may run a day (Actions · each person · a day). Leave it empty for no limit of your own; the Platform limit Still applies either way. Alerts takes you to where you choose to be emailed when someone reaches it. The limit is in force the moment you save it.

Groups

A group is a kind of person your App has — Free, Pro, Staff. Groups need accounts, so with sign-in off Groups says Sign-in off. Once it is on, open Manage › Users and press New group under Groups, or a group's pencil to edit it. A group has a Name, an ID your App's code uses (fixed once the group exists), a Description, what it Includes, and its Limits. Every group you make becomes a choice in each page's window.

The first group you make is your Default group — the one everyone signed in starts in — and that is the group that describes what your App gives away free. To make another group the default, turn Default on in that group's window; a group with a price can't be the default. A group edit reaches Live when you next publish: the window says On publish · Live keeps its rules.

What a group costs is set in Manage › Payments, not here; Groups shows each group's price, or Hand-out for a group you give to people yourself.

Who is in a group

There are two ways somebody ends up in a group, and they never interfere with each other:

• You put them there. Open Manage › Users → People, open the person, and turn the group on. Each switch saves at once.
• They bought it. If a group has a price, Payments sells it and puts the buyer in it automatically. A bought group shows Bought on the person and can't be switched off by hand — cancelling somebody's subscription is not something a user list should be able to do by accident.

Because the two are kept apart, giving somebody Pro for free and later cancelling a Pro subscription they also had does not take away what you gave them.

Everyone with an account holds your default group without you doing anything — it shows Everyone has it — which is why it can't be given or taken by hand.

Taking somebody out of a group takes effect on their very next page load. There is no waiting period and no need for them to sign out.

How it is enforced

Access is checked on the server, before your page is sent. A visitor without permission never receives the page.

What they get instead depends on why they were refused:

• Not signed in — they see your App's own sign-in, at the address they asked for. Signing in loads that page in place; nothing bounces them to another address and back. Someone who already has an account in your App is recognized without typing anything.
• Signed in, but not in the group — they see a short "you don't have access" page that names the groups which open it.

This matters because a check written inside a page can be skipped: anyone can view the page source or turn off scripts. Server-side means the restriction holds regardless.

Three consequences worth knowing:

• A restricted page is never cached or shared between visitors, so one person's view can never be served to somebody else.
• Your App must have sign-in turned on before a page can require it. With sign-in off, Signed in and Groups can't be picked, and the page window says Signed in and Groups · need sign-in.
• Turning sign-in on sets Other pages to Signed in for you, so an App with accounts is private by default rather than accidentally open. Turning sign-in off puts every page back to Everyone, because there would be nobody left who could get in.

Asking the AI to restrict a page

You can also just ask: "make the admin page only visible to the Staff group." The AI sets the same rule you would have set, and it shows on the page's card in Manage › Pages exactly as if you had done it yourself. There is no separate AI-only version of these settings.

The AI can create the group too — "add a Staff group and give it the settings page" writes both, and the group shows up in Manage › Users for you to edit. The one thing it cannot do is put a price on a group. Pricing is yours: the AI creates the kind of person, you decide what it costs.