void 0.28.0 → 1.1.0

package/docs/guide/database/mysql.md

@@ -51,9 +51,20 @@ void deploy
 
 For direct Cloudflare deploys, export the production `DATABASE_URL` in the shell running `void deploy --platform cloudflare`. Void uses it to provision Hyperdrive and apply pending checked-in migrations before uploading the Worker; it is not written to the Worker config.
 
-::: warning MySQL DDL is not transactional
-MySQL may implicitly commit schema changes. If a multi-statement migration fails partway through, earlier statements can remain applied even though Void does not record the migration as complete. Keep migrations small, review them before deploy, and make failed migrations safe to rerun after repairing the database.
-:::
+Only one migration run changes a database at a time, whether it comes from `void db migrate`, `void db reset`, the reset that `void db seed` does before it loads data, `void deploy --platform cloudflare`, or a `void deploy` of any project that uses the database. Better Auth's table changes run inside the same run. Another run waits for it, up to about 20 seconds for a command that connects with `DATABASE_URL` and about 2 minutes for a `void deploy` to the Void platform, then stops with an error that asks you to try again.
+
+### Failed migrations {#failed-migrations}
+
+Each migration file runs in a transaction, so a failed file that only changes data leaves the database unchanged. On a sharded Vitess keyspace, such as a sharded PlanetScale database, a commit that fails on one shard does not undo the shards that already committed. MySQL commits schema changes such as `CREATE TABLE` and `ALTER TABLE` immediately, so when a file with schema changes fails partway through, its earlier statements stay applied. The error names the file that failed.
+
+To recover, undo the applied statements, fix the file, then run `void db migrate` or `void deploy` again:
+
+```sh
+void db execute "DROP TABLE comments"
+void db execute --remote "DROP TABLE comments" # deployed database
+```
+
+MySQL rejects `IF NOT EXISTS` on `ADD COLUMN` and `CREATE INDEX`, so undoing a statement is usually simpler than making it safe to rerun. Small migrations leave less to undo.
 
 ## Database commands
 

package/docs/guide/database.md

@@ -234,10 +234,6 @@ const usersWithPosts = await db.query.users.findMany({
 });
 ```
 
-::: warning ⚠️ Nuxt and Analog limitations
-In Nuxt and Analog, use the query builder (`db.select().from(table)`). The `db.query.*` relational API is not available in these frameworks.
-:::
-
 ## Seeding
 
 Use `void db seed` to reset your local database, re-apply migrations, and then run a seed file.
@@ -376,7 +372,7 @@ To keep an existing migration history:
 
 Review and commit the metadata, then run `void deploy` again. If no database has applied the SQL yet, you can instead replace it with migrations from `void db generate`.
 
-For D1 migrations containing triggers, add a `--> statement-breakpoint` line after each complete SQL statement, including the trigger's closing `END;`. Keep the trigger body together.
+For D1 migrations containing triggers, and MySQL migrations containing triggers, procedures, functions or events, add a `--> statement-breakpoint` line after each complete SQL statement, including the trigger's closing `END;`. Keep the trigger body together.
 
 ## Scaffolding
 

package/docs/guide/durable-state.md

@@ -6,7 +6,7 @@ outline: deep
 
 Use a Durable Object when requests need to share state under one name, such as a shopping cart, room, or rate limiter. Void gives you typed methods and stores the object's state between calls.
 
-Create a module in `durable-objects/` with `defineDurableState()`. Void provides a SQLite-backed Cloudflare Durable Object for it. This feature supports native Void apps deployed directly to Cloudflare.
+Create a module in `durable-objects/` with `defineDurableState()`. Void provides a SQLite-backed Cloudflare Durable Object for it. This feature supports native Void apps on Void platforms and direct Cloudflare deployments.
 
 Commit `void.lock.json` when Void adds a resource. Keep its deployed migration entries in their original order.
 
@@ -117,7 +117,7 @@ export default Counter;
 
 State migrations update your saved values. Void manages Cloudflare’s separate class migrations in `void.lock.json`.
 
-Do not delete or reorder generated Durable Object migrations in `void.lock.json` after deployment. For a class addition, rename, or removal on an existing Worker, review the migration and run `void deploy --platform cloudflare --atomic`. If this Worker needs atomic publication on every deploy, set `deploy: { cloudflare: { mode: 'atomic' } }` in `void.config.ts`. Cloudflare applies class lifecycle changes in one deployment. The Worker receives traffic before Void checks readiness, and you cannot roll back across that migration boundary. Staged deploys keep pre-traffic readiness verification.
+For direct Cloudflare deployments, do not delete or reorder generated Durable Object migrations in `void.lock.json` after deployment. For a class addition, rename, or removal on an existing Worker, review the migration and run `void deploy --platform cloudflare --atomic`. If this Worker needs atomic publication on every deploy, set `deploy: { cloudflare: { mode: 'atomic' } }` in `void.config.ts`. Cloudflare applies class lifecycle changes in one deployment. The Worker receives traffic before Void checks readiness, and you cannot roll back across that migration boundary. Staged deploys keep pre-traffic readiness verification.
 
 ## Rename a file while keeping its state
 
@@ -158,15 +158,19 @@ If you already moved the file, `void info` also shows resources recorded in `voi
 
 ## Deployment support
 
