Deploy to Cluster¶
Basic Deploy¶
You'll be prompted to confirm before applying. Use --yes to skip:
Preview Changes Before Deploying¶
Use diff to see what would change without applying anything — renders the manifests
and pipes them to kubectl diff:
Exit code follows kubectl diff semantics: 0 = no changes, 1 = diff found.
Re-Deploy Without Specifying the Spec File¶
After the first deploy, the spec path is saved to the registry. Use update to
re-deploy the active app (or a named app) without passing the spec path again:
helm-me update # re-deploy the active app
helm-me update my-app # re-deploy a specific app
helm-me update --yes # skip confirmation
helm-me update --no-wait # don't wait for rollout
Wait for Pods to Be Ready¶
By default, deploy and update block until all Deployments have their desired
replicas available (equivalent to kubectl rollout status):
helm-me deploy deploy.yaml --yes # waits up to 300 s (default)
helm-me deploy deploy.yaml --yes --wait-timeout 120 # custom timeout
helm-me deploy deploy.yaml --yes --no-wait # fire-and-forget
Target a Specific Cluster¶
helm-me deploy deploy.yaml \
--kubeconfig ~/.kube/staging.yaml \
--context staging-eu \
--namespace my-team
What Happens During Deploy¶
- The spec is parsed and validated (
lintcheck) - Kubernetes manifests are rendered
- The target namespace is created if it doesn't exist
- Resources are applied (
create-or-update) - The CLI waits for Deployments to become available (unless
--no-wait) - The deployment is saved to the local registry (
~/.helm-me/deployments/)
After deploy, you can manage the app without specifying the spec file again:
Force Image Pull¶
Force Kubernetes to re-pull images (useful when the tag hasn't changed but the image has):
Rolling Restart After Deploy¶
Active App¶
After deploying, helm-me automatically sets the app as active: