Deploying on Muerte Cloud

Muerte Cloud can deploy your service automatically on every commit, or on demand from the dashboard. Web services, private services, background workers and cron jobs all redeploy with zero downtime, unless the service has a persistent disk attached.

Every deploy is visible in real time on the service's Deploys tab: build logs, runtime logs, commit SHA, duration and status all in one place.

Automatic deploys#

When you create a service you link it to a branch of a GitHub, GitLab or Bitbucket repository. By default, every push or merge to that branch rebuilds and redeploys the service.

Auto-deploys require a connected Git provider. Services that pull a prebuilt Docker image or a public Git URL are deployed manually.

Configuring auto-deploys

Change auto-deploy behaviour from the service's Settings tab:

Skipping a commit

Some commits — README edits, comment tweaks — don't need to ship. Add a skip phrase anywhere in the commit message and Muerte Cloud will record the event without triggering a build:

git commit -m "[skip deploy] tighten copy in README"

Accepted phrases: [skip deploy], [deploy skip], [skip ci].

Manual deploys#

You can also trigger a release outside the git-push flow from the Deploys tab: pick the latest commit, a specific SHA, or clear the build cache first.

Deploy steps#

Every deploy runs the same two-stage pipeline:

1. 1
   Build command

   Installs dependencies and produces build artifacts. Runs on separate build compute — anything it writes to the filesystem is only carried forward through the resulting image.
2. 2
   Start command

   Boots your process on a fresh instance. Once it becomes healthy, traffic swings over from the previous instance.

Example build commands

Example start commands

Managing deploys#

Overlapping deploys

Only one deploy runs at a time per service. When a new deploy is triggered while one is already in flight, Muerte Cloud can either wait (finish the current deploy, then jump straight to the newest triggered one, skipping any intermediate ones) or override (cancel the running deploy and start the new one immediately). The default is wait; change it in workspace settings.

Cancelling a deploy

Click Cancel deploy on the Deploys tab to abort an in-flight build. If another deploy is queued behind it, that one starts immediately.

Restarting a service

A restart is a special manual deploy: same commit, same env vars, new instance. Because a fresh instance is spun up and swapped in, restarts are zero-downtime just like a normal deploy. Note that a restart does not pick up recent env-var edits — trigger a fresh deploy for those to take effect.

Rolling back

Every successful build is stored as a rollback point, so you can return a service to a previous version from the Deploys tab without rebuilding. See Rollbacks for the full flow.

Deployment concepts#

Ephemeral filesystem

By default a service's filesystem is ephemeral: any writes at runtime are discarded on the next deploy or restart. To keep data across releases, use a managed Postgres or Key-Value store, or attach a persistent disk under a specific mount path.

Zero-downtime deploys

When a new version builds successfully, Muerte Cloud starts a fresh instance alongside the current one. The old instance keeps serving every request until the new instance passes its health check, then the edge swings traffic across in a single step.

1. Build the new version. If the build fails, the deploy is cancelled and the current instance keeps serving.
2. Boot a new instance next to the current one.
3. Wait for the new instance to pass its health check.
4. Swing traffic to the new instance; drain in-flight requests on the old one.
5. After a 60-second grace period, send SIGTERM to the old instance.
6. If it doesn't exit within the shutdown delay, send SIGKILL.

Services scaled to multiple instances repeat steps 2–6 one instance at a time. If any new instance fails to become healthy, the whole deploy is cancelled and every replica is reverted to the previous version. Persistent disks disable zero-downtime deploys because only one instance can safely hold the volume open at once.

Graceful shutdown

Your process receives SIGTERM when it's time to stop. Handle it: drain in-flight HTTP requests, finish or requeue worker tasks, close outbound connections, and exit with a zero status. The default shutdown budget is 30 seconds and can be extended up to 300 seconds per service.

const server = app.listen(port, "0.0.0.0");

process.on("SIGTERM", () => {
  console.log("received SIGTERM, draining connections");
  server.close(() => process.exit(0));
});