-Typed state works in local development and direct Cloudflare deploys of native Void apps. Deploy with `void deploy --platform cloudflare`.
+Typed state works in local development, on Void platforms, and in direct Cloudflare deploys of native Void apps. Use `void deploy` for a Void platform or `void deploy --platform cloudflare` for your own Cloudflare account.
 
-Custom Durable Object modules are not supported on Void platforms, in meta-frameworks, or on Node.js, Bun, and Deno.
+On a Void platform, each class keeps its storage across deployments and rollbacks. A rollback restores the class code and keeps the current stored data. Removing a definition makes the class inactive; adding it again with the same resource name restores access to its data. Deleting the project deletes its Durable Object storage.
+
+A project supports up to 32 distinct custom classes, including removed classes whose storage is retained. Keep resource names and instance names stable to preserve data. Upgrade an older Void installation before deploying an app that uses custom Durable Objects.
+
+Custom Durable Object modules are not supported in meta-frameworks or on Node.js, Bun, and Deno.
 
 This is separate from [typed WebSocket routes](./websockets.md), which also use SQLite-backed Durable Objects and work on both direct Cloudflare and hosted Void deployments.
 
 ## Native Durable Object classes
 
-Use `defineDurableObject` to keep a native Cloudflare class, including classes extending Cloudflare Agents. Void discovers its binding and exports the class without replacing its constructor, lifecycle, or RPC methods. Like Durable State, this supports direct Cloudflare deployments.
+Use `defineDurableObject` to keep a native Cloudflare class, including classes extending Cloudflare Agents. Void discovers its binding and exports the class without replacing its constructor, lifecycle, or RPC methods. Like Durable State, this supports Void platforms and direct Cloudflare deployments.
 
 ```ts
 // durable-objects/workspace.ts

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

@@ -6,6 +6,18 @@ outline: deep
 
 Keep one password-manager entry for this platform. Paste the saved values into the installer when asked; most do not need shell environment variables.
 
+| Credential                             | Created by                       | Why the platform needs it                                                                |
+| -------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------- |
+| Management API token                   | You, in Cloudflare               | Lets the CLI change DNS and Access for a domain installation or Access setup.            |
+| Runtime API token                      | You, in Cloudflare               | Stored as a Worker secret so the platform can deploy apps after you close your terminal. |
+| PostgreSQL URL                         | You, with your database provider | Stores platform users, projects, and deployments.                                        |
+| Login provider client ID and secret    | You, or Void for Access login    | Signs people in to the platform.                                                         |
+| R2 Access Key ID and Secret Access Key | You, in Cloudflare               | Lets the platform sign upload links so `void deploy` sends static files straight to R2.  |
+| Access setup and app-access tokens     | You, in Cloudflare               | Only with Cloudflare Access: create and manage Access applications.                      |
+| JWT signing key                        | Void, on interactive installs    | Signs platform login tokens.                                                             |
+| Project encryption key                 | Void, on interactive installs    | Encrypts app secrets stored by your platform.                                            |
+| Email signing key                      | Void, when email is enabled      | Signs confirmation links and email requests.                                             |
+
 ## Cloudflare API Tokens {#runtime-token-permissions}
 
 For a domain installation or Cloudflare Access setup, the installer guides you through creating separate management and runtime tokens using Cloudflare's [API token setup](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/). Its links preselect the permissions and suggest names based on your platform's display name, but Cloudflare's form cannot preselect a zone: for a domain installation, change the zone policy from **All Domains** to **Specified Domains** and select your zone. If Void will create the zone, keep **All Domains** on both tokens: the zone does not exist yet, and the runtime token needs it to purge cache. Save the tokens in your password manager and paste them into the masked CLI prompts.
@@ -74,17 +86,21 @@ The installer deploys the email gateway, prepares the shared mail route, and ver
 
 ## R2 Upload Credentials
 
+`void deploy --platform void` uploads your app's static files straight to R2 instead of through the platform API. The API signs short-lived upload links for them with an R2 key pair.
+
 The installer opens the **R2 token creation** form with a token name based on your platform's display name, **Object Read & Write**, and **Apply to all buckets in this account (including newly created buckets)** preselected. Review the settings and create an account token, or a user token if your role requires it. Save its **Access Key ID** and **Secret Access Key** in your password manager, then paste both into the installer. These differ from the management and runtime API tokens. See [R2’s token instructions](https://developers.cloudflare.com/r2/api/tokens/).
 
 ## Signing and Encryption Keys {#signing-and-encryption-keys}
 
-The **JWT signing key** signs platform login tokens. The **Project encryption key** encrypts app secrets stored by your platform. Generate a separate key for each by running this command twice:
+The **JWT signing key** signs platform login tokens. The **Project encryption key** encrypts app secrets stored by your platform. An interactive install generates both and keeps them in this machine's encrypted recovery data. Lifecycle commands on this machine read them from there.
+
+To keep your own copy, for example to repair the platform from CI or another machine, create both keys before installing and set `VOID_PLATFORM_JWT_SECRET` and `VOID_PLATFORM_PROJECT_SECRET_KEY`. Non-interactive installs must set both. Generate a separate key for each by running this command twice:
 
 ```sh
 openssl rand -base64 32
 ```
 
-Save each result in your password manager, then paste it into the corresponding installer prompt. The command generates 32 random bytes encoded as base64, suitable for either field. Keep the two original keys for recovery; do not regenerate them when resuming or upgrading.
+Save each result in your password manager. The command generates 32 random bytes encoded as base64, suitable for either field. Keep the two original keys for recovery; do not regenerate them when resuming or upgrading.
 
 ::: details Generate the keys without printing them to your terminal
 

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

@@ -100,4 +100,4 @@ New platform resources use deterministic `void-<installation-name>-<role>` names
 | Proxied wildcard DNS records              |                                0 or 1 | Created only when an application domain is configured                                         |
 | Zones                                     |                                0 or 1 | Created only when the requested application zone is absent                                    |
 
-The API Worker uses four Durable Object classes for usage, cron scheduling, error monitoring, and concurrency. Worker bindings create the request and log datasets in Analytics Engine. The core installation doesn't create Container applications, a GitHub App, a dashboard Worker, or build Workers.
+The API Worker uses four Durable Object classes for usage, cron scheduling, error monitoring, and concurrency. Worker bindings create the request and log datasets in Analytics Engine, which must be [enabled for the account](/guide/platform/installation/prerequisites#if-cloudflare-rejects-analytics-engine). The core installation doesn't create Container applications, a GitHub App, a dashboard Worker, or build Workers.

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

@@ -50,6 +50,43 @@ For completed provisioning whose administrator setup is still pending, run
 expired. Enter it at `/setup`, sign in, and confirm the displayed identity.
 An installation that already has an administrator does not reopen setup.
 
+### First administrator sign-in fails
+
+If sign-in fails after you enter the setup code, the page shows the reason and an
+error code. When a provider setting may be the cause, it also shows the callback
+URL the provider must have.
+
+| Error code                                                                  | What to check                                                               |
+| --------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
+| `github_incorrect_client_credentials`, `github_failed`, `oidc_token_failed` | The client ID and client secret, and that the provider has the callback URL |
+| `github_redirect_uri_mismatch`                                              | The callback URL registered in the GitHub OAuth app                         |
+| `oidc_discovery_failed`                                                     | The issuer URL, exactly, including any trailing slash                       |
+| `github_unverified_user_email`                                              | Verify the primary email of the GitHub account                              |
+| `google_domain_not_allowed`, `oidc_group_not_allowed`                       | Sign in with an allowed account, or change the allowed domains or groups    |
+| `login_denied`, `github_bad_verification_code`                              | Start a new sign-in                                                         |
+
+If the provider shows its own error page instead, register exactly the callback
+URL printed with your setup code.
+
+To change the login settings, run repair on the computer that installed the
+platform:
+
+```sh
+void platform repair <id>
+void platform repair <id> --auth-config <path>
+```
+
+Interactive repair asks whether to change the login settings, with the saved
+values filled in; leave the client secret blank to keep it. `--auth-config`
+takes a file in the [install format](/guide/platform/installation/setup#finish-login-configuration)
+and is the way to change OIDC allowed groups. Login methods and Access protection
+stay as installed. Repair prints a new setup code and the callback URL.
+
+A GitHub-only installation signs in with the GitHub OAuth App from its
+installation settings. To replace its client ID and secret, set
+`VOID_PLATFORM_GITHUB_CLIENT_ID` and `VOID_PLATFORM_GITHUB_CLIENT_SECRET` when
+you run `void platform repair <id>`.
+
 ### Repair missing resources
 
 Preview what needs repair, then apply it:
@@ -164,7 +201,7 @@ During a restore, keep platform and application traffic disabled before changing
 
 ### Where local state lives
 
-Installation records live in `~/.void/platforms/`. Credentials are stored separately in encrypted recovery files, with the encryption key in your operating system's keychain. Keep your original secrets in a password manager for recovery on another machine.
+Installation records live in `~/.void/platforms/`. Credentials are stored separately in encrypted recovery files, with the encryption key in your operating system's keychain. Keep your original secrets in a password manager for recovery on another machine. Signing and encryption keys that Void generated exist only in these files; to keep your own copy, [supply them when installing](/guide/platform/installation/credentials#signing-and-encryption-keys).
 
 If the keychain isn't available, Void stops before writing secrets. Headless environments can supply `VOID_PLATFORM_RECOVERY_KEY`: a canonical base64-encoded 32-byte key from a secret manager. A temporary CI runner can use a new recovery-encryption key for each run only when every original credential remains available in protected CI secrets, including `VOID_PLATFORM_JWT_SECRET`, `VOID_PLATFORM_EMAIL_SIGNING_SECRET` for an email-enabled installation, and either the original `VOID_PLATFORM_PROJECT_SECRET_KEY` or the complete rotated keyring and active-version pair.
 

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

@@ -6,7 +6,7 @@ outline: deep
 
 To run a Void platform, you need:
 
-- A Cloudflare account with Workers for Platforms and R2 enabled.
+- A Cloudflare account with Workers for Platforms, R2, and Analytics Engine enabled.
 - An empty hosted PostgreSQL database.
 - An account with your chosen login provider: GitHub, Google, OIDC, or Cloudflare Access.
 - A domain for your apps, or `workers.dev` for testing. You can [add a domain later](/guide/platform/installation/domains#adding-a-domain).
@@ -28,6 +28,10 @@ If that domain is already in this Cloudflare account, use its existing zone. Oth
 
 You can also let Void create the zone during installation. Setting it up now lets you scope the API tokens to that zone and finish installation without a DNS pause. The platform API uses `workers.dev` by default, so it needs no additional domain.
 
+### If Cloudflare rejects Analytics Engine
+
+The platform stores request metrics and logs in Analytics Engine. If installation stops with "You need to enable Analytics Engine" (code 10089), add an Analytics Engine binding to a Worker that is not part of the platform under **Settings** > **Bindings**, and deploy it once from the dashboard. A new Hello World Worker works. Do not edit the platform's own Workers. Then run the printed `void platform install --resume` command.
+
 ## Install the CLI and Preview
 
 With Node.js 24.21.0 or later, install the CLI:
@@ -78,7 +82,7 @@ Use any PostgreSQL provider that accepts connections from your computer and Clou
 | [PlanetScale Postgres](https://planetscale.com/docs/postgres/connecting) | Choose **Postgres**, not Vitess/MySQL. Open **Connect**, create role credentials, and use the direct primary connection on port `5432`, not PgBouncer on `6432`. |
 | [Neon](https://neon.com/docs/get-started-with-neon/connect-neon)         | Open **Connect**, select the database and owner role, and turn **connection pooling off**.                                                                       |
 
-Once installation claims the database, continue using that same database for resume and maintenance commands. Uninstall never deletes external PostgreSQL.
+Once installation claims the database, continue using that same database for resume and maintenance commands. If installation stops because it cannot use the database, for example because the database is not empty, set `VOID_PLATFORM_DATABASE_URL` to another database's URL before you resume. Uninstall never deletes external PostgreSQL.
 
 ### Use a provider CLI
 

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

@@ -153,6 +153,28 @@ providers, and existing company policies. Void creates dedicated applications
 and a scoped service token for protected installation checks. It preserves your
 company policies, including device and MFA requirements.
 
+If no policy fits, choose **Allow my company’s email domain** in the policy list
+and enter your domains. Void creates that Allow policy in your account and keeps
+it there for reuse; you can add MFA or device rules to it in Cloudflare later.
+For identity-provider groups or other rules, choose **Create in Cloudflare** and
+follow the printed steps.
+
+An Allow policy must name who may sign in: emails, email domains or lists,
+identity-provider groups (Okta, Microsoft Entra ID, Google Workspace, GitHub
+organizations, or SAML), authentication contexts, members of a Cloudflare
+account, or Access groups built from them. Microsoft Entra ID groups and
+authentication contexts count only when they come from an identity provider you
+select. A login method also counts when it is one of the identity providers you select and uses
+Cloudflare's connector for a company directory: Microsoft Entra ID, Okta,
+OneLogin, PingOne, Centrify, Google Workspace, or the Cloudflare login with
+**Restrict to account members** turned on. Policies that allow everyone, any
+service token, or bypass Access are rejected, and so are policies that rely
+only on One-time PIN, a public login such as GitHub, or a login added with the
+generic **OpenID Connect** or **SAML** option, even one that fronts your
+company directory. Void cannot tell who can sign in through a generic login;
+add a Require rule such as **Emails ending in** your company domain to that
+policy.
+
 The setup credential needs **Access: Apps and Policies Write** and
 **Access: Organizations, Identity Providers, and Groups Read** in the identity
 account. Creating protection also needs **Access: Service Tokens Write**.
@@ -212,7 +234,7 @@ This OAuth App handles sign-in.
 
 ## Finish installation
 
-The installer collects your runtime token, PostgreSQL URL, login-provider credentials, R2 credentials, and signing and encryption keys. It masks secret values and saves setup progress encrypted through your system keychain. Keep a password-manager copy for recovery on another machine.
+The installer collects your runtime token, PostgreSQL URL, login-provider credentials, and R2 credentials, and generates the [signing and encryption keys](/guide/platform/installation/credentials#signing-and-encryption-keys). It masks secret values and saves setup progress encrypted through your system keychain. Keep a password-manager copy for recovery on another machine.
 
 Once installation finishes, open the printed admin dashboard link. For GitHub-only setup, sign in as the administrator selected during installation. For configurable login, use the one-time `/setup` code to confirm the administrator’s identity. Use the printed API URL to [connect and deploy an app](/guide/platform/installation/first-deployment).
 

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

@@ -33,7 +33,7 @@ void platform uninstall [id] --plan
 void platform uninstall [id]
 ```
 
