← Docs

Deploy a Node or Next.js app

Getting a Node.js or Next.js app live — and shipping every change after that with a safety net. The short version: connect a repository, push, and we build in isolation, run your release step, and only swap the new release in once it passes a health check. A bad deploy rolls itself back.

Every deploy runs the same pipeline: build → release → start. The build happens in a throwaway, network-isolated container and produces an immutable release image. Your release command (a database migration, for example) runs next — and if the app has databases attached, we snapshot them first. Then the new release has to pass a health check on your health path before it takes any traffic; if it fails, the previous image, env, and that database snapshot are restored automatically.

The static preset skips the runtime entirely. A build step is optional: we run one when you've set a build command or your package.json has a `build` script, and otherwise we publish the repository exactly as it is — a repo of plain HTML and assets needs no build and no package.json at all. Env vars are injected at build time, which is where NEXT_PUBLIC_-style values bind. The output is published as plain files served straight from the edge, releases swap atomically, and a bad build can never replace the one currently being served — rollback is an instant symlink flip. A static app is always the Front tier.

1. 1
   Connect a repository

   Point us at a GitHub, GitLab, Bitbucket, or Codeberg repo — connect the GitHub app for push-to-deploy, or use a read-only deploy key. Pick a preset — Next.js, a custom service, or a static site — and a branch. For a repo the connected GitHub app can see, the branch field is a dropdown of that repo's real branches; otherwise you type the branch name.
2. 2
   Set your commands

   The Deploy configuration card on the app's Overview shows the build, release, and start commands — view and edit them anytime; changes apply on the next deploy. On the Next.js preset the start command is managed for you.
3. 3
   Push — or click Deploy

   Every push to your branch ships automatically, and a manual Deploy button is always there. To read what a build actually did, open the Deploys tab and click a release — the row expands to show that build's output. If a deploy fails you also get an email with the reason and a link straight to those logs.
4. 4
   Roll back in one click

   The newest three releases stay on the node — roll back to any of them instantly. For container apps the same health gate and auto-restore protect the rollback; for a static site it's an atomic symlink flip back to the previous release.

← All guides