Let an agent set it up

You can delegate the boring part

This repository was written so a coding agent can read it. It ships a map file (llms.txt), a rules file (AGENTS.md), a step-by-step runbook (docs/agent-setup.md) and a ready-made prompt (prompts/agent-setup.md). Instead of learning each setup command yourself, you paste one prompt and the agent follows the runbook on your computer.

Delegating the typing does not mean skipping the checks. The agent works inside your copy of the repository and must report what it did with evidence. The sections below show what a good report looks like, so you stay in charge of the result.

One honest limit: this automated path sets up the Web app and its backend — the server that handles accounts and data. The prompt and runbook ship with the Web repository and with the All Platforms monorepo. Mobile-only and Desktop-only checkouts carry their own scoped llms.txt and platform setup guides instead.

• Set up the Mobile app locally
• Run the Desktop app

What you need first

Finish the preparation guide first: Node.js, Git and an editor installed, the GitHub invitation accepted, and the supastack folder downloaded to your computer. The agent works inside that folder, so everything in Before you start still applies.

You also need a tool that can act as a coding agent — an editor with a built-in AI coding agent (an AI IDE), or an agent that runs in your terminal (an agent CLI). Any current agent-capable tool works; the prompt already spells out what it must read and run, so you do not need to write instructions yourself.

Finally, you need one of two ways to run the app: Node.js 22 or newer installed on your computer — the path the preparation guide set up — or a container tool such as Docker or Podman, which runs the app inside containers and needs no installed Node.js. You pick one inside the prompt, and the agent follows it.

Copy the prompt, fill in two blanks, paste

Open prompts/agent-setup.md in the editor — it lives in the prompts folder at the top level of the supastack folder, next to llms.txt. Select its whole text and copy it.

Two placeholders need your choices. Replace <SETUP_PATH: docker | podman | host> with one of docker, podman or host — host runs the app directly on your computer using the Node.js you installed; docker or podman runs it inside containers. Replace <DEPLOY_TARGET: coolify | vps-docker | local-only> with where the app should end up — local-only runs it on this computer and deploys nothing, which is the right choice for a first look.

Paste the edited text into the agent's chat and send it. The filled-in first line below shows the docker plus local-only choices; the numbered steps under that line stay exactly as the file ships.

Stand up this supastack checkout end to end for **docker**
and deploy it to **local-only**.

What the agent does with the prompt

The prompt points the agent at the runbook and the security rules, then tells it to work through them in order and prove each phase. In plain terms, the agent:

• Reads the repository map (llms.txt), the project rules (AGENTS.md) and the credential-handling rules (docs/agent-security.md) before touching anything.
• Creates the .env configuration files with node scripts/setup-env.mjs. The helper copies only from .env.example, so the agent never invents setting names, and it preserves secrets you already have instead of overwriting them.
• Starts Postgres — the database the app keeps accounts and records in — and the app itself, as containers for the docker or podman path or with commands on your computer for the host path.
• Runs the database migrations — the commands that create the app's tables — before the first real sign-in, because an account created before the tables exist is a broken one.
• Verifies each phase at a checkpoint and finishes with a report marking every check PASS, FAIL, BLOCKED or NOT RUN, with the output that backs it up.

What you check in the agent's report

A good report shows evidence, not claims. Look for the real health response and command output behind each PASS — not a sentence like 'everything works'.

The prompt tells the agent to stop and report after the same step fails twice — not to work around the failure — and to ask you before anything destructive, such as wiping a database. If your agent keeps improvising after repeated failures, stop it and take the first error to the troubleshooting guide.

Two things must never appear: a security feature switched off to silence an error, and a secret value such as a password or key printed into the chat or the report. If you see either, treat the run as failed.

Keep the demo and a real sign-in separate in your head. The /dashboard demo's local reference flow needs no database, so it can pass on its own; creating an account at /auth works only after migrations ran. 'The demo worked' is not yet 'accounts work'.

If you would rather do it by hand

Every step above also exists as a click-by-click tutorial. Run the five-minute Web guide for the first demo, then Web local setup for the full local environment with a real database.

An agent is still useful after setup even when it did not do the installing — the agent workflow guide covers everyday tasks such as new screens, restyling and reviews.