Deploy pipeline

Git push to running service. No YAML in between.

Kapten works out how your app builds, builds it, and rolls it onto the cluster already running in your account. You do not write a pipeline, and you do not describe the cluster — both already exist by the time you push.

Trigger

git push, or the API

Build

Buildpacks or your Dockerfile

Rollout

Rolling, behind health gates

Rollback

Any previous build, one click

• Zero config to first deploy

  Point Kapten at a repository. It detects the runtime, picks a builder and ships it. No pipeline file to author, no cluster manifest, no Helm values to fill in before anything runs.

• Your Dockerfile wins

  A Dockerfile in the repository is used as-is. Buildpacks are the fallback for repositories that do not have one — never an override of one you wrote.

• Health-gated rollouts

  A new revision only takes traffic once it answers its checks. A build that fails to come up stays a failed build instead of becoming a failed production.

• Rollback is a re-point, not a re-run

  Every previous image stays addressable. Rolling back moves traffic to a build that already exists — it does not send you back through CI to get there.

• A preview environment per branch

  Every branch can get its own environment, its own URL and its own data, torn down when the branch merges. Review apps stop being a thing you keep meaning to set up.

• Logs while it builds

  Build output streams as it happens and stays attached to the deployment that produced it, so a failure three weeks ago still has its reason next to it.