Build Your Own Kubernetes based SaaS Cloud Platform with Kamaji and GitOps

Think building a SaaS platform is out of reach? With Kamaji, GitOps, and Kubernetes, it’s simpler — and more powerful — than it seems.

15 min readMay 19, 2025

Note: In this blog, you’ll learn how tools like Kamaji, Argo CD, and Sveltos can power multi-tenant Kubernetes platforms — just like those used by major SaaS providers.
By the end, you’ll be ready to start building your own managed Kubernetes service.
⭐️ If you find it useful, show Kamaji some love on GitHub — it’s already on the radar of giants like OVHCloud and IONOS Cloud or NVIDIA.

Fig. 0: Behind the Scenes: What Actually Happens When You Click “Create”?

Have you ever wondered what really happens behind the scenes when you create a managed Kubernetes cluster on platforms like OVH, Azure, AWS, STACKIT, GCP, or Civo?

Okay, okay — most of us don’t actually click buttons. We use APIs, Infrastructure-as-Code (IaC), or operator-driven automation. Anything else would be… well, sinful.

But here’s a deeper question:
How do cloud providers spin up and manage fleets of Kubernetes clusters — at scale, and cheaper than the competition?

If you’ve already built your own SaaS offering using tools like Kamaji, Sveltos, or Argo CD, you might already know.
If not — stay with me. I promise you, this rabbit hole is worth it.

To get a clearer picture, we’ll first take a peek at Civo and their workflow. Then, we’ll try to recreate something similar using Kamaji, GitOps (Argo CD), and multi-cluster fleet management with Sveltos.

And who knows — maybe we’ll even push Kamaji beyond what its creators imagined. Let’s find out.

What is Civo?

Civo is a UK-based cloud provider that specializes in cloud-native infrastructure. Their platform focuses on speed, simplicity, and — most importantly — transparent pricing.

One of their biggest selling points?
They offer managed Kubernetes for significantly less than the big hyperscalers.

Fig. 1: Civo is more than 50% cheaper than the competitors… how is that possible?

Let’s take a quick look at why that’s possible.

Why is Civo More Affordable?

There are a few clever engineering and architectural choices behind it.

1. Lightweight Kubernetes with K3s

Civo uses K3s — a slimmed-down Kubernetes distribution that ditches some of the usual baggage:

No need for etcd (less CPU and RAM usage)
Fewer components, smaller footprint

K3s stores state in SQLite or Kine, which acts as a proxy to backends like MySQL or PostgreSQL.
This allows Civo to run more clusters per server — higher density, lower cost.

2. Custom Infrastructure: CivoStack

Unlike AWS or GCP, Civo doesn’t rent cloud; they own it.
Their infrastructure is purpose-built for Kubernetes, which means they save on compute, storage, and networking costs.

3. Standardization and Automation

Cluster launch in under 90 seconds? That’s no magic — just heavy automation.
Less manual ops = leaner operations = lower cost. Simple math!

4. Community-first and Open Source

Civo relies on tools like K3s, Talos, and Cilium — all open source, no license fees.
Most services come from the community or are intgerated into their marketplace.
Civo makes money on infrastructure, not on overpriced extras.

So far, so good. But just to be clear: this blog isn’t about promoting Civo. It’s about showing you that it’s entirely possible to build a lean, affordable Kubernetes-based SaaS platform.
And yes, you might just be the one to build it.

Launching a Kubernetes Cluster on Civo

Let’s walk through what it looks like when you create a cluster.

You log into the UI, go to “Kubernetes”, click “Launch your first cluster”.
(If you’re new to Civo, there’s $250 in free credits waiting for you.)

Now — you should probably be doing this through Terraform or IaC. But for demonstration, we’ll use the UI — it helps to actually see the pricing, distro choices, and marketplace. It’s surprisingly simple:

Fig. 2: Launch Kubernetes Cluster on Civo — Part 1

You select the cluster type (K3s or Talos), the number of nodes, and the CNI.

Fig. 3: Launch Kubernetes Cluster on Civo — Part 2

Civo’s Marketplace includes pre-integrated tools:

It’s affordable, practical, and surprisingly smooth.

What Happens Behind the Scenes?

