Know what is running.
And what should be.
Lembos is an internal developer platform built on versioned building blocks. It records the software you have and the shape it should take in every environment, observes what is actually there, and closes the gap between the two.
The Portal, showing the catalog of a sample retailer the platform seeds in development.
What it is
Not only a portal. Not only a catalog.
Lembos is the system that controls how software is deployed, configured and governed. A portal is how people reach it, and a catalog is part of what it knows — neither is the thing itself.
A catalog says
this component exists, and this team owns it.
A pipeline says
this ran, and it exited zero.
Lembos says
this is what should be running here, this is what is, and here is what closes the difference.
One component, different everywhere it runs. The catalog says what a component is; each environment records which version of it is running there. So staging can run a version ahead of production, one region can stay on an older build, and every one of those answers is true at once.
The idea underneath
Everything is versioned, so nothing changes under you
Blueprints, configuration, API contracts, policies and environments are each published as versions. A deployment pins a version, and a published version never changes — so what you deployed is exactly what you can deploy again.
- Reproducibility
- A published version cannot change under anything that uses it, so repeating a deployment a month later produces the same result.
- Divergence on purpose
- Staging a version ahead, a canary slot on a newer build, a region on an older blueprint — differences between environments are deliberate, and you can see every one of them.
- One question, one answer
- “Which version is in effect here?” is asked and answered the same way for a blueprint, a configuration, an API contract or a policy.
Convergence
Lembos converges rather than merely deploys
Recording current state alone answers “what is running” but not “is that what we asked for” — which is precisely the question when a configuration was published and never deployed, a rollout half-completed, or someone edited a cluster by hand.
Desired state
What was declared and published
- artifact
- cart-service@sha256:9f2c…
- blueprint
- helm-web-service 2.4.0
- config
- revision 17
- replicas
- 6
Observed state
What the execution target reports
- artifact
- cart-service@sha256:9f2c…
- blueprint
- helm-web-service 2.2.0
- config
- revision 15
- replicas
- 6
For everything it delivers, Lembos records both what should be running and what is. The difference between the two is drift, and closing it is the work. Automated deployment is one way to close it. Reconciliation, rollback and progressive rollout are others.
In the Portal
Three areas, one for each kind of work
Everything in Lembos is owned by a team and visible to the people who need it. Product teams describe and ship their software, platform teams publish the paths they ship on, and administrators decide who is involved.
Workspace
For product teams
What software do we have, who owns it, and how does it ship?
Platform
For platform, security and operations teams
How is it built, where does it run, and what is allowed?
Organization
For administrators
Who is involved, and what may each of them do?
A tour of each area
What every page is for and who uses it, with screenshots — from describing your software to shipping it.
Every component knows what it is
A component names the blueprint it is built from, so Lembos knows how to build, configure and deploy it — not just what it is called. What it provides, consumes and depends on is drawn as a graph, so you can see what a change might touch before you make it.
Capabilities
What the platform carries
Built in from the start, rather than integrations sitting beside it.
Software catalog
Business areas, capabilities, systems, components, APIs and resources — with owners and dependencies, so you know what you have and who to ask.
Configuration that ships with the code
A component's settings are part of its versioned spec, so a release pins them and a rollback takes them back. Values layer common → environment → slot, and secrets stay in your vault — Lembos holds only where to find them.
Golden paths
Blueprints pin the tool, its version and where the recipe lives, and are offered only once Lembos has fetched them — a recipe that cannot be retrieved never reaches a team.
Environments and slots
Split an environment by country for data residency or by region for latency, and let each workload say which slots it needs. Review environments carry a lease and expire on their own.
Progressive delivery
Traffic weights, analysis windows and abort thresholds live in the blueprint. A promotion can name specific slots, so a regional rollout is a series of steps with a look in between.
Rollback as its own step
Rolling back is recorded differently from deploying an old version, so policies can treat it differently — a rollback often has to skip gates a new release must pass.
Release history
A release freezes its contents when it is ready and records every promotion, so “in which environments was this version tested before production?” has an answer.
Policy you can look back on
Every policy decision remembers the exact policy version that made it, so a later edit cannot change what was enforced. Policies are checked before work starts, not audited after.
A complete audit trail
Every change, by a person or by a machine, is recorded — whether or not anything else reacts to it. Nobody has to remember to turn it on.
Guardrails
Access control is three layers, not one
Each answers a different question, and folding them into one mechanism fails whichever one is chosen. Roles alone cannot express “production is restricted to a few people while anyone may create a dev environment”.
- 01
Permission
May this person or machine do this kind of thing?
Roles grant permissions, so “who may deploy?” is answered by a list rather than an investigation.
- 02
Ownership
Do they reach this particular thing?
Group membership, inherited down the hierarchy, so a member of a parent group reaches what its children own.
- 03
Policy
Is this particular change allowed right now?
Policies check the facts of the change at the moment it is asked for, and record which version decided.
And work only goes where it can run
Clusters and cloud accounts say what they can do, and each piece of work goes only where it can run. Adding a new kind of runtime means registering it, not rewriting how deployment works.
platform/aws-production
eligiblehardened-runtimebackup-enabledpci-dssplatform/aws-nonproduction
not eligibleno capabilities declared
How it is used
Three people, one system of record
Lembos is adopted by a whole engineering organisation rather than by one team, because the three questions below are usually answered by three different systems that disagree with each other.
A developer
“I need this service running in staging.”
Describes the component on a blueprint and picks where it should run. Lembos works out its settings, checks the policies and starts the deployment.
Because The blueprint already carries the chart, the traffic weights and the dashboards — none of the runtime has to be learned to use it.
A platform engineer
“I need to change how every service is deployed.”
Publishes a new blueprint version. Nothing on the old one moves until its owner moves it, and where each version is still in use stays visible.
Because Published versions never change, so the golden path can move forward without every team migrating on the same day.
Security and compliance
“Show me what was running in production in March.”
Reads the release, the promotions that carried it, and the policy version that was checked at the time.
Because Every change is recorded, and every policy decision remembers the exact version of the policy it applied.
What that looks like in practice
A review environment that cleans itself up
Ephemeral environments carry a lease, so a pull-request environment expires on its own instead of running up a bill until someone notices.
A payment provider that differs per country
An override on that country's slot — not a fork of the component, and not a copy of the environment. The most specific setting wins and the rest is shared.
A regulated workload that cannot land anywhere
The component requires a capability, and only the clusters or accounts that declare it can take it. Policy is checked before anything runs, not audited after.
Germany before France, with a look in between
A promotion names the slots it goes to, so a regional rollout is a series of promotions with a person able to check between them.
What you operate
A platform you run yourself
There is no hosted Lembos. It runs in a Kubernetes cluster you operate, and builds into the cloud accounts and clusters you already own.
A Kubernetes cluster
Lembos installs into it with one Helm chart
Your clouds and clusters
Where it builds and deploys
Your sign-in
Invitations, or your GitHub organisation
Your vault
Secrets stay where they are
Its own data stores
PostgreSQL, Redis and Temporal — or yours
One Helm chart installs it, makes every secret and key it needs, and runs simply or highly available. The install guide covers it, and the quickstart runs it on a laptop.
See it for yourself
The quickstart puts a complete Lembos on a local Kubernetes in about fifteen minutes — with a sample organisation to explore, if you want one.
Questions, or interested in contributing? [email protected]