Requirements
- A Kubernetes cluster running 1.26 or later;
- Helm 3.8 or later (OCI registry support is required to pull the charts from GHCR); and
- A PostgreSQL database and a Redis instance the cluster can reach. The charts deploy neither — see managed dependencies below.
Choose your chart version
Two chart lines are published, and they are not interchangeable.
Installing without a
--version flag gives you the latest 2.x release.
Install
Add the chart repository:Minimum values
At a minimum Lago needs its public URLs, a database, a Redis instance, and its encryption and signing secrets:charts/lago/examples/
in the chart repository.
What a default install deploys
With no optional components enabled, the chart creates four Deployments and a migration Job:
That is deliberately the smallest useful deployment. Everything below is opt-in.
Scale workers by queue
The 1.x chart ran one Sidekiq worker for everything. In 2.x each queue can be split into its own Deployment, so a slow billing run cannot starve webhook delivery, and each queue is sized and scaled on its own. Every queue isfalse by default, which leaves its jobs with the catch-all
lago-worker. Enabling one moves that queue’s jobs to a dedicated Deployment:
Optional components
PDF generation
Invoice rendering runs as its own subchart, bundling Gotenberg and its worker:Streaming ingestion
High-volume event ingestion through Kafka and ClickHouse is off by default. Enabling it adds the events consumer and the events processor, and requires connection details for both backends:Managed dependencies
The charts do not deploy PostgreSQL, Redis, or object storage. Point Lago at managed services, or at instances you run separately — the compatibility matrix lists the supported versions. For file storage, configure S3 (or any S3-compatible endpoint) underglobal.s3. The chart provisions no local volume, so without object storage
configured, generated files live only in the container filesystem and are lost
when a pod restarts.
Coming from chart v1
There is no supported in-place upgrade. Treat it as a fresh install against the same database:1
Keep your 1.x release running
Do not uninstall it yet. Your data is in PostgreSQL, not in the release.
2
Translate your values
The schema changed. Most 1.x keys have a 2.x equivalent under
global, and
per-component settings moved under the subchart key they belong to. Nothing
carries over automatically.3
Install 2.x as a separate release
Point it at your existing PostgreSQL and Redis. The migration Job brings the
schema up to date on first start.
4
Cut traffic over, then remove the old release
Verify the new release serves correctly, move your ingress or DNS, and only
then
helm uninstall the 1.x release.Run this against a copy of your database first if you can. The migration Job
applies schema changes that the 1.x release will not expect, so the two
versions cannot safely share a database for long.
Staying on 1.x
1.x remains available and keeps receiving fixes on thev1 branch. Pin the
version and nothing changes for you:
Values reference
Every chart carries a generatedREADME.md documenting its values. Start with
the umbrella chart,
then follow into the subchart that owns the component you are configuring.