Sign-in and access
How administrators sign in, choose a platform, recover access and give other people access.
On this pageSign in as an administrator · Recover administrator login · Invite people and connect apps
Signing in
For the browser admin UI, open <API URL>/admin. Use the administrator login chosen during setup. On a new installation, follow the printed setup steps to create the first admin. No app or CLI sign-in is needed first.
Requires: login or token
void platform auth login opens a browser to sign in as an administrator.
This step connects to the API URL and signs in as an administrator.
void connect platform.example.com --no-login
void platform auth loginExample output: The connection is saved, then a browser sign-in opens.
The first command saves the connection. The second opens a browser sign-in and saves the session in your keychain. Sessions last one hour, per platform.
This step shows which account is signed in.
void platform auth statusExample output: Your account, session expiry and the platform's features.
This shows your account, the session's expiry, and the features available on the platform. To end the session, run void platform auth logout.
If Cloudflare Access protects the platform, void connect <url> handles the company sign-in first. It uses a local cloudflared and saves a short-lived credential in your keychain for that origin. You never copy browser cookies.
For CI, use a project deploy token alongside your Access credentials in origin-keyed VOID_ACCESS_CREDENTIALS. An Access service token does not authorize an SDK deployment. See CI deployment setup for the required origins and shape.
Choosing a platform
This step lists your connections and picks a default, if you manage several platforms.
void platform list
void platform use <connection-id>Example output: Your saved connections, then a confirmation of the new default.
This step targets a platform for one command with --connection.
void platform user list --connection <connection-id>Example output: The users on the selected platform.
Use an ID or URL from the connection list. Administrative commands use this selection even when you run them inside an app with a different deployment destination.
Recovering administrator login
If no administrator can use the identity provider, the installation owner can recover one. This needs Cloudflare management access, database access and the original encrypted recovery credentials.
void platform config auth recover company --installation <id> --file recovery.jsonExample output: A login test, then a prompt to confirm the identity before access is restored.
The file identifies the existing account, for example {"administratorUserId":"existing-admin-id"}. Recovery runs a real login test and asks you to confirm the identity. It does not create a new administrator. To use a replacement provider, include its nonsecret configuration with a new connection ID and supply the secret through --client-secret-env <name>. To rotate an existing provider's secret, keep its connection ID and identity configuration.
For --yes, also pin expectedIdentity with the exact issuer and subject in the file. A successful browser login is still required. Use --plan to preview the affected administrator and connection before starting recovery.
Giving people access
Open Settings in the administrator UI, or run void platform config auth, to add, test, enable, or disable login methods. Access protection and login methods are separate settings. A provider test shows the authenticated account before you explicitly link it or enable the configuration.
This step changes the company gate after installation. Run it on the installing workstation with its saved recovery credentials.
void platform config auth protection show
void platform config auth protection enable --installation <id>Example output: The current protection state, then the enable flow and its checks.
void platform config auth protection disable --installation <id>Example output: A summary of the change and a confirmation prompt.
Enabling offers application creation or connection to an existing application. It checks every API, proxy, and configured dashboard origin and requires a company user sign-in. Changing protection ends all human sessions. Sign in again afterwards. Before removing a gate used for company signup, select another verified company rule or restricted signup. Removing protection retains the Cloudflare applications for deliberate cleanup. Disabling an Access login method does not remove the gate.
Users can add another enabled login to their existing account with void account link <connection-id> or Account in the optional dashboard. Sign in again first if prompted, then authenticate with the additional provider and confirm the identity shown. Matching email addresses alone do not link accounts.
In the admin dashboard, open People → Access to choose who can join, invite people, and manage individual signup grants. Choose Company-approved or individually approved users to create accounts automatically for people who meet your configured company rules while still allowing explicit invitations and allowlist grants. Company protection at the platform edge still applies before anyone reaches a login page.
This step lets a GitHub teammate join. It adds their login to the allowlist, with invited or allowlisted signup selected.
void platform signup allow github teammateExample output: The change and a confirmation prompt.
The SDK shows the change and asks you to confirm it. The teammate can then run void connect with the platform's URL and sign in.
This step allows an email address or a whole email domain.
void platform signup allow email teammate@example.com
void platform signup allow email '*@example.com'Example output: Each change and a confirmation prompt.
Email patterns apply across the platform's sign-in providers. Quote a domain pattern so your shell passes the * to the platform.
This step allows an OIDC identity without a verified email, by its login connection and provider subject.
void platform signup allow identity company-sso 'Employee-42'Example output: The change and a confirmation prompt.
Use the connection ID shown by void platform config auth list and the exact subject reported by your identity provider. The match is case-sensitive and does not infer an email address or link another account. Any domain or group restrictions configured for that login method still apply, and the account joins as an ordinary user. Remove the grant with void platform signup disallow identity company-sso 'Employee-42'.
This step invites someone by email.
void platform invitation send alex@example.orgExample output: The invitation and its delivery outcome.
An invitation grants signup access for that exact email address. The person must sign in with a login method that supplies the same verified email address. When platform email delivery is configured, the platform also sends connection instructions. If delivery is unavailable or fails, the grant still works: share the platform's /invite page or void connect '<platform URL>' command with the person yourself. The admin dashboard shows the delivery outcome separately from the invitation's pending, accepted, or revoked status.
This step shows the access settings and invitations.
void platform signup show
void platform invitation listExample output: The signup settings, then the invitation list.
Invitation history remains available after an involved account is removed. The stored actor ID remains visible when that account's login no longer exists.
void platform signup open allows anyone to sign up. Everyone who signs up can deploy apps on your application domain, so check how those apps share cookies before opening signup. Use void platform signup restrict to require an allowlist match again. Disallowing an entry affects future signup. It does not suspend existing accounts.
Connected apps
Register separate applications as OAuth clients through Connected apps. Users connect their identity and approve each publish on the platform.
