Skip to content
Built with

Platform configuration ​

SDK Reference

You need an administrator session for these commands. See Platform Management for choosing a platform, previews and confirmation.

On this pageChange platform authentication settings · Configure plans · Preview a change before you apply it

void platform config plans opens an interactive plan menu with your admin session. Plans have stable IDs and editable names. You can copy a plan to add one and edit limits without a redeploy. You can archive a plan to stop new assignments, or remove it and name a replacement for its accounts. Commands that take a <plan-id> use an ID from show.

Requires: platform admin login

These commands need an admin session from void platform auth login. Automation uses VOID_OPERATOR_TOKEN from a secret store. Never put it in project files.

Now you will run void platform config plans show and void platform config plans add.

sh
void platform config plans show [plan-id]
void platform config plans add <plan-id> --copy <existing-id> --name "Team"

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config plans set and void platform config plans reset.

sh
void platform config plans set <plan-id> [--name "Team"] [--file plan.json]
void platform config plans reset <builtin-plan-id>

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config plans archive and void platform config plans restore.

sh
void platform config plans archive <plan-id>
void platform config plans restore <plan-id>

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config plans remove and void platform config plans default.

sh
void platform config plans remove <plan-id> [--replacement <plan-id>]
void platform config plans default <plan-id>

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config plans sync.

sh
void platform config plans sync

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Use --plan to preview changes and affected accounts. Scripted changes need --yes. Every command supports --connection <slug-or-url> and --json.

  • show reports the effective limits, default, assignments and pending account updates.
  • reset restores a built-in plan's original limits and build instance size.
  • Archived plans keep their accounts but get no new ones. Change the default before you archive it.
  • remove needs a replacement if the plan has accounts or is the default.
  • Changing the default only affects new accounts.

For add and set, --file reads a JSON object. It may hold name, limits, buildInstanceType and the boolean allowShortSlugs.

  • limits is a partial object of whole numbers, zero or more. 0 means the plan sets no limit.
  • Build timeouts stay capped at the platform maximum of 60 minutes. 0 uses that maximum.
  • Settings you leave out keep their current or copied values.
  • buildInstanceType is standard-3 or standard-4.
  • allowShortSlugs allows new project slugs of five characters or fewer. Existing URLs keep working.

Storage quotas cannot be edited. See Plans and Limits for supported limits and examples.

An apply checks the preview's revision and rejects changes made at the same time. Lower quotas can restrict accounts that are already above them. Usage history and billing periods are kept. The CLI keeps updating accounts until done. If an update fails or stalls, the config stays saved and the command exits with an error. Run sync --yes to continue before you edit plans again. If an outcome is uncertain, check show and operator events.

Authentication configuration ​

void platform config auth opens interactive setup. These commands use your admin session from void platform auth login. Later steps use the method ID (such as company) that you add in an earlier step.

Now you will run void platform config auth list and void platform config auth show company.

sh
void platform config auth list
void platform config auth show company

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config auth add google and void platform config auth add oidc.

sh
void platform config auth add google
void platform config auth add oidc --id company

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config auth add cloudflare-access and void platform config auth configure company.

sh
void platform config auth add cloudflare-access --id access
void platform config auth configure company

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config auth test company and void platform config auth link company.

sh
void platform config auth test company
void platform config auth link company

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config auth enable company and void platform config auth disable github.

sh
void platform config auth enable company
void platform config auth disable github

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config auth admission and void platform config auth protection show.

sh
void platform config auth admission
void platform config auth protection show

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config auth protection enable and void platform config auth protection disable.

sh
void platform config auth protection enable --installation <id>
void platform config auth protection disable --installation <id>

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

Next, run void platform config auth recover company.

sh
void platform config auth recover company --installation <id> --file recovery.json

Example output: the requested record, list, or a confirmation. Commands with --plan show the change without applying it.

The first time you configure an existing installation, run void platform config auth initialize. Then sign in again. Its current login methods and signup policy are kept.

Adding or editing a method saves a pending config. Enabling it checks the login in your browser first. Linking the verified identity to your account is a separate step.

Before you disable a method, make sure another linked method works. The last method cannot be disabled. Disabling revokes human sessions created through that method, including operator sessions. Scoped deploy tokens stay valid. A human login token used as VOID_TOKEN is still revoked.

Commands accept --connection <slug-or-url> and --json. Changes accept --plan or --yes.

For scripts, put non-secret fields in --file <path>. Pass the secret through an env variable named with --client-secret-env <name>. Never put the secret in the file. Leave the secret out when editing to keep the saved value. For enable or link in scripts, pass --test-id <id> from a finished test. test --json returns a browser URL, test ID and expiry without waiting.

admission chooses invited or allowlisted, company-approved or public signup. Company-approved signup creates normal accounts when a user passes a company rule. Pick an enabled, company-restricted OIDC or Google Workspace method, or an enabled Cloudflare Access gate. In scripts, admission --file <path> --yes reads a policy such as {"mode":"company","connections":["company"],"access":false}.

protection enable creates or connects Cloudflare Access applications, separate from login methods. Its --file takes the cloudflareAccess object described in installation setup. Protection changes need installation ownership, the saved recovery credentials and a human admin session. They revoke current human sessions. Before you remove protection, change any signup rule that depends on that gate. Cloudflare applications are kept so you can clean them up on purpose.

recover <connection-id> restores an existing admin when normal login does not work. Its file holds administratorUserId and optional non-secret provider configuration. With --yes, it also needs an expectedIdentity object with the exact issuer and subject. Recovery needs Cloudflare management and database authority, the original recovery keys and a passing browser provider test. Use --client-secret-env <name> for new or rotated credentials.

For automation, see operator authentication.

Next steps ​

implemented.stream AI