Do I know exactly what happens under the hood? No.
Do I have a working theory? Of course.

Fig. 4: Hypothetical workflow after clicking “Launch Kubernetes Cluster” on Civo

Here’s how I imagine it goes:

You hit “Launch”. Behind the scenes, infrastructure is provisioned via Civo’s Cloud API — probably with something like Terraform.
Once resources pass health checks, the K3s control plane is installed, and nodes are joined.
Based on selected marketplace tools, a background job kicks off — maybe rendering Helm charts or applying templates via kubectl apply.

Roughly 70 seconds later, I had a fully functional Kubernetes cluster.
And it cost me less than €40/month — for three nodes.

That’s honestly impressive!!

Could It Be Even Cheaper?

Yes — depending on your hardware choices.

If you scale up to larger nodes, costs rise quickly. But if you compare VM pricing across providers, you’ll see some room for cost optimization.

Of course, it’s not an apples-to-apples comparison.

Civo bundles in their Marketplace, pre-configured networking, and a UI that just works.
Still, if your goal is to build your own Kubernetes SaaS platform, you have to think like a product manager:
Where do you position yourself in the market? What’s your cost base? Your unique edge?

Call it pricing strategy. Or market positioning. Or as the MBAs say: Marktanalyse.

Before You Build: Understand the Landscape

Before we dive into Kamaji, GitOps, and multi-cluster orchestration, let’s make sure we understand the playing field.

Because once you know how the existing platforms work, you’ll be ready to build your own — cheaper, faster, and maybe even better.

Understanding the Different Approaches on the Market

STACKIT, Ænix, and Others

STACKIT, for example, builds its Kubernetes service (SKE) on Gardener, SAP’s open-source project for managing Kubernetes at scale.

Ænix, on the other hand, uses Kamaji as the foundation for its hybrid-cloud Kubernetes service, CozyStack.

Why does this matter? You’ll see in a moment — but first, let’s talk about the types of architectures out there.

Cluster API: Lifecycle Management for Kubernetes Clusters

The Cluster API (CAPI) is a Kubernetes-native framework for managing the lifecycle of Kubernetes clusters themselves. It’s used by providers like VMware Tanzu, Giant Swarm, Kubermatic, AWS EKS Anywhere, Syself and others.

The Approach is:

Fig. 7: Provision Infrastructure and Control Planes with Cluster API

With Cluster API, infrastructure and control planes are defined using Kubernetes CustomResourceDefintions (CRDs) and reconciled by controllers.

This allows you to provision clusters across multiple cloud providers — declaratively.

Fig. 8: Cluster API — Infrastructure Layer

This includes spinning up VMs, setting up networks, and preparing the base for installing Kubernetes (often vanilla, but AKS support is emerging too).

It works — but it’s not cheap. Users often provisions through Cluster API three separate VMs for each control plane for an HA setup.
That adds up fast, especially on public cloud infrastructure.
The tradeoff: high flexibility and portability.

Cluster API Meets Kamaji

But what if you could skip the dedicated VMs and just run Controlplanes inside pods?

Well, with Kamaji’s Cluster API provider, that’s exactly what happens.

Fig. 9: Cluster API with Kamaji Control Planes

You define your clusters like usual — but instead of spinning up VMs for control planes, Kamaji deploys them as TenantControlPlanes in your management cluster.
Each tenant acts like its own full Kubernetes control plane (API server, scheduler, controllers), but runs inside pods.

So you don’t need separate infrastructure for each control plane — they share the resources of the management cluster.

Gardener, Kamaji, k0smotron, and Kubermatic Kubernetes Platform (KKP)

All of these take a similar approach:
They decouple the control plane from the node cluster, running it centrally — often in a dedicated namespace within a management cluster.

This offers:

Better resource efficiency
Simplified operations
True multi-tenancy

Each tool has pros and cons — I covered that in another post, feel free to check it out.

But here’s how Kamaji’s model looks in practice:

Fig. 11: Kamaji TenantControlPlane Architecture

Kamaji runs TenantControlPlane resources on the management cluster.
Kubermatic calls these “seed” clusters.
In Gardener, the term is “shoot” clusters.
Same idea — slightly different branding.

