Glossary
The words these docs use, defined once. Lodekit uses each term consistently — the same word appears in the docs, the dashboard, and the SDK.
The AI assistant you build through, in whatever form you use it: a desktop app, an IDE, or a terminal coding agent. Lodekit is agent-agnostic — any agent that can load the skill and speak MCP can drive it. See Connect your agent.
A self-contained personal web app that runs on Lodekit — the thing you build. Each app lives at its own URL and keeps its own data. See What is Lodekit?.
app contract
Section titled “app contract”The required shape of an app’s source: a manifest, TanStack Start routes, and a committed route tree. What “a valid app” means. See App anatomy.
app id
Section titled “app id”An app’s URL-safe identity: lowercase letters, digits, hyphens. It equals the app’s folder name and is simultaneously its URL path and its data namespace. See The manifest.
app worker
Section titled “app worker”The isolated worker inside the engine that runs one app’s server code — server rendering and server functions. See How Lodekit works.
backup tree
Section titled “backup tree”The apps, data, and gateways directories under the Lodekit root, together: the durable state worth preserving. Back up that one folder and you have everything. See Your Lodekit folder.
build state
Section titled “build state”Where an app is in its build lifecycle: building → ready or error. Shown live on each app’s card in the dashboard.
bundled
Section titled “bundled”How apps ship: source is compiled into built output that Lodekit serves. You never run a build yourself. See How Lodekit works.
Regenerable built output at ~/Library/Caches/Lodekit, kept
outside the Lodekit root and never backed up. Deleting it costs only a
rebuild. See File locations.
connection
Section titled “connection”An app’s grant to use a gateway: declared in
src/gateways.ts under an app-local alias, completed in the dashboard by
linking a secret into each secret slot and setting each config slot. See
Gateways.
dashboard
Section titled “dashboard”Lodekit’s built-in web UI: every app with its live build state and health, plus logs, events, secrets, gateways, and settings. See The dashboard.
data tree
Section titled “data tree”The data/ directory under the Lodekit root: each app’s
saved records, one folder per app id. See
Your Lodekit folder.
Engine
Section titled “Engine”The single Node process at the heart of the platform: it hosts, builds, watches, and serves your apps, the dashboard, and the API. See How Lodekit works.
A durable message on the platform’s event bus: an app announcing an export finished, the platform announcing an app became ready. Events trigger reactions; they’re never the system of record. See the Event Store.
Event Store
Section titled “Event Store”The platform-wide event bus and its history (event-store
for short): every event lands in one ordered, replayable log, reached through
the SDK as the events handle. See
the Event Store.
File Store
Section titled “File Store”Every app’s own blob storage (file-store for short):
documents and images kept as real, Finder-browsable files, reached through
the SDK as the files handle. See the File Store.
gateway
Section titled “gateway”The managed door to one provider: a declarative manifest plus the engine machinery that injects credentials and guards traffic. Apps reach outside providers only through gateways. See Gateways.
gateways tree
Section titled “gateways tree”The gateways/ directory under the Lodekit root, one
folder per provider; part of the backup tree. See
Your Lodekit folder.
Key-Value Data Store
Section titled “Key-Value Data Store”Every app’s own key-value store (kv-store for
short): the app’s memory — counters, cursors, caches, flags — reached through
the SDK as the kv handle. See
the Key-Value Data Store.
Lodekit root
Section titled “Lodekit root”The one folder (~/Documents/Lodekit by default) holding
the apps, data, and gateways trees side by side. The thing you back up. See
Your Lodekit folder.
Log Store
Section titled “Log Store”Structured log records from your apps and the platform
(log-store for short), kept for a week, written through the SDK as the
logs handle, and read in the dashboard’s Logs view. See
the Log Store.
manager
Section titled “manager”The menubar app that ships and supervises the platform: it runs the engine, shows its status, and opens the dashboard. See The menubar manager.
manifest
Section titled “manifest”The manifest.json at an app’s root declaring its name, app
id, icon, and description — the record that makes a folder an app. See
The manifest.
MCP server
Section titled “MCP server”The agent-facing surface through which your agent drives Lodekit — scaffold, list, open, inspect — and reads app data on your behalf. See MCP tools.
platform
Section titled “platform”The installed subset of Lodekit on your machine: engine, SDK, UI library, dashboard, and manager. What downloading Lodekit puts on disk.
provider
Section titled “provider”The external party a gateway fronts: whoever sits on the other end of a gateway’s base URL. See Gateways.
Relational Data Store
Section titled “Relational Data Store”Every app’s own relational database (db-store
for short): the default home for domain records — entities, relationships,
queries — reached through the SDK as the db handle. See
the Relational Data Store.
runtime
Section titled “runtime”Retired name for the engine — older material may still use it.
scaffold
Section titled “scaffold”To generate a new app’s starter files, conforming to the app contract. Usually your agent does it, through the MCP server. See Your first app.
scoped API
Section titled “scoped API”The per-app HTTP API (/api/apps/<app-id>/…) that backs
the SDK; every app reaches only its own namespace. See the
SDK overview.
The typed client (@lodekit/sdk) an app imports to reach its
services. Works on both sides: in the browser and in server code. See the
SDK overview.
Secret Store
Section titled “Secret Store”The platform-wide encrypted catalog of credentials
(secret-store for short): API keys and tokens you manage in the dashboard,
linked into apps slot by slot and read only by server code through the
secrets handle. See the Secret Store.
server function
Section titled “server function”App code that runs on the server: a TanStack Start
createServerFn, callable from the app’s own pages, with inputs validated
at the boundary. See
Data and server functions.
service
Section titled “service”A capability the engine provides to every app — the db-store, kv-store, file-store, event-store, tasks, gateways, secret-store, settings, log-store — reached only through the SDK. See the services overview.
settings
Section titled “settings”Configuration you view and edit in the dashboard: platform settings plus each app’s declared knobs. Apps read their settings, never write them. See Settings.
shared toolchain
Section titled “shared toolchain”The one build stack (Vite, React, TypeScript, Tailwind) Lodekit installs once and shares across every app, so apps carry no dependencies of their own. See The stack.
The instruction pack your agent loads to learn how to build on Lodekit: what a valid app looks like and how to use the MCP server and SDK. See Connect your agent.
The prescribed way app code is written: TanStack Start + TypeScript + Tailwind through the shared toolchain, importing the SDK and the UI library. See The stack.
Machine-local operational data at
~/Library/Application Support/Lodekit — mainly the log-store. Losing it
costs history, never apps or data. See
File locations.
storage tiers
Section titled “storage tiers”The rule for where data lives, by cost of loss: precious (the backup tree), operational history (State), regenerable (the Cache). See File locations.
UI library
Section titled “UI library”The themed component library (@lodekit/ui) every app
imports, so all apps look like one product. See
Using the UI library.