Pipelines

A ZopDay pipeline is the path a commit takes from your git branch to a live URL on your cluster or VM. Every deploy runs the same pipeline: ZopDay resolves where the service runs, clones the repo, detects how to build it, builds the image on GitHub Actions, and rolls it out. It is one pipeline, with no separate tools to chain. You run it in the Quickstart and see it per revision in Deployments.

Service drawer, Overview tab: the public URL, live revision, and git source the pipeline shipped. Earlier revisions are on the Revisions tab.

Before you start

• A service in an environment bound to a registered cluster or VM. See Projects and environments.
• For auto-deploy on push, the repo connected through the GitHub App integration.
• The deployment:* policies to redeploy, change config, or roll back.

How it works

Pipeline stages

Resolve → Clone → Detect → Build (GitHub Actions) → Callback → Deploy → WatchRollout

1. Resolve. ZopDay reads the service, its environment, and the space (cluster or VM) the environment is bound to.
2. Clone. ZopDay clones the repo at the configured branch.
3. Detect. ZopDay works out the language, framework, and port. If the repo has a Dockerfile, ZopDay uses it as-is. If it doesn’t, ZopDay builds the image for you, so no Dockerfile is required.
4. Build. ZopDay dispatches the build to a GitHub Actions runner, which builds the image and pushes it to the environment’s registry. Builds never run inside your cluster.
5. Callback. The runner streams build logs back to ZopDay and reports the result over a signed callback. On success, the deploy stage is queued.
6. Deploy. ZopDay rolls the new image out: as a Helm release on a Kubernetes cluster, or as a container behind Caddy on a VM.
7. WatchRollout. ZopDay follows the rollout until the service reaches Active or fails.

Each stage writes an entry to the deploy’s append-only timeline when it starts and when it succeeds or fails, so you can see exactly where a deploy is and where it stopped.

Where builds run and images go

• Builds run on GitHub Actions, not in your cluster. The runner clones, builds, and pushes the image, then reports back.
• Images go to your registry. The image is pushed to the registry integration bound to the environment. If there isn’t one, it goes to the cloud’s default registry (ECR, Artifact Registry, or ACR) on the space’s cloud account.
• No standing cluster credentials. For each deploy, ZopDay mints a short-lived kubeconfig from your cloud account credentials (about 13 minutes on EKS, about 45 minutes on GKE). Nothing stays on your cluster afterwards.

Secrets handling

Environment variable values are treated as secrets. They are never shown back to you in the UI or returned by the API or MCP tools, and they are not written to the audit trail.

For datastores that ZopDay provisions, the root password goes to your cloud’s secret manager, and ZopDay keeps only the reference:

• AWS: Secrets Manager.
• GCP: Secret Manager.
• Azure: Key Vault.

See Provisioning datastores for how services connect to them.

Trigger a deploy

Auto-deploy is a per-service setting. Turn it on only where you are happy for anyone who can push to the branch to ship to that environment. With it off, pushes don’t ship and someone redeploys explicitly.

If GitHub delivers the same webhook twice, ZopDay recognises the repeat and ignores it, so a retried delivery never creates a duplicate deploy.

Follow a deploy

The canvas opens the live rollout view as soon as a deploy starts. It shows the current stage, streams the build log from GitHub Actions, and shows the live URL once the service is active. A service’s deploy history, with each revision’s status, image, commit, and who triggered it, is on the service drawer’s Revisions tab.

Config-only revisions and rollbacks skip the build and finish sooner.

When a stage fails

If a stage fails, ZopDay retries the revision up to 3 times. If it still fails, the revision moves to a dead-letter state (dlq) and stops. The timeline shows the failing stage and its error.

ZopDay does not roll back automatically. The service’s current revision stays the last one that reached Active. Fix the cause and redeploy, or roll back to an earlier revision.

ZopDay also guards against a lost build callback. If the runner pushed the image but its success report never reached ZopDay, a watchdog finds the push in the build log and resumes the deploy.

Reference

Audit

Every change that starts or alters a deploy (a manual deploy, a config change, a rollback) is recorded in Activity → Audit Logs with the actor, the request, and the time. You can forward the audit feed to your SIEM. See Audit logs.

Troubleshooting

Next steps