Frameworks on Edge Scripting

Run a web framework on Bunny Edge Scripting. Render pages per request at the edge, serve the build from Bunny Storage, and deploy it all with one command.

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

browser ──▶ pull zone ──▶ Edge Script (the framework's server)
                │              │
                │              └─ route the framework owns ── render it now
                │
                └─ asset or prerendered page ─▶ Bunny Storage

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

bunny lab deploy astro       # build and publish
bunny lab undeploy astro     # delete the app and everything it runs on

The CLI puts the adapter in, builds the site, and creates what it needs: a storage zone for the files, an Edge Script for the server, and the pull zone the script is the origin of. Later deploys are the same command. See bunny lab for the reference.

lab says the interface is still being shaped, so a workflow built on either command should expect to be updated.

Each deploy’s client files go into their own folder in the storage zone, and the published script carries that folder’s name. So a release can only read the files it was built against. There is no rollback: one Edge Script publishes one version at a time, so going back means deploying the commit you want.

A build that prerenders every page needs no server, and bunny sites deploy deploys it as a directory of files.

An adapter tells the CLI what it built, in a small manifest the build writes. The CLI reads the manifest, so it deploys an adapter without knowing anything about the framework, 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 lab deploy astro publishes. It needs Astro 7. 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.