void 1.4.0 → 1.6.0

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

@@ -8,7 +8,7 @@ Keep one password-manager entry for this platform. Paste the saved values into t
 
 | Credential                             | Created by                       | Why the platform needs it                                                                |
 | -------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------- |
-| Management API token                   | You, in Cloudflare               | Lets the CLI change DNS and Access for a domain installation or Access setup.            |
+| Management API token                   | You, in Cloudflare               | Lets the CLI create a zone, change DNS, and set up Access.                               |
 | Runtime API token                      | You, in Cloudflare               | Stored as a Worker secret so the platform can deploy apps after you close your terminal. |
 | PostgreSQL URL                         | You, with your database provider | Stores platform users, projects, and deployments.                                        |
 | Login provider client ID and secret    | You, or Void for Access login    | Signs people in to the platform.                                                         |
@@ -20,11 +20,13 @@ Keep one password-manager entry for this platform. Paste the saved values into t
 
 ## Cloudflare API Tokens {#runtime-token-permissions}
 
-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, but Cloudflare's form cannot preselect a zone: for a domain installation, change the zone policy from **All Domains** to **Specified Domains** and select your zone. If Void will create the zone, keep **All Domains** on both tokens: the zone does not exist yet, and the runtime token needs it to purge cache. Save the tokens in your password manager and paste them into the masked CLI prompts.
+For a domain installation or Cloudflare Access setup, the installer guides you through creating tokens using Cloudflare's [API token setup](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/): a runtime token, and a separate management token when the installation creates the zone or its wildcard DNS record, or sets up Access. Its links preselect the permissions and suggest names based on your platform's display name, but Cloudflare's form cannot preselect a zone: for a domain installation, change the zone policy from **All Domains** to **Specified Domains** and select your zone. If Void will create the zone, keep **All Domains** on both tokens: the zone does not exist yet, and the runtime token needs it to purge cache. Save the tokens 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
-infrastructure setup. Void also checks account-wide Access requirements; if the
-current credential cannot read them, the installer asks for a scoped Access token.
+infrastructure setup. So can a domain installation on an existing zone whose
+`*.<application domain>` record is already proxied. 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.
@@ -70,7 +72,7 @@ Void checks access before provisioning. If it reports a missing permission, upda
 
 Choose a shared sender domain and its Cloudflare zone ID. The mail zone may differ from the application zone, but it must belong to the platform's Cloudflare account.
 
