Deployments and rollback
Review deployment changes, track the rollout and return to a previous successful revision.
A deployment asks Hakopod to apply one application revision. Closing the browser or losing the CLI connection does not cancel an accepted request. The server stores the operation in PostgreSQL and continues applying it.
Understand the plan#
The plan shows the configuration to apply, its changes, warnings and the revision it expects to replace. Applying a stale plan returns a conflict. Review again against the latest configuration instead of overwriting a concurrent edit.
The dashboard provides the review step. In the CLI, inspect hakopod plan before running hakopod deploy; deploy obtains its own fresh plan and submits that expected revision. Use --wait when your script needs the final deployment result rather than acceptance alone.
For a service-only change:
hakopod plan --file hakopod.toml --service api
hakopod deploy --file hakopod.toml --service api --wait
Services outside the change keep the image digests from their latest accepted configuration, even if their image tags have moved. Hakopod records the result as a complete application revision.
Deploy from CI#
Use the deployment API guide to trigger releases from an existing pipeline, preserve unrelated services and wait for rollout results.
Deploy from a repository#
For GitHub and GitLab.com repositories, choose how Hakopod should deploy:
- Sync TOML: bind an approved repository, branch and relative file path. A plan resolves a commit and reads the file at that exact SHA. Automatic deployment uses authenticated push events.
- Build an image: select a Dockerfile or Cloud Native Buildpacks preset, context and target architecture. Review the generated CI configuration before an administrator installs it. Builds run on the provider's runners, then Hakopod verifies the returned source commit and image digest.
Repository credentials and OAuth login are separate integrations. Signing in with GitHub does not approve a repository. Private output images also need a persistent registry pull credential in the target environment.
GitHub builds use Actions and GHCR. GitLab builds use GitLab CI and Container Registry, with one Hakopod-managed build per repository in this release. Hakopod refuses to replace an unowned .gitlab-ci.yml or a custom CI entrypoint. The operator's provider account pays runner charges and is subject to its runner limits.
Automatic flows need the correct publicly reachable HTTPS webhook and event types. Saving a binding on a loopback development server does not make it reachable by GitHub or GitLab. Changed settings, expired grants or revoked permissions block later deployment steps.
Check current service health#
Deployment history says whether a rollout succeeded at that time. Service observations say what is happening now. A later scheduling error, node pressure or failed readiness probe can make a formerly successful application unhealthy.
Inspect pod events, replicas and live observations before treating an old success as proof of availability. A deployment can update some services before another service fails; those changes do not all succeed or fail together. The deployment detail records service results and any attempted recovery after a failed group.
Return to a successful revision#
Select a previous successful release in the application's deployment history. Review rollback and apply it, or use the CLI with the actual revision number:
hakopod rollback shop --revision 1 --wait
Rollback records a new revision using the earlier saved configuration and image digests. It still needs valid permissions, available capacity and current network grants. It does not restore database contents, undo migrations or reverse external side effects. Persistent services can have downtime while they are recreated.
Use Backups for data recovery and Observability to investigate the failure before retrying.