void 0.27.0 → 1.0.3

package/dist/yarn-pnp-DLbEFMT0.mjs

@@ -0,0 +1,92 @@
+import { a as join, n as dirname } from "./dist-ipQi0Q8y.mjs";
+import { existsSync, readdirSync } from "node:fs";
+import { fileURLToPath, pathToFileURL } from "node:url";
+//#region src/cli/yarn-pnp.ts
+const drizzleKitBin = join(fileURLToPath(import.meta.resolve("drizzle-kit")), "..", "bin.cjs");
+/** Read the PnP runtime files in `dir` only, or `undefined` when neither exists. */
+function readPnpRuntimeAt(dir) {
+	const cjs = join(dir, ".pnp.cjs");
+	const loader = join(dir, ".pnp.loader.mjs");
+	const cjsExists = existsSync(cjs);
+	const loaderExists = existsSync(loader);
+	if (!cjsExists && !loaderExists) return;
+	return {
+		pnpCjs: cjsExists ? cjs : void 0,
+		pnpLoader: loaderExists ? loader : void 0
+	};
+}
+/**
+* Whether `dir` has its own package-manager lockfile, i.e. it is an install
+* root: workspace members share the root lockfile. `packageManager` is not a
+* signal, because a Yarn workspace member may pin it and still resolve through
+* the root's `.pnp.cjs`.
+*/
+function hasLocalLockfile(dir) {
+	return existsSync(join(dir, "pnpm-lock.yaml")) || existsSync(join(dir, "package-lock.json")) || existsSync(join(dir, "yarn.lock")) || existsSync(join(dir, "bun.lock")) || existsSync(join(dir, "bun.lockb"));
+}
+/**
+* Find Yarn Berry PnP runtime files at `start` or its nearest ancestor, since a
+* monorepo keeps `.pnp.cjs` at the workspace root. A lockfile at `start` stops
+* the walk: an outer PnP graph lacks the local install's dependencies.
+*/
+function findYarnPnpRuntime(start) {
+	const local = readPnpRuntimeAt(start);
+	if (local !== void 0) return {
+		dir: start,
+		runtime: local
+	};
+	if (hasLocalLockfile(start)) return;
+	let dir = dirname(start);
+	if (dir === start) return;
+	while (true) {
+		const found = readPnpRuntimeAt(dir);
+		if (found !== void 0) return {
+			dir,
+			runtime: found
+		};
+		const parent = dirname(dir);
+		if (parent === dir) return;
+		dir = parent;
+	}
+}
+/**
+* Like {@link findYarnPnpRuntime}, but only when Yarn has installed into that
+* same directory. A committed `.pnp.cjs` alone does not prove an install: its
+* ZIP archives may not be fetched yet.
+*/
+function findInstalledYarnPnpRuntime(start) {
+	const found = findYarnPnpRuntime(start);
+	return found && isYarnPnpInstalled(found.dir) ? found.runtime : void 0;
+}
+/**
+* Yarn writes `.yarn/install-state.gz` on every install; a zero-install
+* checkout instead commits a populated `.yarn/cache`.
+*/
+function isYarnPnpInstalled(dir) {
+	if (existsSync(join(dir, ".yarn", "install-state.gz"))) return true;
+	const cacheDir = join(dir, ".yarn", "cache");
+	if (!existsSync(cacheDir)) return false;
+	try {
+		return readdirSync(cacheDir).some((e) => e.endsWith(".zip"));
+	} catch {
+		return false;
+	}
+}
+/**
+* Build a child env that loads the Yarn PnP runtime found at or above `root`,
+* like `yarn node` does. Existing `NODE_OPTIONS` go after our flags so the PnP
+* `--require` patches resolution first.
+*/
+function buildDrizzleKitSpawnEnv(root) {
+	const env = { ...process.env };
+	const pnp = findYarnPnpRuntime(root)?.runtime;
+	if (!pnp) return env;
+	const flags = [];
+	if (pnp.pnpCjs) flags.push(`--require ${JSON.stringify(pnp.pnpCjs)}`);
+	if (pnp.pnpLoader) flags.push(`--experimental-loader ${pathToFileURL(pnp.pnpLoader).href}`);
+	const injected = flags.join(" ");
+	env.NODE_OPTIONS = process.env.NODE_OPTIONS ? `${injected} ${process.env.NODE_OPTIONS}` : injected;
+	return env;
+}
+//#endregion
+export { hasLocalLockfile as i, drizzleKitBin as n, findInstalledYarnPnpRuntime as r, buildDrizzleKitSpawnEnv as t };

