void 0.23.0 → 0.25.0

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

@@ -4,65 +4,51 @@ outline: deep
 
 # Quickstart
 
-Create a Void app, run it locally, and deploy it. You can also [add Void to an existing Vite app](#adding-to-an-existing-vite-app). Use Node.js 24.21.0 or later.
+Create a Void app, run it locally, and deploy it. You can also [add Void to an existing Vite app](#adding-to-an-existing-vite-app).
 
-## Start in an Empty Directory
+## Create an app
 
-Install Void in an empty project directory:
+In an empty directory, install Void and run setup:
 
 ::: code-group
 
 ```sh [npm]
 npm install -D void
+npx void init
 ```
 
 ```sh [pnpm]
 pnpm add -D void
+pnpm void init
 ```
 
 ```sh [yarn]
 yarn add -D void
+yarn void init
 ```
 
 ```sh [bun]
 bun add -D void
+bunx void init
 ```
 
 :::
 
-Run setup:
-
-::: code-group
-
-```sh [npm]
-npx void init
-```
+Choose your UI framework, a starter, and a deployment target. Vite+ is the default build tool. D1 is a good first database: it runs locally without a separate database server. Choose Cloudflare to deploy to your own account, or skip deployment setup for now.
 
-```sh [pnpm]
-pnpm void init
-```
+With pnpm, `pnpm create void my-app` also creates the project directory and configures native build permissions for you.
 
-```sh [yarn]
-yarn void init
-```
+## Run locally
 
-```sh [bun]
-bunx void init
+```sh
+npm run dev
 ```
 
-:::
-
-Void asks you to choose Vite+ or Vite, a UI framework, a starter, and a deployment target. Vite+ is the default. D1 needs no local database server; choose PostgreSQL or MySQL if you use an external database. You can skip deployment setup and decide later.
-
-With pnpm, you can start with `pnpm create void my-app`. It configures native build permissions before installing Void.
-
-The examples below use `void` for brevity. Outside package scripts, run the local binary with `npx void`, `pnpm void`, `yarn void`, or `bunx void`. Keep Void installed in the project so the CLI and app use the same version.
+Open `http://localhost:5173`. In a Pages starter, `pages/` contains your UI and companion `.server.ts` files contain its server loaders and actions. Loaders return data to page components as typed props.
 
-## Run and deploy
+## Call a server route
 
-### 1. Edit the generated API route
-
-Database-backed starters include `routes/api/hello.ts`. You can edit its `GET` handler, or create this file if you started with Static Pages:
+Edit `routes/api/hello.ts`, or create it if your starter doesn't include it:
 
 ```ts
 import { defineHandler } from 'void';
@@ -72,75 +58,46 @@ export const GET = defineHandler(() => {
 });
 ```
 
-### 2. Run locally
-
-```sh
-npm run dev
-```
+Visit `http://localhost:5173/api/hello` to see the response. From your client code, call it with Void's typed fetch:
 
-Then visit:
+```ts
+import { fetch } from 'void/client';
 
-- App: `http://localhost:5173`
-- API route: `http://localhost:5173/api/hello`
+const { message } = await fetch('/api/hello');
+```
 
-### 3. Deploy
+The file path defines the URL, and the handler defines the response type. Change `message` in the handler and TypeScript checks the client against the new shape.
 
-If you chose a deployment target during setup, run:
+Database starters also include `db/schema.ts`. Its Drizzle schema defines your tables and query types; Void runs a local database and provisions one when you deploy.
 
-```sh
-void deploy
-```
+## Deploy
 
-If you skipped deployment setup, select your Cloudflare account for the first deploy:
+If you chose a target during setup:
 
 ```sh
-void deploy --platform cloudflare
+npx void deploy
 ```
 
-Void opens your browser to sign in when needed. To use your team's platform, connect using the API URL from your administrator, then link a project and deploy:
+If you skipped setup, select your Cloudflare account:
 
 ```sh
-void connect https://platform.example.com
-void project link
-void deploy
+npx void deploy --platform cloudflare
 ```
 
-Void builds the app, provisions its resources, applies pending migrations, and prints the deployed URL. If a production secret is missing, [set it](./env-vars.md) and deploy again. Later deploys use the saved target.
-
-See [Deployment](./deployment.md) for CI setup and rollback.
-
-## Using with Coding Agents
-
-`void init` detects your coding agent and installs its instructions and skills. If no agent is detected, use the bundled docs linked in `AGENTS.md`. In agents that support it, load the `/void` skill and describe the app you want to build. See [Coding Agents](../integrations/agents) for setup details.
+Void opens your browser to sign in when needed, builds the app, provisions resources, applies migrations, and prints the deployed URL. Later deploys use the saved target. See [Deployment](./deployment.md) for team platforms, CI, and rollback.
 
-## Meta Frameworks
+## Adding to an existing Vite app
 
-Use Void's [Pages routing](./pages-routing/overview) or keep a framework such as TanStack Start, React Router, or SvelteKit. Follow the [framework guides](../integrations/frameworks/overview) for setup.
+Install Void and run `void init` with your package manager as shown [above](#create-an-app). Setup adds `voidPlugin()` to your Vite config and creates the remaining project files. If the config needs a manual edit, the CLI shows the change to make.
 
-## Adding to an Existing Vite App
+For a meta framework such as TanStack Start, React Router, or SvelteKit, follow its [integration guide](../integrations/frameworks/overview.md).
 
-Install Void using the package manager command [above](#start-in-an-empty-directory).
-
-Enable the plugin in `vite.config.ts`:
-
-```ts
-import { defineConfig } from 'vite';
-import { voidPlugin } from 'void';
-
-export default defineConfig({
-  plugins: [voidPlugin()],
-});
-```
-
-Then run `void init` with your package manager to configure the remaining project files.
+## Next steps
 
-## Troubleshooting pnpm installs
+- [Pages Routing](./pages-routing/overview.md): loaders, layouts, and forms
+- [Server Routing](./server-routing.md): params, middleware, and validation
+- [Database](./database.md): queries and migrations
+- [Environment Variables](./env-vars.md): local values and production secrets
+- [Coding Agents](../integrations/agents.md): use Void's bundled docs and skills
 
 If a manual pnpm install reports blocked build scripts, run `pnpm approve-builds` for `esbuild`, `sharp`, and `workerd`. Set `better-sqlite3: false` in `pnpm-workspace.yaml`'s `allowBuilds`; Void uses its bundled binaries.
-
-## Next steps
-
-- To understand what kind of apps are supported: [Supported App Types](./app-types)
-- [Server Routing](./server-routing): dynamic params, middleware, and validation
-- [Database](./database): queries, migrations, and generated types
-- [Type Safety](./type-safety): end-to-end typed fetch client

package/skills/void/docs/guide/remote-dev.md

@@ -49,7 +49,7 @@ AI requests use your platform’s account and allowance in both local and remote
 When the dev server starts with remote mode active, it prints:
 
 ```
-⚡ Remote bindings active (my-project.void.app)
+⚡ Remote bindings active (my-project.apps.example.com)
    DB      → remote D1
    KV      → remote KV
    STORAGE → remote R2

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/auth.md

@@ -41,11 +41,12 @@ are Void account operations. Prefer `void auth status`, `void account link`, and
 
 Browser login through one of the platform's currently enabled methods. The token is saved in the operating-system keychain, scoped to the platform origin. Login fails closed when no keychain is available instead of writing the token to a plaintext file; headless environments use `VOID_TOKEN` from their secret manager.
 
-If an older CLI login is no longer recognized after updating Void, run `void account login` again. Your saved platform and project links remain unchanged.
+Connect to a platform with `void connect <url>` before logging in. If an older project link has no platform URL, connect and run `void project link` to select its project again.
 
 Set `VOID_API_URL` alongside `VOID_TOKEN` to identify the platform that issued it.
-A token without an API URL is only used for Void Cloud's production API; a saved
-connection or project cannot forward it to another platform. To use a platform's
+Both the URL and token are required for environment-based authentication, and the
+URL must already be connected. In a fresh CI environment, run
+`void connect "$VOID_API_URL" --no-login` before deploying. To use a platform's
 saved login instead, unset `VOID_TOKEN`.
 
 This is optional if you already completed auth during `void connect` or the interactive `void init` flow.

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

@@ -52,7 +52,7 @@ Run ad-hoc SQL against the database. Provide SQL inline or from a file. SELECT q
 
 By default, targets the local database. Pass `--remote` to run against the deployed database selected in `.void/project.json`:
 
-- **Void platform D1 projects**: routes the query through the selected platform's registered proxy using your auth token. Void Cloud's proxy is `proxy.void.cloud`; a self-hosted platform uses its own proxy URL.
+- **Void platform D1 projects**: routes the query through the selected platform's registered proxy using your auth token.
 - **Direct Cloudflare D1 projects**: invokes Cloudflare against the pinned D1 binding from `void.config.ts` or `void.lock.json`.
 - **Hosted PostgreSQL and MySQL projects**: fetches the stored connection string from the platform and connects directly.
 - **Direct Cloudflare PostgreSQL and MySQL projects**: uses `DATABASE_URL` from the current shell; Cloudflare cannot return the password from Hyperdrive.

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

@@ -14,7 +14,13 @@ void deploy --platform cloudflare --atomic
 
 Auto-detects your project type and chooses the right pipeline. See [Supported App Types](../../guide/app-types.md) and [Deployment](../../guide/deployment.md) for details.
 
-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.
+Deploying to a Void platform requires an explicit connection with `void connect <url>`.
+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 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.
 
 For an existing Void Worker, `void deploy` can link the Worker and migrate its root Cloudflare config. Keep the first deployment focused on the existing app. See [Deploy an existing Worker](../../integrations/cloudflare.md#deploy-an-existing-worker) for requirements and the ISR cache choice.
 
@@ -53,6 +59,20 @@ For the Void platform, project resolution precedence is:
 
 If no project is linked and no override is provided, CLI prompts to link or create one. In CI (non-TTY), `void deploy` errors out instead — set `VOID_PROJECT` or pass `--project <slug>`.
 
+To deploy to another connected Void platform for one invocation:
+
+```sh
+void connect https://second.example.com
+VOID_API_URL=https://second.example.com void deploy --platform void --project my-app
+```
+
+`VOID_API_URL` selects the platform and `--project` selects its project. You must
+name the project when overriding a different platform's saved link. Existing
+project links and deployment preferences remain unchanged, even when the target
+project is created. The same applies to `VOID_PROJECT` and to another project on
+the current platform. A first deployment still links the project when no destination
+is configured. See [Deploy to another Void platform](../../guide/deployment.md#deploy-to-another-void-platform).
+
 ## `void deploy --platform cloudflare` {#void-deploy-platform-cloudflare}
 
 Build and deploy to your Cloudflare account using `void.config.ts`: