Owner access after a browser deploy

After you build in Generated Backend and deploy from Cloudflare Infrastructure, the very first deploy seeds your app's first administrator (user.role === "sysadmin"), a first organization they own, and a password. Cloudflare Infrastructure shows the email, a click-to-reveal password, and a normal link to your app's Account login:

https://<your-app>.<subdomain>.workers.dev/account/login

Sign in with that email and password. That's the whole setup. After sign-in, /cms/ opens on the organization membership the deploy also seeded — you are owner of the first org. That is the role hierarchy (owner / admin / member), not user.role. Start sets cms.access: "member" so the CMS uses that seat. user.role === "sysadmin" is the platform data-plane tier (one above appmanager); the CMS only falls back to it when you belong to no organization.

What you get

• Shown once. The plaintext password is returned to Start on the deploy that created the admin. Quickback stores the hash in your app's auth database, never the password. Copy it when you see it — a later refresh does not show it again.
• A first organization. The deploy also inserts an organization named after your Worker and seats the admin as owner, so org-scoped tables and the CMS tenant picker have somewhere to land. A routine redeploy does not create a second one. If the compiled config sets features.pinnedOrganizationId, that string is the organization id — the pin and the AUTH_DB row match, the CMS skips the tenant picker, and the seeded sysadmin is owner of that org (so create/update/delete in the CMS actually work). Without a pin the id is a random hex.
• Your app's login. After that reveal you sign in through your app's own auth — the same email + password login every other user of your app gets. If your app has the Account UI enabled, that's /account/login.
• A public URL, not a secret. The login link is an ordinary <a href="…/account/login">. It does not carry a token. Anyone can open the page; only the password signs you in.

The email is the verified address on your Quickback account — the same one you used to sign in to Start. It is written once, when the admin is created. The broker never changes the email afterwards.

Type it exactly as shown next to the password. Apps seeded before this keep whatever address they were given (owner@<app>.invalid on older deploys).

Signing up yourself doesn't make you an admin

/account/signup creates an ordinary user. It never sets role === "sysadmin", so that account can't open /cms/. The seeded admin is the only path to the first administrator.

No confirmation email is sent, either — apps built from Start default to email and password with verification off, because a workers.dev deploy has no verified sending domain. If you're waiting on a signup email, nothing is coming; use the credentials in Cloudflare Infrastructure.

Quickback is not your app's identity provider. The password reveal is a bootstrap window, not a login method: once you've signed in (or reset), your app has no runtime dependency on Quickback or the deploy broker for authentication.

Lost access

Deployed apps on workers.dev can't send password-reset email until the app has outbound email (a custom domain + a sending provider). Copy the password when Cloudflare Infrastructure first shows it. Once email works, Better Auth's own forgot-password flow can reach that inbox, because it is a real, verified address.

A routine redeploy does not re-surface credentials.

For CLI deploys

Browser deploys seed the admin automatically. Apps deployed with quickback deploy don't; create your admin through your own flow, or deploy once through Start to bootstrap. The generated /__quickback/claim route still exists for older apps and answers 404 unless a leftover QUICKBACK_CLAIM_KEY Worker secret is set — new deploys do not set it.