Every cluster you own.
One deploy button.

Kaja gives the Kubernetes clusters you already run — in the cloud, in your own building, or behind NAT with no public IP — push-to-deploy, rollbacks, domains, HTTPS, logs and metrics from one console. Your compute is never metered, because it isn't ours.

Free during beta. No credit card.

Connecting a cluster is one command. The console generates it, with a token that works once.

curl -sfL https://kaja.dev/install.sh | sh -s -- <token> <version>

Installs k3s, cert-manager and the agent on a fresh machine. Safe to re-run. The console fills in the token and version for you.

How it reaches your servers

Nothing dials in.

You install an agent that only makes outbound connections. No open ports, no exposed API server, no kubeconfig shared with us. A machine behind NAT with every inbound port closed can still serve real traffic on a real domain over HTTPS.

This is the part worth checking against anything else you are evaluating. Platforms that deploy into infrastructure you own generally require two things of it: that it can provision a public load-balancer IP, and that their control plane can reach its Kubernetes API. Kaja requires neither, which is why a cluster in a rack behind CGNAT is a supported setup here rather than an unsupported one.

Underneath the console, everything Kaja creates is a standard Kubernetes object in your cluster. You can inspect it, keep it, or walk away with it.

Someone opens your app in a browser

No inbound ports. Your cluster opens the connection and keeps it open, and requests travel back down that same connection. A machine behind NAT with every inbound port closed still serves real traffic on a real domain.

What Kaja does today

Everything below is built and usable now.

Not a roadmap. If something is missing from this list, it is because it does not work yet, and it is in the next section instead.

Deploying

  • Connect a GitHub repo once. Every push builds and rolls out, with no pipeline to wire up.
  • Or point Kaja at a container image in any registry and deploy that instead.
  • Builds run on your own cluster, from a Dockerfile or a buildpack. They are never billed by the minute.
  • Every deploy is a numbered revision. Rolling back is one click.
  • Builds and rollouts share one timeline, so you can see what shipped and which commit it came from.

Traffic

  • Every app gets a URL as soon as it deploys.
  • Attach your own domain and certificates are issued and renewed for you, wildcards included.
  • Domain ownership is verified, and re-checked afterwards rather than trusted forever.
  • Clusters with no public IP can still serve public HTTPS, through a gateway we run.

Data

  • PostgreSQL, managed by CloudNativePG, with failover and pgvector. Apps bound to it get a DATABASE_URL.
  • Point Postgres at an S3 bucket you own and it takes scheduled backups, keeps the history, and requires a final snapshot before it will let you delete the database.
  • MySQL, managed by the Percona operator, fronted by a connection proxy and backed up to your object store.
  • Redis, running Valkey, as either a cache or a durable instance with its own volume.
  • Metrics and logs, installed together in one click and collected per project.

Running it

  • Stream logs and watch CPU and memory per app, stored on your own hardware.
  • Open a terminal inside a running app or database from the console, so you can run one psql without kubectl access to the cluster.
  • Images built from distroless or scratch have no shell to attach to, so Kaja offers to run a debug container beside them instead.
  • Pause a project to scale its apps to zero without losing any configuration.
  • Duplicate a project, or save one as a blueprint and spawn new environments from it.
  • Configs and secrets per project, synced to the right cluster and mounted into your apps.
  • The agent updates itself from the console, so a fleet does not drift.

Teams

  • Admin, editor, and viewer roles, with per-resource permissions.
  • An audit log of every change.
  • Terminal access is its own permission. Restrict it to admins, or switch it off for the whole organization and cut every live session.
  • Any number of clusters in one organization, managed from one console.

What it doesn't do

And what we'd rather you heard from us.

A command-line tool

The CLI is written and works, but it is not published anywhere you can install it from yet.

Servers we run for you

Today you bring a Kubernetes cluster. If you do not have one, Kaja has nothing to offer you yet.

Project network isolation

Built, and off by default. Parts of it are verified on a real cluster and parts are not, so it stays opt-in until they are.

Kaja is in beta and free while it is. It is young software: there is no SLA, no compliance certification, and it is not yet running anyone's production workloads. If that rules it out for you, it should, and it is better said here than discovered later.

What this costs

Your compute is never metered.

Your apps, builds, logs and metrics all run on hardware you already pay for. That costs us nothing, so there is no per-container, per-build-minute or per-gigabyte-of-logs line item, and there will not be one.

Always free
Apps, projects, deployments, builds, rollbacks, secrets, logs and metrics, on every plan.
What you pay for
The servers you manage from one dashboard, and the gateway traffic we carry on your behalf.
If you stop paying
Your apps keep running. Everything Kaja created is still a standard Kubernetes object in your cluster.
See what that costs →

Connect a cluster and deploy something.

If you have a cluster running already, this takes a few minutes. If it doesn't work, we would genuinely like to know.