Release to K3s with a plan you read before anything changes
Release, scale, restart and roll back Deployments from your desktop. Every change is a server-side dry-run plan you confirm, guarded by a Lease.
What it is
Reviewed releases are the write path of the Infra console. Four actions are available on existing Deployments:
| Action | What changes |
|---|---|
| Release | One container’s image, set to a registered digest |
| Scale | spec.replicas, 0–1,000; the Pod template is untouched |
| Restart | A Pod template annotation, so Pods roll according to the update strategy |
| Roll back | One container’s image, set to the digest from an earlier successful release |
Each one follows the same sequence: plan → review → confirm → apply → verify → record.
How it works
- Plan. DevOpsPad reads the Deployment and binds the plan to its UID,
resourceVersion, container, image digest, namespace, application selector and the cluster endpoint. It then submits the change as a Kubernetes server-side dry-run, so admission and validation errors appear before anything is written. - Review. The dialog shows the current and target image, or the replica change, and the plan’s expiry. Plans live only in memory, expire after 10 minutes and can be used once.
- Lock. On confirm, DevOpsPad takes a
coordination.k8s.io/v1Lease in the target namespace for that Deployment (300-second lease, 180-second execution limit), then checks the UID andresourceVersionagain. - Apply. The update is written. Image releases and restarts add a
devopspad.io/releaseannotation; scaling leaves the template unchanged. - Verify. Success means the controller observed the new generation and the updated, available and total replicas equal the desired count.
- Record. Every step is written to
releases/<uuid>.jsonin the project. If the record can’t be written, execution stops.
Timeouts, lost connections and concurrent edits are recorded as incomplete. A record left by a crashed client shows 执行中 / 待核实 (running / needs verification). Nothing is retried or rolled back automatically.
Artifacts by digest
Releases use artifacts: image references pinned to @sha256: digests, registered by hand or created automatically when an AI agent reports a successful build. DevOpsPad doesn’t build or push images; your registry can live on your laptop or LAN as long as the nodes can pull from it.
Limits
- Existing Deployments only, one container per release. StatefulSets and DaemonSets are view-only; creating or deleting workloads isn’t supported.
- A rollback restores the image only, not ConfigMaps or replicas.
- The Lease is honored only by DevOpsPad clients. GitOps controllers may revert changes they manage.
- Release specs with ConfigMaps, migration Jobs, Nginx steps and fleet-wide rollout are validated by
devopspadctlbut not yet executed.
The design is explained in dry-run plans and leases for desktop releases.
Help articles
Release a new image to a Deployment
Release a registered image to one container of an existing Deployment. DevOpsPad runs a server-side dry-run, takes a Lease and waits for the rollout.
Scale or restart a Deployment
Change a Deployment's replicas between 0 and 1,000 or trigger a rolling restart from the Infra console, after reviewing a dry-run plan.
Roll back to a previous image version
Roll a Deployment container back to the image digest of an earlier successful release. A new plan is checked against the current state first.
Register an image as an artifact
Register an existing image by its immutable sha256 digest so you can release it. DevOpsPad does not build, push or verify images in your registry.
Record AI builds and releases in DevOpsPad
Let an AI agent report build and release steps with devopspadctl runs record. Successful builds become artifacts; records are idempotent and validated.
Frequently asked questions
What happens if a release fails halfway?
DevOpsPad marks it as incomplete and asks you to check the cluster. It never retries or rolls back on its own, so a partial state is never hidden behind an automatic action.
Can two people release the same Deployment at the same time?
Two DevOpsPad clients cannot. Each Deployment has a Kubernetes Lease that the second client must wait for. Other tools ignore that Lease, but the resourceVersion check still stops DevOpsPad from overwriting their changes.
Why must images use a sha256 digest?
Tags such as latest can point to a different image later. A digest identifies one exact image, so release records and rollbacks always refer to what actually ran.