Operations

Build & Deploy

Day-to-day platform work: preview changes, follow logs, check health and script routine tasks.

On this pagePreview a change before applying it · Follow logs · Automate checks with scripts

Previewing changes

Requires: login or token

These commands need a signed-in administrator session.

Commands that change the platform show what they affect before asking to confirm. This step previews a change with --plan.

void platform user suspend <user-id> --reason "Investigating unexpected traffic" --plan

Example output: A preview of the planned changes. Nothing is applied yet.

The preview shows which account will be suspended and the effect on its projects. Run it again without --plan to confirm interactively. This step applies it with --yes.

void platform user suspend <user-id> --reason "Investigating unexpected traffic" --yes

Example output: The user suspended without a prompt.

Scripts must use --yes to apply these changes. The void platform auth session commands run directly and do not use --plan or --yes; changes under void platform config auth do use previews and confirmation. After a change, void platform system events shows the administrator, affected objects, and recorded outcome.

Changes take longer when an account owns many resources. Change requests allow five minutes by default. This step sets a different limit in seconds with --timeout.

void platform user delete <user-id> --timeout 600 --plan

Example output: A preview of the planned changes. Nothing is applied yet.

If a request times out or loses its connection, some work may already have finished. Check the affected objects and system events before retrying. The SDK reports partial results when it can and does not automatically repeat the change.

Following logs

This step finds a deployment ID, then follows its logs. Use the ID from the first command.

void platform deployment list --project <project-id>
void platform deployment logs <deployment-id> --since 10m --follow

Example output: The project's deployments, then a live log stream.

Runtime logs include application messages, exceptions, and HTTP status codes. Without --follow, the command reads a page of historical logs. Use --since to choose a duration, an ISO date, or a timestamp in milliseconds.

Logs can become available after a request finishes. Following checks a five-minute overlap to pick up delayed records without printing them again. Records delayed longer than that may need a later historical query.

This step follows build logs by build ID.

void platform build logs <build-id> --follow

Example output: A live build log stream.

Following waits for the final logs before stopping, including diagnostics written after the build's status changes. For a GitHub Actions build, the command gives you the URL of its logs.

Checking the platform

Health checks

This step shows recent activity, then checks the platform's services and database.

void platform system overview
void platform system health

Example output: A platform summary, then health checks.

Health checks use the services configured for the selected platform. An unhealthy result exits with a nonzero status, so the same command can be used in a script.

The dashboard’s System Status page refreshes health checks every 30 seconds and shows errors beside the affected service.

Use void platform upgrade, repair, disable, and enable to maintain your platform. See platform maintenance.

During an upgrade or rollback, the admin UI shows progress at /admin/status. See Follow upgrade and rollback progress.

For backups and restores, see Prepare for disaster recovery.

Using scripts

This step returns results as JSON for other programs.

void platform user list --page 1 --limit 50 --json
void platform system health --json

Example output: Users and health as JSON.

Results go to standard output. Command errors go to standard error as JSON and exit with a nonzero status. With --follow, each log response is a separate JSON line.

Operator tokens expire after one hour. In CI, mint a new one at the start of each job. Use a valid full API session from an active administrator. Choose the platform explicitly, inject the full session as VOID_TOKEN from your secret manager, and capture the exchange output directly into the protected job environment:

Run these four steps in the same terminal or CI job step. Later steps use variables exported by earlier ones.

1. Exchange the full session for an operator token. This step sets VOID_API_URL and reads VOID_TOKEN from your secret manager.

   export VOID_API_URL=https://platform.example.com
   VOID_OPERATOR_TOKEN="$(
     printf '%s' "$VOID_TOKEN" | void platform auth token --token-stdin
   )" || exit 1

   Example output: no output on success. The job exits if the exchange fails.

2. Export the operator token from step 1 and remove the full session.

   export VOID_OPERATOR_TOKEN
   unset VOID_TOKEN

   Example output: no output.

3. Check platform health. This step uses the operator token exported in step 2.

   void platform system health --json

   Example output: platform health as JSON.

4. Clear the operator token when you are done.

   unset VOID_OPERATOR_TOKEN

   Example output: no output.

Disable shell tracing for the exchange and do not write either token to logs or plaintext files. A full API login session expires after 30 days and can be revoked sooner; renew it through the normal authenticated login flow and update the protected CI secret. A job that runs longer than one hour must repeat the exchange while its full API session is still valid. An expired operator token cannot refresh itself, and the platform does not issue permanent service tokens for administrator automation.

auth login --token-stdin performs the same elevation and saves the one-hour operator token in the system keychain for interactive use. See operator authentication for the full command syntax.

Next steps

NextOverviewPreviousEmailZoneAll Build & Deploy pages