Your agent does the analysis.
Your box keeps the data.

# the agent, on its machine
lhbox login                     # prints a link and a code; the person approves once in the browser
lhbox duckdb                    # the DuckDB shell with the catalog attached (the recipe is never on screen)
lhbox connect --engine duckdb   # or a paste-ready recipe: duckdb | pyiceberg | spark

-- inside DuckDB
SELECT product, sum(revenue) FROM demo_data.sales.orders WHERE day >= current_date - 7 GROUP BY 1;
CREATE TABLE demo_data.analytics.weekly_sales AS SELECT …;   -- one Iceberg commit; another session can open it

The approval flow. lhbox login prints a link (/app/device?user_code=XXXX-XXXX) and the code, opens the browser when there is one, and waits up to 15 minutes. The person sees this machine's name, the catalog and the access asked for (read and write by default; they may lower it to read only) and approves. The CLI receives the key of a new agent of their organisation, named after the machine and holding exactly the approved access, saves it and never prints it. A person with no account yet creates one on the same page. When login cannot block: lhbox login --no-wait, send the link, later lhbox login --resume. Running login again on a connected machine answers Still connected.

The connection. The catalog is an Iceberg REST catalog with its own S3-compatible bucket. lhbox connect prints, per engine, the catalog URL, the bucket and the catalog's credential filled in; lhbox duckdb passes the same through a private init file. Several catalogs: lhbox catalog list, then --catalog <name>. The full page an agent follows: Agent setup.

The recorded run (2026-09-20, live service): DuckDB 1.5.5 on a laptop read a 185,884-row table, pivoted it into 61 rows in 363 ms and saved the result as a new table in 1,231 ms; a second process attached and read it back 340 ms later.

People sign in on the account page with email and password. Agents connect with lhbox login, approved once in a browser, or are given an agent key by an administrator; every key is revocable on its own and scoped to one catalog at read or write level.

Short-lived credentials do the work. The engine exchanges the catalog's credential for catalog tokens that live 900 seconds and for per-table storage credentials that live about an hour, by itself, on every request. A credential for one catalog cannot list, read or write another: the boundary is enforced by the catalog and the object store, not by our application code, and the isolation suite proves it with a positive control on every run.

Direct reads. Data files are read straight from the object store over HTTPS with those credentials. Public catalogs (the public data) are readable with no credentials at all, at the storage level; their catalog endpoint stays private.

The contract in full: the docs, "Permissions and access". Security notes: Security.

Hourly, for every table, whether or not anyone is connected: compaction of small files, snapshot expiry (20 snapshots and 7 days are kept, so time travel reaches back that far) and orphan-file cleanup. Maintenance commits are optimistic like any other: a client committing at the same moment gets a conflict and retries.

Recovery. Off-host copies run every 5 minutes for accounts and grants, hourly for table metadata and nightly for data files; the restore is rehearsed (about 35 minutes the last time).

Beta, said plainly: one host, no automatic failover, no SLA yet; a host failure means downtime until a restore. Paid plans, high availability and encryption at rest are not yet offered. What is live, with its status: Capabilities.

One thing is metered: how much you store, measured hourly and on demand. Not queries, not commits, not rows, not egress. Query compute runs in your environment, so there is nothing of ours to charge for it. Table maintenance (compaction, snapshot expiry, orphan cleanup, hourly) costs a fraction of a cent per gigabyte processed and is included, not metered.

Today's offer is the free plan: 5 GB stored, no card. Paid plans are not yet announced; public data gets its own tier (50 GB, coming soon). The other limits are guards, not prices: catalogs per project, snapshot history at 20 snapshots and 7 days. The API tells you each limit and its headroom before you reach it.

Limits and how storage is measured: the docs. The plan and the beta conditions: Pricing.