These platforms leverage the Kubernetes API itself to define and manage tenant clusters via CRDs.
The cool part: you’re just scheduling pods — not spinning VMs.

Pods start faster, scale easier, and can be autoscaled with HPA or VPA — across any distro, as long as a metrics server is running.

The result? Lower cost, more agility.

What About Dedicated Control Planes?

Of course, there are closed-source solutions with dedicated control planes on VMs or own infrastructure.

These include:

They’re tightly integrated into their ecosystems, offer lots of features and add-ons (AI, IAM, managed DBs, etc.) — but you pay for it.

If your goal is a cost-efficient, scalable platform, then tools like Kamaji or Gardener may be a better fit.

Let’s dive in.

Kamaji: The Control Plane Mastermind

Kamaji also runs on top of Kubernetes — but unlike vCluster, it’s not bound to the node pools of your management cluster.
You can bring your own nodes — whether they’re edge devices, VMs on AWS or Azure, Raspberry Pis, IoT gateways, or full-blown private datacenter setups.

Fig. 12: Kamaji to rule them all — from edge to private datacenters

As you can see, Kamaji can be used in many environments. But let’s stay focused:
This blog is about SaaS Kubernetes platforms, not edge use cases (though I might write a dedicated blog for that later).

For now, we’ll concentrate on setups using cloud infrastructure and private datacenters.

Real-World Use Case: Control Plane in the Cloud, Workloads on Prem

Imagine you’re offering a SaaS managed Kubernetes service. Your management cluster runs on AKS in the US.

Your customer, however, has dedicated fiber lines from towers in Austria that feed data into their own datacenter. They want low-latency access to that data — and they don’t want their apps running halfway across the world.

Fig. 13: Control planes in the US — but worker nodes in Austria

With Kamaji, no problem. You run the TenantControlPlane in the US (inside AKS), and the customer’s worker nodes — provisioned via VMs or metal — are joined to that control plane. The workloads run in Austria, close to the data.

That’s not just cool — it’s cost-effective and customer-centric.

Requirement for SaaS: Kamaji on Hetzner

Say a customer is looking for a cheaper Kubernetes solution than the major clouds, and already has infrastructure on Hetzner.

Fig. 14: Spin up Kamaji Control Planes on Hetzner — just on demand!

You run a management cluster on Hetzner. Kamaji is installed and managing several tenants already. Each project has its own set of dedicated worker nodes.

Now simulate a user creating a new cluster via your UI.

Fig. 15: User launches a new cluster — what happens behind the scenes

The user picks a Kubernetes version and configures node count. On “Launch,” a TenantControlPlane CR is created. Kamaji generates a join token.
A node pool is provisioned (e.g. via APIs from Proxmox, vSphere, Azure, etc.).
kubeadm join runs (e.g. via cloud-init), and nodes are attached to the control plane.

That’s it — your user now has a custom Kubernetes cluster running across two infrastructures, seamlessly.

Why This Matters

Let’s say your managed Kubernetes platform runs in Germany. Your customer, however, wants their applications hosted in Austria — but your cloud provider doesn’t have a datacenter there.

With Kamaji, you don’t need to switch vendors — just use the customer’s infrastructure (if they expose a virtualization API), spin VMs, and join them to a control plane hosted elsewhere.

Latency between control plane and nodes may exist — but latency to the application users is near zero.

This flexibility is what makes Kamaji so powerful for SaaS providers.

Inspired by Anime, Driven by Engineering

What is Kamaji, really?

The name comes from the anime Spirited Away by Studio Ghibli. Kamaji (釜爺, “Boiler Grandpa”) is the silent hero in the boiler room — keeping the whole bathhouse running with six arms and no complaints.

Fig. 17: Kamaji logo — spot the resemblance?

In spirit and in architecture, Kamaji represents dedication, reliability, and tireless automation.

Developed by Clastix (the creators of Capsule, now part of CNCF Sandbox), Kamaji is an open source Operator that provisions and manages Kubernetes control planes as code — and makes it effortless.

How Kamaji Works

When you install Kamaji, you get two CRD-based APIs:

TenantControlPlane – defines your Kubernetes control plane
Datastore – backend used by one or more control planes

