void 0.24.0 → 0.25.0

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

@@ -6,6 +6,12 @@ outline: deep
 
 Use a Cloudflare Sandbox to run commands, work with files, and connect to servers from server code. Each Sandbox ID selects an isolated container.
 
+## Requirements
+
+Cloudflare deployments require [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans) and Containers access. Run Docker for local development and direct deployments that build an image. A team platform's runtime token needs Account / Containers: Edit and Account / Cloudchamber: Edit.
+
+## Run a command
+
 ```ts
 import { defineHandler } from 'void';
 import { getSandbox } from 'void/sandbox';
@@ -23,46 +29,7 @@ export const POST = defineHandler(async (c) => {
 });
 ```
 
-Importing from `void/sandbox` enables the required resources. Local development, native Cloudflare deployments, and Void Platform share the same runtime API.
-
-## Configuration
-
-The default environment provides Node.js 24 on Debian Trixie. Local development and native deploys need Docker running. Managed platform deploys use Cloudflare's managed Node.js image.
-
-Use `void.config.ts` when you need a custom image or container size:
-
-```ts
-import { defineConfig } from 'void/config';
-
-export default defineConfig({
-  sandbox: {
-    image: './Dockerfile.sandbox',
-    platformImage: 'registry.cloudflare.com/<account-id>/sandbox@sha256:<digest>',
-    instanceType: 'standard-1',
-  },
-});
-```
-
-| Field               | Default                     | Description                                                          |
-| ------------------- | --------------------------- | -------------------------------------------------------------------- |
-| `binding`           | `SANDBOX`                   | Binding name for local and native Cloudflare use                     |
-| `className`         | `SandboxV1`                 | Durable Object class for local and native Cloudflare use             |
-| `containerName`     | `void-sandbox-v1`           | Cloudflare container application name                                |
-| `image`             | Packaged Node.js Dockerfile | Dockerfile or digest-pinned Cloudflare registry image for native use |
-| `imageBuildContext` | Directory of `image`        | Docker build context                                                 |
-| `platformImage`     | `cloudflare/debian-trixie`  | Image used by managed platform deploys                               |
-| `instanceType`      | `lite`                      | `lite`, `standard-1`, `standard-2`, `standard-3`, or `standard-4`    |
-
-Custom images must include the helper matching Void's installed Sandbox SDK version. The SDK image supplies this binary, but is not a runnable environment itself:
-
-```dockerfile
-FROM node:24.21.0-trixie-slim
-COPY --from=docker.io/cloudflare/sandbox:1.0.0 /usr/local/bin/sandbox-shim /usr/local/bin/sandbox-shim
-WORKDIR /workspace
-CMD ["sleep", "infinity"]
-```
-
-For a managed platform, push your custom image to that platform account's Cloudflare registry and set `platformImage` to its digest-pinned reference. If `image` is already a Cloudflare registry reference, it also becomes the default `platformImage`. External registries and mutable tags are not supported. See [Cloudflare's image management guide](https://developers.cloudflare.com/containers/guides/image-management/#push-images-to-the-cloudflare-registry).
+Importing from `void/sandbox` enables the required resources. Local development, direct Cloudflare deployments, and team platforms share the same runtime API.
 
 ## Runtime API
 
@@ -109,14 +76,37 @@ The `limited` handler receives `resource: 'sandbox'`, a `reason` of `concurrency
 
 Files, running processes, and listening servers last only as long as the container. It can stop after inactivity, crash, or restart. Save anything you need to keep in your database, KV, or R2. Deleting a project on a Void platform removes both its Durable Objects and containers.
 
-## Deployment
+## Configuration
 
-Sandboxes require [Workers Paid](https://dash.cloudflare.com/?to=/:account/workers/plans) and Containers access. A managed platform's runtime token needs Account / Containers: Edit and Account / Cloudchamber: Edit.
+The default environment provides Node.js 24 on Debian Trixie. Managed platform deploys use Cloudflare's managed Node.js image.
 
-`void deploy --platform cloudflare` builds native images and deploys the Sandbox alongside the application. `void deploy` on a connected Void Platform applies the platform's Sandbox concurrency and runtime limits. Upgrade the platform before deploying an application built with this Sandbox API.
+Use `void.config.ts` when you need a custom image or container size:
 
-## Moving from Sandbox SDK 0.x
+```ts
+import { defineConfig } from 'void/config';
 
-Update string commands to argument arrays, move file calls under `.files`, and consume process output and file responses as shown above. Replace `sleepAfter` and `keepAlive` with `inactivityTimeoutMs`; remove `maxInstances` from configuration. The old `Sandbox` export, sessions, code interpreter, process-list helpers, and preview-URL helpers are no longer part of this API.
+export default defineConfig({
+  sandbox: {
+    image: './Dockerfile.sandbox',
+    platformImage: 'registry.cloudflare.com/<account-id>/sandbox@sha256:<digest>',
+    instanceType: 'standard-1',
+  },
+});
+```
+
+See the [configuration reference](../reference/config.md#sandbox) for binding names, image settings, and container sizes.
+
+Custom images must include the helper matching Void's installed Sandbox SDK version. The SDK image supplies this binary, but is not a runnable environment itself:
+
+```dockerfile
+FROM node:24.21.0-trixie-slim
+COPY --from=docker.io/cloudflare/sandbox:1.0.0 /usr/local/bin/sandbox-shim /usr/local/bin/sandbox-shim
+WORKDIR /workspace
+CMD ["sleep", "infinity"]
+```
+
+For a managed platform, push your custom image to that platform account's Cloudflare registry and set `platformImage` to its digest-pinned reference. If `image` is already a Cloudflare registry reference, it also becomes the default `platformImage`. External registries and mutable tags are not supported. See [Cloudflare's image management guide](https://developers.cloudflare.com/containers/guides/image-management/#push-images-to-the-cloudflare-registry).
+
+## Deployment
 
-Existing native 0.x Sandboxes need a new Worker configuration and namespace. Back up container files and any Durable Object data, choose a fresh `worker.name`, and remove the old Sandbox bindings, containers, and migrations from that new configuration before deploying. The new default class is `SandboxV1`; existing state does not transfer automatically. Retain the old Worker until you have validated the replacement and restored your data, then clean up its resources. See [Cloudflare's scheduling-policy migration guide](https://developers.cloudflare.com/containers/guides/migrate-to-durable-object-scheduling-policy/).
+`void deploy --platform cloudflare` builds native images and deploys the Sandbox alongside the application. `void deploy` on a connected Void Platform applies the platform's Sandbox concurrency and runtime limits.

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

@@ -12,6 +12,26 @@ The core platform supports GitHub, Google, generic OIDC, and Cloudflare Access l
 
 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, build Containers, and custom project domains aren't part of the core installation. 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.
 
+## Deployment features
+
+Both targets use the same application APIs. A core platform adds shared access and retained deployment history:
+
+| Feature                                          | Direct Cloudflare                | Core self-hosted platform                     |
+| ------------------------------------------------ | -------------------------------- | --------------------------------------------- |
+| Static sites, SPAs, and native Pages SSR         | Supported                        | Supported                                     |
+| Routing rules, WebSockets, queues, cron, and ISR | Supported                        | Supported                                     |
+| D1, KV, R2, and external SQL through Hyperdrive  | Supported                        | Supported                                     |
+| Workers AI and provider requests                 | Your account and gateway         | Installation gateway and proxy                |
+| Runtime logs                                     | Live Cloudflare tail             | Retained platform logs                        |
+| Application rollback                             | Worker versions                  | Retained platform deployments                 |
+| Typed Durable State                              | Supported                        | Unavailable                                   |
+| Sandboxes                                        | Requires Workers Paid and Docker | Requires Workers Paid on the platform account |
+| Custom application domains                       | Supported                        | Unavailable in the core installation          |
+| 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       |
+
+A team platform requires Workers for Platforms and the [documented infrastructure](/guide/platform/installation/domains#cloudflare-footprint). Features depend on the installation's configuration.
+
 ## Installation Guides
 
 - [Prerequisites](/guide/platform/installation/prerequisites)

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

@@ -202,8 +202,6 @@ Both `defineRoom()` and `defineWebSocket()` accept optional `name`. Use a static
 
 By default, the instance key includes parameter names. `/chat/:room` with `room: 'general'` uses `room=general`; a route without parameters uses `default`. Multiple parameters are joined in route order, for example `team=acme&room=general`. If a multi-parameter route has a value containing `&`, its key uses a versioned encoding to keep rooms separate.
 
-When upgrading an existing multi-parameter route with `&` in its parameter values, those rooms start with isolated storage. The previous storage is retained, but may have been shared by multiple rooms. Migrate only data whose ownership you have verified into each new room. Single-parameter rooms and multi-parameter rooms without `&` keep their existing identities.
-
 If you also rename `[room]` to `[id]`, preserve the old key explicitly:
 
 ```ts

package/skills/void/docs/integrations/frameworks/overview.md

@@ -36,11 +36,11 @@ With `voidPlugin()` added to the framework's Vite config, frameworks get most of
 - **Auth:** Void-managed auth is not supported in framework mode yet. For now, use Better Auth's official integration for your framework.
 - **Cron jobs:** scheduled handlers via the `crons/` directory.
 - **Queue consumers:** typed producers and consumers via the `queues/` directory.
-- **Revalidation and prerendering:** configure them with [`routing.revalidate`](../../guide/edge/revalidation.md) and [`routing.prerender`](../../guide/edge/prerendering.md) in `void.config.ts`. Void apps can also set these per page in component files.
+- **Revalidation and prerendering:** configure them with [`routing.revalidate`](../../guide/edge/revalidation.md) and [`routing.prerender`](../../guide/edge/prerendering.md) in `void.config.ts`. Void apps can also set these per page in companion `.server.ts` files.
 
 For framework apps, Void revalidation caches public HTML document responses with both `void deploy` and `void deploy --platform cloudflare`. Client data requests continue to use the framework's own behavior. A response with `Set-Cookie` or `Cache-Control: private`, `no-store`, or `no-cache` is never shared.
 
-Frameworks can also access bindings directly via the framework's own mechanisms (e.g. `platform.env` in SvelteKit, `event.context.cloudflare.env` in Nuxt, `env` from `cloudflare:workers` in Analog, `Astro.locals.runtime.env` in Astro).
+Frameworks can also access bindings directly via the framework's own mechanisms (e.g. `env` from `cloudflare:workers` in SvelteKit 3 and Analog, `platform.env` in SvelteKit 2, `event.context.cloudflare.env` in Nuxt, `Astro.locals.runtime.env` in Astro).
 
 ## Configuration
 

package/skills/void/docs/integrations/frameworks/sveltekit.md

@@ -6,6 +6,8 @@ outline: deep
 
 Use Void with [SvelteKit](https://svelte.dev/docs/kit) for resource detection, typed database queries, and migrations. SvelteKit keeps its own build and Cloudflare integration; Void plugs into its Vite configuration.
 
+Void supports SvelteKit 3 and SvelteKit 2.62 or later. The setup below uses SvelteKit 3 with `@sveltejs/adapter-cloudflare` 8.
+
 ## Setup
 
 ### 1. Create a new project
@@ -27,10 +29,8 @@ npm install -D @sveltejs/adapter-cloudflare void
 import adapter from '@sveltejs/adapter-cloudflare';
 import { sveltekit } from '@sveltejs/kit/vite';
 import { voidPlugin } from 'void';
-import { withVoidTSConfig } from 'void/sveltekit';
-import { defineConfig } from 'vite';
 
-export default defineConfig({
+export default {
   plugins: [
     voidPlugin(),
     sveltekit({
@@ -38,16 +38,11 @@ export default defineConfig({
         config: './.void-wrangler.jsonc',
         platformProxy: { configPath: './.void-wrangler.jsonc' },
       }),
-      typescript: {
-        config: withVoidTSConfig(),
-      },
     }),
   ],
-});
+};
 ```
 
-If your project already configures SvelteKit in `svelte.config.js`, keep that file and add `typescript.config: withVoidTSConfig()` under its `kit` options instead. SvelteKit ignores `svelte.config.js` when options are passed directly to `sveltekit()`.
-
 ### 4. Create `void.config.ts`
 
 Point SvelteKit's adapter at Void's generated Cloudflare config as shown above. Add your Cloudflare settings to `void.config.ts`:
@@ -66,20 +61,19 @@ export default defineConfig({
 
 ### 5. Configure `tsconfig.json`
 
-Extend SvelteKit’s generated config. The `withVoidTSConfig()` hook in the Vite config above adds Void’s types and aliases:
-
-Keep `compilerOptions.paths` out of the root config so it does not override SvelteKit’s aliases.
+Extend SvelteKit’s generated config and Void’s generated types and database aliases:
 
 ```json
 {
-  "extends": "./.svelte-kit/tsconfig.json",
+  "extends": ["$app/tsconfig", "./.void/tsconfig.json"],
   "compilerOptions": {
-    "types": ["void/env"]
-  }
+    "types": ["$app/types", "void/env"]
+  },
+  "include": ["src", "db", "crons", "queues", "*.ts"]
 }
 ```
 
-Run `void prepare` after a fresh clone or before typechecking in CI so `.void/tsconfig.json` exists before SvelteKit syncs its config.
+Run `void prepare` after a fresh clone or before typechecking in CI so `.void/tsconfig.json` exists before SvelteKit syncs its config. Use `package.json` subpath imports for aliases such as SvelteKit 3's `#lib`.
 
 ### 6. Deploy
 
@@ -116,20 +110,41 @@ Declare variables in `env.ts` and read them with `import { env } from "void/env"
 
 ## Accessing Bindings Directly
 
-You can also use SvelteKit's `platform.env` in server hooks and load functions:
+In SvelteKit 3, use the `cloudflare:workers` module in server-side code:
 
 ```ts
-// src/routes/users/+page.server.ts
-export async function load({ platform }) {
-  const { results } = await platform.env.DB.prepare('SELECT * FROM users').all();
-  return { users: results };
-}
+import { env } from 'cloudflare:workers';
+
+const { results } = await env.DB.prepare('SELECT * FROM users').all();
 ```
 
-Or the `cloudflare:workers` module:
+## Existing SvelteKit 2 apps
+
+Use SvelteKit 2.62 or later with `@sveltejs/adapter-cloudflare` 7. The Vite configuration above also works with Kit 2; add Void's tsconfig hook to the `sveltekit()` options:
 
 ```ts
-import { env } from 'cloudflare:workers';
+import { withVoidTSConfig } from 'void/sveltekit';
 
-const { results } = await env.DB.prepare('SELECT * FROM users').all();
+sveltekit({
+  adapter: adapter({
+    config: './.void-wrangler.jsonc',
+    platformProxy: { configPath: './.void-wrangler.jsonc' },
+  }),
+  typescript: {
+    config: withVoidTSConfig(),
+  },
+});
+```
+
+Keep the Kit 2 tsconfig setup:
+
+```json
+{
+  "extends": "./.svelte-kit/tsconfig.json",
+  "compilerOptions": {
+    "types": ["void/env"]
+  }
+}
 ```
+
+If your app uses `svelte.config.js` or `svelte.config.ts`, keep its configuration and add `typescript.config: withVoidTSConfig()` under `kit`. Kit 2's `platform.env` remains available in hooks and load functions.

package/skills/void/docs/integrations/nodejs-bun-deno.md

@@ -89,12 +89,17 @@ These Void features work identically across all targets:
 - [Typed fetch client](../guide/typed-fetch.md) (`void/client`)
 - [Custom headers](../guide/edge/headers.md) (`routing.headers`)
 - [Redirects](../guide/edge/redirects.md) (`routing.redirects`)
-- [Environment variables](../guide/env-vars.md) (`.env` files)
 - [Static site generation](../guide/ssg.md)
 - [Vite preview](https://vite.dev/guide/cli#vite-preview) for testing production builds locally
 
 ## What's Different
 
+### Environment variables
+
+Supply server values through your host's environment and read them with `process.env` in Node.js or Bun, or `Deno.env.get()` in Deno. The `void/env` schema and secret workflow requires Cloudflare.
+
+For browser code, use Vite's `import.meta.env.VITE_*` values. These are embedded at build time and must not contain secrets.
+
 ### No Cloudflare bindings
 
 The following imports are **not available** with a non-CF target and produce a compile-time error:
@@ -106,7 +111,7 @@ The following imports are **not available** with a non-CF target and produce a c
 | `void/storage` | R2 (blob storage)        |
 | `void/auth`    | Void-managed Better Auth |
 | `void/ai`      | Workers AI               |
-| `void/env`     | CF env type augmentation |
+| `void/env`     | Typed environment schema |
 
 If you need a database or storage, use an external provider and connect via standard Node.js libraries.
 

package/skills/void/docs/reference/api/resources.md

@@ -70,6 +70,33 @@ const response = await ai
 
 **Key exports:** `ai`, `VoidAi`, provider request types. See [AI](../../guide/ai.md) for provider setup and streaming examples.
 
+### Provider keys
+
+Default secret names for `ai.provider()`. Use `apiKeyEnv` to choose another name.
+
+| Provider prefix    | Env var               |
+| ------------------ | --------------------- |
+| `openai`           | `OPENAI_API_KEY`      |
+| `anthropic`        | `ANTHROPIC_API_KEY`   |
+| `google-ai-studio` | `GOOGLE_API_KEY`      |
+| `deepseek`         | `DEEPSEEK_API_KEY`    |
+| `groq`             | `GROQ_API_KEY`        |
+| `mistral`          | `MISTRAL_API_KEY`     |
+| `grok`             | `GROK_API_KEY`        |
+| `openrouter`       | `OPENROUTER_API_KEY`  |
+| `perplexity`       | `PERPLEXITY_API_KEY`  |
+| `cohere`           | `COHERE_API_KEY`      |
+| `cerebras`         | `CEREBRAS_API_KEY`    |
+| `huggingface`      | `HUGGINGFACE_API_KEY` |
+| `replicate`        | `REPLICATE_API_KEY`   |
+| `baseten`          | `BASETEN_API_KEY`     |
+| `cartesia`         | `CARTESIA_API_KEY`    |
+| `deepgram`         | `DEEPGRAM_API_KEY`    |
+| `elevenlabs`       | `ELEVENLABS_API_KEY`  |
+| `fal`              | `FAL_API_KEY`         |
+| `ideogram`         | `IDEOGRAM_API_KEY`    |
+| `parallel`         | `PARALLEL_API_KEY`    |
+
 ## ISR {#isr}
 
 Imported from `"void/isr"`.

package/skills/void/docs/reference/api.md

@@ -49,7 +49,7 @@ Import Void's app-facing APIs from these paths:
 | `void/response`           | `convertReturnValue`                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
 | `void/validator`          | `runValidation`, `ValidatorSlots`, `HandlerInput`                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | `void/drizzle-zod`        | Re-exports [`drizzle-zod`](https://orm.drizzle.team/docs/zod) for schema-derived Zod validators for Drizzle tables                                                                                                                                                                                                                                                                                                                                                                 |
-| `void/drizzle-valibot`    | Re-exports [`drizzle-valibot`](https://orm.drizzle.team/docs/typebox) for schema-derived Valibot validators for Drizzle tables                                                                                                                                                                                                                                                                                                                                                     |
+| `void/drizzle-valibot`    | Re-exports [`drizzle-valibot`](https://orm.drizzle.team/docs/valibot) for schema-derived Valibot validators for Drizzle tables                                                                                                                                                                                                                                                                                                                                                     |
 | `void/drizzle-arktype`    | Re-exports [`drizzle-arktype`](https://orm.drizzle.team/docs/arktype) for schema-derived ArkType validators for Drizzle tables                                                                                                                                                                                                                                                                                                                                                     |
 | `void/schema-d1`          | Re-exports [`drizzle-orm/sqlite-core`](https://orm.drizzle.team/docs/column-types/sqlite) for D1 table and column builders                                                                                                                                                                                                                                                                                                                                                         |
 | `void/schema-pg`          | Re-exports [`drizzle-orm/pg-core`](https://orm.drizzle.team/docs/column-types/pg) for PostgreSQL table and column builders                                                                                                                                                                                                                                                                                                                                                         |

package/skills/void/docs/reference/cli/deploy.md

@@ -18,7 +18,7 @@ Deploying to a Void platform requires an explicit connection with `void connect
 A saved project URL or `VOID_API_URL` alone does not establish a connection.
 In fresh CI environments, run `void connect "$VOID_API_URL" --no-login` first.
 
-On an upgraded Void platform, an accepted deployment continues if the CLI disconnects. The CLI automatically reconnects to its progress. Pressing Ctrl+C stops observation; use `void project cancel` to request cancellation and `void project status` to inspect the result. If interrupted execution requires recovery, wait for its result before deploying again.
+On a Void platform, an accepted deployment continues if the CLI disconnects. The CLI automatically reconnects to its progress. Pressing Ctrl+C stops observation; use `void project cancel` to request cancellation and `void project status` to inspect the result. If interrupted execution requires recovery, wait for its result before deploying again.
 
 The CLI reports stalled progress and automatic recovery, and waits up to 30 minutes after acceptance. If it times out, the deployment can continue; check `void project status` before trying another deployment.
 

package/skills/void/docs/reference/cli/platform-operations.md

@@ -17,11 +17,7 @@ void platform deployment migrate-assets <id> [--cursor <cursor>] [--plan|--yes]
 
 Cancellation applies while a deployment is pending, uploading, migrating, or prerendering, and can be requested again while it is canceling. A deployment that has begun switching traffic, is compensating for a failure, or has finished cannot be canceled through this command.
 
-`migrate-assets` copies legacy assets to scoped R2 storage, verifies their contents, and updates each batch only after all its assets are verified. Original assets remain in place, and application traffic stays on the same deployment. Upgrade the platform runtime before using this command. Migrate both active deployments and retained rollback deployments before removing support for older asset storage.
-
-Use `--plan` to preview the first batch. Applying authorizes all remaining batches for that deployment; the CLI previews each batch and prints its result, including `nextCursor`. With `--json`, results are JSON Lines. If a later batch fails or the command is interrupted, resume with the cursor from the last successful result. An ambiguous request is never retried automatically; inspect the deployment before resuming. A completed migration reports `complete: true` and `nextCursor: null`.
-
-Use [`void platform system asset-migrations`](#operator-system) to find deployments requiring migration. Inspect every inventory page, migrate each deployment with `needsMigration` greater than zero, then inspect every page again. Include retained rollback deployments and stored bundles. Investigate rows marked `invalid` before considering migration complete. Keep the older asset readers until the full inventory is valid and no protected deployment needs migration.
+`migrate-assets` copies a deployment's legacy assets to scoped R2 storage without changing application traffic. Use `--plan` to preview and `--cursor` to resume from a successful batch. Original assets remain in place.
 
 Read its runtime logs with:
 
@@ -44,7 +40,7 @@ void platform build logs <id> [--since <sequence>] [--limit <n>] [--follow]
 
 Build logs start at sequence `0` and return up to 500 lines. Use the returned `lastSeq` as `--since` to continue; `--limit` accepts 1 to 500. Container log retrieval requires managed builds to be enabled. GitHub Actions builds return an external log URL.
 
-Following waits for the final logs after the build becomes terminal. If completion cannot be confirmed within two minutes, the command exits with an error. Older builds without a completion signal may wait for 30 seconds without new lines before following stops.
+Following waits for the final logs after the build becomes terminal. If completion cannot be confirmed within two minutes, the command exits with an error.
 
 ## System {#operator-system}
 
@@ -62,11 +58,11 @@ void platform system sandbox-drain [--cursor <opaque-cursor>]
 
 `overview` shows platform totals and recent activity. `health` checks the configured services and database, and exits with a nonzero status if a check fails. `cli-versions` reports the CLI versions used by deployments.
 
-`asset-migrations` inventories active deployments, retained rollback deployments, and deployments with stored bundles. It reports their asset counts, `needsMigration`, and an `invalid` flag for unreadable metadata. Read all pages using the response's pagination fields. Migrate each deployment with `needsMigration` greater than zero through [`deployment migrate-assets`](#operator-deployments), then rerun the full inventory. Migration keeps the original assets; removing those assets or their older readers requires separate verification.
+`asset-migrations` inventories stored deployment assets and reports `needsMigration` and `invalid` counts. Use the response's pagination fields to read all entries.
 
 `events` shows the administrator, target, and outcome of changes. A pending event means the outcome has not been recorded. Previews and session login/logout do not create these events. `backfill-queue-tokens` repairs older queue entries that are missing authentication tokens and supports `--plan` before applying the repair.
 
-Use `sandbox-drain` when an upgrade from the legacy tenant-owned Sandbox runtime asks you to finish cleanup. Preview with `--plan`; pass the returned `nextCursor` as `--cursor` to inspect later pages. Apply with `--yes` and rerun until it reports `complete: true`, then rerun the interrupted upgrade. Application traffic stays paused during cleanup, while administrator login remains available. The completed upgrade enables the current managed Sandbox controller automatically.
+`sandbox-drain` removes legacy tenant-owned Sandbox resources. Use `--plan` to preview and `--yes` to apply, then pass `nextCursor` as `--cursor` to continue. Application traffic stays paused during cleanup.
 
 Use the [platform lifecycle commands](./platform-installation.md#lifecycle-commands) to maintain your installation's Workers.
 

package/skills/void/docs/reference/cli/platform.md

@@ -16,6 +16,11 @@ void platform status [id]
 
 `use` and `status` auto-select the only configured platform; with multiple platforms they show a picker interactively and require an id or URL in non-interactive use. A project with a recorded platform URL keeps using that platform when the global default changes.
 
+For a self-hosted installation, `status <installation-id>` prints locally saved
+lifecycle progress before checking the live API. The saved checkpoint may be out
+of date. If live discovery fails during maintenance, the command still shows that
+checkpoint and exits with an error; it does not confirm current availability.
+
 ## Operator commands {#operator-commands}
 
 Use `void platform` to administer the users and apps on your selected platform. Start with the [Platform Administration guide](../../guide/platform-administration.md) for signing in, giving people access, and investigating deployments.

package/skills/void/docs/reference/resource-inference.md

@@ -27,7 +27,7 @@ Durable state is inferred from files in `durable-objects/`. For example, `durabl
 
 ### Standard mode
 
-When using Void's built-in routing (no meta-framework), these directories are scanned:
+Native Void apps scan these directories by default. With [`sourceDir`](./config.md#sourcedir) configured, Void scans that source tree instead:
 
 | Directory     | Contains                                    |
 | ------------- | ------------------------------------------- |
@@ -36,10 +36,12 @@ When using Void's built-in routing (no meta-framework), these directories are sc
 | `queues/`     | Queue consumers                             |
 | `pages/`      | Page components and `.server.ts` companions |
 | `crons/`      | Scheduled job handlers                      |
+| `email/`      | Inbound email handlers                      |
+| `src/`        | Application source                          |
 
 ### Framework mode
 
-When a meta-framework is detected (TanStack Start, React Router, SvelteKit, Nuxt, or Astro), a broader set of directories is scanned instead:
+For [supported meta frameworks](../integrations/frameworks/overview.md), Void scans these directories:
 
 | Directory | Contains                |
 | --------- | ----------------------- |
@@ -47,17 +49,18 @@ When a meta-framework is detected (TanStack Start, React Router, SvelteKit, Nuxt
 | `app/`    | Framework app directory |
 | `routes/` | Framework routes        |
 | `server/` | Server-side code        |
+| `pages/`  | Framework pages         |
+| `crons/`  | Scheduled job handlers  |
+| `queues/` | Queue consumers         |
 
-Framework detection checks `package.json` for `@tanstack/react-start`, `@react-router/dev`, `@sveltejs/kit`, `nuxt`, or `astro` in dependencies.
-
-For SvelteKit, Nuxt, and Astro, add `voidPlugin()` to the framework's Vite config to enable inference during dev. See [Frameworks Integration](../integrations/frameworks/overview.md) for setup details.
+Framework detection uses `package.json` dependencies and dev dependencies. Add `voidPlugin()` to your framework's Vite config to enable inference during development. The integration guides show the setup for each framework.
 
 ### Always scanned
 
 Regardless of mode, these are always checked:
 
 - **SSR entry** such as `src/main.ssr.ts`, for SSR apps that access bindings during rendering
-- **`src/`**, which is always scanned for auth imports unless it is already in the scan list for framework mode
+- **Application source** in `src/` or your configured `sourceDir`, including resource and auth imports
 - **`durable-objects/`**, which is scanned for typed Durable Object state modules in native Void apps
 
 ## Custom Scan Directories
@@ -72,7 +75,7 @@ If your project organizes code in non-standard directories, you can override whi
 }
 ```
 
-Paths are relative to the project root. When `inference.scanDirs` is set, it replaces the default directories entirely. Defaults for the current mode are not merged in. The SSR entry and `src/` auth scan still apply either way.
+Paths are relative to the project root. When `inference.scanDirs` is set, it replaces the default directories entirely. The SSR entry and application source scan still apply.
 
 ## Explicit Binding Overrides
 
@@ -95,4 +98,4 @@ Explicit values override only their named bindings. Omitted bindings continue to
 
 ## File Types
 
-Inference scans files matching `**/*.{ts,tsx,mts,js,jsx,mjs}` within each directory. Non-JS files (CSS, HTML, images) are ignored.
+Inference scans `.ts`, `.tsx`, `.mts`, `.js`, `.jsx`, `.mjs`, and Astro frontmatter. Put server resource imports in these files or a page's `.server.ts` companion; Vue and Svelte component files are not scanned directly.

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

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

package/dist/client-B9UBI03V.mjs

@@ -1,2 +0,0 @@
-import { n as PlatformClient } from "./client-DKAsFA4X.mjs";
-export { PlatformClient };

package/dist/deploy-irP5q0-x.mjs

@@ -1,2 +0,0 @@
-import { A as parseRootWranglerConfig, J as runDeploy, f as checkWranglerMigrationApplySet } from "./deploy-gCVaiJbS.mjs";
-export { checkWranglerMigrationApplySet, parseRootWranglerConfig, runDeploy };

package/dist/gen-DvQTWzDU.mjs

@@ -1,2 +0,0 @@
-import { r as runGenCommand } from "./gen-CshAkukR.mjs";
-export { runGenCommand };

package/dist/help-mabuIV98.mjs

@@ -1,2 +0,0 @@
-import { r as printHelpPage } from "./help-Dotbf6iz.mjs";
-export { printHelpPage };

package/dist/login-DIy9Sb-U.mjs

@@ -1,2 +0,0 @@
-import { r as selectPlatformLoginMethod } from "./login-BuiMyUrx.mjs";
-export { selectPlatformLoginMethod };

package/dist/migrate-BCiJ8w0f.mjs

@@ -1,2 +0,0 @@
-import { n as runMigrateCommand } from "./migrate-q4_njtaW.mjs";
-export { runMigrateCommand };

package/dist/platform-args-DdnM6WIf.mjs

@@ -1,2 +0,0 @@
-import { t as parsePlatformArgs } from "./platform-args-3k8X9-H_.mjs";
-export { parsePlatformArgs };

package/dist/platform-management-DG47jys8.mjs

@@ -1,2 +0,0 @@
-import { c as selectAuthoritativePlatformManifest, s as runInstalledPlatformCommand, u as verifyPlatformInstallationOwnership } from "./platform-management-CWOQOWXm.mjs";
-export { runInstalledPlatformCommand, selectAuthoritativePlatformManifest, verifyPlatformInstallationOwnership };

package/skills/void/docs/guide/env-migration.md

@@ -1,109 +0,0 @@
-# Environment migration
-
-Use `.env` for local development and remote secrets for server-side production values.
-
-## 1. Back up and consolidate values
-
-Before changing any dotenv files, securely back up the production values you need to migrate outside the project directory. Keep them out of Git. Do not delete the original files until the upload and verification in step 3 succeed.
-
-Merge the values you still need locally into `.env`:
-
-```text
-.env.local
-.env.development
-.env.development.local
-→ .env
-```
-
-Keep the legacy files for now. You will remove them in step 5, after migrating their values.
-
-Ensure `.env` is ignored by Git:
-
-```text
-.env
-```
-
-## 2. Update `env.ts`
-
-Remove `.secret()` and `.public()` from `env.ts` before running secret commands.
-
-Change:
-
-```ts
-export default defineEnv({
-  STRIPE_KEY: string().secret(),
-  VITE_API_ORIGIN: url().public(),
-});
-```
-
-to:
-
-```ts
-export default defineEnv({
-  STRIPE_KEY: string(),
-  VITE_API_ORIGIN: url(),
-});
-```
-
-Server keys have no `VITE_` prefix; client keys do.
-
-## 3. Upload server secrets
-
-For managed Void projects, upload each non-client schema key:
-
-```sh
-void secret put DATABASE_URL
-void secret put STRIPE_KEY
-```
-
-To migrate a production file in one pass, prepare a copy outside the project directory containing only server keys declared in `env.ts`, then upload it:
-
-```sh
-void secret sync /secure/path/production-secrets.txt
-```
-
-The sync command validates every entry against `env.ts`. It rejects undeclared names, invalid values, and client-prefixed names. Keep client-prefixed values for step 4 instead of including them in this file.
-
-For direct Cloudflare deployments, select Cloudflare and use the same commands:
-
-```sh
-void connect --platform cloudflare
-void secret put DATABASE_URL
-void secret put STRIPE_KEY
-```
-
-After the upload succeeds, confirm that all expected server names appear in the remote store:
-
-```sh
-void secret list
-```
-
-If an upload fails or a name is missing, keep the source values and retry before continuing.
-
-For direct Cloudflare deployments, remove the migrated server keys from `cloudflare.vars` in `void.config.ts` after confirming the upload. Void now treats any schema-declared server key in Worker `vars` as an error.
-
-## 4. Set client build values
-
-Move `VITE_*` production values to CI/build-shell variables, or make the value an explicit schema default:
-
-```sh
-export VITE_API_ORIGIN=https://api.example.com
-```
-
-Keep these variables set for the remote check and deployment in step 5. Client values are compiled into browser assets and are public.
-
-These values are also available during server rendering. Do not upload them as remote secrets.
-
-## 5. Remove old files and verify
-
-Once the local values are in `.env`, the server values are uploaded and listed remotely, and the client values are available to the build, delete every `.env.*` file, `.env.example`, and `.dev.vars*` file from the project. Keep the secure backup until verification succeeds. Environment checks and deployment reject these old files.
-
-Use `env.ts` as the checked-in list of names, types, defaults, and requiredness. `void env example` is no longer supported.
-
-Then verify:
-
-```sh
-void env check
-void env check --remote
-void deploy
-```