The useful mental model: Lakebed is trying to make the smallest full-stack TypeScript app into one self-contained “capsule” that an AI coding agent can understand, build, inspect, and deploy without assembling Next.js + DB + auth + hosting + logs from scratch.
throwaway internal tools, agent-built UIs, demos, small stateful apps, webhook experiments.
production systems, complex npm dependencies, file storage, long-lived critical data, serious auth/compliance.
No public pricing or billing surfaced. Current public flow is anonymous deploy → GitHub-claimed deploy.
High if the goal is “let agents create small tools quickly and inspect state/logs cheaply.” This aligns with Hermes / Personal Orchestrator style workflows.
Alpha / early prototype. Public docs explicitly call it “alpha-stage”; npm README calls it an “early public prototype.”
Low today. No arbitrary npm imports, no Node built-ins inside capsules, no file storage, local state resets, limited schema types.
Lakebed describes itself as “an alpha-stage agent-native CLI and runtime for building small full-stack TypeScript apps called capsules.” A capsule is the whole app: server contract, Preact client, state, auth, logs, and deploy URL.
The “agent-native” part matters. The docs tell agents to treat the capsule directory as the whole app: write server/index.ts, write client/index.tsx, run the CLI, inspect DB/logs, and deploy. That is much narrower and more machine-manageable than the usual sprawl of package config, framework routes, ORM migrations, auth provider config, hosting, log drains, and database dashboards.
server/index.ts schema, queries, mutations, HTTP endpoints client/index.tsx Preact UI using Lakebed hooks shared/ pure TypeScript shared by server and client .env.lakebed.server optional server-only env values
| Area | What Lakebed gives you | What is missing / constrained |
|---|---|---|
| App model | One capsule = source + server API + client UI + state + auth + logs + deploy URL. | No general framework surface; v0 expects one server entry and one client entry. |
| Server | capsule() with schema, queries, mutations, and external HTTP endpoints/webhooks. | Server modules import only lakebed/server and pure relative files; no Node built-ins in capsule modules. |
| Database | Typed table helpers; rows get id, createdAt, updatedAt; methods include where, orderBy, limit, all, get, insert, update, delete. | V0 field helpers are basically string(), boolean(), and defaults. Not a full Postgres app model for capsule authors. |
| Client | Preact app with useQuery, useMutation, useAuth, routing, links, Google sign-in UI. | No arbitrary npm imports; Tailwind classes in JSX but no CSS pipeline/config. |
| Auth | Guest auth by default; Google sign-in built in. Dev can switch guest identity with npx lakebed auth as alice or per-tab query params. | Not a full auth platform. Treat built-in auth as useful for demos / simple apps until proven otherwise. |
| Env / secrets | .env.lakebed.server is available to server handlers through ctx.env; not exposed to client or embedded in anonymous artifacts. | Hosted env sync requires a claimed deploy. Sync replaces hosted env with file contents. |
| Inspection | CLI can inspect DB, dumps, logs locally and hosted: npx lakebed db dump, logs, inspect. | Public inspection must be explicitly enabled. Private hosted inspection relies on claim token in .lakebed/deploy.json. |
| Deploy | npx lakebed deploy publishes anonymous deploys; claimed deploys can use env and outbound server-side fetch; claimed apps can reserve *.lakebed.app subdomains. | Anonymous deploys disable outbound server-side fetch and env. Unclaimed anonymous deploys expire/clean up in runner defaults. |
| Self-hosting / runner | Package includes anonymous-server; README documents Postgres via DATABASE_URL and Railway-oriented service split. | Public repo appears unavailable/private; self-hosting is possible from npm package but not yet a polished operator experience. |
The CLI defaults to https://api.lakebed.dev; dashboard is https://dashboard.lakebed.dev/deploys; app base domain is lakebed.app. Deploy flow is anonymous first, then claim via GitHub OAuth when you need server env or outbound fetch.
free anonymous deploy path existsresource-limitedalpha
I found no public pricing page, billing page, paid tier, Stripe checkout, or usage price list. The public product model currently looks like “try/deploy anonymously; claim with GitHub for non-expiring deploys + env/fetch.” That does not mean it will stay free; it means pricing is not publicly specified.
no public pricingGitHub claim
fetch or hosted server env; claiming unlocks source-backed server artifact with async handlers, server-side fetch, and env sync.Lakebed can run a deploy API/runner yourself. The README documents production env such as PUBLIC_ROOT_URL, LAKEBED_DASHBOARD_ROOT_URL, LAKEBED_APP_BASE_DOMAIN, DATABASE_URL, GitHub OAuth env, session secret, and server env encryption secret. It specifically references a staged Railway split: all-in-one, api-dashboard, and capsule-runner services.
So the cloud-provider story is: hosted Lakebed runs Theo’s managed API/dashboard/runner, while the package contains enough runner/API machinery to run it on your own infrastructure, especially Railway/Postgres. It is not yet a general “bring any cloud provider and click deploy” product.
Lakebed’s strongest fit is “Hermes, make me a tiny app for this workflow.” Examples: Open Tabs triage UI, proposal review queue, GBrain query workbench, audio-memory approval panel, personal finance/admin checklist. The capsule boundary is simple enough for agents to reason over.
For experiments that need state/auth/logs but not a full stack, Lakebed could be faster than bootstrapping Next/Prisma/Supabase/Vercel. Anonymous deploys are especially useful for sharing a prototype quickly.
The built-in DB/log inspection is aligned with how you evaluate agents: prove done, inspect state, avoid guessing. A capsule can become a small, inspectable artifact rather than a pile of framework files.
Even if you do not adopt Lakebed, its contract is worth studying: “agent-native app runtime” is exactly the kind of bounded surface Hermes could target for personal software generation.
mkdir -p ~/experiments/lakebed cd ~/experiments/lakebed npx lakebed new open-tabs-mini --template todo --no-git cd open-tabs-mini npx lakebed dev
In another terminal:
npx lakebed auth as connor npx lakebed db dump --port 3000 npx lakebed logs --port 3000
I verified this environment can create and build the starter capsule with Node v22.22.0 and npm 10.9.4. The anonymous build produced a Lakebed artifact successfully.
Do not start with a generic todo. Build one useful capsule:
npx lakebed deploy # If you need env or server-side fetch: npx lakebed claim npx lakebed deploy
Claim when the capsule needs secrets, external API calls, or permanence. If it is just a demo, anonymous deploy is enough.
| Question | Pass condition |
|---|---|
| Can Hermes/Codex edit the capsule without confusion? | Agent can implement a feature and pass manual inspection in under 20 minutes. |
| Is state/log inspection useful? | db dump and logs explain behavior faster than reading code. |
| Can it call your real systems? | Claimed deploy with env + server fetch can hit a harmless webhook or test endpoint. |
| Is the restricted model painful? | If you immediately need npm packages, file storage, custom CSS, or complex data types, Lakebed is not ready for that use case. |
github.com/pingdotgg/span, but the repo was not publicly readable during research.The most recent Nerd Snipe episode in the Substack RSS feed is “Google is Not a Serious Company” from 2026-05-28. Its description says: “Oh and apparently Theo's building his own cloud.” I attempted to pull the YouTube transcript for the embedded video, but YouTube caption access was blocked from this cloud IP and the local YouTube-memory fallback did not recover usable subtitles. I therefore used the episode metadata as a directional clue, not as a source of detailed claims.