Skip to content

Addis Ababa, Ethiopia. Support on 6993.MCP ready. Attach your agents 100% self-service. Sign up using google or phone number. No sales call to get started

System status
AletCloud

Deploying apps

How deploys work

What happens between a push and an app serving traffic, and the one rule that decides whether it comes up.

On this page

The four stages

Reading this page saves the most common hour of debugging on any container platform. A deploy runs in four stages.

  1. 01Detect. The repository is read to work out the stack, the build command and the port the app listens on.
  2. 02Build. A container image is built from the code. Build logs stream live, so the failing step is visible as it happens.
  3. 03Health check. The new container starts and is checked for a TCP connection on its port.
  4. 04Cut over. Once the new version is healthy, traffic moves to it and the old one is retired.

Because the cut over only happens after the health check passes, a broken release cannot take a site down. The previous version keeps serving until the new one proves it can accept connections.

The port contract

This is the rule. An app must listen on the port it is given, on all network interfaces.

  • A PORT environment variable is set in the container. Read it rather than hardcoding a number.
  • Bind 0.0.0.0, not localhost or 127.0.0.1. A process bound to localhost is reachable only from inside its own container, so neither the health check nor a visitor can see it.
  • The port is detected from the source where possible. If detection gets it wrong, set the port explicitly in the app’s settings.

Binding localhost instead of 0.0.0.0 is the single most common cause of a build that succeeds and an app that never comes up. If an app works locally but not here, check this first.

javascript
// Node, correct​const port = process.env.PORT || 3000;​app.listen(port, '0.0.0.0');​​// Node, will fail its health check​app.listen(3000, 'localhost');​

How long an app has to start

These are the timings actually applied, so a slow boot can be told apart from a broken one.

ReadinessStarts five seconds after the container does, runs every five seconds, and allows six consecutive failures. In practice an app has roughly thirty-five seconds to open its port.
LivenessStarts after sixty seconds and runs every fifteen, allowing six failures. It only restarts a container that has stopped responding entirely, and it is lenient on purpose so a slow-booting Spring Boot or Next.js app is never killed for being slow.
BothPlain TCP connections to the port. No /health endpoint and no particular path is required.

An app that needs longer than about thirty-five seconds should open its port early in startup and finish initialising behind it, rather than doing all the work before it listens.

What triggers a deploy

  • A push to the branch the app is connected to.
  • Pressing Redeploy in the console.
  • An environment variable change, applied on the next deploy or restart.
  • An AI agent acting on the account’s behalf over MCP.

Where a worker differs

A worker skips stages three and four as described above. With no port to check, it counts as healthy once its process stays running, and the previous instance is stopped before the new one starts.

Support is free, and a person answers.

Call 6993System statusContact