The Kaja Team
From a GitHub repo to a running app
What the path from code to a live URL looks like when there's no pipeline to wire up and no YAML to write.
The distance between "this works on my machine" and "this is running somewhere other people can reach" is where a surprising amount of engineering time goes. Not because any single step is hard, but because there are so many of them, and they live in different places: a pipeline definition, a registry credential, a Deployment, a Service, an Ingress, a certificate, a secret.
Here's what that path looks like in Kaja.
Connect a server
One install command on a machine you already run — a cloud VM, an on-prem box, a homelab machine with k3s. The agent connects outbound and the server shows up in the console. Nothing is exposed to do this.
Point a project at a repo
Create a project, create an app, and choose the GitHub repository and branch. Kaja builds the image and rolls it out. The build runs on your own server, which is why there's no build queue to wait in and no build-minute charge.
From then on, pushing to that branch is the deploy. No pipeline file, no webhook to configure by hand. If several commits land while a build is running, they coalesce — you get a build of the newest commit rather than a backlog of stale ones.
If you already build images in your own CI, skip all of that and deploy the image directly. You keep your pipeline; Kaja handles the rollout, revisions, and rollback.
Go live
The app gets a working HTTPS URL as soon as it's running — including on servers with no public IP. When you're ready for your own domain, add it, prove ownership with a TXT record, point a CNAME, and certificates are handled from there.
Then the part nobody demos
Deploying is the easy half. The rest of it is where platforms are actually judged:
- When it breaks — every build and rollout for an app sits in one timeline, so you can see what shipped, from which commit, and when. Rolling back is picking an earlier revision.
- When you need to look inside — logs stream and CPU and memory are per-app, stored on your own servers, so there's no retention bill deciding how much history you're allowed.
- When it needs a database — add a service from the catalog and bind it to the app; credentials are generated and mounted rather than copied into config by hand.
- When someone else joins — roles scope what each person can touch, and changes are recorded.
The point
None of this is impossible to assemble yourself. It's just that assembling it takes a quarter, and maintaining it never stops — and at the end you've built a platform instead of the product you meant to build. The quick start is the fastest way to see whether the shape fits your setup.