The platform, not the app

How Doable works

This page is about Doable itself, the builder and runtime this project lives in. For how this specific app is put together, see Architecture instead.

What Doable is

Doable is a visual app builder. It scaffolds a project like this one, runs its dev server, gives it a backend for data, auth, and files, and deploys it to a live URL, all without a terminal. You work in Doable's own panels: Preview, Infrastructure, and Env, while the code underneath stays a normal Next.js project.

Preview and the dev server

Doable starts and restarts the dev server outside this sandbox; nothing here runs npm run dev manually.
It detects whichever port the server comes up on and shows the running app in the Preview pane.
The Preview pane auto-reloads as files change, the same hot reload a local Next.js dev server gives you, just without opening a terminal.

The doable client

Every project gets one client, imported as import { doable } from "doable-do", already configured. It replaces a database, an auth library, and a file store:

Surface	What it does
doable.data	save / list / get / update / remove on a named collection, e.g. doable.data.save("stack", {...}). No schema, no migration: a collection exists on first write.
doable.auth	signUp, signIn, signOut, and user() for the current session. A signed-in user's saved data is private to them automatically.
doable.files	upload(file) stores an upload and returns an id; url(id) resolves it to a fetchable URL.

Saved data is visible in Doable's Infrastructure panel. There is no ORM, no DATABASE_URL, and no migrations to write.

Connection, kept out of the code

The doable client needs a backend address and a credential. Doable injects both as environment variables rather than asking you to paste them anywhere:

Variable	Purpose
DOABLE_BACKEND_URL	Server-side address of the Doable backend this project talks to. Injected automatically, never typed in by hand.
DOABLE_KEY	Server-side credential pairing this project with its backend. Injected automatically.
NEXT_PUBLIC_DOABLE_BACKEND_URL / NEXT_PUBLIC_DOABLE_KEY	Browser-visible counterparts the doable client uses on the client side.

Names only, never values: this page does not print what those variables currently hold.

Local preview vs. published app

While previewing, saved data lives in small local files. Once the app is deployed, the same data layer is backed by a real database instead. The two behave the same way from the app's point of view; the only difference you might notice is that a screen listing thousands of saved items can feel a touch slower in local preview than it does live.

Deploying

Each project carries a .doable.json file recording where it deploys and how the last deploy went:

Field	Meaning
url	The live address this project deploys to (one fixed subdomain; every deploy updates the same URL).
deploy.target	Where deploys go, e.g. "cloud".
lastDeploy.status / .ok / .at	Outcome and timestamp of the most recent deploy, written back after each one.

Deploying ships the current code to that fixed URL; every later deploy updates the same address rather than creating a new one.

Agent tooling

Doable also exposes a set of tools to the AI agent working on a project, things like previewing, deploying, reading logs, and querying saved data directly. These are agent-side tools for building the app, not a public API this app calls at runtime.