Deployments Overview

Deployments are how your code gets from GitHub to your server. You can trigger them manually from the dashboard or automatically on git push.

Your source code is cloned and built directly on your server. It never passes through Reoclo’s infrastructure.

Triggering a Deployment

Manual

Navigate to your application in the dashboard and click Deploy. This deploys the latest commit from the configured branch immediately.

Use manual deployments when you want explicit control over when code ships to production.

Auto-Deploy

Enable auto-deploy in your application settings to trigger deployments automatically when you push to the configured branch.

Auto-deploy is great for staging environments or development servers where you want continuous deployment. For production apps that need manual approval, leave it disabled.

Deployment States

State	Meaning
pending	Reoclo recorded the deployment and has not started it.
queued	The deployment waits because your organization is at its plan’s concurrent deployment limit.
waiting_ci	Reoclo is waiting for the commit’s CI checks to finish. See Wait for CI before a deployment.
cloning	Reoclo is cloning the repository onto the target server.
building	Reoclo is building the Docker image.
pushing	Reserved. Current pipelines do not normally enter this state.
deploying	Reoclo is starting the new container.
succeeded	The deployment finished and the new container is live and healthy.
running	Legacy spelling of succeeded on deployments recorded before September 2026.
failed	The deployment did not finish. The previous container stays live.
cancelled	You or Reoclo stopped the deployment before it finished.
rolled_back	Reserved. A deployment that was reverted shows this state. Current pipelines report a failed deploy with the previous container still live instead.

Zero-Downtime Deploys

Reoclo uses a blue-green deployment strategy:

1. The new container starts alongside the old one
2. Health checks run against the new container
3. Only after the health check passes does the old container stop
4. On failure, the old container stays running and the new one is removed

Failed deployments do not cause downtime. If your new code breaks the health check, the old version keeps serving traffic.

Health Check Tip

If your app takes time to warm up (database connections, cache loading, and so on), make sure your health check endpoint reflects actual readiness, not just process startup.

Viewing Deployments

The dashboard shows deployment history with:

• Status, one of the deployment states described earlier
• Duration
• Commit SHA and message
• Full pipeline logs

Click any deployment to see the complete log output. This is useful for debugging build failures or understanding why a health check failed.

Next Steps

• Configure your deployment with environment variables, health checks, and Docker settings
• Understand server connections to see how Reoclo connects to your infrastructure
• Review encryption to understand how secrets are protected