Busabase organizes trusted knowledge as nodes. Every node appears in the dashboard navigation. Creation and lifecycle operations use the Change Request flow; content save behavior depends on the node type.
Whiteboard is a full Excalidraw workspace for free-form thinking. Draw shapes, arrows, text, and diagrams without forcing the content into a table or fixed graph. The scene is stored as versioned JSON in the node's metadata.whiteboardDocument; image insertion stays disabled until binary assets move to object storage.
Workflow turns a repeatable process into a versioned graph. Nodes can trigger on an event, call a Webhook, reference a sandboxed Webhook function rule, evaluate a condition, wait, request approval, describe an action, or end with an outcome. Connections store labels and machine-readable branch outcomes. Execution mode, concurrency, timeout, and error policy are stored separately from the graph so a future runner can reuse the definition without changing its shape. P0 saves and validates the definition but does not execute it.
HTML combines a source editor with an immediate preview. It works well for forms, email or landing-page prototypes, and small interactive concepts. Preview code runs inside a sandboxed iframe; it cannot access the parent Busabase application.
Drive is a pure file-tree node. It uses the same file listing, read, change-request, and merge machinery as Skill, but its seed is intentionally minimal: one README.md file.
Skill remains backward-compatible. Existing /skills/* API routes, SkillVO, contract schemas, and core handler exports keep the same names and shapes. The implementation now delegates to the shared file-tree kind.
AirApp is Busabase's Instant App format: an agent-authored, live interface that opens inside the workspace without a separate deployment. It is less like a conventional application with a fixed release cycle and more like a living presentation over your workspace data. Use it for a dashboard, briefing, data story, review surface, or any purpose-built view that would be clearer as an interface than as another document.
No deployment loop. Once an agent's proposed files are approved and merged, open the AirApp in Busabase and its current version starts automatically. There is no separate hosting setup and no need to keep a local pnpm dev terminal open.
The view stays connected to Busabase. An AirApp can read the current data in the workspace through Busabase's same-origin API. Instead of copying a Base into a static export, the app can present the latest approved records whenever it runs.
Conversation remains the editing interface. Ask Codex, Claude Code, or another connected agent to move a section, add a metric, or tell the story differently. The agent proposes changes through the normal Change Request flow; after approval, the same AirApp runs the new version.
The app is durable even though the runtime is instant. Its files, history, and relationship to workspace data remain in Busabase. You can reopen it, keep iterating, and reuse it instead of losing a one-off localhost prototype.
This makes an AirApp especially useful when people need to see and understand live agent work, not just click through a rigid set of controls. The interface can still be interactive, but it does not have to become a separately deployed product before it is useful.
AirApp is also a file-tree node — same file listing, read, change-request, and merge machinery as Skill and Drive. An agent writes or edits the app's files through the normal ChangeRequest flow, the same way it edits a Skill or Drive. A human then opens the node and sees three tabs: App (the default — a Run button and a live preview iframe), Files (a read-only file browser + code viewer), and Logs (streaming install/start output).
Clicking Run executes the app in the reviewer's own browser, not on a server: Nodepod (@scelar/nodepod) is a Web Worker + Service Worker based Node.js runtime that installs the app's declared dependencies, starts its server, and streams the output into the Logs tab. Once the server reports ready, the App tab's preview iframe points at a same-origin virtual URL (/__virtual__/...) serving the running app.
The App tab's toolbar has two more controls once a run is ready: a fullscreen toggle for reviewing the preview at full size, and a "pin to side panel" button that docks the live preview into a persistent side panel on the right — the app keeps running there while you navigate anywhere else in the workspace, and multiple AirApps can be pinned at once as separate tabs. The run itself also survives ordinary navigation: switching to a different node and back (or reopening the same AirApp) does not restart it — it's still running and the preview picks up right where it left off, so reviewers don't need to click Run again just because they looked at something else.
Nodepod is not a full Node.js — it's Node's API surface reimplemented to run inside a browser Web Worker. That single fact explains everything below: anything that needs a real OS process, a real native binary, or a real headless browser will not work, no matter how it's configured. Anything that's pure JavaScript (plus WASM-compiled fallbacks) generally does.
Confirmed working — safe defaults for a new AirApp:
A plain Node HTTP server. The seed template is Hono + @hono/node-server — no bundler, no build step, npm install && node server.js and it's serving. This is the safest starting point for anything backend-heavy.
node:sqlite (Node's built-in SQLite module) for real, queryable state — no external database dependency, and it isn't a native binary (it's compiled into Node itself).
Vite, pinned to vite@7.3.1, for a bundler-based frontend dev server. Older Vite (^5.4.10/4.5.5) crashes on boot inside Nodepod with Cannot destructure property 'createServer' — this was an esbuild/native-binary resolution bug that Nodepod's own upstream fixed for the versions of esbuild that ship with Vite 7. Do not use @vitejs/plugin-react (see below) — configure JSX through Vite's own built-in esbuild transform instead:
Trade-off: no React Fast Refresh — edits trigger a full page reload instead of preserving component state. Hono can also be mounted directly as Vite middleware (via configureServer) for a one-process full-stack pattern — also confirmed working under the same vite@7.3.1 pin.
@vitejs/plugin-react (Babel-based React Fast Refresh, real component-state-preserving edits) — was confirmed broken ([BABEL] .length is not a valid Plugin property, a real bug in how Nodepod loaded Babel plugins) through Nodepod 1.9.5. Fixed upstream in 1.9.6 — re-verified live on 1.9.9 with a full click-through test (the demo's counter button works, edits preserve state). If you want real Fast Refresh rather than the full-reload trade-off above, use this instead.
@vitejs/plugin-react-swc (SWC-based Fast Refresh, avoiding Babel) — fails with Failed to load native binding. @swc/core ships a platform-native binary; Nodepod has no OS to load it into. Still broken (identical error) as of Nodepod 1.9.9.
Any tool whose install or dev-server-boot step needs a platform-native binary — the SWC failure above is one instance of a general rule. If a package's postinstall downloads or compiles a native artifact (a native ML runtime, an image-processing library with a native build, etc.), assume it won't run, even if npm install itself succeeds.
Any tool that needs to spawn a real headless browser or a real OS subprocess — for example, HeyGen's HyperFrames CLI. Its full HTML-to-MP4 render pipeline depends on Puppeteer (a real headless Chrome) and FFmpeg (a native binary), architecturally incompatible with a Web-Worker sandbox regardless of configuration. Its lighter hyperframes preview command (no Puppeteer/FFmpeg) was spike-tested directly: npm install genuinely succeeds, but running it crashes with TypeError: require is not a function — a genuine Nodepod runtime limitation, not something fixable from the AirApp's own code. Still broken (identical error) as of Nodepod 1.9.9.
Next.js has not been tested directly (no official Nodepod example exists to adapt). Its default compiler, SWC, is independently already known-broken here for the reason above — its Babel fallback is no longer known-broken (see the Fast Refresh entry above), so a from-scratch Next.js-with-Babel AirApp might be worth trying, but hasn't been.
The seed gallery is a live reference, not just documentation. A fresh Busabase install seeds working demos (Hono API server, two Vite + React variants, Hono mounted in Vite, node:sqlite) and keeps the still-broken ones above (SWC, HyperFrames) as real, runnable nodes rather than deleting them — clicking Run on any of them reproduces the actual failure. If Nodepod fixes one of these upstream too, the demo starts succeeding instead of erroring, without any change needed on the Busabase side — exactly what happened with the Babel demo above.
Running always reflects the node's current (merged/HEAD) file tree — previewing a pending, not-yet-merged ChangeRequest's files isn't supported yet for any node type in Busabase.
Run requires a secure context. Service Workers — what Nodepod uses to intercept preview/virtual-server requests — only register in a browser "secure context": https:, or the literal hostname localhost/127.0.0.1/[::1]. Accessing the dashboard over plain HTTP through any other hostname (a LAN IP, a custom DNS name mapped to your machine, a tunnel domain) is not a secure context even though it resolves to the same server, so the service worker silently fails to register and clicking Run 404s. Use https:// or http://localhost:<port>.
File is the simplest node: it just points at one Asset in the deduped Asset library (name, MIME type, size, and download URL). There is no file tree — for a folder of files, use Drive instead.
Hover any node in the sidebar and a small drag handle appears — grab it to drag the node up or down among its siblings, or drop it onto a folder to move it there instead.
Hovering a node in the sidebar reveals its drag handle.
A drop has to make sense — you can't drop a folder inside its own subfolder, and you can't drop a node onto something that isn't a folder. Everything else is fair game.
One thing worth knowing: reordering and moving happen immediately — they don't go through the change-request review that every other edit on this page goes through. It's treated as tidying up navigation, not changing content, so there's nothing to approve.
Node creation and lifecycle operations, reviewed file changes, and supported document edits land in the Inbox. Rich-node content saves are permission-checked and audit-logged, but Whiteboard, Workflow, and HTML metadata updates are direct in P0 and do not yet create Inbox items.