Each TenantControlPlane is namespace-scoped and allows deep config control — from Kubernetes version to pod resource limits, tolerations, network exposure (LB, ClusterIP, NodePort), and more.

Why Kamaji Is Powerful for SaaS

Here’s what makes Kamaji a strong contender for building your Kubernetes platform:

Fast provisioning: Control planes ready in ~16 seconds
Quick upgrades: Blue/Green rollouts in ~10 seconds
Resource savings: No need for 3-node etcd clusters → up to 60% infra saved
Autoscaling: Scale up or down like any other pod
Full declarative model: Drift detection + constant reconciliation
Certificate automation: kubeadm + full auto-rotation
Core add-on management: CoreDNS, kube-proxy, konnectivity — all included
Self-healing: If something breaks or gets deleted, Kamaji rebuilds it
Datastore multi-tenancy: Multiple control planes per datastore
etcd not required: Use Kine for MySQL, PostgreSQL, or even NATS
Cross-network compatibility: Konnectivity handles NAT & private IPs

So yes — you can run your control plane on Cloud X and your nodes on Cloud Y.
That matters when you’re building a SaaS solution for global customers. It enables true multi-tenancy: skip in-cluster access to the TenantControlPlane and simply use its external URL:6443 — just as you would with a dedicated cluster.

You’re no longer locked into any one provider.
You decide where things run — based on price, performance, or proximity.

Fig. 18: Kamaji Adopters — OVHCloud, Ænix, NVIDIA, and more

Now that you understand the pieces —
It’s time to start putting the puzzle together.

How Does GitOps Fit In? Let’s Bring the Puzzle Together

Because Kamaji is declarative and built on CRDs, it’s a natural fit for GitOps.
It integrates perfectly into any Kubernetes platform that manages infrastructure and services as code — at scale.

Let’s say you already have a platform with Argo CD and a curated Helm chart catalog. Here’s how you wire in Kamaji:

Add Kamaji’s Helm chart to your catalog.
Use Argo CD with the App of Apps pattern.
When a user launches a new cluster, an event triggers creation of a templated Argo CD app.
That app contains the TenantControlPlane CR, which gets committed and pushed.
Argo CD reconciles the repo → deploys the control plane via Kamaji.

Everything that goes into the cluster through GitOps can also be removed the same way — clean, repeatable, reliable.

Fig. 19: GitOps in action — Argo CD and Kamaji working together

Here’s a high-level workflow:

A user defines a TenantControlPlane (TCP) CR.
Argo CD watches the apps/ directory using the App of Apps pattern.
It picks up the new CR and applies it to the management cluster. Kamaji reconciles the resource and spins up the required components (Deployment, Secrets, Ingress, etc.).

The actual control plane components — kube-apiserver, scheduler, controller-manager, konnectivity-server — all run inside a single pod.

No separate etcd is needed. Kamaji handles that for you — either through its shared etcd or by using Kine, which supports MySQL, PostgreSQL, or even NATS.

Your directory structure might look like this:

managed-kubernetes-service-catalog
├── argo-cd
├── cert-manager
├── external-dns
├── external-secrets
├── ingress-nginx
├── kamaji
└── vcluster

apps
└── kamaji-1.yaml

And your Helm chart for Kamaji might start like this:

apiVersion: v2
name: kamaji
version: 1.0.0
description: This Chart deploys kamaji-system.
dependencies:
  - name: kamaji
    version: 1.0.0
    repository: https://clastix.github.io/charts

I deploy Kamaji’s controller using Argo CD ApplicationSets.

Then you generate individual TenantControlPlane manifests from templates — one per tenant.

apiVersion: kamaji.clastix.io/v1alpha1
kind: TenantControlPlane
metadata:
  name: k8s-130-1
  namespace: kamaji-1
  labels:
    tenant.clastix.io: k8s-130-1
