Deployment Runs
A deployment run tracks the execution of a deployment pipeline — from server provisioning through application startup. Every time you deploy or redeploy, a new run is created.
Viewing runs
Runs are displayed in the Runs tab on the right sidebar of the chat interface. Click on a run to view its detailed steps and logs.
Run steps
Each run consists of multiple steps executed sequentially.
Step statuses
| Status | Indicator | Description |
|---|---|---|
| Pending | Gray | Step hasn't started yet |
| Running | Blue, animated | Step is currently executing |
| Completed | Green | Step finished successfully |
| Failed | Red | Step encountered an error |
| Skipped | Gray, strikethrough | Step was skipped |
Real-time logs
Click on any step to view its real-time logs. Logs stream live during execution, showing the complete output of each command being executed on your server.
Run controls
Pause
Pause an active run to temporarily halt execution. The current step finishes, then the run waits. Useful when you need to investigate something before proceeding.
Resume
Resume a paused run. Execution continues from where it was paused.
Stop
Stop a run entirely. This cancels any remaining steps. Completed steps are not rolled back.
Run statuses
| Status | Description |
|---|---|
| Started | Run has been initiated |
| In Progress | Steps are actively executing |
| Completed | All steps finished successfully |
| Failed | A step encountered an unrecoverable error |
| Paused | Manually paused by user |
| Stopped | Manually stopped by user |
Failed runs
When a run fails, the failed step is highlighted with error details and the AI will suggest fixes based on the error. You can:
- Fix the issue (e.g., update the port configuration)
- Ask the AI to modify the infrastructure plan
- Redeploy, which creates a new run
Redeployment
To redeploy your application after code changes:
- Push changes to your Git repository
- In the project chat, ask: "Redeploy the application"
- A new run is created with the latest code
Redeployments are faster than initial deployments because:
- The server is already provisioned
- Docker layers are cached
- Only changed components need rebuilding
Run history
All past runs are preserved in the Runs tab. You can:
- Review what happened in previous deployments
- Compare successful and failed runs
- Track deployment frequency and duration
- Debug recurring issues by examining historical logs
Runs are ordered by most recent first, making it easy to find the latest deployment.