For developers

Five commands to running. No YAML. // Real Kubernetes underneath. Nothing to configure above.

Your platform team installed AppBahn so you would stop Slacking them about broken deployments. This is your side of that deal.

Read the docs Star on GitHub
— The inner loop

Five commands. No config files.

The sequence, roughly. Every one of these has a docs page with the full flag set.

  1. appbahn login OIDC against your IdP.
  2. appbahn project create <slug> Create a project under your workspace.
  3. appbahn resource create <slug> --image <ref> Declare a container resource with an image reference.
  4. appbahn deploy trigger <slug> Roll it out. Operator reconciles Deployment, Service, and Ingress.
  5. appbahn deploy status <id> Watch the reconcile. Exits when the resource is ready or failed.
— How it feels

Boring in the good way.

01

CLI-first, console-second

Every action in the console has a CLI flag. Every CLI flag has a docs page. Shell-completion generation is tracked tech debt.

02

No YAML for common paths

You get a Deployment, a Service, and an Ingress without typing the word "apiVersion". The operator owns the YAML; you own the app.

03

Environments as a first-class tier

Workspace → project → environment → resource. Per-environment config, per-environment RBAC, per-environment slugs. Per-PR preview envs are on the roadmap.

04

Observability by delegation

We do not ship metrics and logging stacks. AppBahn plugs into the Prometheus and Victoria Logs already installed in your cluster, so your retention, storage, and access stay yours.

— Get the CLI

One binary. GitHub releases.

Download the appbahn binary from GitHub releases and drop it in your PATH. Platform docs cover the cluster side. Developer docs cover the CLI and the console. Start wherever your problem is.

Read the docs GitHub releases →