kran docs

Commands

Command kamal Runs
kran init kamal init writes config/kran.yml
kran deploy kamal deploy docker login, docker build --push, krane render \| krane deploy
kran build push kamal build push docker login, docker build --push
kran build details kamal build details docker version, docker buildx ls
kran logs kamal app logs kubectl logs -l <selector> --prefix --timestamps
kran exec kamal app exec kubectl get pods then kubectl exec
kran shell kamal shell alias for kran exec --interactive bash
kran console kamal console alias for kran exec --interactive bin/rails console
kran details kamal details kubectl get all -o wide
kran audit kamal audit kubectl rollout history deployment -l <selector>
kran version kamal version docker --version, krane version, kubectl version --client

Global options

Option Meaning
-d NAME, --destination NAME Deep-merge config/kran.NAME.yml over config/kran.yml
--dry-run Print every command that would run, and run none of them

--dry-run also skips the check that docker, krane and kubectl are installed. Passwords are shown as printf '%s' '[REDACTED]' | docker login ....

Shared behaviour

Every kubectl command is KUBECONFIG=<kubeconfig> kubectl --context <context> --namespace <namespace> ..., filled in from config/kran.yml. Kran never changes the context your shell has selected.

Every external command runs inside Bundler.with_unbundled_env. Kran is often started through bundle exec, and krane and ejson are Ruby programs of their own; without this they would inherit RUBYOPT and BUNDLE_GEMFILE and refuse to start.

Tools are checked before the first command runs, so a missing krane cannot leave a pushed image with no deploy behind it.

kamal commands with no kran equivalent

Kamal manages the lifecycle of a host. On Kubernetes that is the cluster’s job and the templates’: