void 0.22.0 → 0.24.0

package/skills/void/docs/guide/platform/installation/credentials.md

@@ -8,15 +8,20 @@ Keep one password-manager entry for this platform. Paste the saved values into t
 
 ## Cloudflare API Tokens {#runtime-token-permissions}
 
-For a domain installation, create two custom tokens using Cloudflare's [API token setup](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/). Name them **Void Platform Management** and **Void Platform Runtime**. Scope them to your selected account and application zone.
+For a domain installation or Cloudflare Access setup, the installer guides you through creating separate management and runtime tokens using Cloudflare's [API token setup](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/). Its links preselect the permissions and suggest names based on your platform's display name. Scope the tokens to your selected account and, when using a domain, its zone, save them in your password manager, and paste them into the masked CLI prompts.
 
-For workers.dev testing with the default API hostname, browser login can authorize installation: you only need to create the runtime token and R2 credentials below. Skip the zone permissions until you add a domain.
+For workers.dev testing with the default API hostname, browser login can authorize
+infrastructure setup. Void also checks account-wide Access requirements; if the
+current credential cannot read them, the installer asks for a scoped Access token.
+Protected apps and public apps under Default-Deny need an ongoing app-management
+token, stored encrypted. Access setup requires a management token even on
+workers.dev. Skip zone permissions until you add a domain.
 
-Browser login does not grant AI Gateway access. A preview can therefore show **inspect ai-gateway**: Void verifies that resource with the runtime token after you confirm installation, before creating any resources. Include **Account → AI Gateway → Edit** on that token. Other infrastructure continues using your browser login, and a normal API-token installation keeps using its management token when that token already has access.
+Browser login does not grant AI Gateway access. Include **Account → AI Gateway → Edit** on the runtime token so Void can verify and create that resource.
 
 The management token lets your CLI install and maintain the platform. The runtime token is stored as a Worker secret so the platform can deploy apps after you close your terminal. They are separate credentials.
 
