Deployments
A deployment applies the current project draft to the servers you selected for its components. It is the point at which planned infrastructure and application changes become the intended running state.
Deployments are recorded as a sequence of stages and tasks, which gives you a clear history of what changed and where a rollout stopped if it needs attention.
Review the change
Select Review and deploy from the project canvas when the draft is ready. The review shows the components, variables, domains, and connections that will change.
Take a moment to confirm:
- The target server for every changed component.
- The source revision and settings for each application.
- New or changed variables, particularly secrets and imported connection values.
- Added, removed, or changed domains.
- Any removal of a database, cache, or other stateful component.
If the change is not ready, return to the canvas and keep editing the draft. Nothing is applied until you start the deployment.
Follow progress
Deployments run asynchronously. Once started, open the project's Deployments tab to follow the rollout. Expand a deployment to inspect its stages, task status, errors, and available logs.
| State | Meaning |
|---|---|
pending | The rollout has been accepted and is waiting to start. |
running | One or more deployment tasks are in progress. |
succeeded | All planned work completed successfully. |
failed | A task could not complete; inspect the failed stage and its logs. |
canceled | The rollout was stopped before it completed successfully. |
The first deployment to a server can take longer because Kumoto needs to prepare that server for the project. Subsequent deployments usually have less setup work, but their duration will still depend on the changes, your application build, and the server.
When a deployment fails
A failed deployment does not mean you need to recreate the project. Start with the failed task and its log output, then correct the relevant configuration or source change in the draft.
Common things to check include:
- Whether the selected source revision exists and can be built.
- Required variables and imported values.
- Application commands, paths, and runtime settings.
- Domain configuration and DNS changes.
- Whether the target server is connected and has the capacity your workload needs.
After correcting the issue, review the updated draft and create a new deployment. Keep the failed deployment as useful history rather than overwriting or ignoring it.
Cancel and retry deliberately
If a rollout is still running and you need to stop it, cancel it from the deployment view. Review the project and the deployment status before making a follow-up change, especially when the rollout included stateful services.
For a routine application update, the normal recovery path is simple: adjust the draft, review the complete diff, and deploy again. For an unexpected production issue, use the deployment history and logs to understand the last change before deciding on the next rollout.
Deployments started from either the dashboard or MCP are asynchronous. Check the recorded status before treating a rollout as complete.