-Before you enable email, 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.
+Before enabling platform email, configure [Cloudflare Email Routing](https://developers.cloudflare.com/email-service/get-started/route-emails/) for the shared sender domain. For a subdomain, add it under **Email Routing → Settings → Subdomains**. Let Cloudflare add the required MX and SPF records, then confirm that the domain's MX records point to Cloudflare.
 
 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. The runtime token needs these permissions:
 
@@ -86,7 +88,7 @@ The zone permissions must include each zone that will carry mail, including the
 
 For a new installation, set `VOID_EMAIL_SENDER_DOMAIN` and `VOID_EMAIL_SHARED_ZONE_ID` before `void platform install`. The runtime-token link then preselects these permissions.
 
-For an existing installation, add the permissions to its runtime token first. Edit the token in the Cloudflare dashboard. The token value stays the same. Or set `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN` to a new token that has all runtime permissions. Then run:
+For an existing installation, edit its runtime token's permissions in Cloudflare, or supply a replacement with `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN`. Then run:
 
 ```sh
 VOID_EMAIL_SENDER_DOMAIN=mail.example.com \
@@ -94,13 +96,13 @@ VOID_EMAIL_SHARED_ZONE_ID=your-zone-id \
 void platform upgrade your-installation-id
 ```
 
-Void records the domain and zone for later upgrades; an ordinary upgrade cannot replace them.
+Void saves this domain and zone for later upgrades. Choose them for the lifetime of the installation.
 
-Before the CLI changes anything or pauses traffic, it checks that the runtime token can read the mail zone and its Email Routing settings, rules, and addresses. If Cloudflare denies a request, the command stops and names each missing permission. Void keeps a saved runtime token, so you can add the permission to the same token and run the command again. The check cannot confirm Edit access or Email Sending, so select those permissions as the table shows.
+If setup reports a missing permission, add it to the runtime token and rerun the command. Select all permissions in the table, including Edit access and Email Sending.
 
-Without `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN`, `upgrade`, `repair`, `enable`, and `rollback` check the runtime token saved on this machine. The platform can use a newer token, for example one set from another machine. If Cloudflare does not accept the saved token, the CLI shows a warning and continues without the check. To check the token that the platform uses, set `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN` to it.
+When maintaining the platform from another machine, set `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN` to the current runtime token so the CLI checks its permissions.
 
-The installer deploys the email gateway, prepares the shared mail route, and verifies inbound readiness before opening platform traffic. If setup fails, fix the problem that the error names, for example a missing permission, the exact-domain MX records, or a routing conflict. Then run the same install or upgrade command again. A fresh install resumes with `void platform install --resume --name <installation-id>`; it continues the recorded email operation after the configuration is corrected.
+The installer configures the email gateway and shared mail route. If setup fails, fix the reported permission, DNS, or routing problem and rerun the command. Resume a fresh installation with `void platform install --resume --name <installation-id>`.
 
 ## R2 Upload Credentials
 

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

@@ -100,9 +100,9 @@ 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. Upgrade the platform before your team updates its CLI: a newer CLI refuses to work with an older platform and asks for `void platform upgrade`. Install the new CLI on the administrator's machine, run the upgrade below, then have the team update.
+Upgrade the platform before your team updates its CLI. Install the new CLI on the administrator's machine, run the upgrade below, then have the team update.
 
-If the platform will deploy apps that use `void/sandbox`, its runtime token needs **Account → Containers → Edit** and **Account → Cloudchamber → Edit**. A token made from an older setup link may lack them, and an upgrade does not add them. Edit the token in the Cloudflare dashboard, or set `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN` to a new token when you upgrade. See [Cloudflare API Tokens](/guide/platform/installation/credentials#runtime-token-permissions).
+For apps using `void/sandbox`, add **Account → Containers → Edit** and **Account → Cloudchamber → Edit** to the runtime token. Edit its permissions in Cloudflare, or supply a replacement with `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN`. See [Cloudflare API Tokens](/guide/platform/installation/credentials#runtime-token-permissions).
 
 Use the installed CLI's packaged runtime to upgrade:
 
@@ -115,11 +115,11 @@ An upgrade validates the runtime, applies supported pending migrations, deploys
 
 Before starting, Void checks access to the installation's Cloudflare account, Workers, and existing R2 buckets. If credentials are rejected, set `CLOUDFLARE_API_TOKEN` to a management token scoped to that account and retry. This overrides the installation's saved management token.
 
-Some upgrades pause application traffic during the cutover to the new version. Traffic resumes after the new version passes its health checks. If an upgrade or another lifecycle command fails after it paused traffic, traffic stays paused until a later run succeeds. To resume:
+Some upgrades pause application traffic until the new version passes health checks. If a command fails while traffic is paused:
 
 1. Run `void platform status <id>` to see the saved progress.
-2. Fix the problem that the error names.
-3. Run the resume command that the CLI printed. It is the same command, with the same runtime.
+2. Fix the reported problem.
+3. Run the printed resume command with the same runtime. Traffic resumes when it succeeds.
 
 ::: details Migration safety, credential rotation, and rollback
 
@@ -147,31 +147,28 @@ Let running rotations finish before you roll back. If an older proxy runs next t
 
 :::
 
-### Platform Workers changed outside Void {#workers-changed-outside-void}
-
-Void manages the platform's own Workers. Do not change them in the Cloudflare dashboard or with the Cloudflare API. To change the platform, use the Void commands on this page.
-
-`upgrade`, `repair`, `enable`, `rollback`, and `install --resume` deploy the platform Workers again. Before they change a platform Worker or pause traffic, Void finds each platform Worker that:
+### Change runtime logs {#runtime-logs}
 
-- was changed in the Cloudflare dashboard or with the Cloudflare API.
-- has an active version without a Void deployment record. This can occur when an earlier run replaced a change made outside Void, and then stopped or failed. If that run stopped during the cutover to the new version, the command first makes the earlier versions active again. Void checks those earlier versions too. A version that an older Void release deployed can also have no record.
+Switch an installed platform between [full and minimal runtime logs](/guide/platform/installation/setup#runtime-logs) with an upgrade:
 
-The `--plan` preview of `upgrade`, `repair`, `enable`, and `rollback` shows the same list as a warning.
+```sh
+void platform upgrade [id] --runtime-logs minimal
+void platform upgrade [id] --runtime-logs full
+```
 
-In a terminal, Void lists these Workers and asks **Replace the configuration of these Workers?** The default answer is No.
+Later upgrades keep the setting. The upgrade also changes Workers Logs on the projects' existing deployments. If that step fails, the upgrade still finishes and prints what to run next: `void platform repair [id]` after switching to minimal, or the same upgrade again after switching to full. Records stored before the change are not removed; they expire with Cloudflare's retention.
 
-- If you answer No, the command stops. No platform Worker changed, and the command did not pause traffic.
-- If you answer Yes, the command continues. First, Void prepares the platform resources and the database. Then, before it pauses traffic or deploys a Worker, the Cloudflare CLI asks you again for each Worker changed in the dashboard or with the API. For a dashboard change, it shows the differences. Void uploads a new version of each of these Workers and does not deploy it yet. For a Worker that has an active version without a Void deployment record, the Cloudflare CLI does not ask again.
+While runtime logs are minimal, `void platform rollback` refuses a runtime that does not support the setting. Run `void platform upgrade [id] --runtime-logs full` first.
 
-If you refuse in the Cloudflare CLI, the command stops. Void does not undo the resource and database changes. No deployment changed, and the command did not pause traffic.
+### Platform Workers changed outside Void {#workers-changed-outside-void}
 
-The replacement removes values that Void does not set, for example an `EMAIL_FROM` variable that you added. It also resets values that Void sets, for example `AUTH_REDIRECT_URI`.
+Use Void commands to manage the platform's Workers. If their configuration was changed in Cloudflare, or Void cannot identify the active version, maintenance asks you to approve replacing it. Preview the affected Workers with `--plan`.
 
-Without a terminal, for example in CI, or with `--yes`, the command stops before it changes a platform Worker, and it does not pause traffic. Run the command that Void prints once in a terminal, and answer the questions there. After that run completes, the command works in CI again.
+Run the printed command in a terminal and review **Replace the configuration of these Workers?** The default is No. Accepting restores Void's configuration, including removing manually added variables. You may see another confirmation with the configuration differences before deployment. Declining that later prompt leaves any resource and database preparation in place.
 
-If Void cannot read a platform Worker, the command also stops before it changes a platform Worker or pauses traffic. Run the command again. If a platform Worker has no single version that gets 100% of traffic, for example after a gradual deployment, deploy one version of it to 100% of traffic in the Cloudflare dashboard. Then run the command once in a terminal, so that you can approve the dashboard change.
+CI and `--yes` runs stop when this approval is needed. Complete the interactive command once, then resume automation. If a Worker uses a gradual deployment, first select one version for 100% of traffic in Cloudflare.
 
-If an earlier run failed after it paused traffic, traffic stays paused after these stops. To resume traffic, see [Upgrade the platform](#upgrade-the-platform).
+If traffic was already paused by an earlier failed run, follow [Upgrade the platform](#upgrade-the-platform) to resume it.
 
 ### Follow upgrade and rollback progress
 

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

@@ -37,7 +37,7 @@ If your account's dashboard has no **Enable** action, create a disposable Hello
 
 ## Install the CLI and Preview
 
-With Node.js 24.21.0 or later, install the CLI:
+With Node.js 24.22+ or 26.12+, install the CLI:
 
 ```sh
 pnpm add --global void

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

@@ -12,7 +12,7 @@ For workers.dev testing, start the interactive install and choose your login met
 void platform install --workers-dev
 ```
 
-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. When using an existing domain, change the zone policy from **All Domains** to **Specified Domains** and select your zone, as the CLI prompt describes. No shell environment variable is needed for interactive installation.
+When a domain installation creates the zone or its wildcard DNS record, or you set up Access, Void guides you to create a management API token and paste it into a masked prompt. Browser login can preview DNS and use an existing proxied `*.<application domain>` record, but cannot change DNS or configure Access. The token-creation link preselects the permissions for your choices. When using an existing domain, change the zone policy from **All Domains** to **Specified Domains** and select your zone, as the CLI prompt describes. No shell environment variable is needed for interactive installation.
 
 ::: details Use an existing management token from the shell
 
@@ -93,6 +93,25 @@ 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.
 
+## Choose what runtime logs record {#runtime-logs}
+
+By default, the platform records each request's URL, console output, and exception messages. Project owners see them with `void project logs`, and administrators with `void platform deployment logs`. They are kept in your Cloudflare account, in Workers Logs and in the platform's log history.
+
+If your apps can put personal data in URLs, logs, or error messages, install with minimal runtime logs:
+
+```sh
+void platform install --runtime-logs minimal
+```
+
+With minimal runtime logs:
+
+- Platform and project Workers do not send anything to Workers Logs.
+- Log history keeps each request's time, method, status, outcome, deployment, log levels, and exception names, but not its URL, log messages, or exception messages.
+- `--level` filters still work. `--filter` can match exception names, but not the messages that are no longer recorded.
+- Log views say that messages and URLs are not recorded on this platform.
+
+The setting covers the whole platform. To change it later, see [Change runtime logs](/guide/platform/installation/maintenance#runtime-logs).
+
 ## Finish login configuration
 
 For Google, create an OAuth client and register the printed callback URL. You
@@ -260,6 +279,8 @@ You can also rerun `void platform install` and choose **Continue setup** for an
 
 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. A missing [email permission](/guide/platform/installation/credentials#enable-email) does not discard the saved token: add the permission to the same token, then resume. Network or service failures do not discard saved tokens. Tokens supplied through the environment must be corrected there instead.
+If Cloudflare rejects a saved runtime token, Void opens the token page and asks for a replacement. For a missing [email permission](/guide/platform/installation/credentials#enable-email), update the existing token's permissions and resume. If you supplied a token through an environment variable, update that variable.
+
+To replace the runtime token, for example after revoking it, resume with the new token in `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN`. Void checks it, saves it, and updates the platform Workers that the interrupted run already deployed.
 
 :::

package/docs/guide/platform/installation/uninstall.md

@@ -91,7 +91,7 @@ If installation configured Cloudflare Access, the uninstall plan lists its recor
 
 Uninstall does not remove the applications created for [project Zero Trust](/guide/platform/administration/zero-trust). While Zero Trust is enabled or still has Access applications, uninstall and `--plan` stop before any change and list those applications. Run `void platform zero-trust disable` first. Uninstall reads this from the installation database, so it also stops when the database cannot be reached.
 
-If the installation database is permanently gone and cannot be restored, there is no uninstall command that can clear the local installation record or list its Cloudflare resources. Once you have decided not to recover that installation, delete `~/.void/platforms/<account-id>/<installation-id>.json` and any sibling `<installation-id>.recovery.enc` or `<installation-id>.secrets.enc` files. This removes only local state and encrypted credentials; it does not delete Cloudflare resources. Review and remove those resources manually using [Remove retained resources](#remove-retained-resources).
+If the installation database is permanently lost, [remove its Cloudflare resources manually](#remove-retained-resources). Once cleanup is complete, delete the local record at `~/.void/platforms/<account-id>/<installation-id>.json` and its sibling `<installation-id>.recovery.enc` and `<installation-id>.secrets.enc` files. These files contain installation metadata and encrypted credentials; deleting them leaves Cloudflare resources in place.
 
 If no platform user exists yet, for example because first administrator setup did
 not finish, nobody can run `zero-trust disable`. Uninstall then turns off project

package/docs/guide/queues.md

@@ -76,7 +76,7 @@ export default defineQueue<Message>(async (batch, env) => {
 - `batch.ackAll()`: acknowledge all messages in the batch
 - `batch.retryAll(options?)`: retry all messages in the batch
 
-The first call wins for each message. Calling `ack()` after `retry()`, or the reverse, does nothing. Messages with no explicit decision are acknowledged if the handler succeeds, or retried if it throws.
+The first `ack()` or `retry()` call wins for each message. Messages without an explicit decision are acknowledged when the handler succeeds and retried when it throws. Void logs handler errors automatically.
 
 The `timestamp` field on each message is a `Date` object.
 
@@ -118,15 +118,11 @@ Void provisions queues and connects their producers and consumers when you deplo
 
 ### Cloudflare queue names
 
-Queue names are unique per Cloudflare account. So `void deploy --platform cloudflare` names each queue after the Worker: in a Worker named `app-staging`, `queues/jobs.ts` uses the Cloudflare queue `app-staging-jobs` (a `_` in the Worker name becomes `-`). Two Workers in one account, such as `app-staging` and `app-production`, get separate queues. Your code keeps using the name from `queues/` (`queues.jobs.send()`), and `vp dev` uses that name too.
+With `void deploy --platform cloudflare`, queue names include the Worker name: `queues/jobs.ts` in `app-staging` creates `app-staging-jobs`. Underscores in the Worker name become hyphens. Your app uses `queues.jobs.send()` in every environment.
 
-The deploy stops before creating anything when:
+Keep the full name within 63 characters and unique within the account. Each Cloudflare queue supports one consumer; Void reports naming or consumer conflicts during deploy.
 
-- a new queue's full name is longer than 63 characters. Shorten the Worker name or the file name.
-- one queue's full name is the name of another file in `queues/`, such as `queues/jobs.ts` and `queues/app-jobs.ts` in Worker `app`. Rename one of the files.
-- another Worker already consumes the Cloudflare queue the deploy would use. A Cloudflare queue has one consumer.
-
-A queue that the Worker already consumes keeps its name, so an app deployed before Worker-named queues keeps its queue (for example `jobs`) and the messages in it. The deploy prints a note when it keeps a name. To move to the Worker-named queue, remove the Worker's consumer from the old queue in the Cloudflare dashboard, then deploy again. Messages that reach the old queue before that deploy finishes stay there, so do this when the app is not sending messages, and check that the old queue is empty before you delete it.
+Existing deployments keep their queues and messages. To adopt the new naming, pause producers, drain the old queue, remove its Worker consumer in Cloudflare, and redeploy. Check that the old queue is empty before deleting it.
 
 ## Local development
 

package/docs/guide/self-hosted-platform.md

@@ -6,11 +6,11 @@ outline: deep
 
 A Void platform lets your team deploy apps into a shared Cloudflare account. As an administrator, you install and maintain the platform. Developers connect the Void CLI to its URL, sign in through an enabled login method, and deploy their apps.
 
-If you're deploying an app for yourself, [deploy directly to Cloudflare](/integrations/cloudflare#deploy-to-your-own-cloudflare-account). You don't need to install a platform first.
+For an individual app, [deploy directly to Cloudflare](/integrations/cloudflare#deploy-to-your-own-cloudflare-account).
 
 The core platform supports GitHub, Google, generic OIDC, and Cloudflare Access login, CLI deploys, D1, KV, R2, Queues, cron jobs, Workers AI, WebSockets, SSE, ISR, routing, logs, and rollback.
 
-The core installation includes managed Sandboxes and an email gateway; email is enabled when you configure a shared mail domain and zone. The user dashboard, GitHub builds and webhooks, and build Containers aren't part of the core installation. [Project custom domains](/guide/platform/installation/domains#project-custom-domains) are opt-in with `--custom-domains`. Source-built platforms that add the optional GitHub services should follow the [isolated webhook ingress setup](/guide/platform/development/runtime#optional-github-webhook-ingress-for-access-protected-apis) when Access protects the API.
+The core installation also includes managed Sandboxes and an email gateway. Configure a shared mail domain and zone to enable email, and add `--custom-domains` for [project custom domains](/guide/platform/installation/domains#project-custom-domains). A user dashboard and managed GitHub builds require a [custom platform build](/guide/platform-development).
 
 ## Deployment features
 
@@ -26,7 +26,7 @@ Both targets use the same application APIs. A core platform adds shared access a
 | Application rollback                             | Worker versions                  | Retained platform deployments                 |
 | Typed Durable State and native Durable Objects   | Supported                        | Supported                                     |
 | Sandboxes                                        | Requires Workers Paid and Docker | Requires Workers Paid on the platform account |
-| Custom application domains                       | Supported                        | Unavailable in the core installation          |
+| Custom application domains                       | Supported                        | Enable with `--custom-domains`                |
 | Generated GitHub deployment workflow             | Supported                        | Use your CI with a scoped developer token     |
 | User dashboard and managed GitHub builds         | Not required                     | Not included in a standard installation       |
 

package/docs/guide/server-routing.md

@@ -12,7 +12,7 @@ Create route handlers in `routes/` using `.ts`, `.tsx`, `.js`, `.jsx`, `.mts`, o
 
 <RoutesFileTree />
 
-Dynamic segments use brackets: `[id]` becomes a route parameter and `[...slug]` becomes a catch-all. Files or directories starting with `_` are ignored, and so are those starting with `.`, except `.well-known`. Directories wrapped in parentheses like `(admin)` are route groups. They help organize files without changing the URL.
+Dynamic segments use brackets: `[id]` becomes a route parameter and `[...slug]` becomes a catch-all. Prefix files or directories with `_` or `.` to exclude them from routing; `.well-known` remains available for standard discovery endpoints. Directories wrapped in parentheses like `(admin)` are route groups. They help organize files without changing the URL.
 
 ### Environment-only routes
 
@@ -45,8 +45,8 @@ export const GET = defineHandler((c) => {
 A file can export multiple methods:
 
 ```ts
-import { users } from '@schema';
 // routes/api/users/index.ts  →  GET + POST /api/users
+import { users } from '@schema';
 import { defineHandler } from 'void';
 import { db } from 'void/db';
 
@@ -61,13 +61,13 @@ export const POST = defineHandler(async (c) => {
 });
 ```
 
-`GET` also answers `HEAD` requests, so route files can't export `HEAD`.
+`GET` handlers also answer `HEAD` requests automatically.
 
 See [Database](./database.md) for queries with D1, PostgreSQL, or MySQL.
 
 ### JSX handlers
 
-Use `.tsx` or `.jsx` when a server handler contains JSX. Void doesn't choose a JSX runtime: route files compile with the same JSX settings as the rest of your Vite app. In a React or Solid app, that is the framework's JSX, so render it with the framework's server renderer and return HTML. For example, in a React app:
+Use `.tsx` or `.jsx` when a server handler contains JSX. Route files use your app's JSX settings. In React or Solid, render JSX to HTML with the framework's server renderer. For example, in React:
 
 ```tsx
 // routes/hello.tsx → GET /hello
@@ -77,7 +77,7 @@ import { defineHandler } from 'void';
 export const GET = defineHandler((c) => c.html(renderToStaticMarkup(<h1>Hello!</h1>)));
 ```
 
-In an app without a JSX framework (API only, Vue, or Svelte), use [Hono's JSX](https://hono.dev/docs/guides/jsx). Your app needs `hono` in its own dependencies (new Void apps have it). Set the runtime in `vite.config.ts`, so it applies to `.tsx` and `.jsx` files alike:
+For API-only, Vue, or Svelte apps, add `hono` as a dependency and configure [Hono's JSX](https://hono.dev/docs/guides/jsx) in `vite.config.ts`:
 
 ```ts
 // vite.config.ts
@@ -115,8 +115,8 @@ Return values are automatically converted:
 `defineHandler.withValidator()` adds input validation for `body`, `query`, and `params`. The recommended approach is to derive validators from your [Drizzle schema](./database.md#schema-derived-validators), which keeps validation in sync with the database.
 
 ```ts
-import { users, insertUserSchema } from '@schema';
 // routes/api/users/index.ts
+import { users, insertUserSchema } from '@schema';
 import { defineHandler } from 'void';
 import { db } from 'void/db';
 
@@ -254,8 +254,8 @@ defineHandler(middleware1, middleware2, handler);
 Middleware runs in order. Each can short-circuit (return a response without calling `next()`) or post-process (modify the response after `await next()`). Both `defineMiddleware`-wrapped functions and raw Hono `MiddlewareHandler` functions are accepted.
 
 ```ts
-import { cors } from 'hono/cors';
 // routes/api/stats.ts
+import { cors } from 'hono/cors';
 import { defineHandler } from 'void';
 
 export const GET = defineHandler(cors({ origin: 'https://app.example.com' }), (c) => ({

package/docs/guide/ssg.md

@@ -58,8 +58,8 @@ With the default `output: "server"`, use `export const prerender = true` for dep
 
 `void deploy` chooses the deployment automatically:
 
-- **Fully static:** if every page is prerendered and there are no API routes, middleware, cron jobs, or queues, Void deploys as a pure static site with no worker.
-- **Hybrid:** if any pages are not prerenderable, such as dynamic pages without `getPrerenderPaths()` or pages with `export const prerender = false`, a worker is deployed to handle those routes at runtime. Prerendered pages are still served as static assets.
+- **Fully static:** if every page is prerendered and there are no API routes, middleware, cron jobs, or queues, Void deploys the built files as a static site. With `--platform cloudflare`, pages and files are served without running a Worker. If you use [edge rules](./edge/headers.md) (`routing` headers, redirects, rewrites, fallbacks, or `alwaysUseHttps`) or a `_headers` or `_redirects` file in `public/`, a small Worker runs on every request to apply them.
+- **Hybrid:** if any pages are not prerenderable, such as dynamic pages without `getPrerenderPaths()` or pages with `export const prerender = false`, a Worker is deployed to handle those routes at runtime. With `--platform cloudflare`, prerendered pages without a `.server.ts` file are served as static files without running the Worker. API routes, pages with a `.server.ts` file, and dynamic pages run in the Worker. Every page runs through the Worker when the app uses middleware, auth, live updates, edge rules (including a `_headers` or `_redirects` file in `public/`), a custom Vite `base`, a `routing.notFound` setting other than `"none"`, or a dynamic page at the top level of `pages/`, such as `pages/[slug].vue`.
 
 ## Relationship to `inference.appType: "static"`
 
@@ -68,5 +68,5 @@ The `inference.appType` field describes app type (SPA, static, void), while `out
 |              | `inference.appType: "static"`                   | `output: "static"`                            |
 | ------------ | ----------------------------------------------- | --------------------------------------------- |
 | **What**     | Deploy a pre-built static site (no Void plugin) | Prerender a Void app at build time            |
-| **Worker**   | None (static assets only)                       | Only if some pages can't be prerendered       |
+| **Worker**   | None (static assets only)                       | Only for server code and edge rules           |
 | **Use case** | VitePress, plain HTML, external SSG tools       | Void apps with mostly or fully static content |

package/docs/guide/type-safety.md

@@ -65,7 +65,7 @@ export const loader = defineHandler(async (c) => {
 <!-- pages/users/index.vue -->
 <script setup lang="ts">
 import type { Props } from './index.server';
-defineProps<Props>(); // ← { users: { id: number; name: string; ... }[] }
+const { users } = defineProps<Props>(); // ← users: { id: number; name: string; ... }[]
 </script>
 ```
 
@@ -102,6 +102,87 @@ const deleteForm = useForm('/users/:id?delete', { id: '' }, { params: { id } });
 
 The `action()` helper gets the same type checking. See [Actions & Forms](./pages-routing/actions-and-forms) for the full API.
 
+## Typed URLs and Navigation
+
+Use `routeUrl()` from `void/routes` to build URLs from your app's page, HTTP, and WebSocket route patterns. For a page at `pages/users/[id].tsx`, the pattern is `/users/:id`:
+
+```ts
+import { routeUrl } from 'void/routes';
+
+const url = routeUrl('/users/:id', {
+  params: { id: 42 },
+  query: { tab: 'activity' },
+  hash: 'details',
+});
+// /users/42?tab=activity#details
+```
+
+Your editor autocompletes route patterns and parameter names. TypeScript checks that the route exists and all required parameters are supplied. Parameter values accept strings or numbers; Void encodes them for the URL. Query keys are chosen by your app, and values can be strings, numbers, booleans, or arrays of those values. Arrays become repeated query parameters; `null` and `undefined` values are omitted.
+
+Pass the returned string to `Link`, a plain `<a>`, or `c.redirect()`. For programmatic navigation and `c.rewrite()`, you can pass a destination object directly:
+
+```ts
+import type { RouteDestination } from 'void/routes';
+
+const profile = {
+  pathname: '/users/:id',
+  params: { id: 42 },
+  query: { tab: 'activity' },
+  hash: 'details',
+} satisfies RouteDestination;
+```
+
+Destination objects use the same parameter checking and URL encoding as `routeUrl()`. See [Pages Routing](./pages-routing/overview.md#typed-navigation) for links and router methods, and [Rewrites](../reference/api/rewrites.md#c-rewrite-destination) for server navigation.
+
+For a catch-all page such as `pages/files/[...path].tsx`, use `/files/:path{.+}` and pass the full path as one value:
+
+```ts
+routeUrl('/files/:path{.+}', { params: { path: 'docs/get started' } });
+// /files/docs/get%20started
+```
+
+### Checked URL strings
+
+[`routing.typedRoutes`](../reference/config.md#routing-typedroutes) checks plain URL strings in `Link`'s `href`, `router.visit()`, `router.prefetch()`, `router.flush()`, and `c.rewrite()`. Apps created with `void init` have it on. To turn it on in an existing app:
+
+```ts
+// void.config.ts
+import { defineConfig } from 'void/config';
+
+export default defineConfig({
+  routing: { typedRoutes: true },
+});
+```
+
+A string must then match one of your routes, optionally followed by a query string or hash:
+
+```tsx
+<Link href="/about">About</Link>
+<Link href={`/users/${user.id}?tab=activity`}>Profile</Link>
+<Link href={routeUrl('/users/:id', { params: { id } })}>Profile</Link>
+<Link href="/abuot">About</Link> // Type error: no route matches
+```
+
+Links can also point to the current page (`?page=2`, `#comments`) and to `http://`, `https://`, `mailto:`, and `tel:` URLs. Relative paths such as `../settings` are rejected; use the absolute path. A fixed part with spaces or non-ASCII characters can be written as is (`/café menu`) or percent-encoded in uppercase, as `routeUrl()` returns it (`/caf%C3%A9%20menu`). A dynamic segment matches any text, including none, so `/users/:id` also accepts `/users/` and `/users/42/edit`. With a root dynamic page such as `pages/[slug].tsx`, a protocol-relative URL like `//example.com` passes too.
+
+`void/routes` exports two types for these strings:
+
+- `RouteUrl`: the URL of one of your routes. `routeUrl()` returns it, and `c.rewrite()` accepts it.
+- `Href`: anything a link can point to: a `RouteUrl`, a same-page query or hash, or an external URL.
+
+Cast a string that TypeScript can't check, such as a path from your CMS or a file in `public/`:
+
+```tsx
+import type { Href, RouteUrl } from 'void/routes';
+
+<Link href={post.path as RouteUrl}>{post.title}</Link>
+<Link href={user.website as Href}>Website</Link>
+```
+
+Restart the dev server or run `void prepare` after changing `routing.typedRoutes`.
+
+Route types update with the dev server. For CI or standalone typechecking, run `void prepare` and follow [Setup](#setup). The [API reference](../reference/api/types.md#void-routes) lists the URL helper and route types.
+
 ## What Gets Checked
 
 | Layer        | What's type-checked                                                                                                   |
@@ -109,6 +190,8 @@ The `action()` helper gets the same type checking. See [Actions & Forms](./pages
 | Database     | Table columns, value types, insert/update shapes from Drizzle schema                                                  |
 | Handlers     | `c.env` bindings, validator input, return type                                                                        |
 | Fetch client | Route paths, HTTP methods, `body`/`query`/`params`, response type                                                     |
+| Navigation   | Route patterns and required parameter names and values in `routeUrl()` and destination objects                        |
+| Links        | With `routing.typedRoutes`, URL strings in `Link`, router methods, and `c.rewrite()`                                  |
 | `useForm`    | Action URLs, `data` fields, `errors` keys, `reset()` args (including `{ initial: true }`), `params`, `resetOnSuccess` |
 | `action()`   | Action URLs, `data` payload, `params`                                                                                 |
 

package/docs/guide/typed-fetch.md

@@ -106,4 +106,4 @@ export default defineRender(async (c, assetTags) => {
 });
 ```
 
-Server-side calls to your app forward the incoming request's `cookie` and `authorization` headers. Explicit headers take precedence. Calls to an external `baseURL` use HTTP and do not inherit these headers.
+Server-side calls to your app forward the incoming request's `cookie` and `authorization` headers. Explicit headers take precedence. For an external `baseURL`, supply authentication headers explicitly.

package/docs/guide/websockets.md

@@ -32,7 +32,7 @@ Filename rules match regular server routes:
 - route groups like `(marketing)/chat.ws.ts` are ignored in the URL
 - `chat.dev.ws.ts` / `chat.prod.ws.ts` restrict the route to one environment
 
-The environment suffix goes **before** `.ws`. `chat.ws.dev.ts` is not a WebSocket route.
+Place the environment suffix **before** `.ws`, as in `chat.dev.ws.ts`.
 
 ## `defineRoom()`
 

package/docs/integrations/cloudflare.md

@@ -160,7 +160,7 @@ By default, Void sends Access credentials only to `workers.dev` URLs. If `worker
 export CF_ACCESS_READINESS_ORIGIN="https://app.example.com"
 ```
 
-Use one exact `https:` origin, without a wildcard or a path. Set the variable in the shell or CI environment that runs `void deploy`. Void ignores a value that `void.config.ts` sets, for example through a dotenv import. Set it only for a hostname that you control and that serves this Worker, because Void sends your Access credentials to it.
+Set this variable in the shell or CI environment running `void deploy`. Use an exact HTTPS origin for a hostname you control that serves this Worker; Void sends your Access credentials there.
 
 ### Databases and secrets
 
@@ -193,7 +193,7 @@ void project status
 void project rollback [version]
 ```
 
-Void restores recorded triggers along with the code. Versions without a complete trigger snapshot keep current routes and schedules. Rollback does not reverse database migrations. To undo D1 migrations, run [`void db restore`](../reference/cli/database.md#void-db-restore) with the restore point that deploy printed before it applied them, within 7 days on Workers Free or 30 days on Workers Paid.
+Void restores recorded triggers along with the code. Versions without a complete trigger snapshot keep current routes and schedules. Database recovery is separate: use [`void db restore`](../reference/cli/database.md#void-db-restore) to undo D1 migrations.
 
 #### Scope and limitations
 

package/docs/integrations/frameworks/analog.md

@@ -109,8 +109,8 @@ Declare variables in `env.ts` and read them with `import { env } from "void/env"
 You can also access raw Cloudflare bindings via the H3 event context or the `cloudflare:workers` module:
 
 ```ts
-import { env } from 'cloudflare:workers';
 // src/server/routes/api/users.ts
+import { env } from 'cloudflare:workers';
 import { eventHandler } from 'h3';
 
 export default eventHandler(async () => {

package/docs/integrations/frameworks/astro.md

@@ -6,9 +6,9 @@ outline: deep
 
 Use Void with [Astro](https://astro.build/) for resource detection, typed database queries, and migrations. Astro keeps its own build and Cloudflare integration; Void plugs into its Vite configuration.
 
-::: warning Astro 6 required
+::: warning Astro 7 required
 
-- [Astro 6+](https://astro.build/blog/astro-6/) is required to use `import { x } from "void/x"` helpers in Astro apps.
+- [Astro 7+](https://astro.build/blog/astro-7/) is required because Void needs Vite 8.
 - You also need to enable `"nodejs_als"` under `compatibility_flags` in your Cloudflare config.
 :::
 
@@ -67,16 +67,15 @@ void deploy
 
 ## Using Void Features
 
-Most [Void platform features](../../guide/app-types.md#void-apps) work with Astro in both local dev and production when using Astro 6+ with `nodejs_als`.
+Most [Void platform features](../../guide/app-types.md#void-apps) work with Astro in both local dev and production when using Astro 7+ with `nodejs_als`.
 
 Void-managed auth is not supported in framework mode yet. Use Better Auth's official Astro integration directly for now.
 
-Pages that access runtime bindings must opt out of prerendering:
+Pages and API routes that access runtime bindings must opt out of prerendering:
 
 ```astro
 ---
 export const prerender = false;
-// now Astro.locals.runtime is available
 ---
 ```
 
@@ -89,6 +88,8 @@ import { users } from '@schema';
 import type { APIRoute } from 'astro';
 import { db } from 'void/db';
 
+export const prerender = false;
+
 export const GET: APIRoute = async () => {
   const rows = await db.select().from(users);
   return Response.json(rows);
@@ -105,18 +106,20 @@ Declare variables in `env.ts` and read them with `import { env } from "void/env"
 
 Void always uses `VITE_*` for client-exposed schema keys, including in Astro projects. Astro's separate `PUBLIC_*` convention still applies to direct `import.meta.env` access, but it does not change the `void/env` server/client boundary.
 
-`void/env` replaces [`astro:env`](https://docs.astro.build/en/guides/environment-variables/) and `Astro.locals.runtime.env` for env-var access. Keep `Astro.locals.runtime.env` around when you need raw binding access (D1, KV, R2, etc.).
+`void/env` replaces [`astro:env`](https://docs.astro.build/en/guides/environment-variables/) for env-var access. Use `env` from `cloudflare:workers` when you need raw binding access (D1, KV, R2, etc.).
 
 ## Accessing Bindings Directly
 
-Access bindings via `Astro.locals.runtime.env` (works in both dev and production):
+Access bindings with `env` from `cloudflare:workers` (works in both dev and production):
 
 ```ts
 import type { APIRoute } from 'astro';
+import { env } from 'cloudflare:workers';
+
+export const prerender = false;
 
-export const GET: APIRoute = async ({ locals }) => {
-  const { DB } = locals.runtime.env;
-  const { results } = await DB.prepare('SELECT * FROM users').all();
+export const GET: APIRoute = async () => {
+  const { results } = await env.DB.prepare('SELECT * FROM users').all();
   return Response.json(results);
 };
 ```
@@ -125,8 +128,10 @@ In `.astro` pages (remember to set `prerender = false`):
 
 ```astro
 ---
+import { env } from 'cloudflare:workers';
+
 export const prerender = false;
-const { DB } = Astro.locals.runtime.env;
-const { results } = await DB.prepare("SELECT * FROM users").all();
+
+const { results } = await env.DB.prepare("SELECT * FROM users").all();
 ---
 ```

package/docs/integrations/frameworks/nuxt.md

@@ -80,8 +80,8 @@ Void-managed auth is not supported in framework mode yet. Use Better Auth's offi
 ### Database
 
 ```ts
-import { users } from '@schema';
 // server/api/users.get.ts
+import { users } from '@schema';
 import { db } from 'void/db';
 
 export default defineEventHandler(async () => {