Deployah

Spec-to-Release for Kubernetes

Deploy apps to Kubernetes from a short spec

One binary. No Helm chart to maintain. Nothing to install in the cluster. You get a real Helm release.

Apache 2.0. No vendor lock-in. You bring the cluster and the image.

Spec, plan, deploy, then the app in a browser.

Why this exists

The Kubernetes work moves.

  • In the app repo A Helm chart sits next to the code. You own the templates.
  • On every developer They write Helm values, or the whole chart.
  • In the cluster You install a server and a UI into Kubernetes, then keep that running.

Deployah keeps that work out of all three.

Spectro Cloud: 92% agree developers should not manage infrastructure. One in three say they still build their own clusters. [ref]

Ownership

Two files, two owners.

App teams own what to run. Platform owns where it runs.

App team deployah.yaml
apiVersion: v1-alpha.5
project: my-app
components:
  web:
    image: nginx:1.26
    port: 80
    expose: true

Full spec

Platform deployah.platform.yaml
apiVersion: platform/v1-alpha.3
environments:
  production:
    context: prod-eks
    domains:
      public:
        baseDomain: example.com
        tls:
          mode: certManager
          issuer: letsencrypt-prod

Full platform file

These apiVersions are alpha. Expect breaking changes between releases.

Proof

20x less YAML you own

Nginx 1.26, public HTTPS. Same Deployment, Service, Ingress, and probes. [ref]

  • Deployah 17 lines
  • Kubernetes 135 lines, 3 objects
  • Kustomize 145 lines, base and overlay
  • Helm 340 lines, a chart

20x is against the Helm chart. The other two are near 8x.

CNCF: 75% prefer Helm for packaging Kubernetes apps. We ship a Helm release. The chart is what you stop owning. [ref]

Plan

deployah plan: first install, then a resources change as YAML

Plan before apply. Same CLI in CI.

$ deployah plan local

Same binary on your laptop and in a CI/CD pipeline. Broken paths, bad probes, and task cycles fail before apply.

--detailed-exitcode exits 2 when something would change.

Red Hat: 40% of teams detected a Kubernetes or container misconfiguration in 12 months. We stop the classes we test, before apply. [ref]

Local

Local cluster Ready after deployah cluster up

A cluster on your laptop.

$ deployah cluster up

Needs Docker or Podman. That is the only extra tool.

Warm is about 35 seconds. Cold is about five minutes.

Already have a cluster? Set the environment's kube context. Same spec.

After deploy

Logs and a shell take the project name.

Two pods logging under deployah logs

Every pod's logs.

$ deployah logs my-app

It tails every pod. Filter with --component if you want one.

Component picker for deployah shell

A shell in the container.

$ deployah shell my-app

Finds a shell in the container. Multiple components show a list. Or pass --component.

Commands

Everything runs from a single binary.

No separate helm, kubectl, or kind to install.

$ deployah init

Creates the spec and platform file.

$ deployah deploy local

Install or upgrade the Helm release.

$ deployah plan production

Shows a diff against the last release. --offline renders and validates with no cluster.

$ deployah run migrate production

Runs a spec task as a Job. Tasks can also run on every deploy.

$ deployah status my-app

What is deployed in an environment.

$ deployah delete my-app production

Removes the release. Check it first with --dry-run.

Install the CLI.

$ brew install deployah-dev/tap/deployah

Then run $ deployah init.