Skip to main content

What happens when you deploy

You click Deploy (or push, with auto-deploy on) and a few minutes later your app is live. This page walks through what happens in between, what you see at each step, and, just as important, what happens when a step goes wrong.

The steps​

1. Your manifest is read and validated​

AppHaven reads apphaven.yaml at the branch's latest commit and validates it strictly. A manifest problem (a typo'd field, an undeclared volume, a dependency cycle) stops the deploy right here, with a message naming the problem, before anything about your running app changes.

2. Your image is built once per commit​

If a service has a build block, AppHaven checks whether this exact commit has already been built. If it has, the existing image is reused and the deploy skips straight ahead. Deploying the same commit again, or promoting a previewed commit to production, doesn't rebuild it.

If not, a fresh, isolated build environment is created for this one build: it clones your repository at that commit, runs your Dockerfile, and is destroyed when it finishes. The build's full output appears live in the Builds tab, success or failure, and stays there afterwards: every build is kept in the tab's history with its branch, commit, and duration.

The result is one image per commit. The deployment that goes live runs exactly the image built from the commit it records; nothing can substitute a different image under the same deploy.

3. Your environment is provisioned​

For a first deploy, AppHaven creates the deployment's environment: its own virtual machine at the size you've chosen, its persistent storage, and any managed database, initialized with generated credentials that exist only where the database runs.

4. Your services start​

Containers start in dependency order: anything with depends_on waits for its target to be started, or healthy if you asked for that. ${...} connection references in your env resolve to real values as each service starts, and your console Variables & Secrets are applied on top of the manifest's env.

5. Your app is live​

The ports you declared are served on the deployment's URL over HTTPS, with certificates handled for you. The deployment card lists each container and its state, and each container has a Show logs action: your app's console output, no SSH required.

Throughout, the deployment shows where it is:

  • Provisioning: building or pulling images, starting containers.
  • Running: your app is up, with its containers and URL listed.
  • Failed: something went wrong; the card shows what, with logs.

Deploying an update​

When you deploy a new commit to an already-running deployment, the steps run in an order designed to protect the running version:

  1. The build happens first. While your new image builds, the current version keeps serving traffic, untouched.
  2. Then changed services are replaced. Only services whose image or configuration actually changed are restarted onto the new version; unchanged services keep running as they are.
  3. Your data carries over. Persistent volumes and databases belong to the deployment, not to a release: the new version starts against the same data, on the same URL.

When something goes wrong​

The build fails​

The deploy stops at step 2. Your running version keeps serving traffic: a failed build never touches it. The build appears as failed in the Builds tab with its full log (the error is at the end), and the activity timeline records it. Fix the code or Dockerfile, push, and deploy again.

Services fail to start​

If your containers can't come up (a crashing process, a bad migration, a missing variable), the deployment is marked Failed and the card shows the error. AppHaven captures the final console output of the failed containers at that moment, so you can read exactly what your app printed even after the containers are gone. Your data is untouched: fix the problem and deploy again, or deploy a previous commit, and the deployment starts against the same volumes and database.

Your app crashes while running​

Crashed containers are restarted automatically. A restart loop is visible on the deployment card and in the container logs, so a recurring crash is something you find out about, not something that silently takes the app down for good.

Stopping, deleting, and rolling back​

Stop a deployment and its containers shut down while every byte of persistent data (volumes and databases) is kept. A stopped deployment also releases its CPU and memory back to your project's quota. Deploy again and it picks up right where it left off, same data, same URL.

Deleting a deployment is the operation that removes its data. Stop is reversible; delete is not.

Rolling back is Git-native: every deployment records exactly which commit it shipped, so you always know what is running. To return to a previous version, check out or revert to that commit on your branch and deploy. The image for an already-built commit is reused, so a rollback deploy is fast. For the cases where bad data shipped along with bad code, see Backups & recovery.

Where to go next​