-Uninstall blocks platform traffic, removes Queues that no remaining platform Worker uses, and lists the resources left for you to review. Use `--plan` to review deletions and retained resources before making changes. By default, Workers, the Queues they use, KV, R2, Hyperdrive, the dispatch namespace, and AI Gateway remain in your account. Adopted resources, external PostgreSQL, and zones are always retained. Email Routing settings are retained; `--purge-resources` removes only the rules that send mail to the platform. DNS records, routes, custom domains, and Cloudflare Access resources are retained unless you use `--purge-resources`.
+Uninstall blocks platform traffic, removes Queues that no remaining platform Worker uses, and lists the resources left for you to review. Use `--plan` to review deletions and retained resources before making changes. By default, Workers, the Queues they use, KV, R2, Hyperdrive, the dispatch namespace, and AI Gateway remain in your account. Adopted resources, external PostgreSQL, and zones are always retained. To install a platform again, use a new empty PostgreSQL database. Email Routing settings are retained; `--purge-resources` removes only the rules that send mail to the platform. DNS records, routes, custom domains, and Cloudflare Access resources are retained unless you use `--purge-resources`.
 
 When uninstall finishes, the record of what was kept stays at `~/.void/platforms/<account-id>/<installation-id>.json`. Without `--purge-data`, the encrypted credentials file `<installation-id>.recovery.enc` next to it is kept too. Delete both once you have finished the manual cleanup below.
 
