void 1.1.11 → 1.1.12

package/dist/runtime/validator.d.mts

@@ -1,2 +1,2 @@
-import { D as runValidation, E as ValidatorSlots, T as HandlerInput } from "../handler-_PqY82xe.mjs";
+import { D as runValidation, E as ValidatorSlots, T as HandlerInput } from "../handler-D5K_yP6T.mjs";
 export { HandlerInput, ValidatorSlots, runValidation };

package/dist/runtime/ws-server.d.mts

@@ -1,6 +1,6 @@
 import { n as AuthState } from "../auth-DkcFflXV.mjs";
 import { r as VoidAuthRuntimeOptions, t as VoidAuthEnv } from "../better-auth-shared-Bv18bB-l.mjs";
-import { f as WebSocketInstanceKey, t as AnyWebSocketDefinition } from "../ws-CsBNxv86.mjs";
+import { f as WebSocketInstanceKey, t as AnyWebSocketDefinition } from "../ws-nnFnAyQb.mjs";
 //#region src/runtime/ws-server.d.ts
 export type WebSocketRouteMeta = {
   name?: string;

package/dist/runtime/ws.d.mts

@@ -1,2 +1,2 @@
-import { a as RoomDefinition, c as VoidSocket, d as WebSocketConnection, f as WebSocketInstanceKey, h as defineWebSocket, i as RoomController, l as VoidSocketCloseEvent, m as defineRoom, n as ConnectCommonOptions, o as SocketContext, p as connect, r as RoomContext, s as SocketDefinition, t as AnyWebSocketDefinition, u as WebSocketBaseContext } from "../ws-CsBNxv86.mjs";
+import { a as RoomDefinition, c as VoidSocket, d as WebSocketConnection, f as WebSocketInstanceKey, h as defineWebSocket, i as RoomController, l as VoidSocketCloseEvent, m as defineRoom, n as ConnectCommonOptions, o as SocketContext, p as connect, r as RoomContext, s as SocketDefinition, t as AnyWebSocketDefinition, u as WebSocketBaseContext } from "../ws-nnFnAyQb.mjs";
 export { AnyWebSocketDefinition, ConnectCommonOptions, RoomContext, RoomController, RoomDefinition, SocketContext, SocketDefinition, VoidSocket, VoidSocketCloseEvent, WebSocketBaseContext, WebSocketConnection, WebSocketInstanceKey, connect, defineRoom, defineWebSocket };

package/dist/{secret-CClHaFxm.mjs → secret-wr6Sn4Xa.mjs}

@@ -1,8 +1,8 @@
 import { n as readDeploymentPlatform, r as readProjectConfig } from "./project-rqDnVsJN.mjs";
 import { c as getToken } from "./auth-B6iOCjKI.mjs";
 import { A as confirm, H as outro, L as log, O as cancel, U as password, tt as isCancel } from "./dist-BVdsO7Py.mjs";
-import { m as printSuccess, o as formatCount, p as note } from "./output-Ba6ZbrzY.mjs";
-import { r as PlatformClient } from "./client-GuSO3v_x.mjs";
+import { m as printSuccess, o as formatCount, p as note } from "./output-CKguMgr7.mjs";
+import { r as PlatformClient } from "./client-BdzxubTS.mjs";
 import { a as resolveProjectBySlug, t as getRequestedProjectSlug } from "./resolve-project-WpwkCB_c.mjs";
 import { _ as validateSecretValues } from "./env-validation-D_KyMdab.mjs";
 import { readFileSync } from "node:fs";
@@ -93,7 +93,7 @@ async function resolveSecretBackend(root, args) {
 }
 async function resolveCloudflareSecretBackend(root, args) {
 	if (args.projectName) throw new Error("secret: --project selects a Void platform project and is not used for direct Cloudflare apps.");
-	const { deleteCloudflareSecret, listCloudflareSecrets, putCloudflareSecret, resolveCloudflareOperationContext, syncCloudflareSecrets } = await import("./cloudflare-operations-Cm8lVx7W.mjs");
+	const { deleteCloudflareSecret, listCloudflareSecrets, putCloudflareSecret, resolveCloudflareOperationContext, syncCloudflareSecrets } = await import("./cloudflare-operations-BFLCpUCV.mjs");
 	const context = resolveCloudflareOperationContext(root);
 	return {
 		target: "Cloudflare Worker",

package/dist/serialize-DtR8Vwa_.d.mts

@@ -0,0 +1,18 @@
+//#region src/pages/serialize.d.ts
+/**
+ * Escape JSON for embedding inside an inline `<script type="application/json">`
+ * tag. Replaces `<`, `>`, `&`, U+2028, U+2029 with their `\uXXXX` JSON escape
+ * sequences so the script tag cannot be closed early and the payload survives
+ * `JSON.parse` on hydration.
+ */
+declare function serializePageData(pageObj: unknown): string;
+/** Element id of the Markdown page frontmatter that islands read when they hydrate. */
+declare const ISLAND_FRONTMATTER_ID = "__void_frontmatter";
+/**
+ * Script tag that carries a Markdown page's frontmatter to its islands, so
+ * `useFrontmatter()` returns the same value in the browser as on the server.
+ * Empty when the page has no frontmatter.
+ */
+declare function islandFrontmatterScript(frontmatter: Record<string, unknown> | undefined): string;
+//#endregion
+export { islandFrontmatterScript as n, serializePageData as r, ISLAND_FRONTMATTER_ID as t };

package/dist/serialize-YHvlcG3Q.mjs

@@ -0,0 +1,31 @@
+//#region src/pages/script-json.ts
+const UNSAFE_SCRIPT_CHARS = /[<>&\u2028\u2029]/g;
+function escapeScriptJson(json) {
+	return json.replace(UNSAFE_SCRIPT_CHARS, (c) => {
+		return `\\u${c.charCodeAt(0).toString(16).padStart(4, "0")}`;
+	});
+}
+//#endregion
+//#region src/pages/serialize.ts
+/**
+* Escape JSON for embedding inside an inline `<script type="application/json">`
+* tag. Replaces `<`, `>`, `&`, U+2028, U+2029 with their `\uXXXX` JSON escape
+* sequences so the script tag cannot be closed early and the payload survives
+* `JSON.parse` on hydration.
+*/
+function serializePageData(pageObj) {
+	return escapeScriptJson(JSON.stringify(pageObj));
+}
+/** Element id of the Markdown page frontmatter that islands read when they hydrate. */
+const ISLAND_FRONTMATTER_ID = "__void_frontmatter";
+/**
+* Script tag that carries a Markdown page's frontmatter to its islands, so
+* `useFrontmatter()` returns the same value in the browser as on the server.
+* Empty when the page has no frontmatter.
+*/
+function islandFrontmatterScript(frontmatter) {
+	if (!frontmatter || Object.keys(frontmatter).length === 0) return "";
+	return `<script type="application/json" id="${ISLAND_FRONTMATTER_ID}">${serializePageData(frontmatter)}<\/script>`;
+}
+//#endregion
+export { escapeScriptJson as i, islandFrontmatterScript as n, serializePageData as r, ISLAND_FRONTMATTER_ID as t };

package/dist/{subcommand-prompt-Bm3ZlYgA.mjs → subcommand-prompt-CNZc4XUd.mjs}

@@ -1,5 +1,5 @@
 import { $ as wrapTextWithPrefix, G as promptTitle, M as getGuide, V as optionText, b as S_RADIO_ACTIVE, d as S_CHECKBOX_SELECTED, i as S_BAR_END, it as wrapAnsi, j as formatInstructionFooter, n as SELECT_INSTRUCTIONS, r as S_BAR, t as MULTISELECT_INSTRUCTIONS, u as S_CHECKBOX_INACTIVE, w as S_STEP_SUBMIT } from "./dist-BVdsO7Py.mjs";
-import { f as import_picocolors } from "./output-Ba6ZbrzY.mjs";
+import { f as import_picocolors } from "./output-CKguMgr7.mjs";
 //#region src/cli/subcommand-prompt.ts
 const isUpKey = (key) => key === "\x1B[A" || key === "\x1BOA";
 const isDownKey = (key) => key === "\x1B[B" || key === "\x1BOB";

package/dist/{wrapper-BOigE1xJ.mjs → wrapper-DGsYwNi6.mjs}

@@ -459,6 +459,7 @@ function generateWrapperSource(renamedEntry, handlersModule, features, migration
 	const lines = [];
 	lines.push(WRAPPER_MARKER);
 	lines.push(`import original from "./${renamedEntry}";`);
+	lines.push(`export * from "./${renamedEntry}";`);
 	if (features.isr) {
 		lines.push("import { handleFrameworkIsr } from \"./__void_isr.mjs\";");
 		lines.push(`const __voidIsrDeploymentId = ${JSON.stringify(crypto.randomUUID())};`);
@@ -558,6 +559,7 @@ function generateWrapperSource(renamedEntry, handlersModule, features, migration
 		lines.push("");
 	}
 	lines.push("export default {");
+	lines.push("  ...original,");
 	if (needsFetchWrap) lines.push("  fetch: wrappedFetch,");
 	else lines.push("  fetch: original.fetch,");
 	if (features.crons.length > 0) lines.push(features.isr ? "  scheduled(controller, env, ctx) { env.__VOID_ISR_DEPLOYMENT_ID ??= __voidIsrDeploymentId; return handleScheduled(controller, env, ctx); }," : "  scheduled: handleScheduled,");

package/dist/{ws-CsBNxv86.d.mts → ws-nnFnAyQb.d.mts}

@@ -1,6 +1,6 @@
 import { t as StandardSchemaV1 } from "./standard-schema-Fo_vCAZh.mjs";
 import { r as AuthUser } from "./auth-DkcFflXV.mjs";
-import { a as CloudEnv } from "./handler-_PqY82xe.mjs";
+import { a as CloudEnv } from "./handler-D5K_yP6T.mjs";
 import { WebSocketRouteMap } from "void/routes";
 //#region src/runtime/ws.d.ts
 type MaybePromise<T> = T | Promise<T>;

package/docs/guide/deployment.md

@@ -35,6 +35,8 @@ void db generate
 
 Review and commit the SQL, then deploy again. Rollback does not reverse database migrations. See [Database](./database.md) for the local workflow.
 
+On your own Cloudflare account, deploy saves a D1 [Time Travel](https://developers.cloudflare.com/d1/reference/time-travel/) restore point before it applies pending migrations and prints the [`void db restore`](../reference/cli/database.md#void-db-restore) command for it. If no restore point can be saved, deploy stops before it migrates. If deploy fails after it applied the migrations, for example when the upload fails, it prints the command again. Usually you fix the error and deploy again; restore only if the live version cannot run against the new schema. To recover from a bad migration, roll back the code with `void project rollback` if the new version is live, restore the database, then fix or remove the migration before you deploy again. After a one-off `void deploy --platform cloudflare`, add `--platform cloudflare` to each of these commands. Restoring discards every write made after the restore point. Restore points expire after 7 days on Workers Free and 30 days on Workers Paid; after that, undo a migration with a new one.
+
 ### Environment variables
 
 Declare values in `env.ts` and set production server secrets with `void secret put`. Deploy never uploads your local `.env`. Supply public `VITE_*` values through the build environment. See [Environment Variables](./env-vars.md).

package/docs/guide/edge/headers.md

@@ -43,7 +43,7 @@ On a [Void platform](../deployment.md#deploy-to-a-team-platform), apps usually s
 
 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).
 
-In `void dev`, with `void deploy --platform cloudflare`, and on [other runtimes](../deployment.md#other-runtimes), header rules apply both headers as written.
+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/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.
 
-`void dev` has no local inbound trigger. It serves only the outbound dev inbox. 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` is deprecated. During `void dev` it skips the inbox and returns `BINDING_MISSING`, so it never delivers. Remove it, and 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/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/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/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/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.

package/docs/reference/cli/database.md

@@ -89,6 +89,21 @@ By default, targets the local database. Pass `--remote` to open Studio against t
 - **Direct Cloudflare PostgreSQL and MySQL projects**: use `DATABASE_URL` from the current shell.
 - **D1 projects**: remote Studio is not available. Use `void db execute --remote` to query your deployed D1 database.
 
+## `void db restore` {#void-db-restore}
+
+```
+void db restore --bookmark <bookmark> [--platform cloudflare] [--yes]
+void db restore --timestamp <iso-time> [--platform cloudflare] [--yes]
+```
+
+Restore the deployed D1 database of a direct Cloudflare deploy with D1 [Time Travel](https://developers.cloudflare.com/d1/reference/time-travel/). Before `void deploy --platform cloudflare` applies migrations, it prints the `--bookmark` that undoes them. `--timestamp` restores the state at an ISO 8601 time with `Z` or an offset instead, such as `2026-10-16T09:30:00Z`, with at most millisecond precision. Time Travel keeps 7 days of history on Workers Free and 30 days on Workers Paid. An older bookmark or time can no longer be restored: Cloudflare rejects it and the database stays unchanged. To undo an older migration, write a new migration that reverses it.
+
+If the project's saved destination is not Cloudflare and you deployed once with `void deploy --platform cloudflare`, pass `--platform cloudflare`; deploy prints the command with it.
+
+Restoring replaces the whole database and discards every write made after that point. Void names the database and asks before it restores. Pass `--yes` to skip the prompt in scripts and CI; without a terminal, the command stops unless `--yes` is set. Afterwards Void prints the `void db restore` command that undoes the restore.
+
+A restore also rewinds the record of applied migrations. Void lists the migration files the database no longer has applied; the next deploy applies them, so fix or remove the one that caused the problem first. Restoring does not change the deployed code: use [`void project rollback`](./project.md#void-project-rollback-deployid) if the live version needs the newer schema. After a one-off Cloudflare deploy, pass `--platform cloudflare` to `void project rollback` and `void deploy` as well.
+
 ## `void db rename-migrations` {#void-db-rename-migrations}
 
 Rename existing migrations from the old numeric prefix format (`0001_name.sql`) to timestamp-based format (`20260410161500_name.sql`). Updates local tracking table and remote records if logged in with a linked project. A project that deploys to Void must be linked first with `void project link`; otherwise the command stops without changes.

package/docs/reference/cli/platform-installation.md

@@ -137,6 +137,8 @@ After discovery on another machine, set `VOID_PLATFORM_DATABASE_URL`. See [Manag
 
 Repair and upgrade preserve disabled state. New, resumed, and previously disabled installations block user traffic until all target Workers pass verification; the installer's health probes can still run. Routes and custom domains remain attached.
 
+If a platform Worker was changed outside Void, or has an active version without a Void deployment record, a command that deploys the platform Workers stops before it changes a platform Worker or pauses traffic, unless you agree in a terminal to replace the changes. See [Platform Workers changed outside Void](../../guide/platform/installation/maintenance.md#workers-changed-outside-void).
+
 `--runtime` selects a custom platform build. Relative paths resolve from your current directory. Void verifies the build before making changes; see [Platform Development](../../guide/platform/development/runtime.md#deploying-your-runtime) for creating one.
 
 Without `--runtime`, the CLI uses its packaged platform version.

package/docs/reference/cli/project.md

@@ -169,7 +169,7 @@ void project requests --range 24h
 ## `void project rollback [deployId]` {#void-project-rollback-deployid}
 
 ```
-void project rollback [deployId]
+void project rollback [deployId] [--platform cloudflare]
 ```
 
 Roll back to a previous deployment or Worker Version.
@@ -179,7 +179,9 @@ Roll back to a previous deployment or Worker Version.
 
 On a Void platform, you can select a retained deployment. On Cloudflare, use a complete Worker Version ID or an unambiguous prefix. Void activates that version at 100%. When both versions have complete trigger snapshots, it also restores the selected version's schedules, queues, workflows, routes, and custom domains. Otherwise, rollback keeps the current triggers and restores the code, including versions originally deployed outside Void.
 
-Rollback doesn't reverse database migrations. If older code may run against a newer schema, or migration metadata is missing, Void explains the risk and asks for confirmation.
+If the project's saved destination is not Cloudflare and you deployed once with `void deploy --platform cloudflare`, pass `--platform cloudflare` to roll back that Worker.
+
+Rollback doesn't reverse database migrations. If older code may run against a newer schema, or migration metadata is missing, Void explains the risk and asks for confirmation. On Cloudflare, undo D1 migrations with [`void db restore`](./database.md#void-db-restore) and the restore point that deploy printed before it applied them, within 7 days on Workers Free or 30 days on Workers Paid.
 
 ## `void project cancel [deployId]` {#void-project-cancel-deployid}
 

package/docs/reference/cli.md

@@ -47,6 +47,7 @@ Use this page as a command reference. If you are setting up a project for the fi
 | `void db seed`                    | Reset + seed local database                                                   |
 | `void db execute <sql>`           | Run SQL against the database (--remote for deployed)                          |
 | `void db studio`                  | Open Drizzle Studio (--remote for a deployed external database)               |
+| `void db restore --bookmark <b>`  | Restore the deployed D1 database to a restore point (direct Cloudflare)       |
 | `void secret put <name=value>`    | Set a production secret                                                       |
 | `void secret list`                | List production secrets                                                       |
 | `void secret sync <file>`         | Bulk upload secrets from dotenv file                                          |

package/docs/reference/config.md

@@ -512,7 +512,7 @@ Each binding accepts `true` (use default name), `false` (disable), or a string (
 
 Custom binding names work with `void/db`, `void/kv`, and `void/storage` during development and deployment. Custom AI names also work with `void/ai` on direct Cloudflare deploys; managed Workers AI uses the platform's proxy.
 
-`email` is a boolean feature switch. Set it to `true` to enable [email](../guide/email.md) and the `void dev` inbox without an import from `void/email`, or `false` to disable them. On a Void platform, sending uses the platform proxy. Direct Cloudflare setup records a `SEND_EMAIL` binding in `void.lock.json`; see [`email.from`](#email).
+`email` is a boolean feature switch. Set it to `true` to enable [email](../guide/email.md) and the local email inbox without an import from `void/email`, or `false` to disable them. On a Void platform, sending uses the platform proxy. Direct Cloudflare setup records a `SEND_EMAIL` binding in `void.lock.json`; see [`email.from`](#email).
 
 #### `inference.build`
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "void",
-  "version": "1.1.11",
+  "version": "1.1.12",
   "description": "Full-stack framework and deployment CLI for Cloudflare Workers, powered by Vite.",
   "homepage": "https://void.cloud",
   "bugs": {
@@ -37,6 +37,7 @@
     "#self/sandbox": "./dist/runtime/sandbox.mjs",
     "#self/runtime/live-server": "./dist/runtime/live-server.mjs",
     "#self/runtime/fetch": "./dist/runtime/fetch.mjs",
+    "#self/runtime/fetch-server": "./dist/runtime/fetch-server.mjs",
     "#self/runtime/fetch-stream": "./dist/runtime/fetch-stream.mjs",
     "#self/runtime/route-url": "./dist/runtime/route-url.mjs",
     "#self/runtime/migration-handler": "./dist/runtime/migration-handler.mjs",
@@ -347,11 +348,11 @@
     "@cloudflare/workers-auth": "^0.14.0",
     "@cloudflare/workers-types": "^5.20261014.1",
     "@napi-rs/keyring": "^2.1.1",
-    "@void/deploy-cloudflare": "1.1.11",
-    "@void/deploy-core": "1.1.11",
-    "@void/edge": "1.1.11",
-    "@void/isr": "1.1.11",
-    "@void/platform": "1.1.11",
+    "@void/deploy-cloudflare": "1.1.12",
+    "@void/deploy-core": "1.1.12",
+    "@void/edge": "1.1.12",
+    "@void/isr": "1.1.12",
+    "@void/platform": "1.1.12",
     "better-auth": "^1.7.7",
     "better-sqlite3": "^13.0.3",
     "blake3-jit": "^1.1.0",
@@ -400,7 +401,7 @@
     "zod": "^4.6.7"
   },
   "peerDependencies": {
-    "@void/md": "1.1.11",
+    "@void/md": "1.1.12",
     "arktype": ">=2.0.0",
     "valibot": ">=1.0.0-beta.7",
     "vite": "^8.0.0",

package/dist/cf-build-output-BU3hqdHu.mjs

@@ -1 +0,0 @@
-export { t as prepareCfBuildOutput } from "./cf-build-output-Bc8i3dzE.mjs";

package/dist/client-DrdeJgHR.mjs

@@ -1 +0,0 @@
-export { r as PlatformClient } from "./client-GuSO3v_x.mjs";

package/dist/deploy-CxNgEYr4.mjs

@@ -1,2 +0,0 @@
-import "./deploy-transport-nY3vLXPL.mjs";
-export { i as checkWranglerMigrationApplySet, t as parseRootWranglerConfig, r as runDeploy } from "./deploy-DsW-PrRQ.mjs";