void 0.20.2 → 0.21.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "void",
-  "version": "0.20.2",
+  "version": "0.21.0",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/voidzero-dev/void.git",
@@ -50,6 +50,11 @@
       "require": "./dist/index.mjs"
     },
     "./schema.json": "./schema.json",
+    "./config": {
+      "types": "./dist/config-entry.d.mts",
+      "import": "./dist/config-entry.mjs",
+      "require": "./dist/config-entry.mjs"
+    },
     "./database-provider": {
       "types": "./dist/database-provider.d.mts",
       "import": "./dist/database-provider.mjs",
@@ -314,18 +319,22 @@
     }
   },
   "dependencies": {
+    "@cloudflare/build-output-utils": "0.8.2",
+    "@cloudflare/config": "0.20.0",
     "@cloudflare/sandbox": "^0.12.9",
     "@cloudflare/vite-plugin": "1.54.7",
     "@cloudflare/workers-types": "^4.20260702.1",
     "@napi-rs/keyring": "2.0.0",
-    "@void/deploy-cloudflare": "0.20.2",
-    "@void/deploy-core": "0.20.2",
-    "@void/edge": "0.20.2",
-    "@void/isr": "0.20.2",
-    "@void/platform": "0.20.2",
+    "@void/deploy-cloudflare": "0.21.0",
+    "@void/deploy-core": "0.21.0",
+    "@void/edge": "0.21.0",
+    "@void/isr": "0.21.0",
+    "@void/platform": "0.21.0",
+    "acorn": "^8.15.0",
     "better-auth": "^1.7.3",
     "better-sqlite3": "^13.0.3",
     "blake3-jit": "^1.1.0",
+    "cf": "1.0.0-beta.5",
     "drizzle-arktype": "^0.1.3",
     "drizzle-kit": "^0.31.10",
     "drizzle-orm": "^0.45.2",
@@ -335,13 +344,15 @@
     "es-module-lexer": "^3.0.2",
     "hono": "^4.13.7",
     "ignore": "^7.0.9",
+    "jiti": "^2.7.0",
     "jsonc-parser": "3.3.1",
+    "miniflare": "5.20260926.0-alpha",
     "minimatch": "^10.2.6",
     "mysql2": "3.24.4",
     "pg": "8.23.0",
     "postal-mime": "^2.7.4",
     "proper-lockfile": "^4.1.2",
-    "wrangler": "4.131.0"
+    "undici": "7.29.0"
   },
   "devDependencies": {
     "@clack/core": "1.5.0",
@@ -368,7 +379,7 @@
     "zod": "^4.6.1"
   },
   "peerDependencies": {
-    "@void/md": "0.20.2",
+    "@void/md": "0.21.0",
     "arktype": ">=2.0.0",
     "valibot": ">=1.0.0-beta.7",
     "vite": "^8.0.0",

package/skills/void/SKILL.md

@@ -23,11 +23,11 @@ read permission; `void platform install --plan` verifies coverage. Use the
 self-hosted platform guide for certificate setup rather than enabling a paid
 product without an explicit request.
 
-For first-time platform setup, follow `docs/guide/self-hosted-platform.md` in order and introduce credentials when the user reaches that step. Recommend a domain; offer explicit `void platform install --workers-dev` for testing before one is ready. PostgreSQL, credentials for the selected login methods, runtime/R2 credentials, and saved signing/encryption keys are required. GitHub is the default and is optional. `--auth-config` accepts nonsecret provider configuration with environment secret references; `--plan` does not read those secrets. Configurable installations finish first-administrator setup using a one-time code and browser identity confirmation. Domain-free installation skips zone/DNS/certificate operations and can use browser login. `void platform domain set <domain>` later performs resumable DNS/HTTPS setup while preserving existing test URLs and the API origin. The command checks the deployed runtime token's cache-purge permission for the new zone; it does not ask users to retrieve that token. Prefer interactive prompts for secrets and keep CI variables in the CI workflow. Void creates the platform infrastructure and database tables.
+For first-time platform setup, follow the installation pages linked from `docs/guide/self-hosted-platform.md` in order and introduce credentials when the user reaches that step. Recommend a domain; offer explicit `void platform install --workers-dev` for testing before one is ready. PostgreSQL, credentials for the selected login methods, runtime/R2 credentials, and saved signing/encryption keys are required. GitHub is the default and is optional. `--auth-config` accepts nonsecret provider configuration with environment secret references; `--plan` does not read those secrets. Configurable installations finish first-administrator setup using a one-time code and browser identity confirmation. Domain-free installation skips zone/DNS/certificate operations and can use browser login. `void platform domain set <domain>` later performs resumable DNS/HTTPS setup while preserving existing test URLs and the API origin. The command checks the deployed runtime token's cache-purge permission for the new zone; it does not ask users to retrieve that token. Interactive installation asks whether Void should create Hyperdrive or use a separately managed one; if the latter is missing, it gives setup instructions and stops before provisioning. It still prompts for the owner PostgreSQL URL. Prefer interactive prompts for secrets and keep CI variables in the CI workflow. Void creates the platform infrastructure and database tables.
 
-For an existing Cloudflare site, run `void deploy` with its root `wrangler.jsonc` or `wrangler.json`. An unlinked project gets a prompt to link and deploy using the existing Worker and resources. Accepting verifies and saves the destination, then continues deployment. Keep new application resources, migrations, auth setup, and secret changes separate from this first handoff; ISR has its own explicit cache choice. The active Worker Version must be the latest upload so inherited secrets have an unambiguous source. Failed builds retain the link for retry. Read `docs/integrations/cloudflare.md` for the supported configuration and rollback behavior.
+For an existing Cloudflare site, run `void deploy` with its root `wrangler.jsonc` or `wrangler.json`. An unlinked project gets a prompt to link and deploy using the existing Worker and resources. Accepting verifies and saves the destination, migrates the root config to `void.config.ts` and `void.lock.json`, then continues deployment. Keep new application resources, migrations, auth setup, and secret changes separate from this first handoff; ISR has its own explicit cache choice. The active Worker Version must be the latest upload so inherited secrets have an unambiguous source. Failed builds retain the link for retry. Read `docs/integrations/cloudflare.md` for the supported configuration and rollback behavior.
 
-When linking reports missing inferred resources, check the listed bindings and inference reasons against the existing Worker and `void.json`; preserve `.void/cloudflare-link.json` for retries. For prerendered/revalidated sites without a cache, migration saves an explicit `routing.isr` choice in `void.json`. True provisions the cache during this deployment; false keeps ISR disabled on retries and later deployments until changed. Keep page-level exports with either choice. CI must configure the boolean before resuming a migration with no saved choice. An application KV binding explicitly named `ISR_CACHE` is still required. Existing D1 bindings without checked-in migrations retain their local migration settings during handoff.
+When linking reports missing inferred resources, check the listed bindings and inference reasons against the existing Worker and `void.config.ts`; preserve `.void/cloudflare-link.json` for retries. For prerendered/revalidated sites without a cache, migration saves an explicit `routing.isr` choice in `void.config.ts`. True provisions the cache during this deployment; false keeps ISR disabled on retries and later deployments until changed. Keep page-level exports with either choice. CI must configure the boolean before resuming a migration with no saved choice. An application KV binding explicitly named `ISR_CACHE` is still required. Existing D1 bindings without checked-in migrations retain their local migration settings during handoff.
 
 For Cloudflare upload failures, use the detailed error message printed by the CLI and saved in the deploy log. A numeric error code alone may not identify the cause.
 
@@ -91,7 +91,9 @@ Cloudflare browser login does not grant AI Gateway access. A platform installati
 
 Use `--runtime <directory>` on platform install, upgrade, repair, enable, or rollback when deploying a locally built `@void/platform` runtime. The directory must contain the generated integrity manifest, Worker artifacts, and migration tree. Build it with `vp run --filter @void/platform build`; Git source revisions are detected automatically, with `-dirty` for uncommitted changes. `VOID_PLATFORM_SOURCE_REVISION` is an optional override. Do not treat this as a safety bypass: custom and packaged runtimes follow the same verification and rollback path.
 
-For self-hosted platform installation, require a dedicated empty PostgreSQL database. Interactive lifecycle commands use Cloudflare browser OAuth with keyring storage. Wrangler OAuth has Zone Read, so a plan that creates a zone or DNS record requires a scoped `CLOUDFLARE_API_TOKEN` with Account → Zone → Edit and/or Zone → DNS → Edit; finish Workers onboarding and choose a workers.dev subdomain for a fresh Cloudflare account. The installed platform uses a separate `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN`. Its core permissions include Hyperdrive: Write at account scope and Cache Purge: Purge on the application zone; SSL and Certificates: Edit is needed only when a custom runtime enables custom project domains. The installer preflights account and Hyperdrive access and safely verifies Cache Purge for an existing zone with a unique nonexistent URL. Fresh installs require unique per-installation values from the operator's secret manager: `VOID_PLATFORM_JWT_SECRET` with at least 32 random bytes and `VOID_PLATFORM_PROJECT_SECRET_KEY` as canonical base64 for 32 random bytes. Never let a local checkpoint or ephemeral CI runner be their only custodian. Enabling email generates a separate signing key in encrypted recovery state; supply `VOID_PLATFORM_EMAIL_SIGNING_SECRET` from the secret manager for headless installs without persistent recovery files. The installer transactionally claims the database for one installation, pins that URL after a successful claim, never removes the claim during uninstall, and uses it for a cross-host lifecycle lock plus a secret-free authoritative lifecycle manifest. Local recovery checkpoints are AES-256-GCM encrypted with an OS-keychain key; never place platform secrets in plaintext files. After discovery on a new machine, provide `VOID_PLATFORM_DATABASE_URL`. For email-enabled installations without encrypted recovery state, also restore the original `VOID_PLATFORM_EMAIL_SIGNING_SECRET`; recreating only the email gateway needs this key, not JWT or runtime credentials. Normal upgrades preserve other deployed Worker secrets; restore the original runtime, GitHub, R2, JWT, and project-encryption values when recreating the API or proxy as documented. Managed platform Sandbox is paused for removal: preview `void platform system sandbox-drain --plan`, follow each returned `nextCursor` with `--cursor '<value>'` to inspect bounded pages, then apply with `--yes` and rerun until the DB-backed response reports `complete: true`; never delete an unverified app by name. The installer trusts only DB-backed sandbox-drain probe protocol v1. Before it accepts an empty inventory, the database admission barrier makes older deployment inserts finish and become visible or rejects them after the protocol floor is armed. Lifecycle redeploys preserve unmanaged Worker routes and custom domains in both the new trigger state and rollback snapshot. They stop before migrations or uploads when live Hyperdrive origin metadata differs from the pinned database. Platform upgrade SQL is forward-only: packaged hashes and the live Drizzle prefix must match, pending migrations require an exact source-version/schema rollback edge, and the old version remains authoritative until target health succeeds. Use `void platform rollback --runtime <earlier>` only when the installed runtime declares the exact earlier version/schema compatible; pass `--from-runtime` for the exact current custom artifact. Rollback preserves the forward database schema and cannot lower a database-required safety protocol. Safe uninstall retains Worker routes, custom domains, and R2 for explicit manual cleanup because Cloudflare cannot condition their deletion on an immutable generation.
+For self-hosted platform installation, require a dedicated empty PostgreSQL database. Interactive lifecycle commands use Cloudflare browser OAuth with keyring storage. Wrangler OAuth has Zone Read, so a plan that creates a zone or DNS record requires a scoped `CLOUDFLARE_API_TOKEN` with Account → Zone → Edit and/or Zone → DNS → Edit; finish Workers onboarding and choose a workers.dev subdomain for a fresh Cloudflare account. The installed platform uses a separate `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN`. Its core permissions include Hyperdrive: Write at account scope and Cache Purge: Purge on the application zone; SSL and Certificates: Edit is needed only when a custom runtime enables custom project domains. Managed Sandbox apps additionally require Workers Paid plus Account → Containers → Edit and Account → Cloudchamber → Edit on that runtime token; these are checked on the first Sandbox application deploy, not during platform install or upgrade. The installer preflights account and Hyperdrive access and safely verifies Cache Purge for an existing zone with a unique nonexistent URL. Fresh installs require unique per-installation values from the operator's secret manager: `VOID_PLATFORM_JWT_SECRET` with at least 32 random bytes and `VOID_PLATFORM_PROJECT_SECRET_KEY` as canonical base64 for 32 random bytes. Never let a local checkpoint or ephemeral CI runner be their only custodian. Enabling email generates a separate signing key in encrypted recovery state; supply `VOID_PLATFORM_EMAIL_SIGNING_SECRET` from the secret manager for headless installs without persistent recovery files. The installer transactionally claims the database for one installation, pins that URL after a successful claim, never removes the claim during uninstall, and uses it for a cross-host lifecycle lock plus a secret-free authoritative lifecycle manifest. Local recovery checkpoints are AES-256-GCM encrypted with an OS-keychain key; never place platform secrets in plaintext files. After discovery on a new machine, provide `VOID_PLATFORM_DATABASE_URL`. For email-enabled installations without encrypted recovery state, also restore the original `VOID_PLATFORM_EMAIL_SIGNING_SECRET`; recreating only the email gateway needs this key, not JWT or runtime credentials. Normal upgrades preserve other deployed Worker secrets; restore the original runtime, GitHub, R2, JWT, and project-encryption values when recreating the API or proxy as documented. Upgrades enable managed Sandboxes automatically. An upgrade from the tenant-owned legacy may still require `void platform system sandbox-drain`: preview with `--plan`, follow each `nextCursor`, then apply with `--yes` until the DB-backed response reports `complete: true`; never delete an unverified app by name. The installer trusts only DB-backed sandbox-drain probe protocol v1. Before it accepts an empty inventory, the database admission barrier makes older deployment inserts finish and become visible or rejects them after the protocol floor is armed. Lifecycle redeploys preserve unmanaged Worker routes and custom domains in both the new trigger state and rollback snapshot. They stop before migrations or uploads when live Hyperdrive origin metadata differs from the pinned database. Platform upgrade SQL is forward-only: packaged hashes and the live Drizzle prefix must match, pending migrations require an exact source-version/schema rollback edge, and the old version remains authoritative until target health succeeds. Use `void platform rollback --runtime <earlier>` only when the installed runtime declares the exact earlier version/schema compatible; pass `--from-runtime` for the exact current custom artifact. Rollback preserves the forward database schema and cannot lower a database-required safety protocol. Safe uninstall retains Worker routes, custom domains, and R2 for explicit manual cleanup because Cloudflare cannot condition their deletion on an immutable generation.
+
+For an organization-managed Hyperdrive, set `VOID_PLATFORM_HYPERDRIVE_ID`, `VOID_PLATFORM_HYPERDRIVE_ORIGIN_HOST`, and `VOID_PLATFORM_HYPERDRIVE_ORIGIN_USER` together before installation. Use `VOID_PLATFORM_DATABASE_URL` for a separate owner connection that runs migrations; the Hyperdrive must be named `void-<installation-name>-database` and have SQL result caching disabled. See `docs/guide/platform/installation/prerequisites.md`.
 
 For self-hosted recovery, `VOID_PLATFORM_PROJECT_SECRET_KEY` restores an original `v1` project-secret keyring. After rotation, restore every retained version with `VOID_PLATFORM_PROJECT_SECRET_KEYS_JSON` and its active entry with `VOID_PLATFORM_PROJECT_SECRET_ACTIVE_KEY_VERSION`. These inputs restore a missing API Worker and never replace the live keyring of an existing Worker. Inject them from a secret manager without logging them or writing plaintext files.
 
@@ -107,7 +109,7 @@ If invoked without a concrete task, do a brief app status check and report:
 2. Backend feature usage (`routes/`, `pages/`, `middleware/`, `migrations/`, `crons/`, `queues/`, SSR entries).
 3. Runtime signals (`void/db`, `void/kv`, `void/storage`, queue usage).
 4. Auth signals (`void/auth`, `auth` client imports, OAuth env vars).
-5. Deployment platform and optional Void project linkage (`.void/project.json`), plus config readiness (`void.json`, Cloudflare `account_id`, tsconfig extends).
+5. Deployment platform and optional Void project linkage (`.void/project.json`), plus config readiness (`void.config.ts`, Cloudflare `account_id`, tsconfig extends).
 6. Optional health checks (`void auth whoami`, `void db status` when relevant).
 
 Then ask what to do next.

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

@@ -21,7 +21,7 @@ import { ai } from 'void/ai';
 export const POST = defineHandler(async (c) => {
   const { prompt } = await c.req.json();
 
-  const result = await ai.run('@cf/meta/llama-3.1-8b-instruct', {
+  const result = await ai.run('@cf/meta/llama-3.3-70b-instruct-fp8-fast', {
     messages: [{ role: 'user', content: prompt }],
   });
 
@@ -29,7 +29,7 @@ export const POST = defineHandler(async (c) => {
 });
 ```
 
-You can use any model available through Cloudflare's AI binding, including Workers AI models such as `@cf/meta/llama-3.1-8b-instruct` and Cloudflare Gateway models such as `google/gemini-2.5-flash` or `openai/gpt-4.1-mini`. The input object must match the selected Cloudflare model's schema. Models that return binary data, such as generated images, are returned as a `Blob` from `ai.run()`.
+You can use any model available through Cloudflare's AI binding, including Workers AI models such as `@cf/meta/llama-3.3-70b-instruct-fp8-fast` and Cloudflare Gateway models such as `google/gemini-2.5-flash` or `openai/gpt-4.1-mini`. The input object must match the selected Cloudflare model's schema. Models that return binary data, such as generated images, are returned as a `Blob` from `ai.run()`.
 
 ## Streaming
 
@@ -42,7 +42,7 @@ import { ai } from 'void/ai';
 export const POST = defineHandler(async (c) => {
   const { prompt } = await c.req.json();
 
-  return ai.stream('@cf/meta/llama-3.1-8b-instruct', {
+  return ai.stream('@cf/meta/llama-3.3-70b-instruct-fp8-fast', {
     messages: [{ role: 'user', content: prompt }],
   });
 });

package/skills/void/docs/guide/app-types.md

@@ -10,7 +10,7 @@ Void supports three types of apps:
 2. **Meta frameworks:** [TanStack Start](https://tanstack.com/start/latest), [React Router](https://reactrouter.com/), [SvelteKit](https://svelte.dev/docs/kit), [Nuxt](https://nuxt.com/), and [Astro](https://astro.build/)
 3. **Static sites:** SPAs, sites built with tools like [VitePress](https://vitepress.dev/), or any directory of static files
 
-The type is auto-detected from your project structure, or you can set it explicitly in [`void.json`](../reference/config.md).
+The type is auto-detected from your project structure, or you can set it explicitly in [`void.config.ts`](../reference/config.md).
 
 ## Void Apps
 
@@ -79,14 +79,15 @@ If you add API routes to a static site generator, tell Void whether to deploy th
 
 To deploy both, set `appType` to `"void"` and build the static site before the Void app:
 
-```json
-// void.json
-{
-  "inference": {
-    "appType": "void",
-    "build": "vitepress build && vite build"
-  }
-}
+```ts
+import { defineConfig } from 'void/config';
+
+export default defineConfig({
+  inference: {
+    appType: 'void',
+    build: 'vitepress build && vite build',
+  },
+});
 ```
 
 ```ts
@@ -117,7 +118,7 @@ To deploy only the static output, set:
 
 ## Auto-Detection
 
-When running `void deploy` and no `inference.appType` is set in `void.json`, the detection logic runs in this order:
+When running `void deploy` and no `inference.appType` is set in `void.config.ts`, the detection logic runs in this order:
 
 | Priority | Condition                                                                                                       | Type                                        |
 | -------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
@@ -131,7 +132,7 @@ When running `void deploy` and no `inference.appType` is set in `void.json`, the
 
 ## Explicit Configuration
 
-To lock the app type and skip auto-detection, set `inference.appType` in [`void.json`](../reference/config.md):
+To lock the app type and skip auto-detection, set `inference.appType` in [`void.config.ts`](../reference/config.md):
 
 ```json
 {

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

@@ -14,7 +14,7 @@ Void configures [Better Auth](https://www.better-auth.com/) for your app, includ
 
 ### 1. Enable auth
 
-Add a provider to `void.json`. Email/password is the default, so the simplest config is:
+Add a provider to `void.config.ts`. Email/password is the default, so the simplest config is:
 
 ```json
 {
@@ -91,7 +91,7 @@ Auth turns on automatically when you:
 
 - import anything from `void/auth`
 - import `auth` from `void/client`
-- add `auth` to `void.json`
+- add `auth` to `void.config.ts`
 - add a root-level `auth.ts` file
 
 The simplest setup is no config at all. Email/password auth is enabled by default.

package/skills/void/docs/guide/database/d1.md

@@ -23,7 +23,7 @@ None. D1 is the default dialect, so you can start by defining your schema and qu
 
 ## Local Database
 
-`void dev` and local `void db` commands share the same database. If your root `wrangler.jsonc` or `wrangler.json` already declares the D1 binding, Void uses its ID. A `preview_database_id` takes precedence during local development.
+`void dev` and local `void db` commands share the same database. If `cloudflare.d1_databases` in `void.config.ts` declares the D1 binding, Void uses its ID. A `preview_database_id` takes precedence during local development.
 
 To store local data outside `.void`, set `voidPlugin({ persistTo: 'local-state' })` in your Vite config. Start `void dev` once to record that directory before running database commands. After changing the Vite config, start `void dev` again to refresh it. Frameworks that manage their own Cloudflare runtime use `.wrangler/state`.
 

package/skills/void/docs/guide/database/mysql.md

@@ -8,7 +8,7 @@ Void supports MySQL through [Cloudflare Hyperdrive](https://developers.cloudflar
 
 ## Configure
 
-Set the dialect in `void.json`:
+Set the dialect in `void.config.ts`:
 
 ```json
 {

package/skills/void/docs/guide/database/postgresql.md

@@ -16,7 +16,7 @@ Void can provision the Hyperdrive configuration from your connection string. Dir
 
 ### 1. Set the database
 
-Add to your `void.json`:
+Add to your `void.config.ts`:
 
 ```json
 {
@@ -43,7 +43,7 @@ Your project uses PostgreSQL. Enter your connection string:
 > postgresql://user:password@host:5432/mydb?sslmode=require
 ```
 
-Void provisions Hyperdrive and records its config ID. The connection string isn't written to `wrangler.jsonc` or generated Worker config.
+Void provisions Hyperdrive and records its config ID. The connection string isn't written to `void.config.ts`, `void.lock.json`, or generated Worker config.
 Both `postgres://` and `postgresql://` URLs are supported, including provider-supplied query strings such as `?sslmode=require`.
 
 For a linked Void project, you can also configure the connection with `void db set-url`. For a direct Cloudflare deploy, export the production `DATABASE_URL` in your shell.
@@ -99,7 +99,7 @@ When deploying a PostgreSQL project to a Void platform:
 When deploying to your own account with `void deploy --platform cloudflare`, export the production
 connection string as `DATABASE_URL`. Void uses it to provision Hyperdrive and apply the checked-in
 migrations transactionally before it uploads the Worker. The connection string is not written to
-`wrangler.jsonc` or the generated Worker config.
+`void.config.ts`, `void.lock.json`, or the generated Worker config.
 
 ## Updating the Connection String
 

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

@@ -14,23 +14,23 @@ Direct Cloudflare deployment runs an application in your account. A self-hosted
 Void platform provides that deployment service to a team using the operator's
 account. Both use the same application APIs, with the following differences:
 
-| 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 | Unavailable in beta                       |
-| 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   |
+| 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       |
 
 Ordinary native applications remain compatible with Workers Free within its
 quotas. Installing a team platform requires Workers for Platforms and the
-[documented infrastructure](./self-hosted-platform.md#cloudflare-footprint).
+[documented infrastructure](./platform/installation/domains.md#cloudflare-footprint).
 Application rollback never reverses database migrations.
 
 Routing-rule parity applies to native Void applications and static deployments.
@@ -50,7 +50,7 @@ void deploy # builds and deploys to the saved platform
 
 During setup, Void asks where you want to deploy:
 
-- **Cloudflare:** sign in through your browser and choose an account. Void saves the account in `wrangler.jsonc`.
+- **Cloudflare:** sign in through your browser and choose an account. Void saves the account in `void.config.ts` or `void.lock.json`.
 - **Void:** connect to a platform, sign in, and link or create a project.
 - **Skip:** set up deployment later with `void connect`.
 
@@ -247,7 +247,7 @@ See the [Cloudflare guide](../integrations/cloudflare.md#deploy-to-your-own-clou
 
 ### Node.js, Bun, and Deno
 
-Set [`target`](../reference/config.md#target) in `void.json` to build a standalone server for Node.js, Bun, or Deno. You can run the result on your own server or in a container.
+Set [`target`](../reference/config.md#target) in `void.config.ts` to build a standalone server for Node.js, Bun, or Deno. You can run the result on your own server or in a container.
 
 Deploy `dist/ssr` and `dist/client` together. The server loads the Pages client manifest and assets relative to its emitted module; start it from the app root with `node dist/ssr/index.js`, `bun dist/ssr/index.js`, or `deno run -A dist/ssr/index.js`.
 

package/skills/void/docs/guide/durable-state.md

@@ -8,7 +8,7 @@ Use a Durable Object when requests need to share state under one name, such as a
 
 Void turns each module in `durable-objects/` into a SQLite-backed Cloudflare Durable Object. The filename determines the binding, Worker class, and initial Cloudflare migration, so no manual Cloudflare configuration is needed.
 
-Void writes the inferred binding and migration entry to `wrangler.jsonc`. Commit that file: Cloudflare Durable Object migrations are append-only, and the persisted order ensures a newly added module is migrated after every class already deployed.
+Void records the inferred binding and migration entry in `void.lock.json`. Commit that file: Cloudflare Durable Object migrations are append-only, and the persisted order ensures a newly added module is migrated after every class already deployed.
 
 ## Define state and methods
 
@@ -129,7 +129,7 @@ export default Counter;
 
 These state migrations are separate from Cloudflare's Durable Object class migration. Void generates the latter with `new_sqlite_classes` when it discovers the file.
 
-Do not delete or reorder generated Durable Object migrations in `wrangler.jsonc` after deployment. Native Cloudflare beta deploys can create these classes with the Worker's first deployment, but do not yet apply a later class migration to an existing Worker. Additions, renames, and removals require an explicit supported Cloudflare deployment workflow; after its migration tag is active, `void deploy --platform cloudflare` can resume ordinary version uploads.
+Do not delete or reorder generated Durable Object migrations in `void.lock.json` after deployment. Native Cloudflare beta deploys can create these classes with the Worker's first deployment, but do not yet apply a later class migration to an existing Worker. Additions, renames, and removals require an explicit supported Cloudflare deployment workflow; after its migration tag is active, `void deploy --platform cloudflare` can resume ordinary version uploads.
 
 ## Deployment support
 

package/skills/void/docs/guide/edge/headers.md

@@ -4,7 +4,7 @@ outline: deep
 
 # Custom Headers
 
-Define custom response headers in [`void.json`](../../reference/config) using the `routing.headers` field. Keys are URL patterns, values are arrays of `"Name: value"` strings.
+Define custom response headers in [`void.config.ts`](../../reference/config) using the `routing.headers` field. Keys are URL patterns, values are arrays of `"Name: value"` strings.
 
 ```json
 {
@@ -72,14 +72,14 @@ Header rules do not apply to:
 
 Meta-frameworks like SvelteKit, Nuxt, and Astro generate a `_headers` file with cache rules for their hashed asset directories. Void automatically parses this file during deploy and merges the rules into the deploy manifest.
 
-- Framework-generated rules are applied **before** `void.json` rules. Since the last match wins, `routing.headers` in `void.json` takes precedence and can override framework defaults.
+- Framework-generated rules are applied **before** `void.config.ts` rules. Since the last match wins, `routing.headers` in `void.config.ts` takes precedence and can override framework defaults.
 - The `_headers` file is not uploaded as a static asset. Its contents are parsed and included in the manifest only.
 
 No configuration is needed. If the framework generates a `_headers` file, it is picked up automatically.
 
 ## How headers work
 
-1. `void deploy` reads header rules from the framework `_headers` file (if present) and `routing.headers` in `void.json`, then includes them in the deploy manifest.
+1. `void deploy` reads header rules from the framework `_headers` file (if present) and `routing.headers` in `void.config.ts`, then includes them in the deploy manifest.
 2. The platform stores the rules in the KV routing entry for your project.
 3. The dispatch Worker adds matching headers before returning a response. Most cached responses include those headers. Hashed assets get header rules on each response, including cache hits, so a rule change takes effect without changing the file.
 

package/skills/void/docs/guide/edge/prerendering.md

@@ -61,7 +61,7 @@ export default defineRender(async (c, assetTags) => {
 
 ## Relationship to revalidation
 
-Setting `routing.isr: false` in `void.json` disables ISR and this edge-prerendering behavior, including per-page exports. It does not disable build-time HTML generation with `output: "static"`.
+Setting `routing.isr: false` in `void.config.ts` disables ISR and this edge-prerendering behavior, including per-page exports. It does not disable build-time HTML generation with `output: "static"`.
 
 Pages with long revalidate TTLs (e.g. 1 year) are effectively static, but the first visitor after a deploy hits a cold cache. This is where prerendering helps - it ensures your users never get slow requests.
 

package/skills/void/docs/guide/edge/redirects.md

@@ -4,7 +4,7 @@ outline: deep
 
 # Redirects
 
-Define URL redirects in [`void.json`](../../reference/config) using the `routing.redirects` field. Keys are source URL patterns, values are destination strings or objects with an explicit status.
+Define URL redirects in [`void.config.ts`](../../reference/config) using the `routing.redirects` field. Keys are source URL patterns, values are destination strings or objects with an explicit status.
 
 ```json
 {
@@ -100,16 +100,16 @@ Reads as "when a request hits `old.example.com` on any path, send a 301 to the s
 
 Meta-frameworks may generate a `_redirects` file during build. Void parses this file at deploy time and merges the rules into the deploy manifest.
 
-- `void.json` rules are applied **before** framework-generated `_redirects` rules. Since the first match wins, `routing.redirects` in `void.json` takes precedence.
+- `void.config.ts` rules are applied **before** framework-generated `_redirects` rules. Since the first match wins, `routing.redirects` in `void.config.ts` takes precedence.
 - Both 3xx redirect rules and status `200` [rewrite rules](./rewrites) are supported in `_redirects` files.
 - The `!` force suffix is only meaningful on `200` entries (see [rewrites — `_redirects` file](./rewrites#redirects-file)). On 3xx entries (`301!`, `302!`, `307!`, `308!`) it's silently stripped — a redirect always "forces" by nature, so the suffix is redundant. `void deploy` prints a single aggregated warning tallying every such entry so you can clean them up.
 - The `_redirects` file is not uploaded as a static asset. Its contents are parsed and included in the manifest only.
 
-Precedence when the same source appears in both sources follows the same rules as rewrites — config rules are merged before file rules within each phase, and first match wins, so `void.json` overrides `_redirects`. See [Precedence: `_redirects` vs `void.json`](./rewrites#precedence-redirects-vs-void-json) for the full explanation and a worked example.
+Precedence when the same source appears in both sources follows the same rules as rewrites — config rules are merged before file rules within each phase, and first match wins, so `void.config.ts` overrides `_redirects`. See [rewrite precedence](./rewrites.md) for a worked example.
 
 ## How redirects work
 
-1. `void deploy` reads redirect rules from the framework `_redirects` file (if present) and `routing.redirects` in `void.json`, then includes them in the deploy manifest.
+1. `void deploy` reads redirect rules from the framework `_redirects` file (if present) and `routing.redirects` in `void.config.ts`, then includes them in the deploy manifest.
 2. The platform stores the rules in the KV routing entry for your project.
 3. The dispatch worker checks redirect rules before any worker invocation, so matching requests get a redirect response immediately.
 

package/skills/void/docs/guide/edge/revalidation.md

@@ -6,13 +6,13 @@ outline: deep
 
 Revalidation caches rendered pages and refreshes them in the background. When a cached page becomes stale, visitors can keep reading it while the Worker renders an updated version. This is often called [Incremental Static Regeneration (ISR)](https://vercel.com/docs/incremental-static-regeneration).
 
-This requires [SSR](../ssr.md) or [Pages mode](../pages-routing/overview) to be configured.
+Use revalidation with [Void SSR](../ssr.md), [Pages mode](../pages-routing/overview), or a [supported SSR framework](../../integrations/frameworks/overview.md). For framework apps, Void caches public HTML document responses, not framework data requests.
 
-To disable Void's ISR caching across the app while keeping your per-page settings, set `"routing": { "isr": false }` in `void.json`. This overrides per-page revalidate and prerender policies. Set `isr` back to `true` to enable those policies again. Build-time HTML generation with `output: "static"` is unaffected.
+To disable Void's ISR caching across the app while keeping your per-page settings, set `"routing": { "isr": false }` in `void.config.ts`. This overrides per-page revalidate and prerender policies. Set `isr` back to `true` to enable those policies again. Build-time HTML generation with `output: "static"` is unaffected.
 
 ## Enabling revalidation
 
-Add a `routing.revalidate` field to `void.json` with a TTL in seconds:
+Add a `routing.revalidate` field to `void.config.ts` with a TTL in seconds:
 
 ```json
 {
@@ -61,7 +61,7 @@ export const loader = defineHandler(async (c) => {
 });
 ```
 
-Per-page values take precedence over `void.json` patterns.
+Per-page values take precedence over `void.config.ts` patterns.
 
 ## Precedence
 
@@ -69,8 +69,8 @@ When multiple sources set a revalidate TTL, the most specific wins:
 
 1. `x-revalidate` response header (per-response)
 2. `.server.ts` export (per-page, Pages mode only)
-3. `void.json` `routing.revalidate` path pattern match
-4. `void.json` `routing.revalidate` global number or `"*"` fallback
+3. `void.config.ts` `routing.revalidate` path pattern match
+4. `void.config.ts` `routing.revalidate` global number or `"*"` fallback
 
 ## How revalidation works
 

package/skills/void/docs/guide/edge/rewrites.md

@@ -6,7 +6,7 @@ outline: deep
 
 A rewrite serves one route's content at another URL while keeping the browser's address unchanged. For example, `/docs` can serve the content from `/en/docs`.
 
-Define source patterns and destination paths in `routing.rewrites` in [`void.json`](../../reference/config):
+Define source patterns and destination paths in `routing.rewrites` in [`void.config.ts`](../../reference/config):
 
 ```json
 {
@@ -240,7 +240,7 @@ So a SPA app can carve out specific paths without losing the SPA shell behavior
 
 With this config, an asset miss under `/docs/getting-started` resolves to `/docs.html`, while an asset miss under `/app/settings` still resolves to `/index.html` (the SPA default).
 
-You don't need to write `"/*": "/index.html"` yourself — the CLI **appends** a synthetic `{ source: '/*', destination: '/index.html' }` rule to the fallback list when packaging a SPA deploy that has user fallbacks. Because evaluation is first-match-wins, user rules come before the synthetic entry and take precedence; the synthetic rule only fires when no user rule matched. This is why the shipped manifest may contain more fallback rules than you wrote in `void.json`. If you do write `"/*": "/index.html"` yourself, the CLI emits a warning on `void deploy` noting that the rule duplicates the default and can be omitted.
+You don't need to write `"/*": "/index.html"` yourself — the CLI **appends** a synthetic `{ source: '/*', destination: '/index.html' }` rule to the fallback list when packaging a SPA deploy that has user fallbacks. Because evaluation is first-match-wins, user rules come before the synthetic entry and take precedence; the synthetic rule only fires when no user rule matched. This is why the shipped manifest may contain more fallback rules than you wrote in `void.config.ts`. If you do write `"/*": "/index.html"` yourself, the CLI emits a warning on `void deploy` noting that the rule duplicates the default and can be omitted.
 
 ## `_redirects` file
 
@@ -254,25 +254,25 @@ Rewrites can also be defined in a `_redirects` file placed in Vite's `publicDir`
 /docs/*    /en/docs/:splat 200!
 ```
 
-| File-based form | `void.json` equivalent | Behavior                                                                 |
-| --------------- | ---------------------- | ------------------------------------------------------------------------ |
-| `... 200`       | `routing.fallbacks`    | Fires only when no static asset and no route matched (would have 404'd). |
-| `... 200!`      | `routing.rewrites`     | Always fires, overriding any static asset that would have served.        |
+| File-based form | `void.config.ts` equivalent | Behavior                                                                 |
+| --------------- | --------------------------- | ------------------------------------------------------------------------ |
+| `... 200`       | `routing.fallbacks`         | Fires only when no static asset and no route matched (would have 404'd). |
+| `... 200!`      | `routing.rewrites`          | Always fires, overriding any static asset that would have served.        |
 
-- `void.json` rules are applied **before** file-based rules. Since the first match wins, `routing.rewrites` / `routing.fallbacks` in `void.json` take precedence.
+- `void.config.ts` rules are applied **before** file-based rules. Since the first match wins, `routing.rewrites` / `routing.fallbacks` in `void.config.ts` take precedence.
 - The `_redirects` file can mix 3xx redirects, `200` fallbacks, and `200!` force rewrites. Ordering is preserved within each bucket.
 - The `!` force suffix is only meaningful on `200`. On a 3xx entry like `301!`, the `!` is silently stripped — 3xx redirects always "force" by their nature (they change the URL), so the suffix is meaningless. `void deploy` prints a single aggregated warning tallying all `301!` / `302!` / `307!` / `308!` entries so you can clean them up.
 
-## Precedence: `_redirects` vs `void.json`
+## Precedence: `_redirects` vs `void.config.ts`
 
-When the same source pattern appears in both a `_redirects` file and `void.json` (`routing.redirects` / `routing.rewrites` / `routing.fallbacks`), the rules don't replace each other — they **merge into a single ordered list per phase**, and the first match wins.
+When the same source pattern appears in both a `_redirects` file and `void.config.ts` (`routing.redirects` / `routing.rewrites` / `routing.fallbacks`), the rules don't replace each other — they **merge into a single ordered list per phase**, and the first match wins.
 
 Rules are bucketed by phase before merging:
 
 - **Pre-asset phase** (always fires, runs before static asset lookup): `routing.redirects` + `routing.rewrites` + `_redirects` 3xx entries + `_redirects` `200!` entries.
 - **Post-asset phase** (only fires on an asset miss): `routing.fallbacks` + `_redirects` plain `200` entries. For SPA app types, the synthetic `/* → /index.html` rule is **appended last** in this phase, so user fallbacks evaluated earlier take precedence under first-match-wins.
 
-Within each phase, `void.json` rules run first, followed by `_redirects` rules. The first matching rule wins, so a `void.json` rule takes precedence over the same source pattern in `_redirects`.
+Within each phase, `void.config.ts` rules run first, followed by `_redirects` rules. The first matching rule wins, so a `void.config.ts` rule takes precedence over the same source pattern in `_redirects`.
 
 ### Concrete example
 
@@ -281,26 +281,27 @@ Within each phase, `void.json` rules run first, followed by `_redirects` rules.
 /docs/*    /en/docs/:splat    200!
 ```
 
-```json
-// void.json
-{
-  "routing": {
-    "rewrites": {
-      "/docs/*": "/handbook/:splat"
-    }
-  }
-}
+```ts
+import { defineConfig } from 'void/config';
+
+export default defineConfig({
+  routing: {
+    rewrites: {
+      '/docs/*': '/handbook/:splat',
+    },
+  },
+});
 ```
 
-A request to `/docs/intro` matches both rules. Merged order is `[void.json: /docs/* → /handbook/:splat, _redirects: /docs/* → /en/docs/:splat]`, so `void.json` wins and the request resolves to `/handbook/intro`.
+A request to `/docs/intro` matches both rules. Merged order is `[void.config.ts: /docs/* → /handbook/:splat, _redirects: /docs/* → /en/docs/:splat]`, so `void.config.ts` wins and the request resolves to `/handbook/intro`.
 
-To confirm precedence in practice, check the [`X-Void-Routing` dev header](#debugging-with-x-void-routing) on any response during `vite dev` — it names the winning rule and its origin (`_redirects:<line>` vs `void.json#routing.rewrites`).
+To confirm precedence in practice, check the [`X-Void-Routing` dev header](#debugging-with-x-void-routing) on any response during `vite dev` — it names the winning rule and its origin (`_redirects:<line>` vs `void.config.ts#routing.rewrites`).
 
 ## How rewrites work
 
-**Static rewrites** (`void.json` and `_redirects` file) on managed Void deployments:
+**Static rewrites** (`void.config.ts` and `_redirects` file) on managed Void deployments:
 
-1. `void deploy` reads rewrite rules from the `_redirects` file (status `200` entries) and `routing.rewrites` in `void.json`, then includes them in the deploy manifest alongside redirect rules.
+1. `void deploy` reads rewrite rules from the `_redirects` file (status `200` entries) and `routing.rewrites` in `void.config.ts`, then includes them in the deploy manifest alongside redirect rules.
 2. The platform stores the rules in the KV routing entry for your project.
 3. The dispatch worker evaluates all routing rules (redirects and rewrites) before any worker invocation. If a rewrite matches, the request pathname is updated internally and the request continues through the normal pipeline (static assets, ISR, worker). The original URL is passed as `X-Void-Original-URL`.
 
@@ -337,16 +338,16 @@ During `vite dev`, every response carries an `X-Void-Routing` header that traces
 
 ```
 X-Void-Routing: redirect[/old] -> /new 301 (_redirects:12)
-X-Void-Routing: rewrite[/api/*] -> /backend/:splat (void.json#routing.rewrites)
-X-Void-Routing: fallback[/docs/*] -> /docs.html (void.json#routing.fallbacks)
+X-Void-Routing: rewrite[/api/*] -> /backend/:splat (void.config.ts#routing.rewrites)
+X-Void-Routing: fallback[/docs/*] -> /docs.html (void.config.ts#routing.fallbacks)
 X-Void-Routing: c.rewrite -> /new-path (middleware)
 X-Void-Routing: pass-through
 ```
 
-Phases are separated by `->` so the diagnostic value stays valid as an HTTP header. The parenthesised source hint points at the exact declaration — a line number for `_redirects`, a config path for `void.json`, or `spa-default` for the synthetic SPA catch-all. The header is **only emitted in dev** — production builds strip both the trace code and the per-rule `origin` metadata from the bundle and manifest.
+Phases are separated by `->` so the diagnostic value stays valid as an HTTP header. The parenthesised source hint points at the exact declaration — a line number for `_redirects`, a config path for `void.config.ts`, or `spa-default` for the synthetic SPA catch-all. The header is **only emitted in dev** — production builds strip both the trace code and the per-rule `origin` metadata from the bundle and manifest.
 
 ::: info What fires in `vite dev`
-`vite dev` applies the full static routing pipeline on every target — `node`, `bun`, `deno`, and the default target alike. `void.json` rules (`routing.redirects` / `routing.rewrites` / `routing.fallbacks` / `routing.headers`) and file-based rules (`public/_redirects`, `public/_headers`) are merged at plugin load and compiled into the Hono middleware your worker runs behind. Editing `_redirects` or `_headers` during a dev session re-runs the merge and reloads the page — no restart needed. `c.rewrite()` calls in middleware work everywhere because they live inside the worker itself, and the `X-Void-Routing` dev header reports every decision on every target.
+`vite dev` applies the full static routing pipeline on every target — `node`, `bun`, `deno`, and the default target alike. `void.config.ts` rules (`routing.redirects` / `routing.rewrites` / `routing.fallbacks` / `routing.headers`) and file-based rules (`public/_redirects`, `public/_headers`) are merged at plugin load and compiled into the Hono middleware your worker runs behind. Editing `_redirects` or `_headers` during a dev session re-runs the merge and reloads the page — no restart needed. `c.rewrite()` calls in middleware work everywhere because they live inside the worker itself, and the `X-Void-Routing` dev header reports every decision on every target.
 
 A few things still only run in the deployed runtime, not `vite dev`:
 

package/skills/void/docs/guide/edge/static-assets.md

@@ -135,7 +135,7 @@ For direct Cloudflare deployment, these frameworks need a complete `assets` poli
 
 ### Generated config
 
-Void owns the generated asset routing policy during dev and build for Void apps. If a root `wrangler.jsonc` contains stale `not_found_handling` or `run_worker_first` values, Void replaces those fields so generated config cannot accidentally change which layer sees a request first.
+Void owns the generated asset routing policy during dev and build for Void apps. If `cloudflare.assets` in `void.config.ts` contains stale `not_found_handling` or `run_worker_first` values, Void replaces those fields so generated config cannot accidentally change which layer sees a request first.
 
 TanStack Start and React Router are the exception: Void generates no asset policy for them and leaves both fields to your own Cloudflare config. Writing `not_found_handling` alone would make the asset layer answer unmatched requests and the framework Worker would never run, and completing the policy needs `assets.binding` and `assets.directory` that the framework owns, not Void.