Self-hosting Loams with GitOps

Proposal The deployment design in this post is under review, and Self-hosting with GitOps is still Planned in Loams 0.1.0. What 0.1.0 ships instead is a Docker Compose stack (deploy/release/compose.yaml) that you run on a laptop or on your own VMs (BYOC over SSH with byoc/install.sh), reachable only over your own Tailscale tailnet, with the hosted console at console.loams.dev. Running Loams 0.1.0 has the steps. The open-source boundary at the end has changed since this post; see below.

A platform that lives in your bucket should also be deployable in your cluster, by you, without calling us. The goal is one deployment path: the same Git repository and charts deploy a laptop k3d cluster, a self-hosted cluster on your own hardware, and a multi-tenant BYOC deployment.

The piecesCopy Anchor Link

The Loams operatorCopy Anchor Link

The proposal forks Clever Cloud's Kubernetes operator (MIT, Rust, kube-rs) as the skeleton of a Loams operator, keeping its MIT notice. What carries over is modest and we say so: a controller registry, finalizers, event recording, a metrics server and a hardened Helm chart, about 1,300 lines. Its own custom resources provision Clever Cloud add-ons through Clever's API, so they are dropped. The operator adds four resources:

Object stores sit behind a provider trait that reports capabilities, and Loams refuses a provider without conditional writes, because the write-ahead log's commit protocol depends on them.

We also evaluated Clever Cloud's edge proxy, Sōzu. It is well engineered and reconfigures without restarts, but it is AGPL-3.0 and, as far as its documentation shows, has neither HTTP/3 nor gRPC routes, both of which the runtime needs. Envoy stayed the edge at the time; D1010 later replaced it with loams-gateway. The same evaluation proposes Biscuit (Apache-2.0, now at the Eclipse Foundation, started at Clever Cloud) for sandbox tokens inside the runtime (part 5).

Sync wavesCopy Anchor Link

Argo CD would apply an app-of-apps in waves. Each wave waits for the previous one to be healthy, which needs custom health checks for the child Application resources (Argo CD has none built in), the TiDB Operator's resources and Loams’ own.

deploy/
  helm/loams-stack/          # umbrella chart; every component can be switched off
  gitops/
    bootstrap/argocd/       # Argo CD and its health checks
    root.yaml               # the app-of-apps
    apps/                   # one Application per wave
    envs/{dev-k3d,selfhosted,cloud}/values.yaml

The costs, plainly: Argo CD is heavier than Flux (an application controller, a repo server, Redis and a server), which matters on a laptop and in small clusters, and TiDB Operator v2's resources are still v1alpha1, so each Loams release pins an operator version. A local k3d profile runs one replica of everything; PD, TiKV and TiDB together peaked at about 3.2 GB of memory in our development playground.

What stays true without KubernetesCopy Anchor Link

The engine is still one binary. loams dev runs every role in one process with the openraft metastore and a local directory or any S3 bucket, and needs no TiKV; since this post, Loams Live there runs on an embedded store too. TiKV becomes necessary for Loams Live in clusters, for Loams SQL, for jobs and for clusters that use the TiKV metastore. The 0.1.0 compose stack runs PD, TiKV and TiDB for you, and loams upgrade moves it from one release to the next with a snapshot first.

Open source and the managed cloud (superseded)Copy Anchor Link

Update: D540 (2026-10-02) moved the multi-tenant BYOC control plane (orgs, namespaces, isolation, quota enforcement, GitOps with Argo CD, BYOC install) into the open repository under Apache-2.0. Then, on 2026-10-19, D1119 removed the open core altogether: turning usage into charges and the commercial APIs are open source too, and nothing is proprietary. For 0.1.0 we host only the console and, for oidc mode, the auth service. The table below is the September line, kept for the record.

The line was one rule: anything needed to self-host Loams as a single organisation is open source, under Apache-2.0. Anything needed only to run Loams as a multi-tenant paid cloud is part of the managed Loams Cloud. The open repository must never depend on the managed cloud; the cloud consumes the same hooks and APIs any self-hoster can use.

Quotas show the split well: the engine enforces whatever limits it is given; the managed cloud decides what those limits are for each plan. And we do not hold back reliability or performance features from open source. The hot tier is in the open engine today, and the planned replicated write-ahead log will be too, not behind a license key. Since D1119 there is nothing left to hold back: SSO, SCIM and the managed cloud's own code are open source as well.

Where this standsCopy Anchor Link

That is the end of the platform series. The other series on this blog, What Loams is built on, takes each open-source project under Loams in turn: what it is, how it works inside, why we chose it, exactly how we use it, its license and its current limits.