Deploy Astro to a server you own.

Astro builds either a folder of static files or a Node server, and the two want different things from a host. Depfloy handles both on the same machine — nginx serves a static build directly, and a server build runs as a supervised process behind it.

What runs on the server
Runtime
Node 24
Releases
Zero-downtime symlink flip
Rollback
One click; rebuild depends on runtime and retained releases
The deploy script Depfloy runs
npm ci
npm run build
A static build never touches Node in production

When the output is static, nginx serves the files directly. There is no application process to supervise, nothing to restart, and no runtime to keep patched — which is the whole appeal of building a site this way.

Server output runs as one real process

When the site renders on demand, the Node server is started with exec rather than through an npm script, so DPM — the process manager Depfloy installs — watches the app itself: the memory figure is the app's, and a stop signal reaches it rather than a shell. DPM is a systemd service enabled at boot, so a server build comes back after a reboot on its own.

The build runs on your machine

npm ci and npm run build happen on your own server as part of the release. Depfloy does not charge per build minute. Your provider charges for the server capacity and any metered resources used by those builds.

Astro is unusual in this list because the interesting question is not how it deploys but what it produces. A static build wants a web server and nothing else; a server build wants a process kept alive. Both are ordinary here, and switching between them is a rebuild rather than a migration.

FAQ

Astro questions

Static or server output — which should I pick? +
Static if the pages do not change per request; it is faster and there is no process to keep alive. Server output when you need per-request rendering. Depfloy deploys both the same way, so the decision stays a project decision.
What happens to the old site while a new build runs? +
It keeps serving. The release is built in its own directory and only goes live when the build succeeds, with an atomic symlink flip. A failed build is never linked.
Can I rebuild when content changes rather than when code does? +
Yes — trigger a deploy from the dashboard, the CLI or an agent over MCP. A push is one way to start a release, not the only one.
Does this site run on Astro? +
Yes. depfloy.com is an Astro build deployed to a Depfloy-managed server, which is a reasonable thing to check before trusting the claim.
We run a Node build under PM2 today. What happens to that process? +
Depfloy does not use PM2. Server builds run under DPM, and the DPM repository ships a migration script that reads the PM2 processes and Supervisor programs already on the server and moves them across, with a --dry-run flag to show the plan first. A static build has no process at all, so there is nothing to migrate.

9 other frameworks deploy the same way.

The release model is identical; only the build steps differ.

Deploy Astro to your own server.

7 days free, no credit card. Your servers keep running exactly as Depfloy configured them.