Deployments and rollback

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.

If a release fails before it changes anything, for example at the database health check, the running release stays in place and no recovery runs. The failed configuration is still the accepted one, so plan shows no changes; from alpha.81 it also says that deploying again retries the failed release.

Use Backups for data recovery and Observability to investigate the failure before retrying.

Change a running application from the CLI#

From alpha.79 the CLI covers the routine changes that used to need the dashboard or a hand-edited file:

hakopod export shop > hakopod.toml
hakopod set-image shop --service api --image ghcr.io/acme/api@sha256:DIGEST --wait
hakopod restart shop --service api --wait
hakopod secret set shop STRIPE_KEY --from-file stripe.key

export prints the live configuration as TOML that plans with no changes, with secrets only as references. Export again when you need it instead of keeping a copy in your repository that can drift. set-image plans the live configuration with one image replaced and deploys that plan. restart creates a new revision that restarts the service, for example after a secret changes. Secret values come only from a file or standard input, never from a command-line argument. hakopod apps, hakopod bindings APP and hakopod secret list APP show what is running; secret listings contain names only.