package/docs/guide/ai.md

@@ -17,8 +17,14 @@ npm run dev
 
 When the app imports `void/ai`, Void enables a remote Workers AI binding during
 development and preview. Requests use your Cloudflare account and its allowance;
-Workers AI has no local simulator. Use your Cloudflare login or
-`CLOUDFLARE_API_TOKEN` in an automated environment.
+Workers AI has no local simulator. Development and preview use the same
+Cloudflare login as `void connect`; sign in with `void cloudflare login`. A
+`CLOUDFLARE_API_TOKEN` takes precedence; use one in an automated environment.
+
+If development stops with a Cloudflare authentication error, run
+`void cloudflare login` in a terminal as a user who can access the deployment
+account shown by `void cloudflare status`, or set `CLOUDFLARE_API_TOKEN`.
+`wrangler login` does not affect development.
 
 For a team platform, use `void connect <platform-url>` and link your project.
 Development requests use that platform's account and usage limits.

package/docs/guide/auth.md

@@ -127,6 +127,8 @@ Auth sessions use the same database as your app. Void creates `BETTER_AUTH_SECRE
 
 Local development needs no secret setup. To preview a production build locally, provide `BETTER_AUTH_SECRET`.
 
+Responses to signed-in requests get `Cache-Control: no-store`, so neither the browser cache nor a shared cache keeps a user's data. A route keeps its own policy when it sets `no-store`, or `private` together with `no-cache`. To answer repeat requests with `304`, use `private, no-cache` with Hono's [`etag()`](https://hono.dev/docs/middleware/builtin/etag) middleware. If you set the `ETag` yourself, make it differ per user, so the `304` doesn't reuse another account's page. The browser cache keeps a copy of a `private, no-cache` page, so the Back button can show it again after the user signs out. Keep the default `no-store` for pages that must not stay in the browser cache.
+
 `POST`, `PUT`, `PATCH` and `DELETE` requests and WebSocket connections from another origin don't use the signed-in session unless that origin is in `trustedOrigins`. If a separate frontend calls your app, add its origin there (see [Customization](#customization)). If your routes use their own cookies, check the request `Origin` yourself, for example with Hono's [`csrf()`](https://hono.dev/docs/middleware/builtin/csrf) middleware.
 
 Deployed apps on Cloudflare limit auth requests per client IP with Better Auth's defaults, for example 3 sign-in attempts per 10 seconds. Each Worker instance keeps its own count. Change or turn off the limits with `rateLimit` in `auth.ts`. To share one count across instances, set `rateLimit: { storage: 'database' }`, then run `void db generate` for a direct Cloudflare deploy.

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

@@ -40,6 +40,8 @@ For a Void platform, deploy prompts for the connection string if needed. You can
 
 Void provisions Hyperdrive without saving the connection string in project config. Both `postgres://` and `postgresql://` URLs are supported, including provider query strings such as `?sslmode=require`.
 
+The Hyperdrive that Void creates connects with TLS in Cloudflare's default `require` mode. Hyperdrive does not use the `sslmode=verify-ca`, `sslmode=verify-full`, or `sslrootcert` settings from your connection string. To have Hyperdrive verify your database against a specific certificate authority on a direct Cloudflare deploy, [create the Hyperdrive in Cloudflare with that certificate](https://developers.cloudflare.com/hyperdrive/configuration/tls-ssl-certificates-for-hyperdrive/) and add its ID to [`cloudflare.hyperdrive`](../../integrations/cloudflare.md#databases-and-secrets).
+
 ## Schema Definition
 
 Import schema helpers from `void/schema-pg`:

package/docs/guide/database.md

@@ -47,6 +47,8 @@ Choose a database during `void init`, or set `database` in `void.config.ts`:
 | Managed by | Void                         | Bring your own database             | Bring your own database   |
 | Connection | Automatic D1 binding         | Hyperdrive                          | Hyperdrive                |
 
