Keeping your app private
Who can open your app, and how that changes when you keep it.
Your app starts private. Access moves through four stages, and it only becomes "anyone" if you choose that.
| Stage | Who can open it | How |
|---|---|---|
| Just deployed | Nobody | Requests are rejected before the app runs |
| Link opened | One device | The first device to open the link holds the key |
| Kept | Named people | You claimed it by email and can invite others |
| Later | Those people, or anyone | You choose: invitations, or make it public (and private again) |
The link is the key
The link your AI prints ends in #k=.... That part is a one-time key. It works for 60 minutes and for one device. If it expires, ask your AI to deploy again for a new one. If someone else opened it first, the page says so and tells you to ask the owner for an invite.
Keeping the app
On the first open you are offered Keep this app. The page says when the app is deleted if nobody keeps it (7 days after the deploy). Enter your email, open the message we send on the same device, and press Keep this app on the page it opens. Your device's access becomes your access, the 7-day expiry is removed, and you can name the app, invite people and see it in your dashboard.
Chose "Not now"? The offer stays at https://<your app's address>/_platform/keep for the device that opened the link.
Inviting someone
From the app's Who can open it tab, or by asking your AI ("invite alex@example.com to the family app"). Invitations are by email only. The person opens the link in their email and presses Open the app. They sign in the same way on any other device.
Signing in to the app itself
Because the platform already knows who opened the door, your app does not need its own login screen. Your AI can remove any login library it added; the platform signs people in before the app runs.
When another app has to read it
A pass belongs to a person in a browser. A server has no browser, so a private app turns it away, even your own website asking your private CMS for its pages.
Give that server a key instead. Ask your AI to make one for the private app, or make it yourself: open the app in your dashboard, go to Who can open it, and choose Make a key. You see the key once, so copy it then. The server sends it with every request, in a header called x-uarpie-key, and the private app lets it in. Your app's own logins are not affected.
A new key starts working within a minute or two. Revoke it and it stops working within a minute or two as well, on every address the app has.
Files anyone can see
A public website often shows pictures and videos that live in a private app, such as the media in a CMS. Visitors' browsers load those files directly, and they have no pass.
So a private app can name up to five paths that anyone may read, for example /api/media/file/ for a Payload CMS's media, /uploads/ for Strapi or /media/ for Django. Everything else stays private, and nobody can change those files without a pass. Ask your AI to set them, or choose them yourself under Who can open it, in Files anyone can see. File names with spaces, commas or accents are fine. A file whose name contains % or ; still needs a pass.