Projects

SDK Reference

These commands link the current folder to a project, show its status and manage its team.

On this pageLink or switch projects · List your projects · Manage teammates

void project status [name]

Show deployments for the configured target.

• SDK targets show recent hosted deploys. [name] looks up a project by slug. Without it, the linked project is used.
• Cloudflare targets list Worker Versions, mark the active one and show the recorded migration count. A project name is not accepted, because the Worker name comes from cloudflare.name in void.config.ts.
• Owners and admins also see a warning if the platform cannot finish replacing the project's credentials.

void project link [name]

Links the current folder to an existing hosted SDK project by slug. Without a slug, you pick one from a list. The link is stored in .void/project.json. Direct Cloudflare apps use cloudflare.name in void.config.ts and need no link.

void project list

Lists all hosted projects you can access, with slug, role, type and URL. Shared projects are included. The role column tells them apart from projects you own. For a saved Cloudflare target, it shows the current Worker's versions instead, because there is no SDK project registry.

void project team

These commands manage access to a project hosted on an SDK platform. Commands that take a <user-id> or <invitation-id> use an ID from the list, invitations or pending output.

Requires: project access

These commands need you to be signed in to the platform with access to the project.

Now you will run void project team list and void project team invite.

void project team list [--project <slug>]
void project team invite <email> --role <reader|collaborator|admin> [--project <slug>]

Example output: the requested list or a confirmation.

Next, run void project team invitations and void project team role.

void project team invitations [--project <slug>]
void project team role <user-id> <reader|collaborator|admin> [--project <slug>]

Example output: the requested list or a confirmation.

Next, run void project team remove and void project team revoke.

void project team remove <user-id> [--project <slug>]
void project team revoke <invitation-id> [--project <slug>]

Example output: the requested list or a confirmation.

Next, run void project team leave and void project team pending.

void project team leave [--project <slug>]
void project team pending

Example output: the requested list or a confirmation.

Next, run void project team accept and void project team decline.

void project team accept <invitation-id>
void project team decline <invitation-id>

Example output: the requested list or a confirmation.

Project commands use --project, then VOID_PROJECT, then the linked project. Invitations only work for an email that already belongs to a user on that platform. They do not create accounts or grant signup access. Only the invited account can accept or decline. list shows the same credential warning as void project status.

Readers can view the project but cannot deploy. Collaborators can deploy and manage what deploys need. Project admins can also manage domains, email destinations, GitHub config and the team. Only the owner can delete the project. See Project Collaboration for the full role boundaries.

Project team commands do not work for projects deployed directly to Cloudflare.

The account commands pending, accept and decline use the active connection from void connect <url>. The current project's link and deploy target do not matter. VOID_API_URL wins if set. An unscoped VOID_TOKEN selects Void Cloud. These commands show their platform. Accepting an invitation leaves folder links as they are. To link the invited app, run void project link in an unlinked checkout of it.

void project zero-trust

These commands show or override protection for a project on an SDK platform.

Now you will run void project zero-trust status and void project zero-trust protect.

void project zero-trust status [--project <slug>]
void project zero-trust protect [--project <slug>]

Example output: the requested list or a confirmation.

Next, run void project zero-trust public and void project zero-trust reconcile.

void project zero-trust public [--project <slug>]
void project zero-trust reconcile [--project <slug>]

Example output: the requested list or a confirmation.

The project is chosen by --project, then VOID_PROJECT, then the linked project.

Readers can see the state. The owner or a project admin can protect the project, make it public or repair drift. public does not change the platform default for new projects. Deploys and rollbacks wait until a protection change finishes. If one is refused, the owner or a project admin can run void project zero-trust reconcile before you retry. These commands do not apply to direct Cloudflare deploys.

void project token <create|list|renew|revoke>

Manages revocable aud: deploy credentials for one SDK platform project. The credential can only call the endpoints that void deploy uses. It cannot reach operator, account, secret-writing or project-deletion routes, or other projects.

Step 1. Now you will create a token and list your tokens. Note the credential ID in the list.

void project token create --name github-actions --expires-in 30
void project token list

Example output: the token details or a confirmation. A new token is shown once.

Step 2. Use the credential ID from step 1 to renew or revoke a token.

void project token renew <credential-id> --expires-in 30
void project token revoke <credential-id>

Example output: the token details or a confirmation. A new token is shown once.

Pass --project <name> outside a linked project. Expiry is 1–90 days. Create and renew show the bearer value once. Replace the stored secret right after renewal, because the old credential is revoked in the same step. Deleting the project or suspending the owner also stops the token. Turning off a login method does not revoke these deploy credentials.

Store the printed VOID_TOKEN and VOID_API_URL in your CI secret manager. Never commit them. The Access pair gets through the perimeter. The scoped SDK credential only authorizes this project's deploy workflow.

On an Access-protected platform that uses prerendering or remote proxy bindings, store VOID_ACCESS_CREDENTIALS as a JSON secret keyed by origin. It must hold both exact HTTPS origins, even if both use the same service-token pair:

