Run the whole graph
on your own machines.
iLiveMyLife runs on our own Kubernetes, on our own servers — not a managed cloud we rent. Everything that keeps it alive is a command: bring a cluster up, deploy every service, keep a live standby in a second cluster, back up and restore, move the domain over. The same tooling stands up a copy inside your perimeter, on your domain, under your rules.
The platform, inside your perimeter.
The whole platform, in your cluster
Every service behind the graph — the API, node messengers, history, contracts, notifications, payments — deployed into a Kubernetes cluster you own. Your hardware, your network, your access policy.
A live standby next door
A second production cluster kept in step with the first: manifests, data, or both. When the primary has to go down, the domain moves to the standby with one command.
Your domain, your certificates
Ingress and TLS are part of the install, with certificates issued automatically for your domain. People and partner sites see your address, not ours.
Backups you restore yourself
Backups of the event store on demand, and a restore that takes a date. Getting yesterday back is a rehearsed command, not a ticket to a vendor.
Not one cluster. A fleet of them.
Clusters are named roles in one config file — a sandbox, pre-production, production, a realtime standby and a realtime disaster-recovery copy — each with its own protection level. The public address follows whichever one should be serving right now.
devThe sandboxno confirmations — break it freelystagingPre-productiontest before it is realprodProductionevery change confirmedprod2Realtime standbytakes over on a DNS switchdrDisaster recoverya realtime copy of prod
Moving the public address to the standby is one command: infra prod2 dns update. When two clusters need to be brought level, sync copies the manifests, the data, or both from one to the other.
From an empty server to a release.
One entry point — infra <cluster> <action> [target] — for the whole life of a cluster. Every action is a script you can read; nothing depends on a console someone has to click through.
Your own runbooks become commands. Your team has procedures of its own — a backup to your storage, a compliance check, a step your auditors ask for. Write it as a script, and it runs as infra prod <your-action>: the same cluster names, and every run — started, succeeded, failed — in the same audit log as everything else. Each one runs on its own, so a broken script fails only itself, never the tool.
Safe by default, not by good intentions.
Production asks first
Every cluster carries a protection level. Production stops and asks before anything changes, and deleting there means typing the cluster's name, not pressing y. The sandbox never asks, so experiments stay cheap.
A deploy is read before it runs
plan writes the exact deploy — concrete versions, an explicit service list — into a script. You read it, commit it, and only then run it.
Builds come from the repository, not a laptop
Images are built from a clean checkout of the commit that was pushed. Whatever is lying uncommitted in someone's working copy cannot end up in production.
Sync will not overwrite the wrong cluster
Copying data into a cluster that is not marked as a replica stops and asks. Pointing production's data at production by mistake takes a deliberate yes.
Everything is on the record
Every action lands in an audit log — infra audit shows who ran what, on which cluster, and when.
Not a monolith with a database behind it.
An event-sourced core
Every change to a node is an event, and the current state is built from them — so history is not an add-on, it is how the data is stored. How that works →
Kafka, CDC and read models
Every write is an event in the event store; change-data-capture streams it into Kafka, and dedicated view services build the read models from there. About thirty services, each small, each deployable on its own.
Plain Kubernetes underneath
Ordinary manifests, no proprietary operator. The event store, the read models, the cache and Kafka all run inside the cluster; ingress-nginx and cert-manager handle the edge.
Delivered with us, not downloaded. The images live in our private registry and the tooling is not a public package — yet. A self-hosted install is a project we run together with your team: we stand the clusters up inside your perimeter, hand over the runbook and the CLI, and stay on call while you take it over.
Your cluster — and every tool that talks to it.
The packages your developers would use against our cloud work against your install the same way. They are public on npm; point them at your address, and nothing else in their code changes.
SDK
Scripts and services read and write your graph, subscribe to its changes and ask Lifebot — typed, in TypeScript or plain JavaScript.
CLI and plugins
The ilml command line for people and scripts, and every plugin built on it, run against your install the same way.
MCP
Claude, Cursor and other AI tools work inside your graph through the same MCP server — pointed at your address, not ours.
React
The chat widgets and the shared sign-in, on your own internal sites: one account across all of them, issued by your install.
Straight answers.
Which Kubernetes does it need?
The one you choose: a managed cluster from your cloud provider, or your own servers. The platform's services are ordinary Kubernetes objects — Deployments, StatefulSets, Services, Ingress — with no proprietary operator. The parts that depend on the platform underneath, like preparing the nodes and handing out external addresses, are fitted to yours during the install, so a cluster you already operate is a conversation about details, not a rewrite.
Does any data leave our network?
The platform's data stays in your cluster. The one part that calls out is the AI: Lifebot uses an external language model. It already works with several providers, including over the OpenAI-compatible protocol that most self-hosted models are served with — which model you use is something we scope together.
Can we run more than one copy?
Yes — that is how we run it ourselves: a sandbox, pre-production, production, a realtime standby and a realtime disaster-recovery copy, each a named entry in one config file with its own protection level. Manifests and data sync between them, and the domain moves to another cluster with one command.
Can it run on our own domain?
Yes. Your domain points at your cluster, and TLS certificates for it are issued automatically. Moving the domain from one cluster to another is a single command, set up for your DNS provider during the install.
Is this something we can download?
Not yet. The images live in our private registry and the tooling is not published as a package. Today a self-hosted install is a project we run together with your team; whether it becomes a package depends on who needs it — tell us if you do.
Who is this for?
Teams that cannot put their knowledge into someone else's cloud: regulated industries, contractors working under NDA, companies with data-residency rules — and anyone who simply wants their graph on hardware they control.
Your graph. Your cluster.
Tell us about your infrastructure and your constraints — we will tell you what a self-hosted install looks like for you.
