LakehouseBox — Security overview

Version: 30 October 2026
A factual description of the Service as deployed on this date. Not a contract; the contractual measures are Annex II of the Data Processing Agreement. Questions and vulnerability reports: hello@lakehousebox.com.

What LakehouseBox is

A managed Apache Iceberg lakehouse: the Iceberg REST catalog and the S3-compatible object store are one system, run by us in Frankfurt, Germany. Your data is Iceberg tables and plain objects in open formats; you can take it elsewhere with standard tools at any time.

Where it runs, and who operates it

Since 28 October 2026 the Service (the store, the catalog, the API, the control plane and the MCP server) runs in Frankfurt, Germany, as one container, with storage in Frankfurt replicated to a full second copy in Stockholm, Sweden, for the data and for the backups; the query service, scheduled SQL, hosted agents and the file drop box run in Germany too. The servers, copies and backups used before that day are deleted. The infrastructure is operated for us by sub-processors in the European Union, each named in the privacy policy and the data processing agreement (Annex III). Transactional email is sent through Scaleway SAS in Paris, whose language models hosted agents use. The public website pages are delivered through a content delivery network in front of lakehousebox.com and www., which also distributes, worldwide, the files of catalogs a customer chooses to publish openly (removed from the edge when the catalog is made private or deleted, by a purge that usually completes within a few minutes; a file removed from a catalog that stays public can stay cached for up to a year), and, worldwide too, the files a private catalog's readers read when its owner turns edge caching on for it (cached until the end of the day (UTC) at most); the API, the catalog, and every file of a private catalog without edge caching are reached directly. Our own company mailboxes are at Infomaniak in Switzerland (adequacy decision). No US-controlled company operates any part of the Service or holds your data, and no managed service from a US provider sits in the data path. The open-source software we run (Apache Iceberg, the object store, Caddy) and our own control plane, including its sign-in, are operated by us, on the infrastructure above, under our control. TLS certificates are issued by Let's Encrypt (ISRG, US), which sees hostnames only and is not in the data path. The complete list of sub-processors is in the Privacy Policy.

Isolation between customers

  • Each catalog is a separate bucket with its own storage identity. The only grant is a bucket policy naming that identity, enforced by the catalog and the object store, not by our application code. A credential for one catalog cannot list, read or write another.
  • Table buckets accept only Iceberg files in the Iceberg layout; other files go to the separate blob bucket that accompanies your catalog.
  • Isolation is checked with positive and negative controls in the automated test suite on every deployment.

