Self-hosted

LakehouseBox, in your own infrastructure

Run the same catalog, storage and agent interfaces on your own servers or cloud, air-gapped if you need it. Keep your data in your environment while your team and your AI agents get one open data layer.

Ask about self-hosting Compare managed vs self-hosted

Same containers as managed
Open and portable
Air-gapped if you need it

What you bring in

Parquet & CSV files
Devices & scripts
Your pipelines
Any Iceberg engine

Your infrastructureAny Linux host with Docker: your cloud, your servers, or an air-gapped network

LakehouseBox

CatalogIceberg REST, grants, table maintenance
StorageS3-compatible store on your disk
MCPAgent interfaces (MCP, REST API)
AdminAccounts, permissions, quotas

Analytics & agents

DuckDBQuery data
AI agentsVia MCP or the CLI
Spark, PyIcebergRead and write
Your applicationsUse the open APIs

Managed or self-hosted?

The same core product. Choose who operates it and where it runs.

Dimension	Managed (LakehouseBox)	Self-hosted (your infrastructure)
Control	Lakehousebox, S.L. operates and maintains the service	Full control of the host, the configuration and the data
Operations	No infrastructure to manage	You deploy and operate it with Docker Compose
Updates	Every merged change deploys itself	You choose when to upgrade, with the script that installed it
Storage location	Frankfurt, Germany, with a replicated copy in Stockholm, Sweden (EU)	Wherever you run it: your cloud, your own servers, or a network with no internet access
Internet access	Reached over the internet at lakehousebox.com	Not required: no call home, no licence server; images loaded without a registry, certificates from your own authority (we set this up with you)
Backups	The catalog's state every 5 minutes, encrypted; the data in storage replicated from Frankfurt, Germany, to Stockholm, Sweden	The same scripts and timers, to an S3-compatible store of your choice
Identity	Sign in on the account page; the CLI connects with a link you approve	Built-in email + password, or your OpenID Connect issuer (Okta, Entra, Keycloak, Authentik)
Price	Free: 5 GB stored, no card. Paid storage not open yet (announced at €0.10 per GB-month above the free 5 GB)	Your infrastructure cost; software licence to be decided
Support	Email, first answer within 2 business days; Enterprise within 1 (support and uptime)	Email; terms being decided

What runs where

LakehouseBox is a few containers you run in your own environment, with one state directory, /data.

Catalog

The Iceberg REST catalog: tables, snapshots, per-table credential vending and the maintenance that keeps tables healthy.

Iceberg REST

Storage

An S3-compatible object store on the data disk, in the same container as the catalog. Any disk works.

S3 API · disk at /data

Access (MCP & APIs)

The control plane's REST API and the remote MCP server for your tools and agents, behind a TLS gateway.

MCP server + REST API

Ops & Admin

Accounts, organisations, grants and quotas, with the account page in the browser and the backup timers.

Account page + API

The containers, one by one

Component	Image	Role
store init	LakehouseBox	One-shot init job: generates the store's admin key pair and STS signing key on the data volume, then exits before the store starts
store	LakehouseBox (our build)	Object store, Iceberg REST catalog, IAM and STS, credential vending, table maintenance
control-plane	LakehouseBox	The API: accounts, email + password login (or your OpenID Connect issuer via `AL_OIDC_ISSUERS`), organisations, catalogs, connection recipes, quotas
mcp	LakehouseBox	The remote MCP server on `mcp.`; forwards the caller's token to the control plane
sink-roller	LakehouseBox	The ingest sink's roller: appends due batches to sink tables; idle unless `AL_SINKS_ENABLED` is on
gateway	Caddy	TLS on `api.`, `catalog.`, `s3.`, `*.s3.`, `mcp.`

Every hostname comes from .env; nothing in the containers calls a cloud API or needs one provider's service. Account mail goes out through any SMTP sender (AL_SMTP_*); placement is whatever you set (AL_PROVIDER, AL_REGION).

Deploy with Docker

One host with Docker Compose. There is no Kubernetes package yet.

A release is one directory, lakehousebox-<version>/: the images the managed service runs, the source of the same commit, an SBOM for each image and a signed list of checksums. It installs on one host with no download. Four steps, and a test you can run:

Verify. The bundle's verify.sh checks our signature, every checksum and every SBOM, with our key's fingerprint as you got it from us. Nothing is fetched.
Load. scripts/selfhost_load.sh, from the bundle's own source, verifies it again, loads the images and checks each one against the release's lock file.
Configuration. scripts/selfhost_init.sh --domain writes the .env with secrets generated on the host, gives the hostnames and creates /data; --tls picks Let's Encrypt, your own certificate or an internal authority.
Start. ./al up && ./al bootstrap on the host.
Acceptance. scripts/test.sh phase1 against your hostnames is the suite we run against ours.

Linux host: Docker with Compose, and a data disk mounted at /data. Any disk works.
Air-gapped: load the images with docker load, use certificates from your own authority, and leave the mail sender and external sign-in out. We set this up with you.
Domain: records for api., catalog., s3., mcp. and a wildcard *.s3.. Certificates come from Let's Encrypt through the gateway.
Mail sender: any SMTP account, for set-password links, sign-in codes and invitations. Without one they are read from the control plane's log.
Identity: the built-in email + password login, or your OpenID Connect issuer via AL_OIDC_ISSUERS.

deploy steps

# 1 · verify the release: signature, checksums, SBOMs; nothing is fetched
bash lakehousebox-<version>/verify.sh --fingerprint <our key's fingerprint>
 
# 2 · load the images, from platform/ of the bundle's own source
tar -xzf lakehousebox-<version>/source.tar.gz && cd platform
bash scripts/selfhost_load.sh ../lakehousebox-<version>
 
# 3 · configuration: hostnames from your domain, secrets made on the host
bash scripts/selfhost_init.sh --domain lake.example.com
 
# 4 · start
./al up && ./al bootstrap
 
# 5 · the acceptance test, against your hostnames
set -a; . ./.env; set +a; D=lake.example.com
CP=https://api.$D CP_INTERNAL=http://127.0.0.1:8000 GW=https://api.$D \
  CATALOG=https://catalog.$D CATALOG_IN=https://catalog.$D HOST_CATALOG=https://catalog.$D \
  S3_IN=https://s3.$D HOST_S3=https://s3.$D LHBOX_URL=https://api.$D \
  AL_CLEANUP=1 bash scripts/test.sh phase1

Upgrades and backups

The same images, the same scripts, a backup first.

A self-hosted LakehouseBox runs the images the managed service runs; a new release goes in with scripts/selfhost_upgrade.sh, which verifies it with the key you already trust, keeps a rollback point and puts the previous release back if the new one does not come up. On your own install the backups are yours to run, and off until you name a bucket: the stack's own scheduler then copies the control-plane state every 5 minutes and the store's metadata and data files hourly, encrypted to your key, to an S3-compatible store of your choice, and deploy/backup_incremental.py rebuilds a host's directories from those copies. A restore drill from a real S3 bucket matched every store file byte for byte. Details, including what each script guarantees on a single host: ask us.

Recovery point of a self-hosted install with backups on: minutes for accounts and grants, about an hour for table metadata and data files. The hourly copy runs more often with one setting, AL_JOB_BACKUP_INC_EVERY. Both deployments hold Apache Iceberg tables in open formats: your tables leave with you either way.

Next.

Talk to us Or start on the managed service

The managed service: 5 GB free, no card.