+A Void platform keeps Hyperdrive query caching off for your database connection, so reads reflect completed writes. An existing connection is updated on the project's next deploy.
+
 ## Schema Definition
 
 Define your tables in `db/schema.ts` using column helpers from `void/schema-d1`, `void/schema-pg`, or `void/schema-mysql`.
@@ -232,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.
@@ -374,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,8 +158,36 @@ 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 Void platforms and direct Cloudflare deployments.
+
+```ts
+// durable-objects/workspace.ts
+import { DurableObject } from 'cloudflare:workers';
+import { defineDurableObject } from 'void/durable';
+
+class WorkspaceObject extends DurableObject {
+  async fetch() {
+    return new Response('Workspace');
+  }
+}
+
+export const Workspace = defineDurableObject({
+  name: 'workspace',
+  class: WorkspaceObject,
+});
+export default Workspace;
+```
+
+Call `Workspace.get('project-id')` from a server handler to obtain its typed stub. Keep the resource name and instance name stable across deployments to retain storage.

package/docs/guide/platform/administration/access.md

@@ -158,3 +158,7 @@ Invitation history remains available after an involved account is removed. The s
 remains visible when that account's login no longer exists.
 
 `void platform signup open` allows anyone to sign up. Everyone who signs up can deploy apps on your application domain, so check how those apps [share cookies](/guide/platform/installation/domains#adding-a-domain) before opening signup. Use `void platform signup restrict` to require an allowlist match again. Disallowing an entry affects future signup; it does not suspend an existing account.
+
+## Connected apps
+
+Register separate applications as OAuth clients through [Connected apps](./connected-apps.md). Users connect their identity and approve each publish on Void.

package/docs/guide/platform/administration/connected-apps.md

@@ -0,0 +1,55 @@
+# Connected apps
+
+A connected app is a separate application registered as an OAuth client on your Void installation. Users sign in on Void and decide whether to connect it. The application operator may be different from the platform administrator.
+
+## Register an application
+
+Open **Admin → Connected apps**. Enter the app name, its operator, and each exact HTTPS callback URL on a separate line. Wildcards and callback query strings are not supported. Enable individual publish approvals if the app builds and deploys projects.
+
+Save the returned client ID and secret on the app's server. Void shows the secret once. The client secret authenticates that application; it does not grant access to users' accounts. Register a new client if you need replacement credentials, then disable the old one.
+
+**Disable and revoke access** invalidates the client's grants, pending sign-ins, and publish approvals. Registration and disablement appear in the operator audit.
+
+Local development permits exact HTTP callbacks on localhost when the platform's development authentication bypass is explicitly enabled. Production clients require HTTPS.
+
+## Connect and disconnect
+
+The app sends users to Void's authorization page, where Void displays its registered name, operator, callback origin, and requested permission. Sign-in permits reading the user's ID and username. It does not provide an account token or project management access.
+
+Users can disconnect applications at `<platform API URL>/oauth/connections`. Grants also expire after an hour and become invalid when their platform login session is revoked or their account is suspended. Applications must request a new sign-in when access expires.
+
+## Approve a publish
+
+The app builds first, then sends the user to Void with the prepared artifact. Void displays the project name, checkpoint label, resources, manifest, and artifact digest. The user must explicitly approve on Void.
+
+Approval permits one deployment to that user's chosen project. Void creates a missing project during approval; existing projects require ownership. The app receives a credential valid for up to fifteen minutes, restricted to that artifact's asset uploads, deployment, and receipt. Retries use the same receipt.
+
+Published code can use that project's existing secrets and resources. Review the app operator and deployment details before approving code for an existing project. Migrations and resource changes in the approved manifest take effect during deployment.
+
+Disabling the app or disconnecting its grant stops authorization for subsequent actions and is checked again before a queued deployment publishes. Disconnecting does not remove an app that has already been published; manage that project through Void.
+
+## Build an OAuth client
+
+Discover endpoints at `/.well-known/oauth-authorization-server` on the platform API origin. Use authorization code flow with `scope=profile`, a random `state`, and S256 PKCE. Authenticate token exchanges using HTTP Basic client authentication. Send access tokens as Bearer credentials to `/oauth/userinfo`; its response contains `sub` and `preferred_username`.
+
+For publishing, package the built app with [`prepareDeployArtifact`](/reference/api/deploy). POST to `/oauth/deployment-requests` using the profile token:
+
+```ts
+{
+  redirect_uri: registeredCallback,
+  state: publishState,
+  code_challenge: publishChallenge,
+  code_challenge_method: 'S256',
+  slug: projectSlug,
+  checkpoint: checkpointLabel,
+  artifact: prepared.artifact
+}
+```
+
+Redirect the browser to the returned `authorization_url`. Exchange its code with the publish verifier and the same registered callback. The response includes `project_id`, `approval_id`, and a `deploy:approve` access token. This publish flow is a Void extension; requesting that scope in an ordinary sign-in does not authorize deployment.
+
+Use the token to request URLs from `POST /projects/:id/deploy/upload-urls`, upload the declared assets, and send the artifact to `POST /projects/:id/deploy`. Set `x-void-deploy-idempotency-key` to `approval_id`. Deployment uses Void's managed deployment protocol and requires the platform deployment Queue. The credential cannot read secrets, mint project tokens, delete projects, or deploy different bytes.
+
+Revoke identity grants with `POST /oauth/revoke`, authenticated as the client. No refresh token or OpenID Connect ID token is issued.
+
+If the API is protected by Cloudflare Access, the application operator must also configure a service identity permitted by that Access application's policy. Server OAuth endpoints and approved deployment requests still validate their own client, grant, and project authority; browser consent requires the user's company identity.

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.
@@ -39,6 +51,8 @@ Use the following permissions for the core platform. Cloudflare may label write
 | Account | Hyperdrive         | Write      | Write                                   |
 | Account | Account Analytics  | Read       | Read                                    |
 | Account | AI Gateway         | Edit       | Edit when installing with browser login |
+| Account | Containers         | —          | Edit                                    |
+| Account | Cloudchamber       | —          | Edit                                    |
 | Zone    | Zone               | Read       | —                                       |
 | Zone    | DNS                | Edit       | —                                       |
 | Zone    | Workers Routes     | Edit       | —                                       |
@@ -72,17 +86,21 @@ The installer deploys the email gateway, prepares the shared mail route, and ver
 
 ## R2 Upload Credentials
 
-In the **R2 token creation** form opened by the installer, select **Object Read & Write** and **Apply to all buckets in this account (including newly created buckets)**. 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. These differ from the management and runtime API tokens. See [R2’s token instructions](https://developers.cloudflare.com/r2/api/tokens/).
+`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/quickstart.md

@@ -36,6 +36,8 @@ bunx void init
 
 Choose your UI framework, a starter, and a deployment target. Vite+ is the default build tool. D1 is a good first database: it runs locally without a separate database server. Choose Cloudflare to deploy to your own account, or skip deployment setup for now.
 
+You do not need to install Vite+ globally. Setup preserves your existing package-manager versions and lockfiles.
+
 With pnpm, `pnpm create void my-app` also creates the project directory and configures native build permissions for you.
 
 ## Run locally

package/docs/guide/sandboxes.md

@@ -56,6 +56,8 @@ File operations live under `sandbox.files`: `readFile`, `writeFile`, `stat`, `ls
 
 To reach a server inside the container, await `sandbox.fetch(port, new Request(url))`. `sandbox.running()` checks whether the container is running; `sandbox.destroy()` stops it.
 
+On native Cloudflare deployments, `sandbox.fetch()` also supports WebSocket upgrade requests. Return its response from your Worker handler to connect the client to the container. WebSocket upgrades are currently unavailable on managed Void deployments.
+
 `getSandbox()` options include `inactivityTimeoutMs` (default ten minutes, maximum six hours), `enableInternet` (default `false`), and string `labels`. Internet access and labels take effect on the next container start. `binding` selects a custom native binding; managed platforms use the configured binding.
 
 For code that runs on both deployment targets, use `getSandbox()`. Direct access through `c.env.SANDBOX` is available only on local and native Cloudflare deployments.
@@ -119,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}