Deploying Apps
Every deployment on Burrito starts with a git push. This page explains how the deployment pipeline works, how to view build logs, and how to roll back or promote deployments.
How Deployments Work
When you push to your Burrito git remote:
- Receive — the server receives your push and identifies the branch
- Build — your Dockerfile is built into a container image
- Deploy — the new container replaces the previous one
- Route — HTTPS traffic is routed to your container automatically
The entire process typically takes under a minute for most projects.
Branch-to-Environment Mapping
- Push to
main→ deploys to production - Push to
test→ deploys to test environment
Other branches are ignored.
Viewing Deployment History
From the site detail page on the console, you can see a list of all deployments with their status, commit SHA, environment, and timestamp.
Click on any deployment to view its build log.
Build Logs
Build logs show the full output from your Docker build. If a deployment fails, the build log will contain the error. Common issues:
- Missing
Dockerfilein the repository root - Build errors in your application code
- The container not listening on the port declared by
EXPOSEin your Dockerfile (defaults to 80 — see Dockerfile Requirements)
Rolling Back
If a deployment causes issues, you can roll back to the previous version:
- Go to the site detail page
- Click Rollback next to the environment (prod or test)
- The previous container image is redeployed immediately — no rebuild needed
Rollbacks are instant because they reuse the previously built container image.
Promoting Test to Production
Once you've verified your changes in the test environment:
- Go to the site detail page
- Click Promote to deploy the test container image to production
This deploys the exact same image that's running in test — no rebuild, no surprises.