{
  "https://void-company-api.example.workers.dev": {
    "CF_ACCESS_CLIENT_ID": "<service-token client ID>",
    "CF_ACCESS_CLIENT_SECRET": "<service-token client secret>"
  },
  "https://void-company-proxy.example.workers.dev": {
    "CF_ACCESS_CLIENT_ID": "<service-token client ID>",
    "CF_ACCESS_CLIENT_SECRET": "<service-token client secret>"
  }
}

VOID_ACCESS_ORIGIN limits a pair to one origin. The API origin alone is not enough for a workflow that calls the proxy. Use different pairs in the two entries if your Access policies require it.

void project logs

void project logs [--level <level>] [--filter <text>] [--range <duration>] [--deployment <id>]

Shows runtime logs from the deployed target. Hosted SDK targets read stored log history. Cloudflare targets open a live tail for the Worker named in void.config.ts. They keep no log history.

Flag	Purpose	Default
--range <duration>	How far back to look. Format: <number><unit> (m/h/d). Max 7d.	1h
--level <level>	Filter by log level. One of error, warn, info, log, debug, all. error also includes uncaught exceptions, non-ok outcomes, and any 5xx response — even when the worker neither threw nor logged.	all
--filter <text>	Case-insensitive substring match against log message text and exception name/message — not a level filter. Shows the full request entry on any hit.	none
--deployment <id>	Filter logs to a specific deployment ID.	none

The output shows one line per request (HH:MM:SS METHOD URL STATUS). Console logs and exceptions appear indented below it. Errors and exceptions are red. Warnings are yellow.

Examples:

void project logs --level error --range 12h
void project logs --level error --filter websocket

Logs include top-level console.* calls and uncaught errors that Cloudflare Tail captures. An error you catch and only save to your database does not appear. Also log it with console.error() or logger.error() from void/log. On hosted SDK targets, pass the Error object to console.error(), as in console.error('Save failed:', error). The stack trace then shows under the log line. Logging only error.message shows no stack.

For errors that never reach your Worker, such as edge routing errors or static site requests, use void project requests --status 5xx.

On a direct Cloudflare target, --filter uses Cloudflare's live search. --deployment selects a Worker Version. --level error selects error invocations. Other console levels cannot be filtered, and --range does not select history. void project requests only works for hosted projects.

void project requests

void project requests [--status <filter>] [--range <duration>]

Shows request traffic for the linked project. This includes static assets and edge errors that Worker logs do not show.

Flag	Purpose	Default
--status <filter>	Filter by status: a class (2xx, 3xx, 4xx, 5xx) or an exact 3-digit code (e.g. 500).	none
--range <duration>	How far back to look. Format: <number><unit> (m/h/d). Max 7d.	1h

The output shows one line per request (HH:MM:SS METHOD STATUS TYPE DURATION). 5xx is red and 4xx is yellow. Request paths are not recorded, so you see status and type, not URLs. For per-URL detail on requests that reach your Worker, use void project logs.

Examples:

void project requests --status 5xx
void project requests --range 24h

void project rollback [deployId]

void project rollback [deployId]

Rolls back to an earlier deploy or Worker Version.

• Without [deployId], it shows a menu of kept deploys.
• If the target has fewer applied migrations than the current deploy, a warning lists the difference before you confirm.

On an SDK platform, pick a kept deploy. On Cloudflare, use a full Worker Version ID or a unique prefix. The SDK sends 100% of traffic to that version. If both versions have full trigger snapshots, it also restores the chosen version's schedules, queues, workflows, routes and custom domains. Otherwise, it keeps the current triggers and restores only the code. This also works for versions deployed outside the SDK.

Rollback does not undo database migrations. If older code may run against a newer schema, or migration data is missing, the SDK explains the risk and asks you to confirm.

void project cancel [deployId]

void project cancel [deployId]

Cancels an active deploy.

• Without [deployId], it targets the linked project's active deploy.
• With [deployId], it targets that deploy. The deploy must still be active.

The SDK asks for confirmation before it requests cancellation.

This command only works for hosted projects. Direct Cloudflare deploys run locally, so there is no remote build to cancel.

void project delete [name]

Permanently deletes a hosted SDK project and all its resources: databases, KV namespaces, R2 buckets and deploys. You must type the project slug to confirm. --force (-f) skips the prompt.

Without [name], it uses the linked project.

For direct Cloudflare targets, this command refuses to run. Inferred resources can be shared, so the SDK never removes them on its own. Check who owns them, then remove them with Cloudflare tools.

void project purge-cache

void project purge-cache [--project <name>]

Purges all cached pages for the linked project. The edge cache clears within seconds.

With --project, it purges that project's cache instead.

This command only works for hosted projects. For direct Cloudflare targets, redeploy or purge the ISR KV namespace yourself.

Next steps

NextDeploymentPreviousConnections and AuthenticationZoneAll SDK Reference pages