feat(sites): one command deploys a framework project or a directory

[bogdan-at-bunny]

What

bunny sites deploy deploys this project, whichever shape it is: a build that
renders each page per request on Edge Scripting, or a directory of static files.
The build decides which, and the command is the one that has always deployed a
directory.

bunny sites deploy                           # build if needed, then deploy
bunny sites deploy --build                   # run the project's own build first
bunny sites deploy ./dist --production       # a directory, published live
bunny sites deployments publish --previous   # back to the deploy that was live before

Putting an Astro site on Edge Scripting took five steps, two passwords, three
environment variables, and two raw bunny api POST calls. It now takes the first
line above.

An earlier revision of this branch added a top-level bunny deploy and
bunny rollback beside bunny sites deploy. Neither has shipped, and both are
gone: the project already says which shape it is, so choosing a command was never
the developer's job.

How

The CLI learns nothing about Astro. It reads .bunny/build.json, the build
manifest a framework adapter writes (the contract), and that file says
what to deploy: the one script file, the folder of client files, and the pull zone
settings and variables the site needs. The schema is BuildManifestSchema in
@bunny.net/config, beside bunny.jsonc, because two repositories share it. A
new adapter therefore needs no CLI release.

A framework site is a sites site whose script comes from the build. So it
re-uses almost all of sites: the storage zone, the deploys/{id}/ layout, the
state file, promote and rollback, domains, ssl, delete. state.kind
(static | framework) tells them apart. The router commands refuse a framework
site, and sites deployments publish delegates to the framework path.

Two things a framework site needs that a static one does not:

• The server bundle is kept in storage, at _bunny/deploys/{id}/server.js, so
  a promote or rollback restores the code and the files it names together. An
  Astro server bundle contains the hashed asset names it renders, so old files
  with a new renderer is a broken page.
• The deploy's folder is written into the bundle at publish time
  (globalThis.__BUNNY_DEPLOY__). A published release carries the name of its own
  asset folder, and cannot read another deploy's files.

Only a project that asks for a server is offered an adapter. This is the part
worth reviewing. An Astro project that prerenders every page is a directory of
files, and bunny sites deploy has always deployed one, so it must not be pushed
towards a server it does not want. sites/framework/detect.ts names four signals,
any one of which means the developer already asked:

The signal	What it means
A route under src/pages/ sets prerender = false	That route renders per request
The config sets output: "server"	Every page renders per request
The config names another vendor's adapter	The project renders on demand elsewhere today
@bunny.net/astro-adapter is a dependency	Somebody installed it and stopped

The first matters most: since Astro 5 a project prerenders every page unless a
page opts out, and astro build stops with its own error when a page opts out and
no adapter is installed. Reading the routes puts the offer before that failure.
The scan reads src/pages/ only, because that is where prerender applies, and
it stops at the first match. patchAstroConfig refuses any config it cannot edit
safely, and prints the lines to paste.

A build and a site must be the same kind. A script's type is fixed when the
API creates it, so a static site cannot run a build's server and a framework site
cannot serve a directory. The deploy names the mismatch before it uploads
anything.

The build now runs before the site is resolved. Only the framework path did
that. So a failing build can no longer leave an empty site behind, and neither can
a script the platform refuses: the 10 MB check reads the bundle first, in
readServerBundle.

Layout

commands/deploy/ moves into commands/sites/. build-manifest.ts and
health.ts sit directly under sites/, because both deploy paths read them;
everything a framework site alone needs is under sites/framework/.

Verified against a real account

The showcase from BunnyWay/bunny-adapters (a server build) and its
static-output fixture (every route prerendered), deployed with this branch's
compiled binary on 2026-08-21:

Check	Result
Server build, site created from nothing	storage zone, script, pull zone, .bunny/site.json
Page that renders per request	200, private, no-store, a live request id and client IP
Prerendered page, assets	200 from Storage, max-age=60 / immutable
Endpoint in src/pages/api/	200, JSON, per-request values
A path the deploy does not hold	404, with the deploy's own page
Unchanged redeploy	"No changes", nothing uploaded
Rollback of a changed pair	code and asset both came back
Static build, its own site	200, its own preview URL, its own 404 page
A static build against a framework site	refused, before anything uploaded
A server build against a static site	refused, before anything uploaded
Both sites deleted	every zone and script gone

Two earlier findings, both fixed here:

• A script-backed pull zone reports StorageZoneId: -1, not null, so site
  discovery has to treat anything below 1 as absent. Without it,
  bunny sites list never finds a framework site.
• A publish is not instant. The CLI waits for the release to reach the nodes and
  purges again; a probe cannot tell the outgoing release from the incoming one,
  since both answer 200 with a page.

One defect this does not fix

A static site's HTML answers with cache-control: max-age=25600000, about 296
days in a visitor's browser. Router v4 sets Cache-Control only on a response
that carries none, and Bunny Storage sends one after all: it arrives with
cdn-requestpullcode: 206 from the file server, on a hit and on a miss. So the
static layer's 60 second page lifetime never reaches a page, and turning the
zone's CacheControlMaxAgeOverride off did not achieve what it was meant to.

That is the static layer's own ground, and the fix changes caching for every
static site, so it needs its own change and its own measurement.

Not in this change

There is no --preview for a build that renders per request, and the command
says so rather than publishing production in silence. Such a preview cannot be a
per-deploy snapshot: one script publishes one release at a time, and the page and
its assets are one unit. The design (an environment per preview, sharing the
storage zone) is in bunny-adapters, plans/one-command-deploys.md, with
bunny sites ci init for framework sites and a top-level bunny env.

Tests

bun test 962 pass, bun run typecheck clean, bun run lint clean, and the
compiled binary ran every live check above. New unit tests cover the four
detection signals and the project that shows none of them, the manifest reader
(bad JSON, unknown version, version floor, missing build), the Astro config
patch, the pull-zone settings diff, the env writer (a secret is written once, so
a rotated password survives a deploy), framework-site discovery, and deleting a
deploy's server bundle with its files.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NpdDkzyH7pPq5FZqPCRhzE

[bunnynet-devops]

@codex review

[changeset-bot]

🦋 Changeset detected

Latest commit: 0c6a1a9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages

Name	Type
@bunny.net/cli	Minor
@bunny.net/config	Minor
@bunny.net/cli-linux-x64	Minor
@bunny.net/cli-linux-arm64	Minor
@bunny.net/cli-darwin-x64	Minor
@bunny.net/cli-darwin-arm64	Minor
@bunny.net/cli-windows-x64	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.