Upserting a Superuser Credential
Every new instance gets one platform-managed superuser: your account email plus a generated password. When that password is lost, or when the team needs a second login that survives a restore, upsert it — add the account when the email is new, update it when it exists. Other superusers on the instance are never touched.
The managed credential is stored on the platform record, so
pbc pocketbase info and the instance detail page keep showing it, and the
same email and password work through pbc admin login for everything
inside the instance.
Prerequisites
- A running instance (Deploying PocketBase)
- For the CLI path:
pbcinstalled and logged in (Installing the CLI)
Upsert the credential
Using the portal
- Open your project, go to the PocketBase tab, and click the instance
- Expand Advanced Configuration
- Under Admin Credentials, enter the email and a new password
- Click Save Credentials
The email field starts with the current managed email. The password needs at least 12 characters — the counter beside the field turns red outside the 12–20 range. Leave the password empty and nothing happens; saving needs a new password in it.
Using the CLI
pbc pocketbase superuser sync --email [email protected] --password 'new-password-here' --name my-app-db| Flag | What it does |
|---|---|
--email <email> |
Managed superuser email. Required — new emails are added, existing ones updated. |
--password <password> |
New password, at least 12 characters. Required. |
--name <instance> |
Which instance. Asked for when omitted and no pbc.json binding exists. |
Inside a directory with a pbc.json binding, drop the --name:
cd db && pbc pocketbase superuser sync --email [email protected] --password 'new-password-here'What the platform does for you
The sync runs against the live instance and, on success, updates the
stored credential in the same step — so the detail page, pbc pocketbase info, and the admin panel agree afterwards. Instances restored from a
backup skip the generated password entirely: their superusers come from
the backup, and this is how you rotate one of those without knowing the
old value.
The password is write-only after saving: the portal shows the email and asks for a new password each time, and the CLI never prints it back.