void 1.1.0 → 1.1.12

package/docs/guide/edge/headers.md

@@ -33,9 +33,17 @@ For hashed assets, you can add headers, but the platform keeps control of cachin
 
 Header rules do not apply to ISR cache responses.
 
-### Blocked headers
+### Cookie headers
 
-`Set-Cookie` and `Clear-Site-Data` are ignored in header rules. On a shared domain such as `*.apps.example.com`, a rule could otherwise affect cookies or data belonging to another project's subdomain.
+On a [Void platform](../deployment.md#deploy-to-a-team-platform), apps usually share an application domain, such as `apps.example.com`. Header rules on a platform deploy change two headers on all hostnames of the app, including custom domains:
+
+- Void ignores `Set-Cookie` in header rules.
+- Void removes the `"cookies"` directive from `Clear-Site-Data` in header rules. Other directives, such as `"cache"` and `"storage"`, still apply.
+- Void ignores the full value of a `Clear-Site-Data` rule that includes `"*"`. The response then keeps the `Clear-Site-Data` value from your app's response, without `"cookies"`. If that value also includes `"*"`, the response has no `Clear-Site-Data`.
+
+This stops a header rule from setting or clearing cookies for other apps on the same domain. These limits apply only to header rules. Your app's own response can set cookies and send `Clear-Site-Data`, and on a shared domain those can affect other apps. See [Domains and Resources](../platform/installation/domains.md#adding-a-domain).
+
+During local development, with `void deploy --platform cloudflare`, and on [other runtimes](../deployment.md#other-runtimes), header rules apply both headers as written.
 
 ## Framework `_headers` files
 

package/docs/guide/edge/revalidation.md

@@ -63,6 +63,8 @@ export const loader = defineHandler(async (c) => {
 
 Per-page values take precedence over `void.config.ts` patterns.
 
+A page's `revalidate` export also applies to `routes/` handlers whose URLs match the page pattern. For example, if `pages/[...slug].server.ts` exports `revalidate`, Void can also cache the `GET` response of `routes/now.ts`. Void never caches paths under `/api`. To keep a route handler's response out of the cache, set `x-revalidate: 0` on it. See [Per-response TTL override](#per-response-ttl-override).
+
 ## Precedence
 
 When multiple sources set a revalidate TTL, the most specific wins:

package/docs/guide/email/receiving.md

@@ -96,7 +96,7 @@ to check current provider routing and any remaining setup steps.
 
 For direct deployments, follow [Your own Cloudflare account](./domains.md#your-own-cloudflare-account) to configure inbound addresses.
 
-There is no local inbound trigger yet — `void dev` serves the outbound dev inbox only, so test inbound handlers with `createInboundTestHarness` below.
+The local dev server provides the outbound email inbox but has no inbound email trigger. Test inbound handlers with `createInboundTestHarness` below.
 
 ## Testing inbound handlers {#testing-inbound-handlers}
 

package/docs/guide/email/sending.md

@@ -34,7 +34,7 @@ Check both failure shapes: `result.error` reports a request failure, while `resu
 
 ## Setup {#setup}
 
-On a platform with email enabled, deploy without additional email configuration. Ask your administrator for its shared mail domain. Administrators [enable email during installation or upgrade](/guide/platform/installation/credentials#runtime-token-permissions).
+On a platform with email enabled, deploy without additional email configuration. Ask your administrator for its shared mail domain. Administrators [enable email during installation or upgrade](/guide/platform/installation/credentials#enable-email).
 
 Each project on an email-enabled platform has:
 
@@ -171,7 +171,7 @@ The default platform allowance is 200 recipient attempts per UTC month and 10 pe
 
 ## Local development {#local-development}
 
-During `void dev`, sends are captured to an in-memory inbox instead of going to Cloudflare. The dev server prints the inbox URL when it starts:
+During local development, sends are captured to an in-memory inbox instead of going to Cloudflare. The dev server prints the inbox URL when it starts:
 
 ```
 [void] Email inbox: http://localhost:5173/__void/inbox?token=<printed-token>
@@ -195,7 +195,7 @@ The inbox keeps the most recent 100 messages through HMR and clears on a full se
 
 The dev inbox works in native Void apps, TanStack Start, and React Router. It is unavailable in SvelteKit, Nuxt, Analog, and Astro; sends from those apps return `BINDING_MISSING`. Use `createEmailTestHarness` from `void/email/testing` to capture sends in tests. If a configured inbox cannot be reached, `sendEmail` returns `UPSTREAM_ERROR` without sending.
 
-`sendInDev: true` skips the inbox, but returns `BINDING_MISSING` during `void dev`. Deploy the app to test real delivery.
+`sendInDev` is deprecated. During local development it skips the inbox and returns `BINDING_MISSING`, so it never delivers. Remove it, and deploy the app to test real delivery.
 
 ## Testing {#testing}
 

package/docs/guide/pages-routing/islands.md

@@ -209,7 +209,7 @@ After a successful action, an island page reloads or redirects through `window.l
 
 ## Forms
 
-Island pages cannot use `useForm` because it depends on the Void Router. Use `useIslandForm` instead. It has the same API, but it uses `fetch()` directly:
+Island pages cannot use `useForm` because it depends on the Void Router. Use `useIslandForm` instead. It has the same form state, but its submit helpers take the action URL and use `fetch()` directly:
 
 ::: code-group
 
@@ -344,7 +344,7 @@ export default function PostForm() {
 
 :::
 
-`useIslandForm` provides the same state and methods as [`useForm`](./actions-and-forms#useform). Use `post`, `put`, `patch`, or `delete` with the action URL to submit.
+`useIslandForm` provides the same form state as [`useForm`](./actions-and-forms#useform). Pass the action URL to `post`, `put`, `patch`, or `delete` to submit.
 
 Successful submissions reload the page; redirects navigate to their destination. A `422` response populates `errors` from `{ errors: { field: "message" } }`. Submit helpers return `Promise<void>`.
 

package/docs/guide/pages-routing/markdown.md

@@ -137,7 +137,7 @@ Welcome to Void. Here's an interactive demo:
 ```
 
 - **`<script>` block:** extracted before markdown compilation. Island imports use `with { island: "..." }` syntax (see [islands](./islands)). Any other code in the block becomes a [client script](#client-scripts) that runs in the browser.
-- **Frontmatter:** YAML metadata between `---` fences. Layouts can read it through [`useFrontmatter()`](#frontmatter-access).
+- **Frontmatter:** YAML metadata between `---` fences. Layouts and islands can read it through [`useFrontmatter()`](#frontmatter-access).
 - **Body:** standard markdown plus GFM. Uppercase tags such as `<Counter />` reference imported components and render as islands.
 
 ## Client Scripts
@@ -230,6 +230,8 @@ export default function DocsLayout(props) {
 
 :::
 
+Island components on a Markdown page can call `useFrontmatter()` too. A page with islands includes its frontmatter in the HTML for them to read in the browser. Keep private values out of the frontmatter of those pages.
+
 ## Pages Virtual Module
 
 Import `@void/md/pages` to get metadata for all markdown pages at build time. Use it to build sidebars, navigation, or search indexes:

package/docs/guide/platform/administration/connected-apps.md

@@ -4,7 +4,7 @@ A connected app is a separate application registered as an OAuth client on your
 
 ## Register an application
 
-Open **Admin → Connected apps**. Enter the app name, its operator, and each exact HTTPS callback URL on a separate line. Wildcards and callback query strings are not supported. Enable individual publish approvals if the app builds and deploys projects.
+Open **Admin → Connected apps**. Enter the app name, its operator, and each exact HTTPS callback URL on a separate line. Wildcards and callback query strings are not supported. Enable individual publish approvals if the app builds and deploys projects. Enable private previews to run checkpoints before publishing. Existing clients have an **Enable private previews** button; users must connect again to consent to that permission.
 
 Save the returned client ID and secret on the app's server. Void shows the secret once. The client secret authenticates that application; it does not grant access to users' accounts. Register a new client if you need replacement credentials, then disable the old one.
 
@@ -18,6 +18,22 @@ The app sends users to Void's authorization page, where Void displays its regist
 
 Users can disconnect applications at `<platform API URL>/oauth/connections`. Grants also expire after an hour and become invalid when their platform login session is revoked or their account is suspended. Applications must request a new sign-in when access expires.
 
+## Private previews
+
+Sign-in can request `scope=profile preview:deploy` when the administrator has enabled it. After user consent, the app can build private previews without approval for each checkpoint. Production publishing still requires individual approval.
+
+Use the granted bearer token to:
+
+1. POST `{ workspace: externalWorkspaceId }` to `/oauth/previews`. The response contains a stable `project_id` and preview `url` for that client, owner and workspace.
+2. POST `{ project_id, checkpoint, artifact: prepared.artifact }` to `/oauth/preview-deployment-requests`. Use its `access_token` and `approval_id` with the same asset upload and deployment protocol as publishing.
+3. Once deployment finishes, POST to `/oauth/previews/:id/launch` and open the returned URL. Launch URLs expire after one minute and can be used once. Reload the preview's origin after opening it.
+
+Each workspace has a separate preview origin and resources, with no production secrets. Previews support HTTP apps with isolated D1, KV, R2, AI and native Durable Objects. Authentication, external databases, email, schedules, queues and containers require production publishing. Viewing requires the current user grant; disconnecting or disabling the app denies subsequent requests. Preview writes must originate from that preview's own origin.
+
+Account Access policies must allow requests to generated preview origins to reach Void. A policy that blocks new Workers hostnames also blocks previews. Void still requires a valid preview grant when the hostname is reachable.
+
+Each owner can have ten preview workspaces. Each workspace permits sixty builds per hour and shares the owner's platform resource and usage limits. Inactive previews expire after seven days and Void removes their resources. Opening the workspace through `/oauth/previews` renews that expiry. Disabling preview permission expires its previews.
+
 ## Approve a publish
 
 The app builds first, then sends the user to Void with the prepared artifact. Void displays the project name, checkpoint label, resources, manifest, and artifact digest. The user must explicitly approve on Void.
@@ -30,7 +46,7 @@ Disabling the app or disconnecting its grant stops authorization for subsequent
 
 ## Build an OAuth client
 
-Discover endpoints at `/.well-known/oauth-authorization-server` on the platform API origin. Use authorization code flow with `scope=profile`, a random `state`, and S256 PKCE. Authenticate token exchanges using HTTP Basic client authentication. Send access tokens as Bearer credentials to `/oauth/userinfo`; its response contains `sub` and `preferred_username`.
+Discover endpoints at `/.well-known/oauth-authorization-server` on the platform API origin. Use authorization code flow with `scope=profile`, a random `state`, and S256 PKCE. Authenticate token exchanges using HTTP Basic client authentication. Send access tokens as Bearer credentials to `/oauth/userinfo`; its response contains `sub`, `preferred_username`, and the consented `scope`.
 
 For publishing, package the built app with [`prepareDeployArtifact`](/reference/api/deploy). POST to `/oauth/deployment-requests` using the profile token:
 

package/docs/guide/platform/administration/email.md

@@ -27,6 +27,12 @@ reconciliation verifies delivery afterward; a deleting project stays closed
 and its deletion can be retried. See [operator email commands](../../../reference/cli/platform-email.md#operator-email)
 for the recovery requirements.
 
+### Mail that the platform sends {#platform-sender}
+
+The platform sends its own mail, for example invitations, welcome mail, failed-deploy notices, and error alerts. This mail comes from `noreply@<mail domain>`, and the sender name is the platform's display name. Void sets this sender, so you do not need to configure one. Do not set a different sender on the platform Workers in the Cloudflare dashboard. That change stops the next `upgrade`, `repair`, `enable`, or `rollback` until you let Void replace it. See [Platform Workers changed outside Void](/guide/platform/installation/maintenance#workers-changed-outside-void).
+
+Mail to an address that is not verified needs Cloudflare Email Sending onboarding and [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans).
+
 ### Deciding who mail may reach
 
 By default, mail from the shared sender reaches only the recipients each project has verified. For a team whose applications mainly mail colleagues, widen that once for the whole installation:
@@ -114,7 +120,7 @@ Use the apex of the selected Cloudflare zone. Platform-managed custom inbound em
 void platform email domain-add other.example --project hr-portal --token-stdin --yes < token.txt
 ```
 
-Project owners see administrator-registered domains in `void email domain list` and `status`; `status` names the `void platform email` command for any step they cannot take themselves, and `sync` and `remove` point them at `domain-sync` and `domain-remove`. A domain an owner registered before you switched to `admin` stays theirs to renew, sync and remove. The runtime token needs the email permissions listed in the [self-hosting guide](/guide/platform/installation/credentials#runtime-token-permissions) for this to work.
+Project owners see administrator-registered domains in `void email domain list` and `status`; `status` names the `void platform email` command for any step they cannot take themselves, and `sync` and `remove` point them at `domain-sync` and `domain-remove`. A domain an owner registered before you switched to `admin` stays theirs to renew, sync and remove. The runtime token needs the [email permissions](/guide/platform/installation/credentials#enable-email) for this to work.
 
 A permission refusal leaves setup blocked. After correcting it, run `domain-sync`
 to resume that same setup operation; repeat `domain-rotate-secret` to resume a

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

@@ -51,6 +51,8 @@ void platform install \
 
 Mutations require `--yes` in CI; a read-only `--plan` does not. Custom runtimes also require `--runtime <directory>`. For a new installation, run `--plan` with the same account, name, and domain options as the unattended install. If you use `--auth-config`, pass the same file to both commands. Register `<platform-api-url>/auth/callback` when creating a login provider's OAuth or OIDC client manually; automatic Access setup manages its own application. A custom API hostname is optional.
 
+In CI, `upgrade`, `repair`, `enable`, `rollback`, and `install --resume` stop before they change a platform Worker or pause traffic when a platform Worker was changed in the Cloudflare dashboard or with the Cloudflare API, or has an active version without a Void deployment record. See [Platform Workers changed outside Void](/guide/platform/installation/maintenance#workers-changed-outside-void).
+
 :::
 
 ## Customize the Platform

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

@@ -68,7 +68,25 @@ Void checks access before provisioning. If it reports a missing permission, upda
 
 ## Enable Email {#enable-email}
 
-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. To enable email on an existing installation, run:
+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.
+
+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:
+
+| Scope   | Permission              | Access |
+| ------- | ----------------------- | ------ |
+| Account | Email Routing Addresses | Edit   |
+| Account | Email Sending           | Edit   |
+| Zone    | Zone                    | Read   |
+| Zone    | Zone Settings           | Edit   |
+| Zone    | Email Routing Rules     | Edit   |
+
+The zone permissions must include each zone that will carry mail, including the mail zone. Email Sending onboarding for arbitrary recipients needs Workers Paid.
+
+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:
 
 ```sh
 VOID_EMAIL_SENDER_DOMAIN=mail.example.com \
@@ -76,13 +94,13 @@ VOID_EMAIL_SHARED_ZONE_ID=your-zone-id \
 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.
+Void records the domain and zone for later upgrades; an ordinary upgrade cannot replace them.
 
-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.
+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.
 
-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.
+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.
 
-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.
+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.
 
 ## R2 Upload Credentials
 

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

@@ -113,9 +113,13 @@ 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.
 
-::: details Migration safety, credential rotation, and interrupted upgrades
+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 briefly put the platform into maintenance mode. Traffic resumes after the new version passes health checks. If an upgrade is interrupted during maintenance, rerun the same command to complete it.
+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.
+
+::: details Migration safety, credential rotation, and rollback
 
 To update the runtime Cloudflare token, GitHub OAuth credentials when GitHub login is enabled, or R2 credentials,
 provide their `VOID_PLATFORM_*` environment variables when running the upgrade.
@@ -141,6 +145,32 @@ 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:
+
+- 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.
+
+The `--plan` preview of `upgrade`, `repair`, `enable`, and `rollback` shows the same list as a warning.
+
+In a terminal, Void lists these Workers and asks **Replace the configuration of these Workers?** The default answer is No.
+
+- 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.
+
+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.
+
+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`.
+
+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.
+
+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.
+
+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).
+
 ### Follow upgrade and rollback progress
 
 Watching progress is optional: a running upgrade or rollback proceeds through

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

@@ -260,6 +260,6 @@ 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. 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 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.
 
 :::

package/docs/guide/remote-dev.md

@@ -59,6 +59,8 @@ When the dev server starts with remote mode active, it prints:
 
 - **Network latency:** each binding call makes a network request, so responses may be slower than local development.
 - **R2 multipart uploads:** `createMultipartUpload()` and `resumeMultipartUpload()` are not supported in remote mode.
+- **R2 range and conditional reads:** in remote mode, `get()` ignores request headers passed as `range` or `onlyIf` and returns the whole object. For example, `get(key, { range: request.headers, onlyIf: request.headers })` returns the whole object when the request has a `Range` or `If-None-Match` header. `get()` throws when `range` or `onlyIf` is an object that asks for a byte range or a condition, such as `{ offset: 0, length: 100 }` or `{ etagMatches: etag }`.
 - **R2 conditional writes:** `put(..., { onlyIf })` requires an updated platform and project deployment. Failed preconditions return `null`.
+- **R2 metadata and list options:** custom metadata, HTTP metadata, and `list()` with `delimiter`, `startAfter`, or `include` require an updated project deployment. Without one, `list()` with these options and `put()` with metadata other than `contentType` throw an error.
 - **D1 dump:** `db.dump()` is not supported in remote mode.
 - **D1 batches:** `db.batch()` requires an updated platform and project deployment.

package/docs/guide/typed-fetch.md

@@ -106,4 +106,4 @@ export default defineRender(async (c, assetTags) => {
 });
 ```
 
-Server-side calls forward the incoming request's `cookie` and `authorization` headers. Explicit headers take precedence.
+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.

package/docs/guide/websockets.md

@@ -151,7 +151,7 @@ Messages are JSON events. Raw string and binary messages are not supported.
 
 When Void auth is enabled, every WebSocket hook receives the current user as `ctx.user`, or `null` for an anonymous connection. Use `onBeforeConnect` to reject unauthenticated clients.
 
-Connections from another origin are anonymous unless that origin is in your auth `trustedOrigins`. If you read your own cookies from `ctx.request`, check its `Origin` header yourself.
+Connections from another origin are anonymous unless that origin is in your auth `trustedOrigins`. If you read your own cookies from `ctx.request` in `onBeforeConnect`, check its `Origin` header yourself.
 
 `ctx.user` is resolved when the socket connects and stays the same for that connection, even if the user later signs out or the session is revoked. For actions that must respect a ban or role change, re-check your own records in `onMessage` and close the connection with `ctx.connection.close()` in rooms or `ctx.socket.close()` in `defineWebSocket()`.
 
@@ -173,7 +173,7 @@ Every hook receives a context with:
 - `ctx.id`: deterministic route instance id
 - `ctx.params`: matched route params
 - `ctx.user`: resolved auth user or `null`
-- `ctx.request`
+- `ctx.request`: the HTTP request in `onBeforeConnect`, `onConnect`, and `onRequest`. In `onMessage` and `onClose`, it is a placeholder without headers, cookies, or query. To keep request data, save it in `onConnect` with `ctx.connection.setState()` in rooms or `ctx.socket.setState()` in `defineWebSocket()`. Read it later from `ctx.connection.state` or `ctx.socket.state`.
 - `ctx.env`
 - `ctx.storage`
 

package/docs/index.md

@@ -4,36 +4,92 @@ theme: dark
 
 hero:
   name: Void
-  text: Full-stack apps with Vite
-  tagline: Add server routes, data, and Cloudflare resources to your app. Deploy with one command.
+  text: Build with Vite. Deploy with Void.
+  tagline: Void is a CLI, platform, and full-stack SDK that unifies building & deploying apps.
   actions:
     - theme: brand
       text: Get Started
       link: ./guide/
-  image:
-    src: /hero.svg
-    alt: Void deployment platform
-
+    - theme: alt
+      text: View on GitHub
+      link: https://github.com/voidzero-dev/void
+    - theme: alt
+      text: Read the Announcement
+      link: https://blog.cloudflare.com/deploy-with-void
 features:
-  - iconify: lucide:terminal
-    title: Deploy with One Command
-    details: '`void deploy` builds your app, provisions resources, applies migrations, and deploys it.'
   - iconify: lucide:layers
-    title: Full-Stack Features
-    details: Use a database, KV, object storage, AI, authentication, queues, and cron jobs as your app needs them.
+    visual: stack
+    title: Full-Stack, Inferred
+    details: Import what you need. Void provides local resources and provisions them on deploy.
+    highlights:
+      - Server routes and authentication
+      - Databases, storage, and AI
+      - Queues and scheduled jobs
+    guide:
+      text: Explore the SDK
+      link: /guide/
   - iconify: lucide:wand-sparkles
-    title: Resources from Your Code
-    details: Void detects supported resources from your imports and provisions them on deploy. Configure existing resources explicitly.
-  - iconify: lucide:shield-check
-    title: Deploy with Confidence
-    details: Run on Cloudflare Workers with checked migrations, versioned deployments, logs, and rollback.
+    visual: resources
+    title: Typed from Database to UI
+    details: Share types across your database, server loaders, and page components.
+    highlights:
+      - Types from your database schema
+      - Typed loaders, actions, and APIs
+      - Server code stays on the server
+    guide:
+      text: Explore Type Safety
+      link: /guide/type-safety
   - iconify: lucide:blocks
-    title: Choose Your Framework
-    details: Use React, Vue, Svelte, Solid, or a supported Vite framework with SSR, SSG, ISR, and islands.
-  - iconify: lucide:bot
-    title: Work with Coding Agents
-    details: Void provides project instructions and skills to help coding agents build and deploy your app.
-
+    visual: frameworks
+    title: Use Your Favorite Framework
+    details: Build with Void's adapters or keep your existing Vite framework.
+    highlights:
+      - Ships with adapters for Async React, Vue, Svelte, and Solid
+      - Supports TanStack Start, SvelteKit, Nuxt, and more
+      - Build APIs, SPAs, or server-rendered pages
+    guide:
+      text: Explore Frameworks
+      link: /integrations/frameworks/overview
+platform_features:
+  - id: platform-ai-coding
+    iconify: lucide:bot
+    title: Secure Vibe Coding for Your Team
+    details: Let your team build and deploy with coding agents while admins retain control of Cloudflare access.
+    highlights:
+      - Enable non-technical teammates to build their own apps
+      - Keep Cloudflare credentials with your admin team
+      - Deploy prototypes fast and share apps for feedback
+    guide:
+      text: Explore team deployments
+      link: /guide/self-hosted-platform
+    visual: rive
+    image_alt: Animated illustration of apps being built for a team
+  - id: platform-control-plane
+    iconify: lucide:panels-top-left
+    visual: resources
+    title: Control Plane for Managing Apps
+    details: Manage users, projects, deployments, and platform health from the admin UI or CLI.
+    highlights:
+      - Manage users and project access & resources
+      - Inspect deployments, logs, and rollbacks
+      - Monitor platform health and usage
+    guide:
+      text: Platform administration
+      link: /guide/platform-administration
+    image_alt: List of Void platform commands for access, builds, invitations, and administration
+  - id: platform-security
+    iconify: lucide:shield-check
+    title: Bring your Own Security
+    details: Fork and customize your own Void platform based on your team's security standards.
+    highlights:
+      - Manage access through Cloudflare Access, Google, GitHub, or OIDC
+      - Control who can sign in and deploy
+      - Protect projects with your access policies
+    guide:
+      text: Configure platform access
+      link: /guide/platform/administration/access
+    visual: rive
+    image_alt: Animated illustration of self-hosted platform security
 footer_heading: Build with Vite. Deploy with Void.
 footer_subheading: Server code, resources, and deployment in one workflow.
 ---

package/docs/integrations/cloudflare.md

@@ -183,7 +183,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.
+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.
 
 #### Scope and limitations
 

package/docs/integrations/frameworks/tanstack-start.md

@@ -71,6 +71,31 @@ Use [KV](../../guide/kv.md), [object storage](../../guide/storage.md), and [AI](
 
 Declare variables in `env.ts` and read them with `import { env } from "void/env"`. See [Environment Variables](../../guide/env-vars.md) for local values, production secrets, and public `VITE_*` values.
 
+## Custom Worker Entry
+
+Set `cloudflare.main` in `void.config.ts` when your Worker needs its own entry module, for example to export a Durable Object class:
+
+```ts
+import { defineConfig } from 'void/config';
+
+export default defineConfig({
+  cloudflare: { main: './server.ts' },
+});
+```
+
+The path is relative to your app root. Default-export the TanStack request handler and add your named exports in that module:
+
+```ts
+import handler from '@tanstack/react-start/server-entry';
+
+export { Counter } from './counter';
+export default handler;
+```
+
+Void preserves these named exports in development, production builds, and deploys. Without `cloudflare.main`, Void uses TanStack's default server entry. A package entry such as `@tanstack/react-start/server-entry` is resolved as a module.
+
+Bind an exported Durable Object or Workflow class under `cloudflare` as well, for example in `cloudflare.durable_objects`. These settings apply when you deploy with `void deploy --platform cloudflare`. On a Void platform, use [Durable State](../../guide/durable-state.md) instead.
+
 ## Accessing Bindings Directly
 
 You can also access Cloudflare bindings via the `cloudflare:workers` module:

package/docs/reference/api/deploy.md

@@ -1,6 +1,6 @@
 # Deployment artifacts
 
-Use `void/deploy` from Node.js to prepare a built Void app for a managed platform deployment without platform credentials.
+Use `void/deploy` from Node.js to prepare a built Void app, SPA, or static site for a managed platform deployment without platform credentials.
 
 Build the app in managed mode inside its isolated environment:
 
@@ -16,8 +16,40 @@ import { prepareDeployArtifact } from 'void/deploy';
 const { artifact, assets } = await prepareDeployArtifact('/path/to/app');
 ```
 
-`artifact` contains the deployment manifest, content-addressed asset metadata, and base64 Worker modules. `assets` maps asset URL paths to base64 bytes. Keep this result immutable while requesting [publish approval](/guide/platform/administration/connected-apps).
+`artifact` contains the deployment manifest, content-addressed asset metadata, and base64 Worker modules when the app needs a Worker. SPAs and static sites contain only assets, using the same app detection, output directory and routing configuration as `void deploy`. `assets` maps asset URL paths to base64 bytes. Keep this result immutable while requesting [publish approval](/guide/platform/administration/connected-apps).
 
-Preparation packages existing build output; it does not build, contact a platform, provision resources, or deploy. It supports Void Cloudflare Worker builds. Node targets, static output, remote data, deploy-time prerendering, Sandbox, and Live resources require the normal `void deploy` workflow instead.
+Preparation packages existing build output; it does not build, contact a platform, provision resources, or deploy. It supports Void Cloudflare Worker builds, SPAs, and static sites. Node targets, Pages `output: 'static'`, remote data, deploy-time prerendering, Sandbox, and Live resources require the normal `void deploy` workflow instead.
 
 Run preparation inside the same isolated environment as the app build. App configuration and build plugins execute project code; keep platform credentials on the publishing server.
+
+## Cloudflare Build Output
+
+::: warning Experimental
+`prepareCfBuildOutput` follows Cloudflare's draft Build Output format. Its options and the prepared directory can change between Void releases.
+:::
+
+Use `prepareCfBuildOutput` to convert an existing Cloudflare Worker build into a disposable Cloudflare Build Output directory:
+
+```ts
+import { prepareCfBuildOutput } from 'void/deploy';
+
+const prepared = await prepareCfBuildOutput('/path/to/app/dist/server', { mode: 'staging' });
+if (!prepared) {
+  throw new Error('The Worker build could not be prepared.');
+}
+
+try {
+  // Inspect or pass prepared.directory to your Cloudflare publication workflow.
+} finally {
+  await prepared.dispose();
+}
+```
+
+Pass the Worker output directory that contains a generated `wrangler.json`, such as `dist/ssr`, `dist/rsc`, or `dist/server`. When Cloudflare's build tooling built the app, pass the project root that contains its native Build Output at `.cloudflare/output/v0` instead. Preparation copies modules and assets without changing that input. Native output keeps its module types, auxiliary Workers, Container declarations, and build metadata. Preparation does not provision resources, upload a Worker, or activate a deployment. Container images built from a local Dockerfile exist only in the Docker environment that built them, so publish from that environment.
+
+| Option      | Description                                                                                                                                          |
+| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `accountId` | Cloudflare account the build must target. A different account in the build returns `null`. When omitted, the build's account is kept or left unset.  |
+| `mode`      | Vite build mode. Native output keeps the mode it was built with, and a different value returns `null`. For other output it defaults to `production`. |
+
+The result contains `directory`, an optional `assetsDirectory` pointing to the input assets, and an asynchronous `dispose()` method. Always dispose the result after use. Unsupported build configuration returns `null`. A directory without a Worker build, a missing or invalid Worker module, or an asset symlink outside the asset directory throws an error.