-The runtime-token link preselects all required account permissions, including Workers Tail, Hyperdrive, and AI Gateway when needed. Review them against the short summary beside the link before creating the token. If the form differs, use that summary to correct it. For a domain installation, also select the indicated zone. See [Cloudflare's token template documentation](https://developers.cloudflare.com/fundamentals/api/how-to/account-owned-token-template/).
+Compare each token's form with the permission checklist below, and select the indicated account and zone for a domain installation. The installer saves a management token entered at the prompt in this installation’s encrypted local checkpoint and reuses it on resume. Upgrades, repairs, and other lifecycle maintenance also use that saved management token. During installation, a rejected token can be replaced at the prompt. An explicit `CLOUDFLARE_API_TOKEN` or `CF_API_TOKEN` takes precedence. Keep your password-manager copy for maintenance or another machine; scripts supply it through `CLOUDFLARE_API_TOKEN`.
 
 ::: details Permissions to select for each token
 
@@ -39,6 +44,8 @@ Use the following permissions for the core platform. Cloudflare may label write
 | Zone    | Workers Routes     | Edit       | —                                       |
 | Zone    | Cache Purge        | —          | Purge                                   |
 
+When Void configures Access in the installation account, the initial management-token link also selects **Account → Access: Apps and Policies → Edit** and **Account → Access: Organizations, Identity Providers, and Groups → Read**. Protection adds **Account → Access: Service Tokens → Edit**. When the authentication configuration or saved setup selects existing applications, the link requests Read access instead of Edit. These permissions belong to the management token; the runtime token does not need them.
+
 The management token also needs **Zone Edit** with authority to create zones if you ask Void to create the zone. If it already exists, use the selected zone with Zone Read and DNS Edit. Nested application domains additionally need **SSL and Certificates: Read** on the management token. A custom runtime that enables custom project domains needs **SSL and Certificates: Edit** on the runtime token; the core runtime does not enable that feature.
 
 Void checks access before provisioning. If it reports a missing permission, update the token's permissions for the selected account or zone and retry.
@@ -57,13 +64,15 @@ void platform upgrade your-installation-id
 
 Set the same two variables before `void platform install` to enable email during a new installation. Void records the pair for later upgrades; an ordinary upgrade cannot replace it.
 
+Before installing, enable [Cloudflare Email Routing](https://developers.cloudflare.com/email-service/get-started/route-emails/) for the exact shared sender domain and confirm that its MX records point to Cloudflare. For a subdomain, add that name under the zone's **Email Routing → Settings → Subdomains**. Cloudflare adds the required MX and SPF records. The installer's shared-mail bootstrap verifies those records; it does not add them. Keep existing mail-provider records on other domain names in place.
+
 Enabling email lets administrators [register email domains for projects](/guide/platform/administration/email#registering-email-domains-for-projects) and lets projects register destination addresses through the runtime token. That needs **Email Routing Addresses: Edit** and **Email Sending: Edit** on the account, plus **Zone: Read**, **Zone Settings: Edit** and **Email Routing Rules: Edit** on the zones that will carry mail. The runtime-token link preselects them when email is enabled. Email Sending onboarding for arbitrary recipients needs Workers Paid.
 
-The installer deploys the email gateway, prepares the shared mail route, and verifies inbound readiness before opening platform traffic. If setup fails, correct the reported permission, mail-zone configuration, or routing conflict, then rerun the same install or upgrade command. A fresh install resumes with `void platform install --resume --name <installation-id>`.
+The installer deploys the email gateway, prepares the shared mail route, and verifies inbound readiness before opening platform traffic. If setup fails, correct the reported permission, exact-domain MX records, or routing conflict, then rerun the same install or upgrade command. A fresh install resumes with `void platform install --resume --name <installation-id>`; it continues the recorded email operation after the configuration is corrected.
 
 ## R2 Upload Credentials
 
-The installer opens the **R2 token creation** form directly, requesting an account token (or a user token if your role cannot create account tokens). Select **Object Read & Write**—the form starts with read-only access—and keep **Apply to all buckets in this account (including newly created buckets)** selected. This lets the token access the buckets Void creates afterward. Create the token and save its **Access Key ID** and **Secret Access Key**. These are different from the management/runtime tokens above. See [R2's token instructions](https://developers.cloudflare.com/r2/api/tokens/).
+In the **R2 token creation** form opened by the installer, select **Object Read & Write** and **Apply to all buckets in this account (including newly created buckets)**. Create an account token, or a user token if your role requires it. Save its **Access Key ID** and **Secret Access Key** in your password manager. These differ from the management and runtime API tokens. See [R2’s token instructions](https://developers.cloudflare.com/r2/api/tokens/).
 
 ## Signing and Encryption Keys {#signing-and-encryption-keys}
 

package/skills/void/docs/guide/platform/installation/domains.md

@@ -19,13 +19,15 @@ If nameservers, certificates, or project Zero Trust protection are pending, foll
 
 Use `--installation <id>` to select an installation explicitly, `--zone example.com` for an app domain such as `apps.example.com`, or `--dedicated-zone` for catch-all routing on a dedicated zone. Nested domains still need the wildcard certificate described below. This command adds the first domain; replacing an existing application domain is not currently supported. It uses the installed runtime and does not require `--runtime` or an app redeploy.
 
+Choose an application domain whose wildcard leaves existing Worker Custom Domains reachable. Existing more-specific routes covering all requests can preserve those hostnames. If Void reports a conflict, choose another application domain; for a new installation, you can start with `void platform install --workers-dev` and add a suitable domain later.
+
 Browser login sessions are specific to each origin. Apps using their own OAuth providers may need to register their new callback URLs. Void's built-in auth uses the request origin automatically unless the app overrides that configuration.
 
 ### What Changes in Testing Mode?
 
-Each deployed app gets a small forwarding Worker and its own `workers.dev` origin. It forwards requests, including WebSockets and SSE, through the same platform router. Names include installation and project IDs; a later project with the same slug cannot inherit a deleted project's test URL.
+In testing mode, each app gets a `workers.dev` URL. These URLs continue working after you add a domain; new apps then use the domain.
 
-Testing origins use shared ISR storage but bypass the extra edge response cache because you cannot use your zone's purge API for `workers.dev`. Custom-domain requests use the normal edge cache after activation. Existing test URLs and forwarding Workers are retained when you add a domain; new apps then use the domain without creating more forwarding Workers. Like other platform Workers, forwarders are retained for manual cleanup on uninstall; platform disablement and project suspension still apply to their traffic.
+Testing URLs support WebSockets, SSE, and shared ISR storage, but skip the extra edge response cache. Their forwarding Workers remain for manual cleanup after uninstall. Platform disablement and project suspension still block their traffic.
 
 ## Other Domain Options
 
@@ -49,6 +51,37 @@ The management token needs **SSL and Certificates: Read** (or Edit) on that zone
 
 :::
 
+## Optional Dashboard
+
+The API's `/admin/` pages are included in the core installation. You can deploy
+the optional user dashboard separately and configure its HTTPS origin during
+installation with `--dashboard-url https://dash.example.com`.
+
+For an existing installation, preview and apply the configuration with:
+
+```sh
+void platform repair <installation-id> --dashboard-url https://dash.example.com --plan
+void platform repair <installation-id> --dashboard-url https://dash.example.com --yes
+```
+
+The origin must contain no credentials, path, query, or fragment. Void saves it
+for login callbacks and keeps it across upgrades and repairs. The command does
+not create a dashboard Worker or DNS records. Follow the source app’s
+[standalone dashboard preparation](https://github.com/voidzero-dev/void/tree/main/platform/packages/dashboard#standalone-deployment)
+to deploy your own copy with an unused Worker name, your dashboard hostname,
+and the installed API Worker’s service binding. Set its `API_URL` to the public
+API origin, `DASHBOARD_URL` to the dashboard origin, and `SITE_DOMAIN` to the
+installation’s application domain. Omit the option to keep the saved origin.
+The dashboard provides sign-in, linked login methods, and sign-out; use the CLI
+for user project and team management.
+
+If Access protects the platform, its application must cover this dashboard
+origin too. Configure the origin when installing protection. To change it on an
+already protected platform, deliberately remove protection through authentication
+configuration, apply the origin, then enable protection again. Choose a separate
+admission rule first if signup depends on the Access gate. Maintenance stops if
+the configured origin is outside the active coverage.
+
 ## Cloudflare footprint
 
 New platform resources use deterministic `void-<installation-name>-<role>` names where Cloudflare allows them, such as `void-team-api`. Choose an unused installation name in the account; Void stops on an unowned name conflict instead of replacing that resource. Existing installations keep their recorded names, including older names with suffixes.

package/skills/void/docs/guide/platform/installation/first-deployment.md

@@ -21,6 +21,8 @@ void deploy --platform void --project my-first-app
 
 `void connect` validates the platform and signs you in when needed. Confirm project creation when deploy asks. To use a project that already exists, run `void project link` instead. An app already linked to another platform keeps its existing destination; use a fresh app directory for your first test.
 
+Once accepted by the platform, a deployment continues independently of the CLI connection. The CLI reconnects automatically after a connection failure. Use `void project status` to inspect a deployment after closing the CLI, or `void project cancel` to request cancellation.
+
 The CLI stores login credentials in your system keychain, separately for each platform URL. With no URL, `void connect` offers Cloudflare or a Void platform; `void connect --platform void` offers saved platforms and an option to enter another URL.
 
 For CI, create a bounded, project-scoped deploy credential while signed in as
@@ -31,8 +33,8 @@ void project token create --name ci --expires-in 30
 ```
 
 Store the printed `VOID_TOKEN` and `VOID_API_URL` in the CI secret manager, then
-use `void connect <url> --no-login` in a fresh checkout if connection metadata
-is not committed. Rotate with `void project token renew <id>` and revoke with
+run `void connect "$VOID_API_URL" --no-login` before deploying in each fresh CI
+environment. Project files do not replace this connection step. Rotate with `void project token renew <id>` and revoke with
 `void project token revoke <id>`. A human login token is not a CI credential.
 
 If Cloudflare Access protects the platform, Access proof and the project

package/skills/void/docs/guide/platform/installation/maintenance.md

@@ -28,6 +28,13 @@ existing gate, verify that its service policy admits the installation token and
 that the application covers the printed API and proxy origins. A Cloudflare
 management API token does not authenticate an Access-protected HTTP request.
 
+For automatic setup, resuming also creates or verifies an Access exception
+limited to `/health` on the reserved dispatch health hostname. Void still requires
+its private probe token on that endpoint; requests without it cannot reach an
+application. This lets installation check routing while employee protection and
+account-wide Default-Deny remain enabled. It does not bypass Access for an entire
+Worker or for deployed apps.
+
 For externally supplied credentials, set `VOID_ACCESS_CREDENTIALS` from your
 secret manager to an object keyed by each exact API/proxy origin, with
 `CF_ACCESS_CLIENT_ID` and `CF_ACCESS_CLIENT_SECRET` in each entry. Then rerun
@@ -35,6 +42,11 @@ secret manager to an object keyed by each exact API/proxy origin, with
 and stops if the gate still rejects its checks. Account-wide Default-Deny and
 deployed-application policies remain your responsibility.
 
+If **System Status** reports `proxy HTTP 302 (redirect)` on an older Access-protected
+installation, upgrade with `void platform upgrade <id>`. Current installations use
+a private connection for the dashboard's proxy health check. Keep the proxy's
+Access protection enabled.
+
 ### Expired administrator setup code
 
 Resume an unfinished installation with `void platform install --resume --name <id>`.
@@ -56,6 +68,8 @@ Repair recreates missing infrastructure that the installer owns. It does not res
 
 ### Upgrade the platform
 
+Keep the platform runtime current when updating the Void CLI. If a developer's CLI reports that project lookup requires an upgrade, upgrade the platform before retrying.
+
 Use the installed CLI's packaged runtime to upgrade:
 
 ```sh
@@ -80,7 +94,7 @@ Database migrations only move forward. Void checks compatibility before upgradin
 
 Upgrades automatically enable managed Sandboxes. The platform runtime token needs Account / Containers: Edit and Account / Cloudchamber: Edit, and the Cloudflare account must use Workers Paid before its first Sandbox application deploy. The upgrade itself does not probe Containers access, so platforms that do not deploy Sandbox applications need no additional plan or permissions.
 
-When upgrading from a release that used tenant-owned Sandbox containers, the upgrade may first ask you to finish the legacy cleanup. Follow the [`sandbox-drain` instructions](/reference/cli#operator-system), then rerun the upgrade. Administrator login remains available during that maintenance step.
+When upgrading from a release that used tenant-owned Sandbox containers, the upgrade may first ask you to finish the legacy cleanup. Follow the [`sandbox-drain` instructions](../../../reference/cli/platform-operations.md#operator-system), then rerun the upgrade. Administrator login remains available during that maintenance step.
 
 After a successful upgrade, you can restore a declared-compatible earlier runtime without reversing migrations:
 

package/skills/void/docs/guide/platform/installation/prerequisites.md

@@ -4,19 +4,25 @@ outline: deep
 
 # Prerequisites
 
-Start with a Cloudflare account you can administer, an account with your chosen login provider, and an empty hosted PostgreSQL database. GitHub is the default and is optional when another method is selected. A domain is recommended. If yours is not ready, choose **Use workers.dev for testing** during installation and [add a domain later](/guide/platform/installation/domains#adding-a-domain). The steps below explain how to get the credentials the installer asks for.
+To run a Void platform, you need:
+
+- A Cloudflare account with Workers for Platforms and R2 enabled.
+- An empty hosted PostgreSQL database.
+- An account with your chosen login provider: GitHub, Google, OIDC, or Cloudflare Access.
+- A domain for your apps, or `workers.dev` for testing. You can [add a domain later](/guide/platform/installation/domains#adding-a-domain).
 
 Void creates the Workers, storage, queues, routing, and database tables through the CLI.
 
-This setup has costs: Workers for Platforms requires a paid plan, and your database and Cloudflare usage have their own pricing. External PostgreSQL is required in either mode.
+Workers for Platforms requires a paid plan. Your database and Cloudflare usage are billed separately.
 
 ## Prepare Your Cloudflare Account and Domain
 
 In the [Cloudflare dashboard](https://dash.cloudflare.com/), select the account where you want the platform to live:
 
-1. Open **Workers for Platforms** and enable its plan. Review [Workers for Platforms pricing](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/platform/pricing/) before confirming.
-2. Open **R2 Object Storage** and complete its activation. Void creates the bucket later.
-3. For a domain installation, choose a domain you own, such as `example.app`. If you need one, register it with your preferred registrar. Use a spare domain's root: apps will be served at `my-app.example.app`. For workers.dev testing, skip this step and the DNS setup below.
+1. Open **Workers & Pages** once to let Cloudflare provision Workers for the account.
+2. Open **Workers for Platforms** and enable its plan. Review [Workers for Platforms pricing](https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/platform/pricing/) before confirming.
+3. Open **R2 Object Storage** and complete its activation. Void creates the bucket later.
+4. For a domain installation, choose a domain you own, such as `example.app`. If you need one, register it with your preferred registrar. Use a spare domain's root: apps will be served at `my-app.example.app`. For workers.dev testing, skip this step and the DNS setup below.
 
 If that domain is already in this Cloudflare account, use its existing zone. Otherwise, [add the domain to Cloudflare](https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/) and follow the nameserver instructions until the zone is active. A zone is Cloudflare's DNS configuration for a domain; creating one does not buy the domain.
 
@@ -31,15 +37,7 @@ pnpm add --global void
 void platform install --plan
 ```
 
-Void checks your saved Cloudflare login while you enter the installation name. If sign-in is needed, it opens your browser after you submit the name; press Ctrl+C to cancel. The plan command then asks for the account and basic configuration and shows the resources it would create. It does not require the database or runtime secrets and does not change Cloudflare resources.
-
-The installer first offers these choices, with the domain option selected:
-
-```text
-Where should your apps live?
-  Use a domain — recommended
-  Use workers.dev for testing — add a domain later
-```
+Sign in to Cloudflare when prompted, then choose an installation name and account. `--plan` previews the resources without changing them or requiring runtime secrets. Completed plans save your choices locally. Run `void platform install` again to select a saved plan; Void checks the current Cloudflare state before asking you to apply it.
 
 For a domain installation, use these answers. Testing mode skips the application domain, zone, and catch-all questions:
 
@@ -52,9 +50,9 @@ For a domain installation, use these answers. Testing mode skips the application
 | Optional custom API hostname            | Leave empty to use `workers.dev`                    |
 | Dedicate all unmatched traffic to Void? | Yes only if this whole zone belongs to the platform |
 
-Platform resources use your installation name: `team` creates names such as `void-team-api`, `void-team-proxy`, and `void-team-routing`, with no random suffix. Use a different installation name for another platform in the same account. If a required resource already exists and belongs to another installation, Void stops without overwriting it. Existing installations keep their recorded resource names.
+Choose an unused installation name in your account. For example, `team` creates resources such as `void-team-api` and `void-team-proxy`.
 
-The preview shows the actual resource names and login callback URL that installation will use with the same configuration. It also links directly to the runtime-token form and the account's R2 token page. When you select GitHub login, it links to GitHub OAuth registration. It does not open credential setup pages or save an installation draft; Cloudflare browser login still opens when needed.
+The preview lists the credentials you will need. Review [Credentials](/guide/platform/installation/credentials), then run the install command printed at the end. The guided installation provides setup links and the login callback when needed.
 
 You can select either path directly:
 
@@ -69,7 +67,7 @@ void platform install --workers-dev --plan
 
 Use an empty PostgreSQL database dedicated to this platform. It stores users, projects, and deployments; individual apps can still use D1. Void creates the tables and the Hyperdrive connection, but does not provision the PostgreSQL server.
 
-Void does not require a particular database provider. Use an existing PostgreSQL host or choose a service such as **PlanetScale Postgres**, **Neon**, **Supabase**, or others.
+Use any PostgreSQL provider that accepts connections from your computer and Cloudflare:
 
 1. Create a fresh database or project dedicated to the platform, with no existing application tables. Use a database role that can create and manage its tables and schemas.
 2. Open the provider's connection details and select the primary database. Use a direct connection or a session-mode pooler, not transaction pooling. The connection must work from both your computer and Cloudflare.
@@ -85,4 +83,12 @@ For a dedicated Supabase project, [disable the Data API](https://supabase.com/do
 
 Once installation claims the database, continue using that same database for resume and maintenance commands. Uninstall never deletes external PostgreSQL.
 
-During interactive installation, choose whether Void creates Hyperdrive or uses an existing configuration in your Cloudflare account. Select an existing configuration by name and confirm its database, host, port, runtime user, and disabled SQL result caching. If you need a new separately managed configuration, choose **Set up a separately managed Hyperdrive**; Void pauses and gives you setup instructions. Create it with any unused name, point it at the dedicated PostgreSQL database using a runtime user, and disable SQL result caching. See [Cloudflare's Hyperdrive setup guide](https://developers.cloudflare.com/hyperdrive/get-started/), or ask your organization's Hyperdrive administrator to create it. Rerun the installer and select it. Paste a database owner connection into the PostgreSQL URL prompt for installation and migrations. Void verifies the selected Hyperdrive against that database, records its identity for later maintenance, and leaves its configuration under your external manager's control. For unattended installation, supply the existing Hyperdrive ID, origin host, and runtime user through the environment variables in [Install from CI](/guide/platform/installation/ci).
+### Use an existing Hyperdrive
+
+The installer can create Hyperdrive for you or use one you manage separately. For an existing configuration:
+
+1. Point it at the dedicated platform database using a runtime user, and disable SQL result caching.
+2. Select it in the installer and review the database, host, port, and runtime user.
+3. Supply a database owner connection at the PostgreSQL URL prompt so Void can apply migrations.
+
+To create one first, choose **Set up a separately managed Hyperdrive** and follow the printed instructions or [Cloudflare’s setup guide](https://developers.cloudflare.com/hyperdrive/get-started/). Rerun the installer once it is ready. Void leaves its configuration under your control. For unattended setup, use the Hyperdrive variables in [Install from CI](/guide/platform/installation/ci).

package/skills/void/docs/guide/platform/installation/setup.md

@@ -4,13 +4,19 @@ outline: deep
 
 # Install and Configure Login
 
+Press Enter to accept a suggested zone or display name, or type to replace it. Enter your own installation name and application domain; examples such as `company` and `example.com` are placeholders.
+
 For workers.dev testing, start the interactive install and choose your login method below:
 
 ```sh
 void platform install --workers-dev
 ```
 
-For a domain installation, the management token is the one value the interactive installer needs in the shell. Browser login cannot create the application's DNS record. In Bash or zsh, read the token without displaying it or putting its value in command history:
+For a domain installation or Access setup, Void guides you to create a management API token and paste it into a masked prompt. Browser login can preview DNS, but cannot change it or configure Access. The token-creation link preselects the permissions for your choices; scope the token to your account and, when using a domain, its zone. No shell environment variable is needed for interactive installation.
+
+::: details Use an existing management token from the shell
+
+Set `CLOUDFLARE_API_TOKEN` to use an existing token instead of the prompt. In Bash or zsh, read it without displaying it or putting its value in command history:
 
 ```sh
 printf 'Cloudflare management API token: '
@@ -20,7 +26,7 @@ export CLOUDFLARE_API_TOKEN
 void platform install
 ```
 
-::: details PowerShell equivalent
+In PowerShell:
 
 ```powershell
 $env:CLOUDFLARE_API_TOKEN = [System.Net.NetworkCredential]::new('', (Read-Host 'Cloudflare management API token' -AsSecureString)).Password
@@ -29,14 +35,66 @@ void platform install
 
 :::
 
-After `--plan`, run the install command printed at the end of the preview. Void recalculates the plan and asks you to confirm it; choose the same login methods again if you selected them interactively. Void then saves a local setup draft and opens the runtime-token page when that token is missing. Paste the token into the masked prompt. As you continue, it opens GitHub and R2 at their respective steps. Each page has a short checklist and a clickable fallback link in the terminal. Values already supplied through the environment or saved setup are reused without opening their pages again.
+After reviewing `--plan`, run `void platform install` and select your saved plan, or run the command printed under **Next, run this command to install the platform**. Both carry your choices into installation and check the current Cloudflare state. Review the refreshed plan. At **Apply this plan?**, **Yes** is selected; press Enter to continue to the credential prompts, or choose **No** to stop. Void opens the relevant setup pages and provides fallback links in the terminal. It reuses values you have already supplied.
+
+Saved plans contain your installation choices, including paths to any authentication configuration or custom runtime. They contain no secrets or approval to install. Declining the plan or cancelling management-token setup keeps those choices for your next attempt.
 
 ## Choose login methods
 
-The installer offers GitHub, Google, generic OIDC, and Cloudflare Access login.
+The installer offers GitHub, Google, generic OIDC, and Cloudflare Access login. Select all methods you want to enable; none are selected initially.
 Cloudflare Access protection is a separate choice from Access login. The
 GitHub OAuth steps below apply when you select GitHub login.
 
+## Choose who can access apps
+
+The installer asks **Who should be able to access deployed apps?**
+
+- **Same people allowed by the platform’s Access policy** reuses your selected company identities and policies. This is recommended when platform Access protection is enabled.
+- **Anyone — public apps** allows public visits.
+- **Choose a different Access policy** selects separate company rules for apps. Without platform protection, this option is **Set up Cloudflare Access protection**.
+
+The plan shows the default app access. Void finishes and verifies app access before
+opening application traffic; new projects inherit the selected default automatically.
+If setup stops, use the printed resume command. Existing installations retain their
+administrator settings during upgrades.
+
+App protection uses the account hosting your platform. If platform login or
+protection uses another account, select equivalent identity providers and policies
+in the hosting account when prompted. Use the app domain’s apex or a workers.dev
+hostname for the API so it stays outside the app wildcard.
+
+Void checks account-wide Default-Deny during setup. For public apps in an account
+that requires Access rules, it creates rules for each app and its verified custom
+domains. Other subdomains keep their existing access rules. It leaves account-wide
+Default-Deny enabled and does not bypass the platform API or proxy.
+
+App rules need **Access: Apps and Policies Edit** and **Organizations, Identity
+Providers, and Groups Read**. Void stores this management token encrypted for future
+apps and domain changes. The installer asks before retaining a setup-only token for
+that purpose, or guides you to create a dedicated token. Public apps without
+Default-Deny need no ongoing Access-management credential.
+
+For scripts, use `--app-access public|platform|custom`. Supply
+`VOID_PLATFORM_APP_ACCESS_TOKEN` when app rules are needed, or add an `appAccess`
+section to your `--auth-config` file:
+
+```json
+{
+  "appAccess": {
+    "mode": "custom",
+    "identityProviderIds": ["hosting-account-identity-provider-id"],
+    "policyIds": ["hosting-account-company-policy-id"],
+    "tokenEnv": "APP_ACCESS_API_TOKEN"
+  }
+}
+```
+
+Keep the file’s existing `connections` configuration. For `mode: "platform"`,
+same-account identity and policy selections are reused. Headless setup requires an
+explicit app-management token; it never silently retains an installer-only token.
+
+## Finish login configuration
+
 For Google, create an OAuth client and register the printed callback URL. You
 can restrict it to named Google Workspace domains. For OIDC or Access login,
 provide the issuer URL, client ID, and client secret. Select **Company-approved
@@ -86,6 +144,10 @@ with GitHub or another login method. With company-approved signup, a colleague
 who passes the company gate can create an ordinary account using GitHub even
 when their GitHub email differs from their company email.
 
+Your identity provider determines how employees sign in, such as through Okta or
+Google Workspace. Your Access policies determine who can reach the platform and
+which MFA or device requirements apply.
+
 Automatic setup uses an existing Zero Trust organization, selected identity
 providers, and existing company policies. Void creates dedicated applications
 and a scoped service token for protected installation checks. It preserves your
@@ -94,9 +156,13 @@ company policies, including device and MFA requirements.
 The setup credential needs **Access: Apps and Policies Write** and
 **Access: Organizations, Identity Providers, and Groups Read** in the identity
 account. Creating protection also needs **Access: Service Tokens Write**.
-Provide a separate setup token through `VOID_PLATFORM_ACCESS_SETUP_TOKEN` if
-your Cloudflare management credential lacks these permissions. These permissions
-are not required by the platform's runtime token. See Cloudflare's
+For setup in the installation account, the initial management-token link includes
+these permissions. Void checks Access reads before provisioning and reuses that
+management token during Access setup, so you do not need a second API token.
+For applications in another account, provide a token scoped to that identity
+account when asked. Scripts can supply an explicit override through
+`VOID_PLATFORM_ACCESS_SETUP_TOKEN`. The platform's runtime token does not need
+Access management permissions. See Cloudflare's
 [Access API](https://developers.cloudflare.com/api/resources/zero_trust/subresources/access/subresources/applications/)
 and [service-token permissions](https://developers.cloudflare.com/api/resources/zero_trust/subresources/access/subresources/service_tokens/methods/create/).
 
@@ -117,7 +183,9 @@ Keep the file's `connections` list from the example above, or use a connection
 with `{"id":"access","kind":"cloudflare-access","label":"Company Access"}`
 to create Access login as well. Omit `protection` for login-only setup.
 
-To connect applications managed elsewhere, select **Connect existing applications**.
+To connect applications managed elsewhere, select **Use Access applications your company already manages**.
+Enter the account that owns the Access applications; it can differ from the
+account hosting Void.
 Scripts use `mode: "existing"`, optional `accountId`, and `loginApplicationId`
 and/or `protectionApplicationId`. For login, set `loginClientSecretEnv`. For
 protection, supply `serviceToken` with `id`, `clientIdEnv`, and `clientSecretEnv`
@@ -131,7 +199,9 @@ ID, and secret, without a `cloudflareAccess` block or Cloudflare management toke
 Follow Cloudflare's [OIDC application guide](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/saas-apps/generic-oidc-saas/)
 and register the exact callback printed by Void.
 
-For the default GitHub-only setup:
+### GitHub
+
+For GitHub login:
 
 1. The installer opens [GitHub's new OAuth App form](https://github.com/settings/applications/new) when it needs OAuth credentials. Sign in as the account that will own the login integration.
 2. Set **Application name** to your platform's display name and **Homepage URL** to the API URL Void just printed.
@@ -140,11 +210,13 @@ For the default GitHub-only setup:
 
 This OAuth App handles sign-in.
 
-For the default GitHub-only setup, the prompts collect the runtime token, administrator GitHub username, PostgreSQL URL, GitHub client ID and secret, R2 credentials, and signing/encryption keys. Other login methods collect their configured provider credentials and use the one-time administrator setup code described above. Secret values are masked and setup progress is encrypted locally using the system keychain. Keep a password-manager copy for recovery on another machine.
+## Finish installation
+
+The installer collects your runtime token, PostgreSQL URL, login-provider credentials, R2 credentials, and signing and encryption keys. It masks secret values and saves setup progress encrypted through your system keychain. Keep a password-manager copy for recovery on another machine.
 
-Void shows installation progress while it prepares the database, provisions Cloudflare resources, deploys the services, and verifies platform health. Progress is checkpointed for recovery. When installation finishes, follow the printed administrator sign-in instructions and open the admin dashboard link. GitHub-only setup creates the first admin user when the selected GitHub account signs in; configurable setup uses the one-time `/setup` code and selected administrator login method. No app or CLI login is required. Void also prints the API URL to use when you [connect and deploy an app](/guide/platform/installation/first-deployment).
+Once installation finishes, open the printed admin dashboard link. For GitHub-only setup, sign in as the administrator selected during installation. For configurable login, use the one-time `/setup` code to confirm the administrator’s identity. Use the printed API URL to [connect and deploy an app](/guide/platform/installation/first-deployment).
 
-Remove the management token from the shell when finished:
+If you supplied a management token through the shell, remove it when finished:
 
 ```sh
 unset CLOUDFLARE_API_TOKEN
@@ -160,9 +232,11 @@ If Void created a zone, it stops in `waiting-for-dns` and prints nameservers. Se
 void platform install --resume --name <installation-id>
 ```
 
-Keep the management token available for any remaining DNS changes. When using a source build, also pass the same `--runtime` directory. Resume uses the saved checkpoint and original secrets; do not start a second installation or generate replacement keys. If setup failed before a checkpoint was saved, rerun the original command.
+Resume reuses the saved management token and asks for one if it is missing or rejected by Cloudflare. You can override it through `CLOUDFLARE_API_TOKEN`. When using a source build, also pass the same `--runtime` directory. Resume uses the saved checkpoint and original secrets; do not start a second installation or generate replacement keys. If setup stopped before a checkpoint was saved, rerun `void platform install` and select your saved plan, or rerun the original command.
+
+You can also rerun `void platform install` and choose **Continue setup** for an unfinished installation. For non-interactive recovery, use `--resume --name <id>`. Manage completed platforms with `platform status`, `repair`, or `upgrade`.
 
-If setup stops or fails, rerun `void platform install`. It lists unfinished installations, including those that reached provisioning, and offers **Continue setup** or **Start a new platform install**. Entering an existing unfinished name also asks whether to resume it; declining lets you enter another name. Continuing restores your saved answers and checkpoints. Starting new does not reuse or delete previous credentials or resources. `--resume --name <id>` continues directly and is required for non-interactive recovery. Read-only `--plan` runs do not save drafts. Completed platforms are managed with `platform status`, `repair`, or `upgrade`, not reinstalled.
+Resume restores your selected Hyperdrive. If that selection is missing from the saved checkpoint, add `--hyperdrive <existing-id>` when resuming, using the same configuration you originally selected.
 
 If Cloudflare rejects a saved runtime token during continued credential setup, Void opens the token page and asks for a replacement in the same run. Network or service failures do not discard saved tokens. Tokens supplied through the environment must be corrected there instead.
 

package/skills/void/docs/guide/platform-administration.md

@@ -12,6 +12,7 @@ The operator commands for users, projects, deployments, and system status requir
 
 - [Sign-in and Access](/guide/platform/administration/access)
 - [Users and Projects](/guide/platform/administration/projects)
+- [Plans and Limits](/guide/platform/administration/plans)
 - [Project Zero Trust](/guide/platform/administration/zero-trust)
 - [Email](/guide/platform/administration/email)
 - [Operations](/guide/platform/administration/operations)

package/skills/void/docs/guide/queues.md

@@ -8,13 +8,11 @@ Use queues to process work asynchronously, such as sending emails or handling up
 
 ## Defining queues
 
-Create files in `queues/**/*.ts`; `.mts`, `.js`, and `.mjs` also work. The queue name is inferred from its path, with nested path segments joined by `-`. For example, `queues/emails.ts` creates a queue named `"emails"`, and `queues/order/notifications.ts` creates `"order-notifications"`. A nested path must not normalize to the same name as another file: `queues/order/notifications.ts` and `queues/order-notifications.ts` conflict, so Void reports the collision and asks you to rename one.
+Create a consumer in `queues/`. TypeScript and JavaScript files are supported (`.ts`, `.mts`, `.js`, `.mjs`). Its path determines the queue name: `queues/emails.ts` creates `emails`, and `queues/order/notifications.ts` creates `order-notifications`. Each queue must have a unique name.
 
 The resulting name must follow Cloudflare's queue naming rules: 1–63 characters, only letters, digits, and `-`, beginning and ending with a letter or digit.
 
-If you previously used a nested queue locally, update producer calls from `queues['order/notifications']` to `queues['order-notifications']`. The derived binding remains `QUEUE_ORDER_NOTIFICATIONS`.
-
-Each queue file should export a default handler wrapped with [`defineQueue`](../reference/api.md#definequeue-t-handler). The generic `<T>` parameter defines the message body type. That is the type of each `msg.body` in the batch, and it is also used by the typed `queues` proxy for `send()` calls.
+Export a default handler wrapped with [`defineQueue<T>`](../reference/api/handlers.md#definequeue-t-handler). `T` defines the message body for both the consumer and calls to `send()`:
 
 ```ts
 // queues/emails.ts
@@ -56,8 +54,6 @@ export const POST = defineHandler(async (c) => {
 });
 ```
 
-The binding name is derived automatically: `QUEUE_` + queue name uppercased with non-alphanumeric characters replaced by `_`. For example, `queues/emails.ts` creates binding `QUEUE_EMAILS`, while `queues/order/notifications.ts` creates binding `QUEUE_ORDER_NOTIFICATIONS`.
-
 ## Per-message acknowledgment
 
 Each message in the batch has `ack()` and `retry()` methods matching the [Cloudflare Queues API](https://developers.cloudflare.com/queues/configuration/consumer-concurrency/):
@@ -111,12 +107,14 @@ export default defineQueue<Message>(async (batch, env) => {
 
 - `maxBatchSize`: maximum number of messages per batch (default `10`)
 - `maxBatchTimeout`: maximum seconds to wait before delivering an incomplete batch (default `5`)
-- `maxRetries`: maximum number of retries before a message is dead-lettered (default `3`)
+- `maxRetries`: maximum number of retries before delivery is exhausted (default `3`)
 - `retryDelay`: seconds to wait between retries (default `0`)
 
-## Deployment behavior
+Void-managed queues do not configure a dead-letter queue. Cloudflare permanently
+deletes messages that exhaust their retries without one; see
+[Cloudflare's dead-letter queue guide](https://developers.cloudflare.com/queues/configuration/dead-letter-queues/).
 
-On deploy, Void includes all discovered queues in the deploy manifest. The platform provisions Cloudflare Queues, configures producer bindings on the user worker, and registers the dispatch worker as the queue consumer for relay delivery.
+Void provisions queues and connects their producers and consumers when you deploy.
 
 ## Local development