spec:
  addons:
    konnectivity:
      server:
        port: 8132
      agent:
        extraArgs:
          - --proxy-server-host=kamaji-1-k8s-130-1.konnectivity.xyxy.stackit.run
          - --proxy-server-port=443
  controlPlane:
    service:
      serviceType: ClusterIP
    ingress:
      hostname: kamaji-1-k8s-130-1.k8s.xyxy.stackit.run:443
      ingressClassName: nginx
      additionalMetadata:
        annotations:
          nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
          nginx.ingress.kubernetes.io/ssl-passthrough: "true"
          nginx.ingress.kubernetes.io/ssl-redirect: "true"
          cert-manager.io/cluster-issuer: letsencrypt-prod
    deployment:
      replicas: 1
      extraArgs:
        apiServer:
          - --endpoint-reconciler-type=none
  kubernetes:
    version: "v1.30.2"
    kubelet:
      cgroupfs: systemd
  networkProfile:
    certSANs:
      - kamaji-1-k8s-130-1.k8s.xyxy.stackit.run
      - kamaji-1-k8s-130-1.konnectivity.xyxy.stackit.run
    dnsServiceIPs:
      - 10.96.0.10
    podCidr: 10.244.0.0/16
    port: 6443
    serviceCidr: 10.96.0.0/16

This gets committed into the apps/ folder. Argo CD picks it up and deploys it.

Fig. 20: Argo CD did the heavy lifting for us

To simplify things, this example uses a flat App of Apps setup. In practice, you might nest the tenant apps or generate them dynamically.

Once your TenantControlPlane is deployed, you can verify it like this:

kubectl get secret k8s-130-1-admin-kubeconfig -ojsonpath='{.data.admin\.conf}' | base64 -d > tcp-1.yaml


kubectl get ns --kubeconfig tcp-1.yaml

NAME              STATUS   AGE
default           Active   7m35s
kube-node-lease   Active   7m35s
kube-public       Active   7m35s
kube-system       Active   7m35s

At this point, all that’s left is node provisioning — but that’s out of scope here.

This blog isn’t a ready-made solution — it’s a blueprint to help you build your own.

Fig. 21: The big picture — from “Launch K8s” to nodes joining

If terms like GitOps, ApplicationSets, or App of Apps feel unfamiliar, I recommend checking out some earlier posts or the walkthrough videos linked below.

Bonus Round: Add Sveltos for Event-Driven Fleet Automation

Want to take it even further?

Try layering in Sveltos for fleet-wide event-driven operations.
You can use it to:

Auto-provision databases on the management or dedicated service cluster
Inject credentials into tenant clusters
Keep everything synced and rotated

Yes — seriously.

Fig. 22: Don’t believe it? Just check it out

Fig. 23: Create databases on-demand with Sveltos

Sveltos runs on the same management cluster as Kamaji, and reacts to events from tenant clusters.
It’s like a CI/CD brain — but for infrastructure automation.

If you’re curious, we’ve already built and demoed this — check out the linked blog post for all the juicy details.

Fig. 24: Now it’s your turn — build it, share it, and inspire others

I hope you’re now inspired, informed, and excited to take the next step.
The tools are out there. The architecture is proven.
Now it’s up to you to put it together.

And who knows — maybe your implementation ends up on the next Kamaji adopters list.

Wrap-Up: Build Your Own Kubernetes based SaaS Platform

By now, you should have a clear picture of how to build your own on-demand, cost-efficient, Kubernetes-based SaaS solution — using open source tools that scale, adapt, and actually work.

Combine Kamaji with Argo CD, and you get full GitOps lifecycle automation. Add Sveltos, and you unlock event-driven fleet management, dynamic add-on delivery (like PostgreSQL), and smooth cross-cluster integrations.

Simple building blocks — powerful outcome.

So, good luck building your own Kubernetes SaaS platform.
Who knows — maybe I’ll try it out one day.

Don’t forget to clap 👏 if you like content like this — it helps others find it too.

If you’re interested in topics like developer platforms, GitOps, and abstraction layers that don’t suck, definitely check out:

Still unsure about multi-tenancy — what counts as “soft,” what doesn’t, and how Kamaji differs from vCluster or Sveltos? Watch Daniele Polencic video — he’s the expert on it.

Video 0: Understanding Kubernetes Multi-Tenancy: Models, Challenges, and Solutions

Contact Information

Got questions, want to chat, or just keen to stay connected? Skip the Medium comments and let’s connect on LinkedIn 🤙. Don’t forget to subscribe to the Medium Newsletter so you never miss an update!

ITNEXT