Deployments and rollback
Review a revision, follow the rollout and recover without losing its history.
A deployment is a durable request to apply one application revision. Closing the browser or losing the CLI connection does not cancel an accepted request. The server keeps the operation in PostgreSQL and continues reconciliation.
Understand the plan#
The plan contains normalized configuration, a diff, warnings and an expected revision. 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
Untouched services keep their latest accepted resolved images. A moving tag should not silently replace an unrelated artifact. The resulting revision is still a coherent application configuration.
Deploy from a repository#
GitHub and GitLab.com support two distinct flows:
- 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. Provider runner limits and charges belong to the operator's account.
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 new deployment effects.
Read current health separately#
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. Multi-service groups are not atomic transactions. 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 creates a new auditable revision using the earlier immutable configuration and artifacts. 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.