void 1.5.0 → 1.6.0

package/docs/guide/pages-routing/overview.md

@@ -199,6 +199,8 @@ import { routeUrl } from 'void/routes';
 
 :::
 
+With [`routing.typedRoutes`](../type-safety.md#checked-url-strings), which apps created with `void init` have on, `href` and the router methods below reject plain strings such as `"/user"` that don't match a route.
+
 `Link` also supports query data, history replacement, full-page navigation, and cancellation:
 
 ```tsx
@@ -263,12 +265,113 @@ export default function PostPage() {
 }
 ```
 
+### Active links
+
+`Link` marks the link to the current page with `aria-current="page"` and `data-void-active`. Use them to style navigation:
+
+```css
+nav a[data-void-active] {
+  font-weight: 600;
+}
+```
+
+A link is active only on its own path by default. Set `activeMatch="prefix"` to keep it active on nested pages:
+
+::: code-group
+
+```tsx [React]
+<nav>
+  <Link href="/">Home</Link>
+  <Link href="/users" activeMatch="prefix">
+    Users
+  </Link>
+</nav>
+```
+
+```vue [Vue]
+<nav>
+  <Link href="/">Home</Link>
+  <Link href="/users" active-match="prefix">Users</Link>
+</nav>
+```
+
+```svelte [Svelte]
+<nav>
+  <Link href="/">Home</Link>
+  <Link href="/users" activeMatch="prefix">Users</Link>
+</nav>
+```
+
+```tsx [Solid]
+<nav>
+  <Link href="/">Home</Link>
+  <Link href="/users" activeMatch="prefix">
+    Users
+  </Link>
+</nav>
+```
+
+:::
+
+| Current URL     | `href="/users"` | `href="/users" activeMatch="prefix"` |
+| --------------- | --------------- | ------------------------------------ |
+| `/users`        | both attributes | both attributes                      |
+| `/users?page=2` | both attributes | both attributes                      |
+| `/users/42`     | none            | `data-void-active`                   |
+| `/users-admin`  | none            | none                                 |
+
+`aria-current="page"` marks only the exact page, so select `[aria-current="page"]` to style it differently from its section. A link to `/` is active only on the home page.
+
+Paths match the way pages are routed: letter case and trailing slashes count, while the query string and hash are ignored. Links to other origins and non-GET links are never active. An `aria-current` or `data-void-active` you pass to `Link` replaces the computed value.
+
+### Pending links
+
+While a page loads, `Link` adds `data-void-pending` to every link to it. Use it to show that a click is being handled:
+
+```css
+a[data-void-pending] {
+  opacity: 0.6;
+  /* Skip visits that finish quickly, such as to a prefetched page */
+  transition: opacity 0.15s 0.1s;
+}
+```
+
+A link is pending only while its exact destination loads. The path, query and hash must all match, so a link to `/users?page=2` isn't pending while `/users?page=3` loads. A non-GET link, which renders a `<button>`, is pending while a request with its method to its `href` runs. `router.refresh()` reloads the current page, so links to it are pending during a refresh.
+
+A `data-void-pending` you pass to `Link` replaces the computed value. For a loading indicator that covers the whole page, use [`useNavigation()`](../../reference/api/pages.md).
+
+### Prefetching
+
+Add `prefetch` to a `Link` to load its page before the user clicks, so the visit doesn't wait for the server:
+
+```tsx
+<Link href="/dashboard" prefetch>
+  Dashboard
+</Link>
+```
+
+`prefetch` on its own loads the page on hover, keyboard focus, or touch. A `Link` can also prefetch on click, as soon as it renders, or once it stays in view, and `cacheFor` sets how long a prefetched page is reused. See [Prefetching](../../reference/api/pages.md#prefetching) for every option.
+
+To give every `Link` a prefetch strategy, set `prefetch.defaultStrategy` in the adapter plugin. A `Link` that sets its own `prefetch` keeps it:
+
+```ts
+// vite.config.ts
+voidReact({ prefetch: { defaultStrategy: 'hover' } });
+```
+
+Prefer `'hover'` or `'click'` as the default. With `'mount'` or `'visible'`, every `Link` loads its page once it renders or stays in view, which adds up in long lists.
+
+`Link` doesn't prefetch while the browser reports that data saver is on or the connection is 2G, which only Chromium-based browsers report.
+
+Prefetching runs the destination's loader, so keep loaders free of side effects such as counting views.
+
 ## Scroll Restoration
 
 Void manages scroll position for Pages automatically:
 
 - **Back/forward navigation and reloads** restore the saved scroll position.
 - **New navigation** scrolls to the top of the page.
+- **Actions and forms** keep scroll when updating the current page. Redirects follow normal navigation behavior.
 - **Hash links** (`/docs#api`) scroll to the target element. Same-page hash links (`#section`) skip the server fetch entirely.
 
 To keep the current scroll position, pass `preserveScroll: true`:

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

@@ -16,7 +16,7 @@ Local development permits exact HTTP callbacks on localhost when the platform's
 
 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.
+Users can disconnect applications at `<platform API URL>/oauth/connections`. Access tokens expire after an hour, and apps renew them with a refresh token. Refreshing does not extend access past the Void sign-in the user approved the app from: access ends 30 days after that sign-in, or earlier if the sign-in is revoked or the account is suspended. Applications must then ask the user to sign in again.
 
 ## Private previews
 
@@ -48,6 +48,8 @@ Disabling the app or disconnecting its grant stops authorization for subsequent
 
 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`, `preferred_username`, and the consented `scope`.
 
+The code exchange also returns a `refresh_token`. To renew access, POST `grant_type=refresh_token` and `refresh_token` to `/oauth/token` with client Basic authentication. The response has a new access token and a new `refresh_token`; store the new one and discard the old. Each refresh token works once: sending a used one again revokes the connection and the user must reconnect, so send one refresh at a time per connection. Store refresh tokens as securely as access tokens. An optional space-separated `scope` requests fewer permissions than the user approved; the connection keeps the narrower set, and later refreshes cannot widen it. `deploy:approve` publish tokens never come with a refresh token, so each publish still needs its own approval.
+
 For publishing, package the built app with [`prepareDeployArtifact`](/reference/api/deploy). POST to `/oauth/deployment-requests` using the profile token:
 
 ```ts
@@ -66,6 +68,6 @@ Redirect the browser to the returned `authorization_url`. Exchange its code with
 
 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.
+Revoke a connection with `POST /oauth/revoke`, authenticated as the client, using either its access token or its refresh token. Void does not issue an OpenID Connect ID token.
 
 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

@@ -8,7 +8,7 @@ Keep one password-manager entry for this platform. Paste the saved values into t
 
 | 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.            |
+| Management API token                   | You, in Cloudflare               | Lets the CLI create a zone, change DNS, and set up Access.                               |
 | 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.                                                         |
@@ -20,11 +20,13 @@ Keep one password-manager entry for this platform. Paste the saved values into t
 
 ## 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.
+For a domain installation or Cloudflare Access setup, the installer guides you through creating tokens using Cloudflare's [API token setup](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/): a runtime token, and a separate management token when the installation creates the zone or its wildcard DNS record, or sets up Access. 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.
 
 For workers.dev testing with the default API hostname, browser login can authorize
-infrastructure setup. Void also checks account-wide Access requirements; if the
-current credential cannot read them, the installer asks for a scoped Access token.
+infrastructure setup. So can a domain installation on an existing zone whose
+`*.<application domain>` record is already proxied. Void also checks account-wide
+Access requirements; if the current credential cannot read them, the installer
+asks for a scoped Access token.
 Protected apps and public apps under Default-Deny need an ongoing app-management
 token, stored encrypted. Access setup requires a management token even on
 workers.dev. Skip zone permissions until you add a domain.

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

@@ -147,6 +147,19 @@ Let running rotations finish before you roll back. If an older proxy runs next t
 
 :::
 
+### Change runtime logs {#runtime-logs}
+
+Switch an installed platform between [full and minimal runtime logs](/guide/platform/installation/setup#runtime-logs) with an upgrade:
+
+```sh
+void platform upgrade [id] --runtime-logs minimal
+void platform upgrade [id] --runtime-logs full
+```
+
+Later upgrades keep the setting. The upgrade also changes Workers Logs on the projects' existing deployments. If that step fails, the upgrade still finishes and prints what to run next: `void platform repair [id]` after switching to minimal, or the same upgrade again after switching to full. Records stored before the change are not removed; they expire with Cloudflare's retention.
+
+While runtime logs are minimal, `void platform rollback` refuses a runtime that does not support the setting. Run `void platform upgrade [id] --runtime-logs full` first.
+
 ### Platform Workers changed outside Void {#workers-changed-outside-void}
 
 Use Void commands to manage the platform's Workers. If their configuration was changed in Cloudflare, or Void cannot identify the active version, maintenance asks you to approve replacing it. Preview the affected Workers with `--plan`.

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

@@ -12,7 +12,7 @@ For workers.dev testing, start the interactive install and choose your login met
 void platform install --workers-dev
 ```
 
-For a domain installation or Access setup, Void guides you to create a management API token and paste it into a masked prompt. Browser login can preview DNS, but cannot change it or configure Access. The token-creation link preselects the permissions for your choices. When using an existing domain, change the zone policy from **All Domains** to **Specified Domains** and select your zone, as the CLI prompt describes. No shell environment variable is needed for interactive installation.
+When a domain installation creates the zone or its wildcard DNS record, or you set up Access, Void guides you to create a management API token and paste it into a masked prompt. Browser login can preview DNS and use an existing proxied `*.<application domain>` record, but cannot change DNS or configure Access. The token-creation link preselects the permissions for your choices. When using an existing domain, change the zone policy from **All Domains** to **Specified Domains** and select your zone, as the CLI prompt describes. No shell environment variable is needed for interactive installation.
 
 ::: details Use an existing management token from the shell
 
@@ -93,6 +93,25 @@ Keep the file’s existing `connections` configuration. For `mode: "platform"`,
 same-account identity and policy selections are reused. Headless setup requires an
 explicit app-management token; it never silently retains an installer-only token.
 
+## Choose what runtime logs record {#runtime-logs}
+
+By default, the platform records each request's URL, console output, and exception messages. Project owners see them with `void project logs`, and administrators with `void platform deployment logs`. They are kept in your Cloudflare account, in Workers Logs and in the platform's log history.
+
+If your apps can put personal data in URLs, logs, or error messages, install with minimal runtime logs:
+
+```sh
+void platform install --runtime-logs minimal
+```
+
+With minimal runtime logs:
+
+- Platform and project Workers do not send anything to Workers Logs.
+- Log history keeps each request's time, method, status, outcome, deployment, log levels, and exception names, but not its URL, log messages, or exception messages.
+- `--level` filters still work. `--filter` can match exception names, but not the messages that are no longer recorded.
+- Log views say that messages and URLs are not recorded on this platform.
+
+The setting covers the whole platform. To change it later, see [Change runtime logs](/guide/platform/installation/maintenance#runtime-logs).
+
 ## Finish login configuration
 
 For Google, create an OAuth client and register the printed callback URL. You
@@ -262,4 +281,6 @@ Resume restores your selected Hyperdrive. If that selection is missing from the
 
 If Cloudflare rejects a saved runtime token, Void opens the token page and asks for a replacement. For a missing [email permission](/guide/platform/installation/credentials#enable-email), update the existing token's permissions and resume. If you supplied a token through an environment variable, update that variable.
 
+To replace the runtime token, for example after revoking it, resume with the new token in `VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN`. Void checks it, saves it, and updates the platform Workers that the interrupted run already deployed.
+
 :::

package/docs/guide/ssg.md

@@ -58,8 +58,8 @@ With the default `output: "server"`, use `export const prerender = true` for dep
 
 `void deploy` chooses the deployment automatically:
 
-- **Fully static:** if every page is prerendered and there are no API routes, middleware, cron jobs, or queues, Void deploys as a pure static site with no worker.
-- **Hybrid:** if any pages are not prerenderable, such as dynamic pages without `getPrerenderPaths()` or pages with `export const prerender = false`, a worker is deployed to handle those routes at runtime. Prerendered pages are still served as static assets.
+- **Fully static:** if every page is prerendered and there are no API routes, middleware, cron jobs, or queues, Void deploys the built files as a static site. With `--platform cloudflare`, pages and files are served without running a Worker. If you use [edge rules](./edge/headers.md) (`routing` headers, redirects, rewrites, fallbacks, or `alwaysUseHttps`) or a `_headers` or `_redirects` file in `public/`, a small Worker runs on every request to apply them.
+- **Hybrid:** if any pages are not prerenderable, such as dynamic pages without `getPrerenderPaths()` or pages with `export const prerender = false`, a Worker is deployed to handle those routes at runtime. With `--platform cloudflare`, prerendered pages without a `.server.ts` file are served as static files without running the Worker. API routes, pages with a `.server.ts` file, and dynamic pages run in the Worker. Every page runs through the Worker when the app uses middleware, auth, live updates, edge rules (including a `_headers` or `_redirects` file in `public/`), a custom Vite `base`, a `routing.notFound` setting other than `"none"`, or a dynamic page at the top level of `pages/`, such as `pages/[slug].vue`.
 
 ## Relationship to `inference.appType: "static"`
 
@@ -68,5 +68,5 @@ The `inference.appType` field describes app type (SPA, static, void), while `out
 |              | `inference.appType: "static"`                   | `output: "static"`                            |
 | ------------ | ----------------------------------------------- | --------------------------------------------- |
 | **What**     | Deploy a pre-built static site (no Void plugin) | Prerender a Void app at build time            |
-| **Worker**   | None (static assets only)                       | Only if some pages can't be prerendered       |
+| **Worker**   | None (static assets only)                       | Only for server code and edge rules           |
 | **Use case** | VitePress, plain HTML, external SSG tools       | Void apps with mostly or fully static content |

package/docs/guide/type-safety.md

@@ -65,7 +65,7 @@ export const loader = defineHandler(async (c) => {
 <!-- pages/users/index.vue -->
 <script setup lang="ts">
 import type { Props } from './index.server';
-defineProps<Props>(); // ← { users: { id: number; name: string; ... }[] }
+const { users } = defineProps<Props>(); // ← users: { id: number; name: string; ... }[]
 </script>
 ```
 
@@ -141,6 +141,46 @@ routeUrl('/files/:path{.+}', { params: { path: 'docs/get started' } });
 // /files/docs/get%20started
 ```
 
+### Checked URL strings
+
+[`routing.typedRoutes`](../reference/config.md#routing-typedroutes) checks plain URL strings in `Link`'s `href`, `router.visit()`, `router.prefetch()`, `router.flush()`, and `c.rewrite()`. Apps created with `void init` have it on. To turn it on in an existing app:
+
+```ts
+// void.config.ts
+import { defineConfig } from 'void/config';
+
+export default defineConfig({
+  routing: { typedRoutes: true },
+});
+```
+
+A string must then match one of your routes, optionally followed by a query string or hash:
+
+```tsx
+<Link href="/about">About</Link>
+<Link href={`/users/${user.id}?tab=activity`}>Profile</Link>
+<Link href={routeUrl('/users/:id', { params: { id } })}>Profile</Link>
+<Link href="/abuot">About</Link> // Type error: no route matches
+```
+
+Links can also point to the current page (`?page=2`, `#comments`) and to `http://`, `https://`, `mailto:`, and `tel:` URLs. Relative paths such as `../settings` are rejected; use the absolute path. A fixed part with spaces or non-ASCII characters can be written as is (`/café menu`) or percent-encoded in uppercase, as `routeUrl()` returns it (`/caf%C3%A9%20menu`). A dynamic segment matches any text, including none, so `/users/:id` also accepts `/users/` and `/users/42/edit`. With a root dynamic page such as `pages/[slug].tsx`, a protocol-relative URL like `//example.com` passes too.
+
+`void/routes` exports two types for these strings:
+
+- `RouteUrl`: the URL of one of your routes. `routeUrl()` returns it, and `c.rewrite()` accepts it.
+- `Href`: anything a link can point to: a `RouteUrl`, a same-page query or hash, or an external URL.
+
+Cast a string that TypeScript can't check, such as a path from your CMS or a file in `public/`:
+
+```tsx
+import type { Href, RouteUrl } from 'void/routes';
+
+<Link href={post.path as RouteUrl}>{post.title}</Link>
+<Link href={user.website as Href}>Website</Link>
+```
+
+Restart the dev server or run `void prepare` after changing `routing.typedRoutes`.
+
 Route types update with the dev server. For CI or standalone typechecking, run `void prepare` and follow [Setup](#setup). The [API reference](../reference/api/types.md#void-routes) lists the URL helper and route types.
 
 ## What Gets Checked
@@ -151,6 +191,7 @@ Route types update with the dev server. For CI or standalone typechecking, run `
 | Handlers     | `c.env` bindings, validator input, return type                                                                        |
 | Fetch client | Route paths, HTTP methods, `body`/`query`/`params`, response type                                                     |
 | Navigation   | Route patterns and required parameter names and values in `routeUrl()` and destination objects                        |
+| Links        | With `routing.typedRoutes`, URL strings in `Link`, router methods, and `c.rewrite()`                                  |
 | `useForm`    | Action URLs, `data` fields, `errors` keys, `reset()` args (including `{ initial: true }`), `params`, `resetOnSuccess` |
 | `action()`   | Action URLs, `data` payload, `params`                                                                                 |
 

package/docs/integrations/frameworks/astro.md

@@ -6,9 +6,9 @@ outline: deep
 
 Use Void with [Astro](https://astro.build/) for resource detection, typed database queries, and migrations. Astro keeps its own build and Cloudflare integration; Void plugs into its Vite configuration.
 
-::: warning Astro 6 required
+::: warning Astro 7 required
 
-- [Astro 6+](https://astro.build/blog/astro-6/) is required to use `import { x } from "void/x"` helpers in Astro apps.
+- [Astro 7+](https://astro.build/blog/astro-7/) is required because Void needs Vite 8.
 - You also need to enable `"nodejs_als"` under `compatibility_flags` in your Cloudflare config.
 :::
 
@@ -67,16 +67,15 @@ void deploy
 
 ## Using Void Features
 
-Most [Void platform features](../../guide/app-types.md#void-apps) work with Astro in both local dev and production when using Astro 6+ with `nodejs_als`.
+Most [Void platform features](../../guide/app-types.md#void-apps) work with Astro in both local dev and production when using Astro 7+ with `nodejs_als`.
 
 Void-managed auth is not supported in framework mode yet. Use Better Auth's official Astro integration directly for now.
 
-Pages that access runtime bindings must opt out of prerendering:
+Pages and API routes that access runtime bindings must opt out of prerendering:
 
 ```astro
 ---
 export const prerender = false;
-// now Astro.locals.runtime is available
 ---
 ```
 
@@ -89,6 +88,8 @@ import { users } from '@schema';
 import type { APIRoute } from 'astro';
 import { db } from 'void/db';
 
+export const prerender = false;
+
 export const GET: APIRoute = async () => {
   const rows = await db.select().from(users);
   return Response.json(rows);
@@ -105,18 +106,20 @@ Declare variables in `env.ts` and read them with `import { env } from "void/env"
 
 Void always uses `VITE_*` for client-exposed schema keys, including in Astro projects. Astro's separate `PUBLIC_*` convention still applies to direct `import.meta.env` access, but it does not change the `void/env` server/client boundary.
 
-`void/env` replaces [`astro:env`](https://docs.astro.build/en/guides/environment-variables/) and `Astro.locals.runtime.env` for env-var access. Keep `Astro.locals.runtime.env` around when you need raw binding access (D1, KV, R2, etc.).
+`void/env` replaces [`astro:env`](https://docs.astro.build/en/guides/environment-variables/) for env-var access. Use `env` from `cloudflare:workers` when you need raw binding access (D1, KV, R2, etc.).
 
 ## Accessing Bindings Directly
 
-Access bindings via `Astro.locals.runtime.env` (works in both dev and production):
+Access bindings with `env` from `cloudflare:workers` (works in both dev and production):
 
 ```ts
 import type { APIRoute } from 'astro';
+import { env } from 'cloudflare:workers';
+
+export const prerender = false;
 
-export const GET: APIRoute = async ({ locals }) => {
-  const { DB } = locals.runtime.env;
-  const { results } = await DB.prepare('SELECT * FROM users').all();
+export const GET: APIRoute = async () => {
+  const { results } = await env.DB.prepare('SELECT * FROM users').all();
   return Response.json(results);
 };
 ```
@@ -125,8 +128,10 @@ In `.astro` pages (remember to set `prerender = false`):
 
 ```astro
 ---
+import { env } from 'cloudflare:workers';
+
 export const prerender = false;
-const { DB } = Astro.locals.runtime.env;
-const { results } = await DB.prepare("SELECT * FROM users").all();
+
+const { results } = await env.DB.prepare("SELECT * FROM users").all();
 ---
 ```

package/docs/integrations/frameworks/overview.md

@@ -21,7 +21,7 @@ TanStack Start and React Router use the Cloudflare Vite plugin provided by Void.
 | [SvelteKit](./sveltekit.md)           | `@sveltejs/kit`         | Vite-based, uses its own Cloudflare adapter                                  |
 | [Nuxt](./nuxt.md)                     | `nuxt`                  | Own CLI and build toolchain                                                  |
 | [Analog](./analog.md)                 | `@analogjs/platform`    | Vite-based, uses Nitro with Cloudflare preset                                |
-| [Astro **v6+**](./astro.md)           | `astro`                 | Own CLI and Cloudflare adapter (v6 required)                                 |
+| [Astro **v7+**](./astro.md)           | `astro`                 | Own CLI and Cloudflare adapter (v7 required)                                 |
 
 Detection is automatic. The CLI reads your `package.json` dependencies.
 
@@ -40,7 +40,7 @@ With `voidPlugin()` added to the framework's Vite config, frameworks get most of
 
 For framework apps, Void revalidation caches public HTML document responses with both `void deploy` and `void deploy --platform cloudflare`. Client data requests continue to use the framework's own behavior. A response with `Set-Cookie` or `Cache-Control: private`, `no-store`, or `no-cache` is never shared.
 
-Frameworks can also access bindings directly via the framework's own mechanisms (e.g. `env` from `cloudflare:workers` in SvelteKit 3 and Analog, `platform.env` in SvelteKit 2, `event.context.cloudflare.env` in Nuxt, `Astro.locals.runtime.env` in Astro).
+Frameworks can also access bindings directly via the framework's own mechanisms (e.g. `env` from `cloudflare:workers` in SvelteKit 3, Analog, and Astro, `platform.env` in SvelteKit 2, `event.context.cloudflare.env` in Nuxt).
 
 ## Configuration