Skip to main content
A framework build has two halves: files that are the same for every visitor, and code that must run per request. Edge Scripting covers both when you pair it with Bunny Storage. A standalone script is the origin of its own pull zone, so it sees every request the cache does not answer. Keep the build assets in a storage zone, and let the script decide what each path needs.

​
Two patterns

Server-side rendering

The framework’s own server runs inside the script. It renders pages and runs API routes per request, exactly as it does on a Node host.

Static plus a small script

The framework prerenders everything. The script serves those files and adds a little dynamic behaviour of its own.
Pick SSR when you want the framework’s server features: per-request rendering, API routes, middleware, and cookies. Pick the static pattern when the site is nearly all static and you only need a small dynamic edge.
If the site has no dynamic part at all, you do not need a script. Point a pull zone straight at the storage zone. See the frontend deployment guides.

​
How SSR works here

A framework’s SSR build produces a request handler with the shape (Request) => Response. That is the same shape a script needs, so the script calls the handler directly. The build’s client files have no filesystem at the edge. They go to a storage zone, which the site’s pull zone serves. So the script renders, and the CDN delivers everything the build produced.

​
Deploying

The CLI recognises the framework, offers the adapter when the project renders on demand and has none, builds the site, and creates what it needs: a storage zone for the files, a pull zone for the URL, and an Edge Script for the server. Later deploys are the same command. It is the same command that deploys a directory of files, and the build decides which one this is. Each deploy is immutable: its client files and its server bundle both stay in the storage zone, and the published script carries the name of its own files. So a rollback restores a page and its assets together, in one step:
An adapter tells the CLI what it built, in a small manifest the build writes. The CLI reads the manifest, so every adapter deploys with the same commands, and a new adapter needs no new CLI. Writing an adapter has the contract.

​
What to know first

One file. A deployment is a single JavaScript file, so the framework’s server output has to be bundled. An adapter does that for you. A small Astro SSR build lands near 660 kB, well inside the 10 MB script size limit. Astro has an adapter. Other frameworks do not, yet. Install @bunny.net/astro-adapter, and Astro builds straight to a deployable script that bunny sites deploy publishes. For any other framework you write the handler yourself, and deploy it with bunny scripts deploy. That is workable, because all an adapter really does is hand you the app object. The adapters live in one repository, BunnyWay/bunny-adapters. Ask there for the framework you need. Node-only dependencies do not travel. Anything that needs native binaries or the filesystem must go. Image services that use sharp are the usual example. Swap them for a no-op or an edge-friendly service. Cache misses only. By default a script runs when the cache misses. Turn on before cache execution if every request must reach the framework.

​
Guides

Astro

Render Astro per request at the edge with the official adapter.
Last modified on August 21, 2026