Make something private

Close an app with an invitation list or a single shared password. No account for your visitors, and no login screen for you to build.

Apps are public by default: anyone with the link can open them. When that isn't what you want — a client preview, an internal tool, a draft — you close it, one of two ways.

You don't build a login. There isn't one to build.

Which lock

	Invite people	Set a password
Who gets in	the addresses you name	anyone you give the password to
What they do	type a code you email them	type the password
You need	everyone's email address	nothing
You can see	who has opened it	nothing about who is looking
To remove one person	remove their address	change the password for everyone

Invitations are the stronger lock and the one worth having when the audience matters. A password is the lighter one, for when collecting five email addresses is more ceremony than the thing deserves.

Both close the app the same way: a visitor with nothing sees a small page instead of your content.

Inviting people

only let anna@client.com and me open this

or, for something already live:

make the pricing tool private, and invite the three people on my team

The first person you share it with flips the app to invite-only. Everyone else who has the link now meets a sign-in screen instead of your app.

They open the link

If they've never been here, they see a small page: "This app is private. Enter the email address it was shared with."

They type their email and get a code

Six digits, by email, valid once. Only invited addresses get anywhere. An address that isn't on the list is turned away.

They're in

Their browser stays signed in for a week, so it's a one-time interruption rather than a login they have to remember. No account is created and no password exists.

Invitees are emailed a link to the app when you share it, so in the common case they never see a cold sign-in screen at all.

Managing the list

What you want	What to say
See who can open it	"who has access to the client preview?"
Add someone	"give jonas@client.com access too"
Remove someone	"remove anna@client.com from that app"
Open it up to everyone	"make it public again"
Close it again	"make it invite-only again"

Your agent can also tell you who has actually opened it, which is a quietly useful thing to know before a client meeting.

Revoking is immediate

Removing someone takes effect at once, even if they were signed in a minute ago. Membership is re-checked on every request, not just at sign-in.

Setting a password

put a password on the staging site

Your agent will tell you the password. If you didn't pick one, it made one up:

Harbour Bookings is now PASSWORD PROTECTED.
The password is: k7mq-p2xr-9vft

That is the only time anyone sees it. agenthost keeps a hash of your password and nothing else, so it can't be read back to you afterwards, by us or by anyone who gets at our database. Keep it somewhere, or ask your agent to.

Visitors get one screen with one field, and once they've typed the password their browser stays unlocked for a week.

Changing it

change the password on the staging site to spring-launch-2026

Setting a new password replaces the old one everywhere at once. Anyone still holding the old one is locked out on their very next click, including people who have the app open right now. That is also what to do if you've simply lost it: there is nothing to recover, and a new one takes a second.

A password is one shared secret

It keeps your app off the open web and out of search results, and that is usually the whole job. What it can't do is tell you who is looking, or let you remove one person without disturbing everyone else. When either of those matters, invite people instead.

This is not the same as inviting someone to your account

Inviting someone to an app lets them open it and nothing else. Inviting someone to your organization (invite_user) hands them control of your projects, deploys and other apps. Be clear which one you're asking for — see Work with teammates.

Switching between them

Nothing is thrown away when you switch. Your invitation list survives a spell of password protection, and your password survives a spell of invite-only, so an app that goes public for a launch and closes again afterwards comes back to exactly what it had before.

An invite-only app with nobody on the list is reachable by nobody, including you. If that happens by accident, add yourself or make it public.

Under the hood

A proxy in front of your app forward-authenticates every request against agenthost. A visitor carrying a valid, signed cookie for that hostname passes straight through; anyone else is bounced to the right door for how the app is locked, and comes back with a one-use hand-off token that sets the cookie on your app's domain.

Nothing per-visit is stored: both the cookie and the hand-off token are HMAC-signed rather than recorded. What makes access revocable anyway is that the proof inside the cookie is re-checked on every request — the address against your invitation list, or a fingerprint of the password against the one currently set. That is why both un-inviting someone and changing a password take effect immediately. The cookie itself only bounds how long a visitor goes without proving themselves again (a week by default).

Rebuilding a container regenerates its proxy configuration, which would otherwise drop the gate and quietly leave a private app readable. agenthost re-applies the policy automatically when a private app comes back up after a deploy.

Tools: share_app, set_app_access, list_app_access, revoke_app_access.