Astro

Astro adapter

Astro adapter is the package that turns Astro's server build into something a specific host can run. Without one, Astro can only produce static files.

How it is measured

Look at the adapter line in the config file and the folder the build writes. A static build writes HTML into dist/. An adapter build also writes a server entry, such as dist/server/entry.mjs, shaped for Node, a Worker, or a function host.

Test by requesting a route that is not prerendered. If it returns a page, the adapter and the host agree. If the deploy fails with "no adapter installed", a route asked for on-demand rendering and nothing could serve it.

Worked example

A ski-rental site has 40 static pages and one /availability route that reads a booking API per request. The team adds the Node adapter in standalone mode and sets that one route to render on demand. Build output goes from 40 HTML files to 40 files plus a 2-file server bundle.

The same repo later tries to deploy to a static bucket. The bucket serves the 40 pages and returns 404 for /availability, because a bucket cannot run the server entry.

How it differs

An Astro adapter is the host-agnostic category. The Cloudflare adapter is one concrete choice that emits a Worker. The category says "this build has a server"; the Cloudflare package says "and it runs on Workers with their limits".

Common errors

Installing an adapter and leaving every route static, then paying for a server that never answers a request. Choosing an adapter after the host is already picked and fighting its runtime. Using Node-only modules under an edge adapter. Forgetting to set the site URL so redirects and sitemaps point at localhost.

In practice

Decide the host first, then install its adapter with astro add. Mark each route static or on-demand on purpose. After deploying, hit one prerendered route and one on-demand route and compare the response times.

See also

Cloudflare adapter, Node adapter

Sources

Count this on a real site.

Watch my website