@@ -91,6 +91,11 @@ If installation configured Cloudflare Access, the uninstall plan lists its recor
 
 Uninstall does not remove the applications created for [project Zero Trust](/guide/platform/administration/zero-trust). While Zero Trust is enabled or still has Access applications, uninstall and `--plan` stop before any change and list those applications. Run `void platform zero-trust disable` first. Uninstall reads this from the installation database, so it also stops when the database cannot be reached.
 
+If no platform user exists yet, for example because first administrator setup did
+not finish, nobody can run `zero-trust disable`. Uninstall then turns off project
+Zero Trust and deletes its applications itself. Run it on the computer that installed
+the platform. If the uninstall asks you to, update an older platform runtime first.
+
 ::: details Why some resources require manual cleanup
 
 Resources that may have been shared or repurposed require manual review before deletion. Void verifies ownership, keeps those resources in place, and blocks platform traffic.

package/docs/guide/sandboxes.md

@@ -121,7 +121,7 @@ Custom images must include the helper matching Void's installed Sandbox SDK vers
 
 ```dockerfile
 FROM node:26.10.0-trixie-slim
-COPY --from=docker.io/cloudflare/sandbox:1.0.0 /usr/local/bin/sandbox-shim /usr/local/bin/sandbox-shim
+COPY --from=docker.io/cloudflare/sandbox:1.0.1 /usr/local/bin/sandbox-shim /usr/local/bin/sandbox-shim
 WORKDIR /workspace
 CMD ["sleep", "infinity"]
 ```

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

