void 0.10.13 → 0.20.1

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

@@ -8,7 +8,7 @@ outline: deep
 Void-managed auth currently works only for Void apps. Meta-framework mode is not supported yet.
 :::
 
-Void uses [Better Auth](https://www.better-auth.com/) as the auth engine for Void apps. Void owns the conventions and wiring; Better Auth owns the auth behavior.
+Void configures [Better Auth](https://www.better-auth.com/) for your app, including its database connection, API routes, and client. Start with email and password, or add a social login provider.
 
 ## Quick Start
 
@@ -49,7 +49,7 @@ await auth.signIn.email({
 
 ### 3. Protect a server route
 
-Use `requireAuth` in an API route handler or a page loader to gate access. It returns the authenticated user or throws a `401`:
+Call `requireAuth` in a route handler or page loader that needs a signed-in user. It returns that user, or throws `401` if the request isn't authenticated:
 
 ```ts
 // routes/api/profile.ts
@@ -136,7 +136,7 @@ await auth.signIn.email({
 await auth.signOut();
 ```
 
-The exact client API comes from Better Auth. Void just preconfigures the client with `basePath: "/api/auth"`.
+The client uses Better Auth's API, configured at `/api/auth`.
 
 See the official [Better Auth client docs](https://www.better-auth.com/docs/concepts/client) for the full client API.
 
@@ -220,9 +220,9 @@ When auth is active, Void configures Better Auth with these conventions:
 
 Auth sessions live in the same database system as the rest of the app. `AUTH_KV` is no longer used.
 
-On Void Cloud, Void auto-creates `BETTER_AUTH_SECRET` for auth-enabled apps if you have not set `BETTER_AUTH_SECRET` yourself through project secrets.
+On both deployment targets, Void keeps an existing `BETTER_AUTH_SECRET` or generates one when it's missing. The value is stored as an encrypted Worker secret and reused by later versions.
 
-Localhost dev uses a built-in fallback secret automatically. Outside the managed Void Cloud deploy flow, set `BETTER_AUTH_SECRET` yourself.
+Localhost development uses a built-in fallback secret automatically. Production deployment through Void manages the secret lifecycle for you.
 
 ## Customization
 
@@ -243,19 +243,17 @@ For the full set of available options, see the official [Better Auth options ref
 
 ## Database and Migrations
 
-Void manages Better Auth migrations as part of the normal Void migration flow:
+Auth tables live alongside your app's tables. During local development, Void creates them automatically.
 
-- local dev bootstraps auth tables automatically
-- deploy runs auth migrations together with app migrations
-- users do not run a separate Better Auth CLI path
+A Void platform deploy creates the Better Auth tables at runtime after dispatch. A direct Cloudflare deploy requires those tables in your checked-in migrations. Generate them with:
 
-This applies to `void deploy` (the managed platform), which creates the Better Auth
-tables at runtime after dispatch. Deploying to your own Cloudflare account with
-[`--backend cloudflare`](/integrations/cloudflare) does **not** run that step: there,
-your checked-in `db/migrations/*.sql` must already produce the Better Auth schema, and
-deploy fails closed if they do not. Define the tables in `db/schema.ts` and run
-`void db generate` — Drizzle's `.unique()` and `.references()` are opt-in, and the
-constraints are verified too. See [#274](https://github.com/voidzero-dev/void/issues/274).
+```sh
+void db generate
+```
+
+Void adds the production Better Auth schema, including configured model names and plugin tables, to Drizzle's migration input. Review and commit the SQL before deploying. You don't need to duplicate the auth tables in `db/schema.ts` or run a separate Better Auth CLI.
+
+MySQL stores OAuth access, refresh, and ID tokens as unbounded text. Existing direct-deploy MySQL apps should run `void db generate` once after upgrading to widen earlier `varchar(255)` token columns. Void platform deployments apply the same safe widening automatically.
 
 ## Unsupported Modes
 

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

@@ -21,6 +21,12 @@ For write-heavy workloads, complex queries, or connecting to existing infrastruc
 
 None. D1 is the default dialect, so you can start by defining your schema and querying.
 
+## Local Database
+
+`void dev` and local `void db` commands share the same database. If your root `wrangler.jsonc` or `wrangler.json` already declares the D1 binding, Void uses its ID. A `preview_database_id` takes precedence during local development.
+
+To store local data outside `.void`, set `voidPlugin({ persistTo: 'local-state' })` in your Vite config. Start `void dev` once to record that directory before running database commands. After changing the Vite config, start `void dev` again to refresh it. Frameworks that manage their own Cloudflare runtime use `.wrangler/state`.
+
 ## Migrations & Prototyping
 
 Void offers two workflows for applying schema changes.

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

@@ -0,0 +1,60 @@
+---
+outline: deep
+---
+
+# MySQL
+
+Void supports MySQL through [Cloudflare Hyperdrive](https://developers.cloudflare.com/hyperdrive/). You bring a MySQL-compatible database; Void provides the Drizzle runtime, local tooling, migration workflow, and deployment wiring.
+
+## Configure
+
+Set the dialect in `void.json`:
+
+```json
+{
+  "database": "mysql"
+}
+```
+
+Add a direct connection for local development:
+
+```dotenv
+DATABASE_URL=mysql://user:password@host:3306/app
+```
+
+Void reads `.env` for `void dev` and `void db` commands. In production, the Worker connects through the inferred `HYPERDRIVE` binding.
+
+## Define a schema
+
+```ts
+// db/schema.ts
+import { int, mysqlTable, text, timestamp } from 'void/schema-mysql';
+
+export const messages = mysqlTable('messages', {
+  id: int('id').autoincrement().primaryKey(),
+  text: text('text').notNull(),
+  createdAt: timestamp('created_at').notNull().defaultNow(),
+});
+```
+
+`void gen model` generates MySQL builders automatically when the project uses the MySQL dialect.
+
+## Migrations
+
+Use the normal workflow:
+
+```sh
+void db generate
+void db migrate
+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.
+:::
+
+## Database commands
+
+`void db push`, `generate`, `migrate`, `status`, `reset`, `seed`, `execute`, `studio`, `export`, `rename-migrations`, and `set-url` all understand MySQL. Local commands use `DATABASE_URL` from `.env`; `--remote` execution and Studio use the encrypted URL stored for a linked Void project.

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

@@ -4,13 +4,13 @@ outline: deep
 
 # PostgreSQL
 
-Void supports PostgreSQL via [Cloudflare Hyperdrive](https://developers.cloudflare.com/hyperdrive/). You bring the Postgres database, and Void handles connection pooling plus deployment wiring through the same Drizzle-based workflow used for D1.
+Connect your PostgreSQL database through [Cloudflare Hyperdrive](https://developers.cloudflare.com/hyperdrive/), then use the same Drizzle schema and query workflow as D1.
 
 ## What is Hyperdrive?
 
-Hyperdrive is Cloudflare's connection pooling and caching layer for PostgreSQL. It maintains persistent connections from the edge to your database, dramatically reducing connection latency. Instead of establishing a new TCP + TLS connection on every request, your Worker reuses pooled connections through Hyperdrive.
+Hyperdrive pools connections between your Worker and PostgreSQL. Requests reuse an existing connection instead of opening a new TCP and TLS connection each time.
 
-Void manages the Hyperdrive configuration automatically. You only provide the connection string.
+Void can provision the Hyperdrive configuration from your connection string. Direct Cloudflare deploys also need an API token for first-time provisioning; see the [Cloudflare guide](../../integrations/cloudflare.md#databases-and-secrets).
 
 ## Configuration
 
@@ -26,7 +26,7 @@ Add to your `void.json`:
 
 ### 2. Add your connection string
 
-For local development, add `DATABASE_URL` to `.env.local`:
+For local development, add `DATABASE_URL` to `.env`:
 
 ```
 DATABASE_URL=postgresql://user:password@host:5432/mydb?sslmode=require
@@ -36,17 +36,17 @@ This connects directly to your Postgres database during local Vite development.
 
 ### 3. Deploy
 
-On your first deploy, the CLI will prompt for your connection string:
+When deploying to a Void platform, the CLI asks for a connection string if Hyperdrive isn't configured:
 
 ```
 Your project uses PostgreSQL. Enter your connection string:
 > postgresql://user:password@host:5432/mydb?sslmode=require
 ```
 
-Void provisions a Hyperdrive configuration and stores only the config ID. Your connection string is sent directly to Cloudflare's API and is never stored by Void.
+Void provisions Hyperdrive and records its config ID. The connection string isn't written to `wrangler.jsonc` or generated Worker config.
 Both `postgres://` and `postgresql://` URLs are supported, including provider-supplied query strings such as `?sslmode=require`.
 
-You can also set the connection string ahead of time with `void db set-url`.
+For a linked Void project, you can also configure the connection with `void db set-url`. For a direct Cloudflare deploy, export the production `DATABASE_URL` in your shell.
 
 ## Schema Definition
 
@@ -88,7 +88,7 @@ The main difference is that PostgreSQL supports **transactional DDL**. Each migr
 
 ## Deploy Workflow
 
-When you run `void deploy` with a PostgreSQL project:
+When deploying a PostgreSQL project to a Void platform:
 
 1. The app is built
 2. Migration files are collected from `db/migrations/`
@@ -96,9 +96,14 @@ When you run `void deploy` with a PostgreSQL project:
 4. Pending migrations run inside the deployed worker via Hyperdrive
 5. The new worker goes live
 
+When deploying to your own account with `void deploy --platform cloudflare`, export the production
+connection string as `DATABASE_URL`. Void uses it to provision Hyperdrive and apply the checked-in
+migrations transactionally before it uploads the Worker. The connection string is not written to
+`wrangler.jsonc` or the generated Worker config.
+
 ## Updating the Connection String
 
-To update the connection string for an existing deployment (e.g. migrating to a new database host):
+To update a linked Void project's connection, for example after moving the database to another host:
 
 ```bash
 void db set-url

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

@@ -33,26 +33,26 @@ const dbFileItems = [
 
 # Database
 
-Void provides a first-class [Drizzle ORM](https://orm.drizzle.team) integration. Define your schema in TypeScript, import the pre-wired Drizzle instance from `void/db`, and start querying. You do not need an extra install.
+Define your tables in TypeScript, then query them with `db` from `void/db`. Void includes [Drizzle ORM](https://orm.drizzle.team) and configures the connection, so you can use the same schema and query workflow with D1, PostgreSQL, or MySQL.
 
 <FileTree :items="dbFileItems" default-expanded />
 
 ## Choosing a Dialect
 
-Void supports two database backends. Both use the same Drizzle-based workflow for schema definition, querying, and migrations.
+Void supports three database backends. All use the same Drizzle-based workflow for schema definition, querying, and migrations.
 
-`void init` can start you with D1, PostgreSQL, or no database yet. Choosing D1 keeps the default implicit; choosing PostgreSQL writes `"database": "pg"` to `void.json`; choosing no database lets you start with static Pages and adopt data features later.
+`void init` can start you with D1, PostgreSQL, MySQL, or no database yet. D1 stays implicit; PostgreSQL writes `"database": "pg"`; MySQL writes `"database": "mysql"`.
 
-|            | [D1 (SQLite)](./database/d1) | [PostgreSQL](./database/postgresql)          |
-| ---------- | ---------------------------- | -------------------------------------------- |
-| Config     | Default (no config needed)   | `"database": "pg"` in `void.json`            |
-| Managed by | Void (fully managed)         | Bring your own database                      |
-| Best for   | Read-heavy apps, prototyping | Write-heavy, complex queries, existing infra |
-| Connection | Automatic D1 binding         | Hyperdrive connection pooling                |
+|            | [D1 (SQLite)](./database/d1) | [PostgreSQL](./database/postgresql) | [MySQL](./database/mysql)     |
+| ---------- | ---------------------------- | ----------------------------------- | ----------------------------- |
+| Config     | Default                      | `"database": "pg"`                  | `"database": "mysql"`         |
+| Managed by | Void                         | Bring your own database             | Bring your own database       |
+| Best for   | Prototypes, read-heavy apps  | Complex queries, existing Postgres  | Existing MySQL infrastructure |
+| Connection | Automatic D1 binding         | Hyperdrive                          | Hyperdrive                    |
 
 ## Schema Definition
 
-Define your tables in `db/schema.ts` using column helpers from `void/schema-d1` or `void/schema-pg`. This file is the source of truth for your database structure:
+Define your tables in `db/schema.ts` using column helpers from `void/schema-d1`, `void/schema-pg`, or `void/schema-mysql`.
 
 ::: code-group
 
@@ -85,9 +85,21 @@ export const users = pgTable('users', {
 });
 ```
 
+```ts [MySQL]
+// db/schema.ts
+import { int, mysqlTable, text, timestamp } from 'void/schema-mysql';
+
+export const users = mysqlTable('users', {
+  id: int('id').autoincrement().primaryKey(),
+  name: text('name').notNull(),
+  email: text('email').notNull(),
+  createdAt: timestamp('created_at').notNull().defaultNow(),
+});
+```
+
 :::
 
-Everything ships with `void`, so there is nothing extra to install. You also do not have to write this by hand. Use `void gen model` or let your coding agent generate it.
+The schema helpers are included in `void`. You can write tables yourself or generate a starting point with `void gen model`.
 
 You can also split your schema across multiple files under `db/schema/` and re-export from a barrel file:
 
@@ -245,7 +257,7 @@ If more than one default seed file exists, pass `--file <path>` explicitly.
 
 ### Programmatic seeding
 
-`db/seed.ts` is the first-class path for generated or randomized data. Seed modules can export either a default function or a named `seed` function.
+Use `db/seed.ts` when you want to generate seed data in code. Export a default function or a named `seed` function.
 
 ```ts
 // db/seed.ts
@@ -276,7 +288,7 @@ INSERT INTO messages (text) VALUES ('Hello from SQL');
 
 ## Schema-Derived Validators
 
-Instead of writing validator schemas by hand, you can derive them directly from your Drizzle tables using Void's bundled adapter entrypoints: [`void/drizzle-zod`](../reference/api.md#subpath-exports), [`void/drizzle-valibot`](../reference/api.md#subpath-exports), and [`void/drizzle-arktype`](../reference/api.md#subpath-exports). These resolve through the same package boundary as `void/schema-*`, so the generated validators stay type-compatible with your tables automatically.
+You can derive request validators from your Drizzle tables with [`void/drizzle-zod`](../reference/api.md#user-facing-imports), [`void/drizzle-valibot`](../reference/api.md#user-facing-imports), or [`void/drizzle-arktype`](../reference/api.md#user-facing-imports). These adapters use Void's bundled Drizzle version, keeping the validators compatible with your table types.
 
 ::: code-group
 
@@ -385,24 +397,25 @@ npm install arktype
 
 ## CLI Commands
 
-| Command            | Purpose                                                       |
-| ------------------ | ------------------------------------------------------------- |
-| `void db push`     | Apply schema directly to local database (no migration files)  |
-| `void db generate` | Generate SQL migration files from schema changes              |
-| `void db migrate`  | Apply pending migrations locally                              |
-| `void db status`   | Show schema drift and pending migrations                      |
-| `void db reset`    | Drop the local DB and re-apply all migrations                 |
-| `void db seed`     | Reset + run seed file (`--file <path>`)                       |
-| `void db execute`  | Run ad-hoc SQL against local DB (`--file <path>`)             |
-| `void db studio`   | Open Drizzle Studio for the local database                    |
-| `void db export`   | Dump local DB as SQL (`--output`, `--no-data`, `--no-schema`) |
-| `void db set-url`  | Update the PostgreSQL connection string for deployment        |
+| Command            | Purpose                                                         |
+| ------------------ | --------------------------------------------------------------- |
+| `void db push`     | Apply schema directly to local database (no migration files)    |
+| `void db connect`  | Connect or provision PostgreSQL/MySQL and save `DATABASE_URL`   |
+| `void db generate` | Generate app and Better Auth SQL migrations for production      |
+| `void db migrate`  | Apply pending migrations locally                                |
+| `void db status`   | Show schema drift and pending migrations                        |
+| `void db reset`    | Drop the local DB and re-apply all migrations                   |
+| `void db seed`     | Reset + run seed file (`--file <path>`)                         |
+| `void db execute`  | Run ad-hoc SQL against local DB (`--file <path>`)               |
+| `void db studio`   | Open Drizzle Studio for the local database                      |
+| `void db export`   | Dump local DB as SQL (`--output`, `--no-data`, `--no-schema`)   |
+| `void db set-url`  | Update the PostgreSQL or MySQL connection string for deployment |
 
 See the [CLI reference](../reference/cli.md#database) for details.
 
 ## Scaffolding
 
-The `void gen model` command scaffolds a Drizzle table definition and updates your barrel export. It generates dialect-appropriate code: `sqliteTable` for D1 and `pgTable` for PostgreSQL.
+The `void gen model` command generates dialect-appropriate `sqliteTable`, `pgTable`, or `mysqlTable` definitions.
 
 ```bash
 void gen model post title:string body:text published:boolean

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

@@ -4,18 +4,61 @@ outline: deep
 
 # Deployment
 
-Void apps run on Cloudflare's infrastructure but you don't need to use your own Cloudflare account. Our long term goal is to provide a simpler app-centric deployment experience similar to that of Vercel and Netlify. But right now, Void only supports deploying via the CLI or GitHub actions.
+Use `void deploy` to deploy your app to your own Cloudflare account or a Void platform run by your team. The CLI builds your app, creates the resources it needs, and applies your database migrations.
+
+Choose Cloudflare if you're deploying an app yourself. Choose Void if your team has a shared platform you can connect to. You can also [install a Void platform](./self-hosted-platform.md) in your company's Cloudflare account.
+
+## Beta Support
+
+Direct Cloudflare deployment runs an application in your account. A self-hosted
+Void platform provides that deployment service to a team using the operator's
+account. Both use the same application APIs, with the following differences:
+
+| Feature                                          | Direct Cloudflare                | Core self-hosted platform                 |
+| ------------------------------------------------ | -------------------------------- | ----------------------------------------- |
+| Static sites, SPAs, and native Pages SSR         | Supported                        | Supported                                 |
+| Routing rules, WebSockets, queues, cron, and ISR | Supported                        | Supported                                 |
+| D1, KV, R2, and external SQL through Hyperdrive  | Supported                        | Supported                                 |
+| Workers AI and provider requests                 | Your account and gateway         | Installation gateway and proxy            |
+| Runtime logs                                     | Live Cloudflare tail             | Retained platform logs                    |
+| Application rollback                             | Worker versions                  | Retained platform deployments             |
+| Typed Durable State                              | Supported                        | Unavailable                               |
+| Sandboxes                                        | Requires Workers Paid and Docker | Unavailable in beta                       |
+| Custom application domains                       | Supported                        | Unavailable in the core installation      |
+| Generated GitHub deployment workflow             | Supported                        | Use your CI with a scoped developer token |
+| User dashboard and managed GitHub builds         | Not required                     | Not included in a standard installation   |
+
+Ordinary native applications remain compatible with Workers Free within its
+quotas. Installing a team platform requires Workers for Platforms and the
+[documented infrastructure](./self-hosted-platform.md#cloudflare-footprint).
+Application rollback never reverses database migrations.
+
+Routing-rule parity applies to native Void applications and static deployments.
+Framework-owned Worker output uses its framework's routing and asset policy;
+unsupported Void routing rules are rejected before direct deployment.
+
+Use matching CLI and framework adapter versions. For a team platform, the available features depend on its installed version and configuration. Ask your administrator if a feature is unavailable or an upgrade is required.
 
 ## CLI
 
 ### First deploy
 
 ```bash
-void init               # can handle auth + project setup during onboarding
-void deploy             # auto-detects app type, builds, deploys
+void init   # choose Cloudflare (default), Void, or Skip deployment setup
+void deploy # builds and deploys to the saved platform
 ```
 
-If you skipped Void project setup during `void init`, you can still run `void auth login` manually. On first deploy, the CLI will prompt you to create or select a project if none is linked yet. The project link is saved to `.void/project.json` for subsequent deploys.
+During setup, Void asks where you want to deploy:
+
+- **Cloudflare:** sign in through your browser and choose an account. Void saves the account in `wrangler.jsonc`.
+- **Void:** connect to a platform, sign in, and link or create a project.
+- **Skip:** set up deployment later with `void connect`.
+
+Your choice is saved in `.void/project.json`, so the next deploy is just `void deploy`.
+
+Already have a Cloudflare Worker and a root `wrangler.jsonc` or `wrangler.json`? Run `void deploy`. If no destination is selected, Void offers to link and deploy using the existing Worker and resources. Accept once to keep deploying to that site. See [Deploy an existing Worker](../integrations/cloudflare.md#deploy-an-existing-worker) for the first-deployment checks.
+
+To connect to your team's platform and sign in, run `void connect <url>` using the URL from your administrator. Use `void connect --platform cloudflare` to set up your own Cloudflare account. Connecting preserves existing project links. New Void projects need a platform connection.
 
 ### Migrations
 
@@ -23,33 +66,34 @@ If your app uses Drizzle, `void deploy` runs migrations as part of the deploy fl
 
 1. Build the app
 2. Read SQL migrations from `db/migrations/`
-3. Fail if the schema has drifted ahead of the committed migrations
+3. Check that the migrations match your current schema
 4. Apply pending migrations to the target database
 5. Make the new deploy live
 
-Deploy always uses checked-in migration files. If drift is detected, run `void db generate`, review the generated migration, commit it yourself, then rerun deploy. For the full database workflow and backend-specific details, see the [Database guide](./database.md).
+If you've changed your schema without a matching migration, deploy stops. Run `void db generate`, review and commit the SQL, then deploy again. For the full database workflow and backend-specific details, see the [Database guide](./database.md).
 
 ### Flags
 
 ```bash
-void deploy [--project <name>] [--dir <path>] [--spa]
+void deploy [--platform <cloudflare|void>] [--project <name>] [--dir <path>] [--spa]
 ```
 
-| Flag               | Purpose                                           |
-| ------------------ | ------------------------------------------------- |
-| `--project <name>` | Target a specific project by slug                 |
-| `--dir <path>`     | Deploy a pre-built static directory (skips build) |
-| `--spa`            | Use SPA mode instead of SSG for static deploys    |
+| Flag                            | Purpose                                           |
+| ------------------------------- | ------------------------------------------------- |
+| `--platform <cloudflare\|void>` | Override the saved deployment platform            |
+| `--project <name>`              | Target a specific Void project by slug            |
+| `--dir <path>`                  | Deploy a pre-built static directory (skips build) |
+| `--spa`                         | Use SPA mode instead of SSG for static deploys    |
 
 ### Project resolution
 
-The CLI resolves which project to deploy to in this order:
+For a Void platform deploy, the CLI chooses the project in this order:
 
 1. `--project <name>` flag
 2. `VOID_PROJECT` environment variable
 3. Linked project in `.void/project.json`
 
-If none match, the CLI prompts interactively.
+If none is set, Void asks you to choose a project. Direct Cloudflare deploys use the Worker and account saved in your Cloudflare config.
 
 ### CI preparation
 
@@ -64,11 +108,19 @@ If your CI pipeline runs typechecking or other static analysis before deploy, ru
 
 ## GitHub
 
-You can deploy from a GitHub repo on every push to `main`. Running `void init --github` generates `.github/workflows/void-deploy.yml` in your project.
+You can deploy from a GitHub repo on every push to `main`. Running `void init --github` generates `.github/workflows/void-deploy.yml` for the platform saved in `.void/project.json`.
+
+For Cloudflare, add `CLOUDFLARE_API_TOKEN` to your repository secrets. The token needs access to the account and products your app uses. PostgreSQL and MySQL apps also need a `DATABASE_URL` secret.
+
+If your Worker has no version preview URL, set the `CLOUDFLARE_WORKERS_SUBDOMAIN` repository variable. If Cloudflare Access protects the Worker, also add `CF_ACCESS_CLIENT_ID` and `CF_ACCESS_CLIENT_SECRET` secrets so Void can check that a deployment is ready. See [Cloudflare deployment](../integrations/cloudflare.md#deploy-to-your-own-cloudflare-account) for the setup details.
 
-### Void GitHub App (recommended)
+Void platforms with GitHub Actions support use short-lived GitHub OIDC credentials. You don't need to store a `VOID_TOKEN` for that workflow.
 
-No `.github/workflows/void-deploy.yml` or repository `VOID_TOKEN` is required.
+### Void GitHub App
+
+If your platform supports managed GitHub builds, the Void GitHub App can build and deploy your app when you push. This feature requires a platform with a configured GitHub App and build Containers; it isn't included in a core self-hosted installation.
+
+You don't need a deployment workflow file or a repository `VOID_TOKEN` for this path.
 
 1. Initialize your Void project
 
@@ -84,7 +136,7 @@ void project link
 void github install
 ```
 
-You should receive GitHub url asking you to install and authorize `Void Deploy`.
+Void opens GitHub so you can install and authorize the `Void Deploy` app.
 
 In the browser, select the GitHub account/organization and grant access to the repository.
 
@@ -103,13 +155,15 @@ void github join
 void github connect --executor container
 ```
 
+Organization installations always require a browser proof for the specific repository, including for the person who installed the App. Void does not reveal the installation's full private repository list. If an upgraded platform marks an older organization connection as requiring reconnection, run the same `void github connect` command again to renew that repository-scoped authorization before builds resume.
+
 4. Verify the connection
 
 ```bash
 void github status
 ```
 
-You should receive an output like:
+The output shows the repository, branch, and build executor:
 
 ```bash
 Repository      <owner/repository>
@@ -133,7 +187,9 @@ void build logs --follow
 
 ### GitHub Actions
 
-The workflow authenticates with [GitHub OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) — there is **no long-lived `VOID_TOKEN` secret to store or rotate**. `void deploy` detects GitHub Actions and does the exchange itself: it requests a short-lived OIDC token from GitHub (audience `void`), exchanges it at `POST $VOID_API_URL/auth/github-oidc` for a short-lived project-scoped deploy token (about 15 minutes on the free tier; longer on higher plans, capped at ~60 minutes), and deploys — so the workflow is a single `void deploy` step. `permissions: id-token: write` is still required: it is what lets the job (and the CLI) mint the OIDC token.
+On platforms that support it, the generated workflow uses [GitHub OIDC](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) to obtain a short-lived deploy token for your project. `void deploy` handles the exchange automatically. Keep `permissions: id-token: write` in the workflow so GitHub can issue that credential.
+
+The generated workflow uses the platform selected during `void init`. Core self-hosted installations don't yet support this integration, so Void doesn't offer the workflow for them. For a platform that does, the npm version looks like this; set the repository's `VOID_API_URL` variable to your platform's API URL:
 
 ```yaml
 name: Deploy to Void
@@ -152,7 +208,7 @@ permissions:
   contents: read
 
 env:
-  VOID_API_URL: ${{ vars.VOID_API_URL || 'https://api.void.cloud' }}
+  VOID_API_URL: ${{ vars.VOID_API_URL }}
   VOID_PROJECT: my-app
 
 jobs:
@@ -166,13 +222,31 @@ jobs:
           cache: npm
       - run: npm ci
       - name: Deploy
-        run: npx void deploy --project "$VOID_PROJECT"
+        run: npx void deploy --platform void --project "$VOID_PROJECT"
 ```
 
-Connect the repository to your project once with `void github connect <project> --repo <owner/repo> --executor github_actions` to authorize it. This GitHub Actions path requires the `github_actions` build executor — the default `container` executor will not work with this workflow. The exact steps vary by package manager (the scaffold detects pnpm, yarn, bun, or npm). The `VOID_PROJECT` value is baked in from your linked project when known; otherwise the workflow reads a `VOID_PROJECT` repository variable. To target staging, set a `VOID_API_URL` repository variable to `https://api.staging.void.cloud`.
+Authorize the repository once with `void github connect <project> --repo <owner/repo> --executor github_actions`. Choose the `github_actions` executor for this workflow; `container` runs builds on the platform instead.
+
+The generated workflow uses your package manager and linked project. If no project is linked, it reads the `VOID_PROJECT` repository variable.
 
 ## Other Targets
 
-If you prefer to deploy directly to your own Cloudflare account instead of using Void's managed platform, run `void deploy --backend cloudflare` (add `--provision` on the first deploy to create the D1/KV/R2/Queues/Hyperdrive resources your app needs). This uses your local wrangler auth and root `wrangler.jsonc` -- pin an account (`account_id` or `CLOUDFLARE_ACCOUNT_ID`) and keep real secrets in `wrangler secret put` rather than `.env`. `wrangler login` is enough to authenticate, with one exception: provisioning a **Hyperdrive** config for the first time needs `CLOUDFLARE_API_TOKEN`, because wrangler exposes no machine-readable Hyperdrive list for Void to check against (an already-provisioned Hyperdrive app deploys fine under `wrangler login`). In v1 it deploys **full Void apps on the Cloudflare Workers target** (D1/KV/R2/Queues/Hyperdrive; auth and ISR on D1/SQLite); framework SSR (TanStack Start, React Router, vinext, SvelteKit, Nuxt, Analog, Astro), static/SPA/SSG apps (including `output: "static"`), WebSocket/Durable Object apps (`*.ws.ts`), a custom `migrations_pattern`, `--skip-build`, `node`/`bun`/`deno` targets, and PostgreSQL apps with auth all fail closed with guidance. Auth apps must ship checked-in migrations that produce the Better Auth schema. Provision is a single-operator, dev-machine step and is disabled in CI. See the [Cloudflare integration guide](../integrations/cloudflare.md#deploy-to-your-own-cloudflare-account) for the full walk-through and scope.
+### Your own Cloudflare account
+
+Select Cloudflare during setup, or run:
+
+```sh
+void deploy --platform cloudflare
+```
+
+Void supports full Worker apps, static sites, SPAs, and Cloudflare builds from supported frameworks. It provisions resources, applies migrations, and manages secrets for you. `.env` stays local; production server keys declared in `env.ts` must exist in encrypted remote secret storage and are rejected as plaintext Worker vars. Commands such as `void secret put`, `void project logs`, and `void project rollback` then use the same account and Worker.
+
+See the [Cloudflare guide](../integrations/cloudflare.md#deploy-to-your-own-cloudflare-account) for supported features, CI setup, and deployment limits.
+
+### Node.js, Bun, and Deno
+
+Set [`target`](../reference/config.md#target) in `void.json` to build a standalone server for Node.js, Bun, or Deno. You can run the result on your own server or in a container.
+
+Deploy `dist/ssr` and `dist/client` together. The server loads the Pages client manifest and assets relative to its emitted module; start it from the app root with `node dist/ssr/index.js`, `bun dist/ssr/index.js`, or `deno run -A dist/ssr/index.js`.
 
-To deploy to Node.js, Bun, or Deno instead of Cloudflare, set [`target`](../reference/config.md) in `void.json`. This builds a standalone server you can run anywhere, including Docker, Railway, and Fly.io. These targets do not have access to Void platform features such as D1, KV, R2, built-in auth, Workers AI, or cron scheduling. See the [Node.js, Bun, and Deno guide](../integrations/nodejs-bun-deno.md).
+These targets don't provide Cloudflare bindings such as D1, KV, R2, and Workers AI. See the [Node.js, Bun, and Deno guide](../integrations/nodejs-bun-deno.md) for the features available on each target.