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.
- Runtime
- Node 24
- Releases
- Zero-downtime symlink flip
- Rollback
- One click; rebuild depends on runtime and retained releases
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.
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.
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.
Astro questions
Static or server output — which should I pick? + −
What happens to the old site while a new build runs? + −
Can I rebuild when content changes rather than when code does? + −
Does this site run on Astro? + −
We run a Node build under PM2 today. What happens to that process? + −
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.