Authentication and credentials

  • API keys are random 256-bit secrets, shown once and stored only as a hash. You can list and revoke them at any time.
  • API tokens are short-lived (15 minutes).
  • Storage credentials are vended by the catalog per table or catalog, valid for at most 60 minutes, and signed with a key we can rotate to revoke every outstanding session at once. Rotating a catalog's own credentials refuses the old ones immediately.
  • Sign-in is our own: email and password on the account page (passwords stored as argon2 hashes), with an optional second factor from an authenticator app (TOTP, plus single-use backup codes), and optional passkeys (WebAuthn, the device's unlock required; a passkey is bound to lakehousebox.com and cannot be phished); one-time codes by email for signup and recovery; and a device-approval flow for the CLI and agents. No third-party identity provider is involved.
  • Failed credential attempts are rate-limited per key and per address; a correct key is never locked out.

Encryption

  • In transit: TLS 1.2 and 1.3 only, on every public hostname, with certificates renewed automatically and HSTS. S3 requests are additionally SigV4-signed.
  • At rest: on the server that runs the store, customer content is encrypted before it reaches the local disk. The copy in storage, which holds every catalog's files, keeps them as they were written, reached only with that storage's own keys; we do not add our own encryption to it. Backups are encrypted before they leave the server.

Infrastructure and operations

  • The Service and its services run as containers we build and administer on a container platform, which also runs other customers' containers.
  • Only HTTPS is exposed to the internet. Every storage, catalog and administration port is internal.
  • The containers' software changes only with a new image we build and deploy. The deployment is described as code; changes reach production through reviewed pull requests that pass automated tests, and every deployment is recorded.
  • A security review of the deployment, with each finding and its status, is kept in our repository and re-run after changes.

Availability and recovery

  • Every catalog's files are kept in storage in Frankfurt, Germany, which keeps a full second copy in Stockholm, Sweden. That copy protects against the loss of a site, not against a mistake: a deletion reaches both. A table's recent versions (time travel) are the protection against a mistaken change.
  • The control-plane state, the store's metadata and keys are backed up every 5 minutes, once every write has reached the storage, encrypted, to separate storage replicated the same way; the newest 144 copies (about 12 hours) are kept.
  • A container that stops is restarted; one that loses its disk is rebuilt from the latest backup and the storage (rehearsed before the move).
  • The backups made before 28 October 2026 are deleted.
  • There is no standby yet and no SLA yet.

Monitoring and logging

The Service is monitored continuously with automatic alerting. The website sets no cookies and loads nothing from third parties; its access log keeps only truncated client addresses. The API logs requests with the caller's address for operations and abuse prevention; rate-limit counters are held in memory and in the database for about an hour. We never read your table or object content. Retention of server logs: 30 days.

Compliance

No certifications yet (no ISO 27001, no SOC 2). This page and the DPA's Annex II are what we offer for your assessment; we answer security questionnaires by email. Sub-processors and their roles are listed in the Privacy Policy and the DPA's Annex III.

Not yet in place

  • A standby. One container today, restarted or rebuilt when it fails.
  • Encryption of tenant storage credentials with a separate key inside the control plane's database.
  • Certifications and an SLA. The SLA comes with paid plans.

Reporting a vulnerability

Email hello@lakehousebox.com. You may test your own catalogs and credentials; please do not test other customers' or load-test the shared service without asking. We do not act against good-faith research that follows that rule.

Change log

  • 2026-09-19-draft — first draft, written from platform/docs/security.md, platform/deploy/README.md and platform/STATE.md. Not published.
  • 2026-09-21 (factual corrections, still draft) — Rauthy retired 2026-09-20, replaced in the software list and the sign-in bullet by the control plane's own login; hostnames api., catalog., s3., mcp.lakehousebox.com; "warehouse" → "catalog" in prose (API paths unchanged); bucket-naming and versioning sentence added; Let's Encrypt named as certificate authority.
  • 2026-09-23-draft — rewritten in the standard shape (founder's ask) and brought up to date: encryption at rest live since 2026-09-22 and encrypted off-host copies (both were "not yet" before); automatic host recreation (measured) in place of "downtime until restore"; bunny.net as the website CDN; the operational specifics (backup times, copy counts, rotation timings, host access details) moved out of this page into platform/docs/recovery.md and platform/docs/security.md, which remain the record.
  • 2026-09-24 (factual correction, still draft) — the sign-in bullet names the optional authenticator-app second factor (TOTP and single-use backup codes, live since 2026-09-23).
  • 2026-09-25 (factual correction, still draft) — the sign-in bullet names the optional passkeys (WebAuthn, user verification required), live with this change.
  • 2026-10-02 (presentation only; the version above is unchanged) — notes for the lawyer and placeholders no longer appear on the published page, which carries a banner saying the document is a draft and the company is in formation. Where a placeholder stood, the page shows what is known: the security contact address is "to be published on incorporation" and the retention of server logs is marked "(proposed)"; the other documents' references to this page are links to it. No term changed.
  • 2026-10-02 (factual corrections, still draft) — backups as they run since 2026-09-24 (platform/docs/recovery.md §1): store metadata and data files are copied every hour, not data nightly, with a weekly full archive; the retention is stated per copy (48 hours, then daily for 14 days and weekly for 8 weeks; four weekly archives) instead of "14 days"; the data at risk in a lost storage volume is about an hour of writes, not a night's.
  • 2026-10-02-draft, founder decisions — questions and vulnerability reports go to hello@lakehousebox.com; server logs are kept 30 days (confirmed); backups are in the European Union, in Falkenstein with a second copy in Helsinki, and are kept no longer than 14 days.
  • 2026-10-02b-draft (factual correction, still draft) — Monitoring and logging: rate-limit counters are held in memory and in the database for about an hour (it said "in memory for at most an hour"; platform/docs/audit-and-quota.md, auth_rate).
  • 2026-10-09-draft — a third, locked copy of the recent backups at Scaleway in Paris (security review 2026-10-08, H2): "Where it runs" names it, and the backups list says what it holds, that our servers' credentials cannot delete it and that it too is removed within 14 days (platform/docs/recovery.md §2d).
  • 2026-10-11-draft — the off-site copies are in France only (founder, 2026-10-11: "One copy outside Hetzner is enough"): the second copy of the backups in Helsinki, Finland, is no longer made, and the copy of the cold storage tier (data not written for 7 days) moved from Helsinki to Paris the same day. "Where it runs" names Germany and Paris only; the backups list describes two copies, not three. The 14-day backup retention is unchanged (platform/docs/recovery.md §1, §2d).
  • 2026-10-14-draft — "Where it runs": bunny.net also distributes the files of catalogs a customer chooses to publish openly, from its edge worldwide (PLAN 24.3); private files are still reached directly. (Corrected 2026-10-14, measured: the edge purge after a catalog is made private or deleted is sent by a scheduled job that ran hours apart, so it can take a few hours, not minutes.) (Corrected again 2026-10-14, measured after PLAN 24.6: the purge is now sent within about a minute of falling due, from a runner nothing else uses; three unpublished catalogs were gone from the edge after 42, 84 and 136 s, so "usually within a few minutes", not "a few hours".)
  • 2026-10-16 — in force from 16 October 2026 (founder, 2026-10-16); the draft label is removed from the published page. No term changes.
  • 2026-10-26 — "Where it runs": bunny.net also serves, worldwide, the files a private catalog's readers read when its owner turns edge caching on for it (the customer's choice; the data processing agreement, clause 5.1(b)).
  • 2026-10-28 — the move to bunny.net (research/106; research/results/t106_swap.txt): "Where it runs", "Encryption", "Infrastructure and operations", "Availability and recovery" and "Not yet in place" describe the Service on bunny.net in Germany with storage replicated to Stockholm (infrastructure/tofu/bunny-cells/cell/), metadata-only backups every 5 minutes (platform/cell/migrate/prod_cell_env.py, platform/deploy/backup_meta.py), the files in bunny.net's storage as written (bucket mode; t106_swap.txt, garden), the services still at Hetzner and the read-only copy kept as the way back (platform/cell/migrate/SWITCH.md step 9), and no new copy to Paris.
  • 2026-10-30 (factual correction) — "Where it runs", "Encryption", "Infrastructure and operations" and "Availability and recovery": the hosting used before the move of 28 October 2026 is deleted (the founder, 2026-10-30: the Hetzner project is deleted, with every server, volume, object-storage bucket and backup in it, and the Paris copies made before the move are gone; production runs in Frankfurt, Germany, its data replicated to Stockholm, Sweden: research/106, platform/cell/); the query service, scheduled SQL, hosted agents and the file drop box run in Germany on the same infrastructure; the sub-processors are named in the privacy policy and Annex III of the data processing agreement, and this page gives the locations. No term changes.