@@ -24,7 +24,7 @@ Both targets use the same application APIs. A core platform adds shared access a
 | 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                                   |
+| Typed Durable State and native Durable Objects   | Supported                        | Supported                                     |
 | 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     |

package/docs/integrations/cloudflare.md

@@ -154,7 +154,7 @@ Void uses Access credentials for readiness checks without saving them. If checks
 
 ### Databases and secrets
 
-For PostgreSQL and MySQL, supply `DATABASE_URL` to the deploy process. Void uses it for Hyperdrive and migrations without writing it to config. MySQL schema changes can partially apply before an error.
+For PostgreSQL and MySQL, supply `DATABASE_URL` to the deploy process. Void uses it for Hyperdrive and migrations without writing it to config. MySQL schema changes can partially apply before an error; see [failed MySQL migrations](../guide/database/mysql.md#failed-migrations).
 
 Creating Hyperdrive requires an API token with Hyperdrive edit permission. Alternatively, create it in Cloudflare and add its ID to `cloudflare.hyperdrive`; an existing binding works with browser login.
 
@@ -210,7 +210,7 @@ Custom domain commands update routes immediately. If a first deployment times ou
 
 Local D1, KV, and R2 bindings use local data. Your production resource IDs are used during deployment.
 
-Workers AI runs remotely after you connect to Cloudflare, so development calls consume your account's allowance.
+Workers AI runs remotely after you connect to Cloudflare, so development calls consume your account's allowance. Remote bindings in development and preview use your `void cloudflare login` session, or `CLOUDFLARE_API_TOKEN` when it is set.
 
 ### AI on your Cloudflare account {#ai-self-host}
 

package/docs/integrations/frameworks/analog.md

@@ -26,7 +26,6 @@ Void provides the local Cloudflare binding runtime. `nitro-cloudflare-dev` creat
 ### 3. Configure `vite.config.ts`
 
 ```ts
-import { resolve } from 'node:path';
 import analog from '@analogjs/platform';
 import { defineConfig } from 'vite';
 import { voidPlugin } from 'void';
@@ -41,12 +40,7 @@ export default defineConfig({
       nitro: {
         preset: 'cloudflare-module',
         cloudflareDev: { configPath: './.void-wrangler.jsonc' },
-        modules: ['nitro-cloudflare-dev'],
-        alias: {
-          // Nitro has its own bundler that doesn't use Vite aliases.
-          // Duplicate @schema here so Nitro can resolve it.
-          '@schema': resolve(__dirname, 'db/schema.ts'),
-        },
+        modules: ['nitro-cloudflare-dev', 'void/nitro'],
       },
     }),
     voidPlugin(),
@@ -54,6 +48,8 @@ export default defineConfig({
 });
 ```
 
+The `void/nitro` module gives Analog API routes and page server loads your app's `void/db` and `@schema`.
+
 ### 4. Create `void.config.ts`
 
 Void generates the Cloudflare config used by Analog's development runtime:
@@ -98,10 +94,6 @@ export const load = async ({ event }: PageServerLoad) => {
 };
 ```
 
-::: warning ⚠️ Analog limitation
-Use `db.select().from(table)` for database queries in Analog. The `db.query.*` relational API is not available.
-:::
-
 ### Other resources
 
 Use [KV](../../guide/kv.md), [object storage](../../guide/storage.md), and [AI](../../guide/ai.md) from server-side code with the same imports as a Void app. Add [cron jobs](../../guide/jobs.md) in `crons/` and [queue consumers](../../guide/queues.md) in `queues/`.

package/docs/integrations/frameworks/nuxt.md

@@ -30,23 +30,24 @@ import { resolve } from 'node:path';
 import { voidPlugin } from 'void';
 
 export default defineNuxtConfig({
+  alias: {
+    '@schema': resolve(import.meta.dirname, 'db/schema.ts'),
+  },
   nitro: {
     preset: 'cloudflare-module',
-    cloudflareDev: { configPath: './.void-wrangler.jsonc' },
+    modules: ['void/nitro'],
+    cloudflare: { dev: { configPath: './.void-wrangler.jsonc' } },
     // Required for Nuxt 4.6.0 on Windows.
     externals: {
       inline: [/[\\/]node_modules[\\/]nuxt[\\/]dist[\\/]/],
     },
-    alias: {
-      // Nitro has its own bundler that doesn't use Vite aliases.
-      // Duplicate @schema here so Nitro can resolve it.
-      '@schema': resolve(import.meta.dirname, 'db/schema.ts'),
-    },
   },
   vite: { plugins: [voidPlugin()] },
 });
 ```
 
+The `void/nitro` module gives Nuxt server routes your app's `void/db` and `@schema`. The top-level `alias` lets `nuxi typecheck` resolve `@schema`, because Nuxt also checks server routes with the app's types. `cloudflare.dev` gives the development server the bindings from Void's generated Cloudflare config; Nuxt runs it in development when `compatibilityDate` is `2025-07-15` or later.
+
 ### 4. Create `void.config.ts`
 
 Void generates the Cloudflare config used by Nuxt's development runtime:
@@ -88,10 +89,6 @@ export default defineEventHandler(async () => {
 });
 ```
 
-::: warning ⚠️ Nuxt limitation
-Use `db.select().from(table)` for database queries in Nuxt. The `db.query.*` relational API is not available.
-:::
-
 ### Other resources
 
 Use [KV](../../guide/kv.md), [object storage](../../guide/storage.md), and [AI](../../guide/ai.md) from server-side code with the same imports as a Void app. Add [cron jobs](../../guide/jobs.md) in `crons/` and [queue consumers](../../guide/queues.md) in `queues/`.

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

@@ -80,6 +80,8 @@ dist/
 
 `vite preview` also uses `app.js` to serve your built app locally.
 
+Installed packages that depend on `void` are bundled into `dist/ssr`. If one of their dependencies uses a native addon or reads files next to its own code, add that dependency, in the version the package uses, to your app's `dependencies`. The build then leaves it to Node.
+
 ## What Works
 
 These Void features work identically across all targets:

package/docs/reference/api.md

@@ -68,4 +68,5 @@ Import Void's app-facing APIs from these paths:
 | `void/queues`             | `queues` proxy for sending messages to typed queues                                                                                                                                                                                                                                                                                                                                                                                                                            |
 | `void/sandbox`            | `getSandbox`, `sandbox`, `SandboxLimitError`, `SandboxUnavailableError`, and the SDK 1.0 file, backup, and mount helpers. `getSandbox(id)` resolves a client. Commands, files, port requests, and process completion return promises; limits reject with `SandboxLimitError`, which extends `UsageLimit`. Container state lasts until inactivity (default ten minutes), a crash, or a restart. See [Sandboxes](../guide/sandboxes.md) for the API and deployment requirements. |
 | `void/env`                | `defineEnv`, `env`, schema helpers (`string`, `number`, `boolean`, `url`, `email`, `oneOf`, `json`), and global Cloudflare env types                                                                                                                                                                                                                                                                                                                                           |
+| `void/nitro`              | Nitro module for Nuxt and Analog. Add `'void/nitro'` to the Nitro `modules` so server routes get the app's `void/db` and `@schema`                                                                                                                                                                                                                                                                                                                                             |
 | `void/sveltekit`          | SvelteKit integration helpers: `withVoidTSConfig()` and `mergeVoidSvelteKitTsconfig()`                                                                                                                                                                                                                                                                                                                                                                                         |

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

@@ -58,11 +58,15 @@ authentication file. Upgrades preserve administrator settings.
 
 New resources use `void-<name>-<role>` names; choose an unused installation name. The installer opens setup pages for missing credentials and reuses values already supplied.
 
-During Access setup, choose existing company policies or **Create new** for manual
-setup instructions and an account dashboard link. After you save the policy and
-confirm completion, Void reloads the list so you can select it and continue in the
-same run. **Refresh list** reloads policies created in another window. Your
-identity-provider choice and still-available policy selections are retained.
+During Access setup, choose existing company policies or **Create in Cloudflare**
+for manual setup instructions and an account dashboard link. After you save the
+policy and confirm completion, Void reloads the list so you can select it and
+continue in the same run. When Void creates the Access applications, **Allow my
+company’s email domain** creates an Allow policy for the domains you enter and
+selects it. **Refresh list** reloads policies created in another window. Your
+identity-provider choice and still-available policy selections are retained. If a
+selected policy does not restrict sign-in to company identities, Void explains why
+and asks again.
 
 Installation progress and partial credentials are saved encrypted locally. Rerun the installer to continue unfinished setup, or pass `--resume --name <id>`. Use lifecycle commands for completed installations.
 
@@ -98,7 +102,7 @@ Use these commands to recover, update, pause, or remove an installation:
 void platform discover [--account <id>] [--installation <id-or-name>]
 void platform upgrade [id] [--runtime <path>] [--dashboard-url <origin>] [--plan] [--yes]
 void platform rollback [id] --runtime <earlier-path> [--from-runtime <current-path>] [--plan] [--yes]
-void platform repair [id] [--runtime <path>] [--dashboard-url <origin>] [--plan] [--yes]
+void platform repair [id] [--runtime <path>] [--dashboard-url <origin>] [--auth-config <path>] [--plan] [--yes]
 void platform disable [id] [--plan] [--yes]
 void platform enable [id] [--runtime <path>] [--plan] [--yes]
 void platform uninstall [id] [--plan] [--purge-data | --purge-resources] [--keep-zone] [--yes]
@@ -113,6 +117,12 @@ use `repair --dashboard-url <origin>` or `upgrade --dashboard-url <origin>`.
 Preview with `--plan` first. Existing Access protection must cover the configured
 dashboard origin before maintenance can proceed. See [Optional Dashboard](../../guide/platform/installation/domains.md#optional-dashboard).
 
+While first administrator setup is pending, `repair --auth-config <path>` replaces
+the login settings from a file in the install format and prints a new setup code.
+Interactive repair offers the same change with the saved values filled in. Login
+methods and Access protection stay as installed. Run it on the computer that
+installed the platform. See [First administrator sign-in fails](../../guide/platform/installation/maintenance.md#first-administrator-sign-in-fails).
+
 After discovery on another machine, set `VOID_PLATFORM_DATABASE_URL`. See [Manage an installation from another machine](../../guide/platform/installation/maintenance.md#manage-an-installation-from-another-machine) for the secrets needed to recreate a missing Worker.
 
 | Command     | Behavior                                                                                                    |
@@ -137,6 +147,8 @@ An upgrade completes after the new Workers pass health checks. If rollout fails,
 
 `platform rollback` restores a compatible earlier runtime without reversing database migrations. Pass its files with `--runtime`; if the installed version is custom, also supply that version with `--from-runtime`. Void refuses incompatible targets.
 
+If project Zero Trust is on and no platform user exists yet, uninstall turns it off and deletes its Access applications first. Run it on the computer that installed the platform.
+
 Uninstall verifies remote ownership before removing anything. Data resources are retained unless you pass `--purge-data`. Workers, the Queues they use, R2, AI Gateway, DNS records, routes, custom domains, adopted resources, external PostgreSQL, and zones are retained for manual review.
 
 `--purge-resources` includes `--purge-data` and also deletes every other resource the installation created, including Workers, Queues, R2, AI Gateway, the platform DNS record, routes, custom domains, and installer-created Access resources. It removes only the Email Routing rules that send mail to the platform email gateway, and keeps zones, adopted resources, external PostgreSQL, other Email Routing settings, and API tokens. A route, custom domain, DNS record, or Access resource that no longer matches the installation's record is kept and listed. It refuses before any change while projects remain or resource reads are denied. Use the Edit permissions listed by `--plan`; read checks cannot verify them, so a denied deletion can stop uninstall after changes have begun. Rerun the same command to continue after an interruption, or after a plain or `--purge-data` uninstall stopped.

package/docs/reference/config.md

@@ -297,6 +297,8 @@ Curated Cloudflare Workers configuration. `void init` pins `compatibility_date`
 
 `worker.vars` values must be strings. Root `.env` values override them during local development only. Production builds do not load `.env`, and reject any `worker.vars` name declared as a server key in `env.ts`. Use `void secret put` for production server values.
 
+Managed deployments include `worker.vars` as plain-text bindings. A remote secret with the same name takes precedence. To use the configured variable instead, remove that remote secret and deploy again. Secret deletion changes the running Worker immediately, so plan this migration during a maintenance window.
+
 `worker.limits.cpu_ms` sets the CPU time limit per request, from 1 to 300000 ms. On a Void platform, deploy fails if the limit exceeds the account plan; lower it in `void.config.ts` before retrying. Rollback instead caps the old limit at the current plan ceiling. On direct deploys, [Cloudflare enforces the value](https://developers.cloudflare.com/workers/platform/limits/#cpu-time): Workers Free allows up to 10 ms and Workers Paid up to 300000 ms per request.
 
 ```json

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "void",
-  "version": "0.28.0",
+  "version": "1.1.0",
   "description": "Full-stack framework and deployment CLI for Cloudflare Workers, powered by Vite.",
   "homepage": "https://void.cloud",
   "bugs": {
@@ -90,6 +90,11 @@
     "./routes": {
       "types": "./dist/routes-stub.d.mts"
     },
+    "./nitro": {
+      "types": "./dist/nitro.d.mts",
+      "import": "./dist/nitro.mjs",
+      "require": "./dist/nitro.mjs"
+    },
     "./sveltekit": {
       "types": "./dist/sveltekit.d.mts",
       "import": "./dist/sveltekit.mjs",
@@ -334,26 +339,26 @@
     }
   },
   "dependencies": {
-    "@cloudflare/build-output-utils": "^0.9.0",
-    "@cloudflare/codemods": "^0.4.2",
-    "@cloudflare/config": "^0.24.1",
-    "@cloudflare/sandbox": "1.0.0",
-    "@cloudflare/vite-plugin": "^1.63.1",
-    "@cloudflare/workers-auth": "^0.13.1",
-    "@cloudflare/workers-types": "^5.20261009.1",
-    "@napi-rs/keyring": "^2.1.0",
-    "@void/deploy-cloudflare": "0.28.0",
-    "@void/deploy-core": "0.28.0",
-    "@void/edge": "0.28.0",
-    "@void/isr": "0.28.0",
-    "@void/platform": "0.28.0",
+    "@cloudflare/build-output-utils": "^0.9.2",
+    "@cloudflare/codemods": "^0.5.0",
+    "@cloudflare/config": "^0.26.0",
+    "@cloudflare/sandbox": "^1.0.1",
+    "@cloudflare/vite-plugin": "^1.64.0",
+    "@cloudflare/workers-auth": "^0.14.0",
+    "@cloudflare/workers-types": "^5.20261014.1",
+    "@napi-rs/keyring": "^2.1.1",
+    "@void/deploy-cloudflare": "1.1.0",
+    "@void/deploy-core": "1.1.0",
+    "@void/edge": "1.1.0",
+    "@void/isr": "1.1.0",
+    "@void/platform": "1.1.0",
     "better-auth": "^1.7.7",
     "better-sqlite3": "^13.0.3",
     "blake3-jit": "^1.1.0",
-    "cf": "^1.0.0-beta.14",
+    "cf": "^1.0.0-beta.17",
     "drizzle-arktype": "^0.1.3",
     "drizzle-kit": "^0.31.11",
-    "drizzle-orm": "^0.45.3",
+    "drizzle-orm": "^0.45.4",
     "drizzle-valibot": "^0.4.2",
     "drizzle-zod": "^0.8.3",
     "email-validator": "^2.0.4",
@@ -361,23 +366,24 @@
     "ignore": "^7.0.12",
     "jiti": "^2.7.0",
     "jsonc-parser": "^3.3.1",
-    "mime": "^4.1.0",
-    "miniflare": "5.20261006.1-alpha",
+    "mime": "^4.1.1",
+    "miniflare": "5.20261012.0-beta",
     "minimatch": "^10.2.6",
-    "mysql2": "^3.24.5",
+    "mysql2": "^3.24.6",
     "pg": "^8.23.1",
     "postal-mime": "^4.0.5",
     "proper-lockfile": "^4.1.2",
-    "terminal-link": "^5.0.0"
+    "terminal-link": "^5.0.0",
+    "yaml": "^2.9.1"
   },
   "devDependencies": {
-    "@electric-sql/pglite": "0.5.8",
+    "@electric-sql/pglite": "0.5.9",
     "@types/better-sqlite3": "^9.6.0",
-    "@types/node": "^26.6.4",
+    "@types/node": "^26.6.5",
     "@types/pg": "^8.23.1",
     "@types/proper-lockfile": "^4.1.4",
-    "@voidzero-dev/vite-plus-prompts": "1.1.0",
-    "arktype": "^2.2.7",
+    "@voidzero-dev/vite-plus-prompts": "1.2.0",
+    "arktype": "^2.2.8",
     "ci-info": "^4.4.0",
     "estree-walker": "^3.0.3",
     "fast-wrap-ansi": "^0.2.2",
@@ -389,12 +395,12 @@
     "tinyglobby": "^0.2.17",
     "typescript": "7.0.2",
     "valibot": "^1.5.0",
-    "vite": "npm:@voidzero-dev/vite-plus-core@1.1.0",
-    "vite-plus": "1.1.0",
-    "zod": "^4.6.5"
+    "vite": "npm:@voidzero-dev/vite-plus-core@1.2.0",
+    "vite-plus": "1.2.0",
+    "zod": "^4.6.7"
   },
   "peerDependencies": {
-    "@void/md": "0.28.0",
+    "@void/md": "1.1.0",
     "arktype": ">=2.0.0",
     "valibot": ">=1.0.0-beta.7",
     "vite": "^8.0.0",