LakehouseBox — Privacy Policy
Version: 30 October 2026
Effective: 16 October 2026
Controller: Lakehousebox, S.L., calle Bárbara de Braganza, 2, 2ª planta, 28004 Madrid, Spain, NIF B05742093
Privacy contact: hello@lakehousebox.com
This policy explains what personal data Lakehousebox, S.L. processes as controller: data about the people who open accounts, visit the website or write to us. For personal data that customers store inside the Service (in their tables and files), LakehouseBox is a processor acting on the customer's instructions; that is governed by the Data Processing Agreement, not by this policy.
1. Two roles, in one sentence each
- Account and website data (this policy): we decide why and how it is processed; we are the controller.
- Customer content (the DPA): the customer decides; we store and serve it as instructed; we are the processor.
2. What we collect, why, and on what legal basis
2.1 Account holders (humans)
| data | where it comes from | why | legal basis (Art. 6 GDPR) | kept |
|---|---|---|---|---|
| email address | you, at signup or sign-in | to create and identify the account, send one-time codes, invitations and service notices, place you in your organisation by verified domain | contract (6.1.b) | life of the account + 30 days after deletion, then in backups for up to 14 more days |
| display name / workspace name | you | to label the account and its organisation | contract (6.1.b) | same |
| organisation membership and role (owner, admin, member), claimed email domains, invitations (invited address, role, who invited) | you or your organisation's admins | to run organisations and access control | contract (6.1.b) | same; an unaccepted invitation expires after a set time and can no longer be used (its record is removed with the organisation, see the decisions file) |
login credentials for the account page at lakehousebox.com/app/: password (stored only as an argon2 hash), email-verification and password-change times, single-use set-password / reset links (stored hashed), and the short-lived session token issued when you sign in, with the IP address each session was last used from (kept in full for 30 days, then shortened (IPv4 to /24, IPv6 to /48), as in the audit log, section 2.2) |
you | to authenticate you | contract (6.1.b) | same; set-password links 3 days, reset links 30 minutes, sessions until they expire or you sign out |
| two-factor authentication, if you enable it: the authenticator secret (stored encrypted), single-use backup codes (stored only as keyed hashes) and the times they were used | you and your authenticator app | to check the second factor at sign-in | contract (6.1.b) | same; removed when you turn two-factor authentication off |
| passkeys, if you add them: each passkey's public key and identifier, the name you give it, the authenticator model identifier your device reports (AAGUID), whether it is synced, the IP address it was added from (in full for 30 days, then shortened as for sessions), and when it was added and last used. Your fingerprint, face or PIN never leaves your device and never reaches us; nor does the passkey's private key | you and your device | to sign you in with the passkey | contract (6.1.b) | same; removed when you remove the passkey, reset your password with the mailed link, or delete the account |
| CLI device approvals: the device code (stored hashed), the user code you confirm, and the resulting connection record with the IP address recorded when it was made (in full for 30 days, then shortened as for sessions) | you, through the CLI | to let a command-line tool sign in without pasting a key | contract (6.1.b) | same |
| API keys: key identifier, label, creation, last use and revocation times; the key itself only as a SHA-256 hash | generated by us on your request | to authenticate your tools and agents | contract (6.1.b) | same |
connections of an AI application (Claude, Cursor, …) to our MCP server at mcp.lakehousebox.com, when you approve one: the name, web address and logo the application declares for itself, the IP address it registered from and the one recorded when the connection was made (each in full for 30 days, then shortened as for sessions), the catalogs and levels you granted it and the scope you approved; the connection appears as a token in your Tokens tab; its refresh tokens are stored only as hashes |
the application, and you on the approval page | to let that application read the catalogs you chose, on your behalf | contract (6.1.b) | until you revoke the token; refresh tokens 30 days from their last use; a registration no connection has used for 90 days is deleted |
| one-time signup and recovery codes, stored as a salted hash, plus attempt counter | generated by us | to verify your address | contract (6.1.b) | 10 minutes, or until used |
| paid storage, if your organisation turns it on: the invoice details an administrator enters (legal name, tax ID, address, country, invoice email, purchase-order reference), the monthly budget, the card's brand and last four digits (the card itself is held by Mollie, never by us), and the charges and invoices of the organisation | an administrator of your organisation; Mollie; Holded | to charge for paid storage and issue its invoices | contract (6.1.b); legal obligation to issue and keep invoices (6.1.c) | invoices and the records they rest on as long as Spanish tax and commercial law requires us to keep them; the rest for the life of the account |
| project, catalog and table names, quota counters (bytes stored, objects, commits) | you / measured by us | to run the Service and enforce the free-tier limit | contract (6.1.b), legitimate interest in preventing abuse (6.1.f) | life of the account |
campaign tags of the link that brought you to the signup page, when it carried any: up to four short labels (utm_source, utm_medium, utm_campaign, utm_content, for example chatgpt, cpc, eu-sovereignty-1) naming one of our campaigns, never you (section 2.3) |
the address of the page you signed up on, or the lhbox login or lhbox new command you copied from a tagged page |
to know which of our campaigns and pages bring people who sign up and go on to use the Service | legitimate interest in measuring our own marketing (6.1.f) | life of the account |
| news emails, only if you ask for them (an unticked box on the signup form, or the Email updates switch on the account page): your email address and the record of your choice (the version of the words you were shown, where you chose, when, and the IP address you chose from; when you stopped, and how) | you | to send you news about the Service, our new blog posts and occasional offers, at most once a week | consent (6.1.a); you can withdraw it at any time, with the unsubscribe link in every email, the switch on the account page, or by writing to us, without affecting the account | until you withdraw; the record of your choice is then kept as proof of the consent, and when you delete the account it keeps only its dates |
| Sign in with Google, only if you choose it (the "Continue with Google" button): from Google, your name, your verified email address, your Google account identifier, and, for a Google Workspace account, its organisation's domain; we keep the account identifier and the address it came with (to recognise you the next time) and record the domain in the account security audit log (section 2.2). Your profile picture's address is part of what Google sends; we do not store it. Nothing we hold about you, your catalogs or your queries is sent to Google. If the address is one Google does not run, the code we email to confirm it is the one-time code above (salted hash, 10 minutes) | Google, when you sign in there | to sign you in, or to create your account when you have none | contract (6.1.b) | the account identifier for the life of the account; the audit entry as in section 2.2 |
2.2 Everyone who calls the API (including automated agents)
| data | why | legal basis | kept |
|---|---|---|---|
| IP address of the caller, for rate limiting of signup (5 per hour per address) and of failed credential attempts (10 per key per 10 minutes), in memory and in rate-limit records in the database | to prevent abuse and credential guessing | legitimate interest (6.1.f) | about 1 hour |
| IP address of the requester on the short-lived records of a sign-in or an approval in progress: login links, CLI device codes, two-factor and passkey challenges, AI-application authorisation requests | to secure the sign-in or approval it belongs to | legitimate interest (6.1.f) | until the record expires, a day to a week |
queries run on our servers and files read through them (lhbox query, POST /v1/query, GET /v1/object and the MCP server's query and get_object tools): the organisation, the kind of statement, the catalogs it names, whether it succeeded, how long it waited and ran, the bytes read and rows returned, and the length and a 12-character hash of the SQL text. Never the SQL text, the rows, a file's key or its content: those pass through memory and are not written anywhere by us |
to operate the query service, share it fairly between organisations and find faults | legitimate interest (6.1.f) | as server logs |
catalogs an agent makes without an account (lhbox new, or an application a person lets set it up on our authorisation page, Terms clause 2.5): the network address the request came from (an IPv6 address shortened to its /64), the machine and agent name the request gives, the times it was made and expires, the record that the Terms were accepted with it, and the campaign tags of the tagged page its command came from, when it carried any (section 2.3) |
to apply the limits on such catalogs (5 an hour and 20 a day per address, 200 a day for the Service), and to run and then delete the catalog; the campaign tags, to know which of our campaigns bring agents whose catalogs a person keeps | legitimate interest in preventing abuse (6.1.f); contract (6.1.b); for the campaign tags, legitimate interest in measuring our own marketing (6.1.f) | the address and names with the organisation's record: deleted with it after 72 hours, or kept with it once a person claims it; the campaign tags until the claim or that deletion, and with the creation's entry in the account security audit log (400 days, below); a person who signs up while claiming the catalog has them on their account (the campaign row in section 2.1); the hourly limit's record about 1 hour |
| server logs: time, method, path, response code, error references; the caller's network address and the API key identifier (never the secret) when a request is refused for too many failed attempts; the caller's network address when a signup is rate-limited | to operate, debug and secure the Service | legitimate interest (6.1.f) | 30 days |
| the account security audit log: an entry for each sign-in, each change to keys and access, and each deletion, with its time, the account and organisation, the action and what it concerned, a request reference, and the requester's IP address | to keep accounts secure, and to investigate abuse and disputes about an account | legitimate interest (6.1.f) | 400 days; the IP address is kept in full for 30 days and then shortened (IPv4 to /24, IPv6 to /48) |
2.3 Website visitors (lakehousebox.com)
The website is static. It sets no cookies, runs no analytics scripts and loads no third-party scripts or fonts. Its pages are stored and served by our content delivery network, bunny.net (section 3), which records each request: the time, the page or file requested (without its query string, except the campaign tags below), the response code and size, the referring page (without its query string), your browser's user-agent string, the country the request came from, and your IP address with its last part removed before it is written (an IPv4 address keeps its first three numbers, an IPv6 address its first four groups), so the log never holds your full address. We use these records to count visitors, see which pages are read and where visitors come from, and to keep the site working, on the basis of our legitimate interest (6.1.f); we keep them 30 days (section 4).
When you arrive through one of our ads or a link we tagged, the page address carries up to four campaign tags (utm_source, utm_medium, utm_campaign, utm_content) that name the campaign, for example utm_source=chatgpt. The request log keeps those four and no other part of the address; the site copies them onto its own links while you browse and into the lhbox login and lhbox new commands it shows (lhbox login --campaign chatgpt/cpc/…), without storing anything in your browser (leave the tagged pages and they are gone); and if you sign up, the signup page sends them with the form, or the command-line tool sends them with the login you approve or with the catalog an agent makes for you without an account, which passes them on to your account if you claim it (section 2.1). Anything else in the address, including an advertising network's click identifier, is neither kept nor sent. We send nothing about you to any advertising network: no tracking pixel, no conversion upload, no list of signups. The signup page sends our API what you type in the form and those tags, and nothing else. When you sign in on the account page at lakehousebox.com/app/, our API sets one strictly necessary cookie per signed-in account, lhbox_rt_<account id>, so that you stay signed in across tabs and browser restarts (and can be signed in to several accounts at once): a random session identifier, sent only to api.lakehousebox.com on the sign-in routes (/v1/auth), unreadable by the page's scripts, expiring after 30 days without use and deleted when you log out (you can also end any session from the account page). The short-lived access token stays in the browser tab's storage. While a sign-in with Google is under way, the API also sets one strictly necessary cookie, lhbox_google, sent only to api.lakehousebox.com on /v1/auth/google: it holds, encrypted, the random values that tie Google's answer to the sign-in your browser started, and it is deleted when Google sends you back, or after 10 minutes.
When you open a map of a query result on the account page or on /try (lakehousebox.com/try), the map's background (streets, places, labels) is loaded from tiles.lakehousebox.com: bunny.net serves it from its edge, fetching and caching it from our map provider, CARTO. Your browser talks to bunny.net only; CARTO never receives your address or anything about you, and the tiles you look at are not logged. The geometries drawn on the map never leave your browser.
2.4 People who write to us
Email to our address, hello@lakehousebox.com, for legal, privacy, security and support alike, is stored in mailboxes hosted for us by Infomaniak Network SA in Switzerland, together with your name, address and whatever you write. Legal basis: legitimate interest in answering you (6.1.f), or contract (6.1.b) if you are a customer. Kept for 24 months after the last exchange, longer if needed for a legal claim.
2.5 What we do not do
We do not sell personal data, do not use it for advertising or share it with advertising networks, do not profile account holders, do not send you news or marketing email unless you asked for it (section 2.1: product news is opt-in, every email has an unsubscribe link, and account emails such as password resets are sent either way), and do not use any US-operated service to process it.
3. Where the data is and who else sees it
All account data, customer content, backups and logs are stored on servers in the European Union (the exceptions, both a customer's choice: copies of the files of catalogs it publishes openly, and of the files of a private catalog it turns edge caching on for, cached on bunny.net's edge servers worldwide) operated for us by our sub-processors. The Service and its data are in Frankfurt, Germany (since 28 October 2026), with a full second copy of the stored data and backups in Stockholm, Sweden, kept by the storage's replication; the query service, scheduled SQL, hosted agents and the file drop box run in Germany too. The servers, copies and backups we used before 28 October 2026 are deleted. The public website pages and the website's request log (section 2.3) are stored in Frankfurt, Germany, and the public pages, and the files of catalogs a customer has chosen to publish openly or turned edge caching on for, are cached on bunny.net's edge servers (edge locations worldwide). Our sub-processors, all of them, are:
| sub-processor | country | what they do for us | what personal data they see |
|---|---|---|---|
| Scaleway SAS | France (Paris region) | transactional email: signup and recovery codes, invitations, service notices; the language models hosted agents use | for email: recipient email address, subject and body of the email, delivery logs; for hosted agents: what an agent sends to its model |
| Mollie B.V. | the Netherlands | card payments for paid storage: holds the card, takes the monthly charges | the card details you enter on Mollie's page, the organisation's legal name and invoice email, and the amounts charged; Mollie is also a controller of the payment data it must keep by law |
| Holded Technologies S.L. | Spain | issues and keeps our invoices and our accounts; from 2027 sends invoice records to the Spanish tax agency (VERI*FACTU) | the invoice details of paying organisations (legal name, tax ID, address, country, invoice email) and their invoices and payments; never customer content |
| Lettermint B.V. | the Netherlands | sends the product-news emails, only to people who asked for them (section 2.1), from news.lakehousebox.com; it never receives the list, only one email at a time |
recipient email address, subject and body of the email, delivery, bounce and unsubscribe events |
| Infomaniak Network SA | Switzerland | mailboxes for our own company address (hello@lakehousebox.com) | the content of email you send us. Not used for customer content or account data |
| BunnyWay d.o.o. (bunny.net) | Slovenia | since 28 October 2026, the infrastructure the Service runs on: the containers that run it, in Frankfurt, Germany, and its query service, scheduled SQL, hosted agents and file drop box, in Germany, and the storage of every catalog's tables and files and of the Service's backups, in Frankfurt, Germany, with a replicated copy in Stockholm, Sweden; content delivery network in front of the website pages (lakehousebox.com, www.): caches and serves the public pages, styles, scripts and fonts from edge servers, and the map background on the account page and /try (tiles.lakehousebox.com, fetched from CARTO, section 2.3); and in front of public catalogs: the files of catalogs a customer has chosen to publish openly are distributed from its edge servers worldwide (public-s3.lakehousebox.com, also reachable as lakehousebox-public-data.b-cdn.net; the files of a folder a customer publishes next to a catalog's tables at public-files.lakehousebox.com, also reachable as lakehousebox-public-files.b-cdn.net), and so are their catalogs' table lists and table descriptions (public-catalog.lakehousebox.com); for a private catalog a customer turns edge caching on for, the files its authorised readers read are served from its edge servers worldwide too; DNS hosting for lakehousebox.com. The content delivery network is not in front of the API, the catalog, or any data of a private catalog without edge caching |
as the infrastructure: everything stored in the Service, its backups (encrypted) and its logs while they are there; bunny.net staff do not access it in the ordinary course; as the content delivery network: the visitor's IP address, requested URL and browser headers, in transit; the website's request log with the IP address shortened at the edge before it is written (section 2.3), stored in Germany for 30 days; no request log of public-catalog downloads; copies of the files of published catalogs, removed from the edge when the catalog is made private or deleted (a purge, which usually completes within a few minutes; until it completes the copies can still be served), while a table file removed from a catalog that stays public can stay cached for up to a year, and a file of a published folder that is changed or removed in place is removed from the edge too, usually within a few seconds, and stays cached for at most seven days if that removal cannot run; the copies of a folder that stops being published are removed like those of a catalog made private; copies of the files a private catalog's readers read with edge caching on, until the end of the day (UTC) at most, removed when edge caching is turned off, the catalog is deleted or a person's access is removed. Through the content delivery network, never a private catalog's content without edge caching turned on |
Switzerland is outside the EU/EEA but is covered by a European Commission adequacy decision (Decision 2000/518/EC, confirmed in the Commission's 2024 review), so mail to our Infomaniak mailboxes is not a restricted transfer under Chapter V GDPR. No personal data is transferred to the United States or to any other third country, and no US-controlled company processes it for us, with two exceptions a customer chooses: the files of a catalog it publishes openly, and the files of a private catalog it turns edge caching on for, are cached on bunny.net's edge servers worldwide, outside the EU too, and a reader's download is answered by the edge server nearest to the reader.
Sign in with Google (optional, section 2.1): if you choose to sign in with your Google account, your browser goes to Google, Google signs you in and sends us your name and verified address. Google is not our sub-processor: it acts for you, as the controller of your Google account (Google LLC, United States, or Google Ireland Limited for users in the EU, under Google's own privacy policy), and learns that you sign in to LakehouseBox. We send Google no personal data about you and no customer content: only our client identifier and the one-time code Google gave your browser. Everything works without it.
We disclose personal data to public authorities only when a legally binding request under Spanish or EU law obliges us to, and we tell the affected customer unless the law forbids it.
4. How long we keep it
| what | how long |
|---|---|
| account data (section 2.1) | until you ask us to delete the account, or 30 days after we close it; deletion is complete within 30 days of the request |
| backups | the account database, the storage's metadata and keys, every 5 minutes, encrypted, in storage in Frankfurt, Germany, with a replicated copy in Stockholm, Sweden; the newest 144 copies (about 12 hours) are kept. The backups made before 28 October 2026, and the copy of the Service kept while it moved, are deleted. A deleted record therefore disappears from the backups within about 12 hours. The backups contain the records above, so an IP address can remain in full in a backup after it is shortened in the Service |
| one-time codes | 10 minutes |
| rate-limit counters (in memory and in the database) | about 1 hour |
| short-lived sign-in and approval records (section 2.2), with the requester's IP address | until they expire, a day to a week |
| server logs | 30 days |
| account security audit log (section 2.2) | 400 days; the requester's IP address in full for 30 days, then shortened (IPv4 to /24, IPv6 to /48) |
| website request log (section 2.3) | 30 days: removed from storage and from our monitoring database after 30 days |
| correspondence | 24 months |
| invoices and accounting records (paid storage, section 2.1; announced at €0.10/GB-month, not open yet) | as required by Spanish tax and commercial law (currently 4 years for tax, 6 years for commercial books) |
5. Your rights
You have the rights of access, rectification, erasure, restriction, portability and objection (Arts. 15–21 GDPR), and the right not to be subject to automated decisions with legal effect (we make none). Write to hello@lakehousebox.com from the address on your account, or by post to the address above. We answer within one month, extendable by two more for complex requests, as the GDPR allows. Account holders can see and change most of their data through the API and CLI (GET /v1/orgs, GET /v1/api-keys, DELETE /v1/api-keys/{id}, organisation membership endpoints).
You may complain to the Spanish supervisory authority, the Agencia Española de Protección de Datos (AEPD), C/ Jorge Juan 6, 28001 Madrid, www.aepd.es, or to the authority of the EU country where you live or work.
6. Security
Personal data is protected by the measures described in the Security overview and Annex II of the Data Processing Agreement: TLS 1.2+ on every public endpoint, credentials stored only as hashes, short-lived scoped credentials for storage, per-tenant catalog isolation, only HTTPS exposed to the internet, the account database and the storage's metadata backed up every 5 minutes with a rehearsed rebuild, and rotation procedures for every long-lived key. We also say there what is not yet done.
7. Children
The Service is for professional use and not directed at anyone under 18. We do not knowingly collect data from children; if we learn we have, we delete it.
8. Changes
We update this policy in place with a new version date and a change-log entry. If a change matters to you (new purpose, new sub-processor, new retention period), we email account holders before it takes effect. Sub-processor changes follow the notice procedure in the Data Processing Agreement.
9. Contact
Lakehousebox, S.L., calle Bárbara de Braganza, 2, 2ª planta, 28004 Madrid, Spain. Privacy contact: hello@lakehousebox.com.
Change log
- 2026-09-19-draft — first draft. Data inventory taken from
platform/control_plane/app.py(tablesprincipal,api_key,identity,organization,org_member,org_domain,invitation,agent,signup_code,recovery_code; in-memorySIGNUP_RATEand_AUTH_FAILS), the website deployment (platform/deploy/web_host_setup.sh: no access log, no cookies) and the mail setup (research/21Part B). Not published. - 2026-09-21 (factual corrections, still draft) — the sign-in service at
auth.tablemere.com(Rauthy) was retired on 2026-09-20; its rows are replaced by the control plane's own login (password hash, set/reset links, session token; tablesprincipal,login_token,session,device_code;docs/login.md) and the CLI device approval. Website islakehousebox.com;tablemere.euredirects. "warehouse" → "catalog" in prose. - 2026-09-23-draft (factual corrections) — the website is now stored and served by bunny.net (storage in Falkenstein, Germany;
infrastructure/tofu/bunny/web_storage.tf), and its request log is kept: anonymised at the edge (IPv4 to /24, IPv6 to /64;log_anonymized_style = "OneDigit"), archived in a bunny storage zone in Germany, loaded into our monitoring database and deleted from both after 30 days (platform/deploy/obs/bunny_logs.py, otel_logs TTL). Section 2.3 also corrects "its web server keeps no access log": from 2026-09-20 the gateway kept a masked access log of the site (IPv4 /24, IPv6 /48;platform/stack/gateway/Caddyfile.prod), which the edge log replaces. - 2026-09-24-draft — campaign tags (
operations/04-chatgpt-ads.md): the website's request log keeps the fourutm_*tags of a page address and nothing else of its query string (platform/deploy/obs/bunny_logs.py,CAMPAIGN_TAGS);web/nav.jscopies them onto the site's own links without browser storage; the signup page sends them with the form and the control plane keeps them on the account (principal.signup_campaign, validated by_valid_campaign). Sections 2.1 (a new row), 2.3 and 2.5 say so. No data goes to an advertising network. - 2026-09-24b-draft — the same tags reach a signup that starts from the command line: on a tagged page the site writes them into the
lhbox logincommands it shows (--campaign), the CLI sends them with the login (POST /v1/auth/device, kept on the pending logindevice_code.campaign), and an account created on that login's approval page is attributed to them. Sections 2.1 and 2.3. - 2026-09-24 (factual correction, still draft) — section 2.1 lists the data kept for the optional two-factor authentication (live since 2026-09-23): the authenticator secret, encrypted, and the single-use backup codes, as keyed hashes; both deleted when it is turned off.
- 2026-09-25-draft — the account page's map of a query result loads its basemap from
tiles.lakehousebox.com, a bunny.net pull zone whose origin is CARTO's tile service, with no request log (infrastructure/tofu/bunny/tiles.tf). Section 2.3 and bunny.net's row in section 3. - 2026-09-25b-draft — passkeys (live with this change): section 2.1 lists what is kept for each passkey a person adds (public key and identifier, name, authenticator model identifier, synced or not, the IP address it was added from, when added and last used) and says that no biometric and no private key reaches us.
- 2026-09-25c-draft — two rows from the new consumer MCP server and query service (research/33): MCP connections in section 2.1 (the
oauth_client,oauth_codeand refresh-token tables,docs/mcp-remote.md) and the query log in section 2.2 (platform/query/service.py: statement type, catalogs, timings, sizes and a hash of the SQL; never the SQL, rows or file keys). The query host (al-query1) is a Hetzner server in Nuremberg, inside the existing sub-processor row. - 2026-09-30-draft — the controller is named: LakehouseBox SL, C. de la Basílica, 19, 28020 Madrid (still in formation, CIF pending). Product-news emails added as an opt-in (section 2.1 row, consent 6.1.a; the record of consent in the control plane's
news_consenttable,platform/docs/news.md), section 2.5 no longer says we run no marketing email list, and Lettermint B.V. (the Netherlands) joins the sub-processors as the newsletter sender. The list is built and off until the sender is set up. - 2026-09-30b-draft — the news emails cover blog posts and occasional offers as well as product news, at most once a week (the words at the signup box and the account switch changed the same way, before anyone had subscribed).
- 2026-10-01-draft — company name and registered office: Lakehousebox, S.L., calle Bárbara de Braganza, 2, 2ª planta, 28004 Madrid (still in formation, CIF pending).
- 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 CIF and the privacy contact are "to be published on incorporation", the Data Protection Officer is "to be confirmed on incorporation", the effective date reads "not yet in force", and the retention of server logs and of correspondence is marked "(proposed)". No term changed.
- 2026-10-02 (factual corrections, still draft) — the backups row of section 4 describes the copies as they run since 2026-09-24 (
platform/docs/recovery.md§1: control-plane state every 5 minutes, store metadata and data files hourly, a weekly full archive, and what is kept of each) in place of "daily; 7 copies on the host, 14 copies off-host". The row's 14-day deletion statement is unchanged and is for the founder and the lawyer. - 2026-10-02-draft, founder decisions — the privacy contact is hello@lakehousebox.com (header, section 5, section 9), and section 2.4 names that one address, at Infomaniak, in place of four tablemere.eu addresses; server logs are kept 30 days and correspondence 24 months (confirmed); data and backups are in the European Union, in Germany with a second copy of the backups in Finland (section 3, Hetzner's row); the backups row of section 4 states the retention chosen (hourly and more frequent copies and archives each no longer than 14 days), which removes its contradiction with the 14-day deletion; section 6 says backups are at least daily and currently hourly. The DPO stays to be confirmed; the CIF stays to be published.
- 2026-10-02b-draft, founder decisions — the account security audit log (sign-ins, key and access changes, deletions) is its own category, separate from the 30-day server logs: a row in section 2.2 (purpose: security of accounts, investigating abuse and account disputes; legitimate interest, 6.1.f) and in section 4: events kept 400 days, the requester's IP address in full for 30 days and then shortened to /24 (IPv4) or /48 (IPv6) (
audit_eventin the control plane; the shortening ships with the engineering change onclaude/audit-ip-shorten). - 2026-10-02b-draft, founder decisions (continued) — IP addresses kept with credentials (the address a sign-in session was last used from, the one a passkey was added from, the ones recorded when a CLI or AI-application connection was made and when an application registered) are kept in full for 30 days and then shortened to /24 or /48, as in the audit log; section 2.2 no longer says rate-limit addresses are never written to the database (rate-limit records keep them about an hour) and lists the short-lived sign-in and approval records that keep the requester's address until they expire, a day to a week; section 4 says so, and that a backup can hold a full address for up to 14 days after it is shortened (
platform/docs/audit-and-quota.md, branchclaude/audit-ip-shorten). - 2026-10-09-draft — paid storage, as built (
platform/docs/billing.md): a row in section 2.1 for the billing data of organisations that turn it on (invoice details, budget, the card's brand and last four digits, charges and invoices; contract and the legal obligation to issue and keep invoices; invoices kept as long as Spanish law requires), and two sub-processors in section 3: Mollie B.V. (card payments; also a controller of the payment data it must keep) and Holded Technologies S.L. (our invoicing and accounts, and from 2027 the invoice records sent to the tax agency). - 2026-10-09-draft — a third, locked copy of the recent backups at Scaleway in Paris, France (security review 2026-10-08, H2: the Hetzner key on our servers could delete both earlier copies): section 3 names France and Scaleway's second role, the backups row of section 4 says what the copy holds (the last 2 days), that it cannot be deleted for 6 days and that it is removed within 14 days of each backup's time. The 14-day promise is unchanged (
platform/deploy/backup_vault.py,platform/docs/recovery.md§2d). - 2026-10-11 (presentation only; the version above is unchanged) — section 2 no longer names the old redirect domain.
- 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. Section 3 names Germany and France only, Hetzner's row loses Finland and Scaleway's gains the cold-tier copy; the backups row of section 4 describes two copies, not three. The 14-day backup retention is unchanged (
platform/docs/recovery.md§1, §2d). - 2026-10-12-draft — section 2.2: catalogs an agent makes without an account (research/70): the address the request came from (an IPv6 address as its /64), the names it gives, its times and the Terms acceptance; why (the per-address and daily limits) and how long (deleted with the catalog after 72 hours, or kept with it once claimed).
- 2026-10-12b-draft — the campaign tags also reach a catalog an agent makes without an account (
operations/05): on a tagged page the site writes them into thelhbox newcommands it shows, the CLI sends them withPOST /v1/agent/identity(kept on the catalog's anonymous owner,principal.signup_campaign, until the claim or the deletion, and in theorg.createaudit entry, 400 days), and the claim carries them to a person who signs up on the claim page (device_code.campaign); the claim's own audit entry does not carry them. Sections 2.1, 2.2 and 2.3. - 2026-10-12c-draft — section 2.2: the same catalog can be made by an application when a person lets an application set it up on our authorisation page (research/71); the address recorded is the browser's that clicked, and the same limits apply.
- 2026-10-14-draft — public catalogs (PLAN 24.3): the files of catalogs a customer chooses to publish openly are distributed through bunny.net's CDN, worldwide (
infrastructure/tofu/bunny/public_data.tf); section 3 and bunny.net's row say so, and that this zone's request log shortens the reader's IP address at the edge. Private customer content still never passes through bunny.net. (Corrected the same day, high review of #1317: section 3's EU-only and no-transfer sentences name the one exception, no request log of public-catalog downloads is kept, and bunny.net's row says how long copies stay at the edge.) (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-14b-draft (factual corrections) — section 2.3 and bunny.net's row in section 3 name
/tryalongside the account page for the map background (tiles.lakehousebox.com, fetched from CARTO,web/explore/map.js); the invoices row of section 4 refers to paid storage (section 2.1, announced at €0.10/GB-month, not open yet) in place of "paid plans, later". No term changed. - 2026-10-14c-draft — the company is incorporated (public deed of 2026-10-09): Lakehousebox, S.L., NIF B05742093 (provisional NIF), registered office unchanged; "in formation" removed.
- 2026-10-15-draft (presentation; founder) — the Data Protection Officer line is left out; the privacy contact stays hello@lakehousebox.com. No term changes.
- 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-16b — Sign in with Google is offered on the account page (research/82;
platform/control_plane/plane/google_signin.py, turned on in production by #1527): a row in section 2.1 for what Google sends when a person chooses it (name, verified address, Google account identifier, a Workspace domain; the identifier and address kept, the domain in the audit log, the picture's address not stored), thelhbox_googlecookie in section 2.3 (strictly necessary, for the 10 minutes a Google sign-in is under way), and a paragraph in section 3: Google acts as the controller of the person's own Google account, not as our sub-processor, and receives no personal data and no customer content from us. - 2026-10-18 — the public-catalog edge is named
public-s3.lakehousebox.com(the same bunny.net service; its earlier namelakehousebox-public-data.b-cdn.netstill answers). No term changes. - 2026-10-18b — public catalogs can be attached by name without an account; the catalog's table lists and table descriptions are served from the same bunny.net edge (
public-catalog.lakehousebox.com), with no request log. No term changes. - 2026-10-19 — the files of a folder a customer publishes next to a public catalog's tables are distributed from the same bunny.net service at
public-files.lakehousebox.com(PLAN 29,infrastructure/tofu/bunny/public_files.tf), with no request log; bunny.net's row in section 3 says how long those copies stay at the edge (an hour at most for a changed or removed file; purged when the folder stops being published). No term changes. - 2026-10-19b — a file of a published folder that is changed or removed in place is now removed from the edge as well (PLAN 29 step 3: we follow the storage's change log and purge that file; measured 37 to 72 s), so the edge keeps those copies for up to seven days instead of an hour; seven days is the bound only if the removal cannot run. bunny.net's row in section 3. No term changes.
- 2026-10-26 — a file of a published folder that is changed or removed in place is now removed from the edge usually within a few seconds (research/100: measured 0.4 to 1.4 s), not two minutes; bunny.net's row in section 3. No term changes.
- 2026-10-26b — section 3 and bunny.net's row: a private catalog a customer turns edge caching on for has the files its readers read cached on bunny.net's edge servers worldwide, as published catalogs do (the customer's choice; the data processing agreement, clause 5.1(b)); the earlier wording left this setting out.
- 2026-10-28 — the move to bunny.net (research/106;
research/results/t106_swap.txt): section 3 (where the data is; Hetzner, Scaleway and bunny.net's rows), section 4 (backups) and section 6. The Service and its data are on bunny.net in Germany, its storage replicated to Stockholm, Sweden (infrastructure/tofu/bunny-cells/cell/); backups are the account database and the storage's metadata every 5 minutes, the newest 144 kept (platform/cell/migrate/prod_cell_env.py,platform/deploy/backup_meta.py), and nothing new is copied to Paris (prod_cell_env.py). Hetzner keeps the services that have not moved yet and the read-only copy kept as the way back (platform/cell/migrate/SWITCH.mdstep 9). Scaleway's row names the language models hosted agents use (platform/docs/user/hosted-agents.md), a role this list left out. Section 8's email before a new sub-processor is flagged for the founder, not changed. - 2026-10-30 (factual correction) — section 3 and section 4 (backups): 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/). Hetzner Online GmbH is removed from the sub-processors (no data of ours is there any more); Scaleway's row loses the backup and cold-tier copies; bunny.net's row (kept: the list must name every sub-processor) adds the query service, scheduled SQL, hosted agents and the file drop box, in Germany, which moved there. Narrative sentences give the location instead of the provider. No term changes.