Add a Frameworks section to Edge Scripting, and the bunny sites reference - #429
Draft
bogdan-at-bunny wants to merge 15 commits into
Draft
Add a Frameworks section to Edge Scripting, and the bunny sites reference#429bogdan-at-bunny wants to merge 15 commits into
bogdan-at-bunny wants to merge 15 commits into
Conversation
Add a new "Frameworks" group under Edge Scripting. It shows how to run a web framework on a standalone script: keep the build in Bunny Storage, and let the script serve the files and the dynamic routes. - Add an overview page that explains the pattern and its constraints. - Add a guide that deploys an Astro site end to end. - Link the new section from the Edge Scripting index. - Point readers of the frontend deployment guides here when they need dynamic routes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Et5xuUCDVjxBHpCGtZcECv
Contributor
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
bogdan-at-bunny
marked this pull request as draft
August 19, 2026 07:55
Testing showed that Astro's server runs inside an Edge Script. An SSR build is a (Request) => Response handler, which is the shape a standalone script needs. A minimal site bundles to about 600 KB, well inside the 10 MB limit. The first draft claimed Edge Scripting cannot run a framework server. That was wrong, so the guide now leads with SSR. - Add a complete Astro adapter for Edge Scripting, in two short files. - Show the Edge Script entry that renders SSR routes and reads assets and prerendered pages from Bunny Storage. - Keep the static build as a smaller alternative, and say what it gives up. - Add troubleshooting for the sharp image service, the origin check on POST, and prerendered routes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Et5xuUCDVjxBHpCGtZcECv
Building a fuller demo of the guide found three problems in the adapter it publishes. - Astro.cookies.set() did nothing. The adapter now passes addCookieHeader to app.render(), so Astro writes the Set-Cookie header itself. - The build warned that entrypointResolution "explicit" is deprecated. The adapter now uses "auto" with a project-relative entrypoint, which also drops the fileURLToPath import. - A script's pull zone strips Set-Cookie by default, so cookies still failed after the code was correct. Troubleshooting now covers the Disable cookies setting. Also adds troubleshooting for two traps found while testing: a hashed CSS name changes on every style edit, so the client upload must run with every deploy; and middleware runs during prerendering, where there is no request to read. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Et5xuUCDVjxBHpCGtZcECv
@bunny.net/astro-adapter now holds the code this guide used to ask readers to write. The setup is a config change instead of an adapter, a request handler, and a bundler. - Replace roughly 200 lines of copied code with `adapter: bunny()`. - Use `bunny-astro upload` for the client build, which removes the step people forget and which silently drops the site's styles. - Rename the runtime variables to BUNNY_STORAGE_ZONE, BUNNY_STORAGE_HOST, and BUNNY_STORAGE_KEY, matching the package. - Keep the troubleshooting entries, since the traps are unchanged. The guide is now 262 lines instead of 425, and none of it is glue. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Et5xuUCDVjxBHpCGtZcECv
The adapter moved to BunnyWay/bunny-adapters, and it gained the platform features Astro has hooks for. The guide now covers them: - `bunny-astro deploy`, one command for the upload and the deploy. - Bunny Optimizer as the image service. - Sessions, in a second storage zone the script may write to. - `routeRules`, `CDN-Tag`, and purging. - `Astro.locals.runtime` and `astro preview`. - A link to the live demo, which is also the adapter's test fixture. Two warnings are new, and they belong together. Smart Cache does not cache HTML, so a `routeRules` entry does nothing until it is switched off. A pull zone then applies its own thirty day expiration to any response with no `Cache-Control`, which would cache a page rendered for one visitor, so the adapter marks those `private, no-store`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Et5xuUCDVjxBHpCGtZcECv
The guide implied `fs` was unavailable. Edge Scripting provides most `node:` built-ins, including `node:fs` over a virtual file system, and the adapter rewrites a bare `fs` to the prefixed name so a dependency resolves. Only a package with a native binary is a real problem. The new section also says what that file system is not. It starts empty on every cold start, one isolate cannot see what another wrote, and it lives in the script's memory. So it is a scratch pad for one request, and anything that has to last belongs in Bunny Storage. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Et5xuUCDVjxBHpCGtZcECv
It is the obvious thing to write in a dynamic route, and it throws a 500: a prerendered route has no server component to rewrite to. Return a bodyless 404 instead, and the adapter serves the prerendered page out of Bunny Storage. An endpoint keeps its own 404, so a JSON client is never handed a web page. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Et5xuUCDVjxBHpCGtZcECv
With Optimizer on for the pull zone, every image request that misses the CDN cache answers 523 Origin Connection Failed. Optimizer fetches the original from the origin, and a script is not an origin it can read. Measured on two script-backed pull zones. The support table also gains the rows the adapter's new tests cover: a base path, redirects with their real status, locale routing, content collections, islands, actions, and static page headers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014WoKonkC5YqNMXi5CEYmL9
The adapter answers a range request on a stored object, and says Accept-Ranges on everything it serves. A pull zone will not answer a range from its cache unless the origin says that, so the header is the part that matters. Optimize for large object delivery covers a file nobody has requested yet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014WoKonkC5YqNMXi5CEYmL9
The guide asked for 5 steps before a site was up. It asked for a storage
zone, two passwords, three environment variables, and two raw API calls.
Each step is a place to make a mistake, and each mistake looks like a
broken site.
This rewrites the guide against one command:
bunny deploy
The CLI detects Astro, offers the adapter, builds, provisions the site,
uploads the build, and publishes the script. It sets each credential
itself, so no password moves through the terminal.
The guide now also covers the parts a deploy tool owes a developer:
previews, rollback, environment variables, and continuous integration.
Manual pull zone settings are gone, because the CLI applies what the
adapter asks for and reports the changes.
None of this is built yet. The plan is in BunnyWay/bunny-adapters, at
plans/one-command-deploys.md. Hold this branch until the CLI ships it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DNEZw6pebXfttb98s3ihG8
The previous commit described the deploy we wanted. `bunny deploy` is built now, so this corrects the guide to the tool: - Commands that exist: `bunny sites deployments list`, `bunny sites domains add`, `bunny scripts env set`. The short aliases and `bunny logs` are not built. - Every deploy publishes to production. Preview URLs per branch need a script per environment, which is designed and not built. - The script reads the build's files from Bunny Storage, so it is the script that answers a range request, not the pull zone. The earlier text described a pass-through the adapter does not do yet. - Each deploy keeps its client files and its server bundle in the zone, and the published bundle names its own folder. That is what makes a rollback restore a page with the assets it names. - A new section says plainly what the tooling does not do yet: branch previews, adopting a hand-built site, and logs from the terminal. The first-run transcript is now the CLI's real output, from a fresh `npm create astro` project deployed to a live account. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DNEZw6pebXfttb98s3ihG8
Three real Astro projects met `bunny deploy`, and what they taught goes in the guide. The command adds the adapter and nothing else: Astro's own default prerenders pages, and a page asks for the edge itself. Setting `output: "server"` over that took astro.build's script from 7.83 MB to 22.30 MB. The guide now says what the build decides and why, what a project moving from another host sees, how a monorepo behaves, and what the 10 MB limit looks like when a build hits it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DNEZw6pebXfttb98s3ihG8
A script has 500ms to start, and every byte of it is parsed and evaluated first. So a bundled framework server well under 10 MB can fail to start, and the edge then answers 400 with an empty body. Measured in August 2026: the same code served every request at 7.44 MB and none at 7.83 MB. The limits page now says the two limits work together, and the Astro guide has the 400 in its troubleshooting. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DNEZw6pebXfttb98s3ihG8
The 404 page, the redirects and the headers of a static site belong to the `bunny sites` router, not to a framework adapter. Four pages say so: - New `cli/commands/sites.mdx`: what a site is, immutable deploys and their preview URLs, and the three file names the router reads out of the deploy. It names the subset of `_redirects` and `_headers` that is supported, and the `Cache-Control` the router sets on every response. - New `cli/commands/deploy.mdx`: one command for a project that renders per request and one that ships as files, and what the deploy checks afterwards. - `cdn/custom-404-page.mdx` gains the measured facts. The folder is read at the zone root and a copy in a sub-folder is ignored, the status is 404, the page answers `no-cache`, and one page belongs to one zone. - `storage/static-site-hosting/index.mdx` points at the one command that does the whole page for you, and says what a storage zone cannot do alone. - The Astro guide no longer says a prerendered site needs a script for its 404 page. The router answers it, and the build writes `_redirects` and `_headers`.
`bunny deploy` is gone from the CLI, and `bunny sites deploy` deploys both shapes of site: a directory of files, and a build that renders each page per request. So `cli/commands/deploy.mdx` goes, and `cli/commands/sites.mdx` covers both. No redirect is needed, because neither page has shipped. The Astro guide and the frameworks index name the new command. `bunny rollback` becomes `bunny sites deployments publish --previous`, and `--open` becomes `bunny sites open`, because neither flag exists any more. Two things the guide said were wrong before this change, and are now right: - The example workflow ran `bunny sites deploy` with no build. A workflow has nobody to ask, so an unattended deploy never offers a build: it needs `--build`. - `--env` and `--env-file` apply to the build, so they need `--build` too. Without it the command reports the mistake. Both pages also say when the adapter offer appears, which is new: only a project that renders a page on demand is offered one. A project that prerenders every page deploys as files, and hears nothing about adapters. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NpdDkzyH7pPq5FZqPCRhzE
Contributor
Author
|
@mintlify deploy to staging |
Contributor
|
AI credits exhausted for this billing cycle. Upgrade your plan or wait for your credits to renew. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
scripting/frameworks/index.mdx, which explains how a framework server runs at the edge and what constrains it.scripting/frameworks/astro.mdx, a guide that renders Astro per request on Edge Scripting with the bunny.net adapter.cli/commands/sites.mdx, the reference forbunny sites. It covers both shapes of site: a directory of files, and a build that renders per request.cdn/custom-404-page.mdxandstorage/static-site-hosting/index.mdx: a deploy's own404.html,_redirects, and_headers.Why
A reader who wants a framework on Edge Scripting had no page to start from. The Storage guides cover fully static sites, and stop where the dynamic part begins.
Astro is a server-first framework, so a guide that only prerenders it misses the point. An Astro build that renders per request is a
(Request) => Responsehandler, which is the shape a script already needs.One deploy command
An earlier revision of this branch documented a
bunny deploycommand besidebunny sites deploy. There is only one command now,bunny sites deploy, and it reads the build to decide what to send. Socli/commands/deploy.mdxis gone andcli/commands/sites.mdxcovers both shapes. Neither page has shipped, so no redirect is needed.Both pages also say when the adapter offer appears, which readers could not tell before: only a project that renders a page on demand is offered an adapter. A project that prerenders every page deploys as files and hears nothing about adapters.
Two things the guide got wrong
Found by running the commands again for this revision:
--build.--envand--env-filewere shown without--build. They apply to the build, and the command reports the mistake rather than ignoring them.Depends on the adapter package
This guide uses
@bunny.net/astro-adapter. The package has to be published to npm before this merges. Until then the install command in the guide does not resolve.The adapter is what keeps the guide short. It adds itself to the config, and it does not set
output:Verified
Every command in the guide was run against a real account, with the adapter installed the way a reader would install it.
src/pages/api/, dynamic routes, prerendered pages from Storage, hashed assets, and the build's own 404 page all answered as the guide says.mint broken-linksreports no new broken links.One table on the
bunny sitespage waits on a CLI fix. It says a page may be cached for 60 seconds, which is what the router asks for. In the live run a page reached the browser with a far longer lifetime, because the router only setsCache-Controlon a response that carries none, and Bunny Storage sends one. The table describes the behaviour this documents, and the CLI change is tracked in BunnyWay/cli#172. Neither branch has shipped, so the fix can land before either merges.🤖 Generated with Claude Code
https://claude.ai/code/session_01NpdDkzyH7pPq5FZqPCRhzE