Define once. Run everywhere.

Overview

Stacktora is a generator, not a runtime. You define a stack — a runtime, datastores, backing services, optional frontend or mobile client, exact versions and host ports — and Stacktora writes a clean, opinionated set of files you fully own. There's no lock-in: delete your account tomorrow and every generated project keeps running exactly as before.

The whole flow is three steps:

• Define your stack in the wizard (or start from a template).
• Generate — Stacktora produces the bootstrap in your browser. Your source code never leaves your machine.
• Clone & run — make setup then make dev, and you're up.

Quickstart

Once you've generated and downloaded (or pushed) a project, getting it running is two commands:

# 1) copy the example env and adjust any secrets
cp .env.example .env

# 2) install the toolchain + dependencies and build images
make setup

# 3) boot the full stack with hot reload
make dev

Your app is then live at http://localhost:<port>. Run make doctor any time to check that Docker is ready and the host ports are free before starting.

What you get

Every project includes a consistent, production-minded baseline:

stacktora.json is a small, machine-readable record of your stack (no secrets) — handy for version control and future tooling.

Plus optional outputs you can toggle on: a multi-stage Dockerfile, Kubernetes manifests, a fly.toml for Fly.io, a vercel.json for the optional web frontend, a starter supabase/config.toml, a Taskfile.yml, .editorconfig, .pre-commit-config, .envrc (direnv), .gitpod.yml, a .devcontainer (VS Code / Codespaces), and an app/ folder when you add a mobile client.

Make targets

The Makefile is the standard entry point. Run make help to list everything.

Services & datastores

Add exactly what your app talks to. Each selection becomes a pinned, healthchecked service in docker-compose.yml with a named volume for its data and a connection string wired into your .env using the in-network hostname (e.g. postgres, redis).

Datastores

Backing services

In the wizard, use the search box to filter instantly and the category groups to browse. Each service's version and host port is editable in the Configure step.

Frontend & mobile clients

Stacktora covers backend, web, and mobile.

Runtimes

Web frontend (full-stack)

Toggle on a separate frontend and Stacktora adds a second web service alongside your API — Vite + React, Vite + Vue, SvelteKit or Angular — wired to call the API.

Mobile client

Add a mobile app and Stacktora generates an app/ folder with a real client that pings your API. Because phones don't run in Docker, the app runs on your host while the backend runs in Docker.

make app-setup     # install the app's dependencies
make app           # start the Expo / RN / Flutter dev server

Path to production

Local compose is for development. Four optional outputs give you a real path out of it, and they solve different problems — pick based on how you actually want to run this in production.

Kubernetes mirrors your whole stack onto a cluster. Toggle it on and Stacktora generates k8s/manifests.yaml — a namespace, a Secret with your app env, a Deployment + Service for the app, and a Deployment + Service + PersistentVolumeClaim for each stateful datastore. In-cluster hostnames match the Service names, so your connection strings work unchanged.

# build & push your app image (manifests reference app:latest)
docker build -t <your-registry>/app:latest .
docker push <your-registry>/app:latest

# apply everything (creates the namespace)
kubectl apply -f k8s/manifests.yaml

An optional config.resources field ({ "cpu": 1, "memory": 512 } — cores and megabytes) sizes both outputs consistently: K8s gets real requests/limits on the app container (limits match your values, requests are set at half), and Fly's [[vm]] gets a matching size and memory. Leave it out and both keep their previous sensible defaults — nothing changes for existing recipes.

The included k8s/README.md is explicit that this is a starting point — before real production add Ingress + TLS, liveness/readiness probes, an autoscaler, and proper secret management (Sealed Secrets / external-secrets), and prefer managed datastores where you can. Once you're running for real, node-level cost optimization (Karpenter, Cast AI) is the natural next stop — outside what Stacktora generates, but worth knowing about.

Fly.io is the simpler option if you don't want to run a cluster. Toggle it on and Stacktora generates fly.toml — but be clear about what it does: Fly deploys your app container only, not a multi-service stack. It doesn't run docker-compose-style setups from one config file the way a cluster can.

# first deploy — keeps the fly.toml Stacktora generated
fly launch --no-deploy

# datastores are separate managed Fly resources, attached once
fly postgres create --name app-db
fly postgres attach app-db

fly deploy

The included fly/README.md lists the exact attach command for each datastore you selected — Postgres and Redis have first-party managed options on Fly; anything else needs its own small Fly app or an external managed provider, and the README says so plainly rather than pretending otherwise.

Vercel is for the optional web frontend specifically — it needs stack.config.web.enabled on, and has no effect otherwise. Toggle it on and Stacktora generates a root-level vercel.json (installCommand, buildCommand and outputDirectory, all pointed at web/) plus a vercel/README.md. Push to GitHub, then use Vercel's own Import from GitHub — it reads vercel.json automatically, no dashboard configuration needed. Vercel deploys the frontend only; the backend still deploys the way you've configured elsewhere.

Supabase needs postgres in your datastores, and has no effect otherwise. Toggle it on and Stacktora generates a starter supabase/config.toml for the Supabase CLI — project ref, local ports, and (if you enabled seed data) a [db.seed] block pointed at the same docker/init.sql your compose stack already uses. Worth being precise about what this is: it configures a separate, Supabase-managed Postgres instance, not the one in your docker-compose.yml — use it if you want Supabase as your Postgres/Auth/Storage provider instead of, or alongside, local compose. supabase/README.md covers supabase link and wiring the connection string into .env.

Push to GitHub

On a paid plan you can push the generated bootstrap straight to a repository as a pull request, without leaving Stacktora. Connect a repository, and Stacktora commits every file on a new branch and opens a PR for review. You can also download the project as files at any time.

This is also the path to Vercel and Supabase (see Path to production above): push to GitHub, then let each platform's own Import from GitHub pick up the vercel.json or supabase/config.toml Stacktora already generated. Stacktora deliberately doesn't ask for a Vercel or Supabase token itself — a live deploy or a database service key is a much bigger trust ask than a scoped GitHub PR, and each platform is better placed to own the credentials that belong to it.

CLI & stacktora.json

Every project includes a stacktora.json — a small, secret-free record of your stack (runtime, datastores, services, ports, options). The official Stacktora CLI reads that file and regenerates your project's files locally, using the exact same engine as this site — no account, no network, fully offline.

# run without installing
npx stacktora sync     # regenerate all files from stacktora.json
npx stacktora check    # show which files would change, without writing
npx stacktora plan     # like check, but the actual line-by-line diff
npx stacktora doctor   # Docker, port conflicts, missing .env keys, runtime mismatch
npx stacktora status   # live container health (docker compose ps) for the stack running here
npx stacktora recipes  # list curated starting recipes bundled with the CLI
npx stacktora install  # write one as your stacktora.json — e.g. `stacktora install nextjs`
npx stacktora audit    # check stacktora.json against company.stacktora.json policy, if one exists
npx stacktora init     # create a starter stacktora.json here
npx stacktora mcp      # run as an MCP server over stdio — same operations, exposed as tools

This keeps a project's dev environment from drifting — when you change a port or add a service inside stacktora.json and re-run sync, your local files update to match without touching .env or any other untracked file. Add --json to check, plan, doctor, status, recipes, or audit for structured output built for CI pipelines and AI agents, rather than parsing colored terminal text.

Each custom environment variable can also carry a source — a plain-text pointer to where the real value actually lives (a vault path, a 1Password item, wherever your team keeps it). Stacktora never stores the secret itself, only where to find it, and prints it as a comment above the variable in your generated .env and .env.example.

If your formatter is Prettier, an optional tools.codeStyle block (semicolons, quote style, line width) generates a real .prettierrc.json matching your preferences — leave it out and nothing changes from the default output.

Every stacktora.json Stacktora writes includes a $schema field pointing at a real JSON Schema — most editors (VS Code included) pick this up automatically for autocomplete and inline validation while you hand-edit the file, catching typos like an invalid datastore id before you ever run sync.

stacktora recipes and stacktora install <id> pull from the same curated stack list as the templates gallery. Teams can also drop their own recipe files in .stacktora/recipes/*.json — these are listed first and take priority over the bundled ones, so a repo can standardize on its own baseline without waiting on anything server-side.

For enforcing standards rather than just suggesting them, a company.stacktora.json next to the recipe lets stacktora audit check allowed/banned runtimes, tooling, datastores, and services, require a source note on every secret, and require specific output files to be enabled — no server needed, just a file committed to the repo.

Prefer to enforce this in CI without installing the CLI at all? stacktora/audit-action runs the same schema and policy checks as a GitHub Action — add uses: stacktora/audit-action@v1 to a workflow and every pull request gets validated automatically.

Want the same checks live in your editor instead of waiting for CI? The Stacktora VS Code extension validates stacktora.json against company.stacktora.json as you type — inline warnings on the exact field, plus a status bar summary.

Want an agent to work with a project's stack directly, rather than shelling out and parsing CLI output? stacktora mcp runs this same CLI as an MCP server over stdio — read, init, install, recipes, sync, check, plan, audit, doctor, and status all exposed as tools. Point any MCP-compatible client at npx -y stacktora mcp; it's the same package and engine as everything else on this page, not a separate service to host or keep in sync.

All three of those checks (CLI, CI, editor) run somewhere and stop — nothing remembers the result. The Compliance dashboard is where that changes: generate a workspace token, add it to stacktora/audit-action's inputs, and every audit run reports back automatically. A repo shows up the first time it reports, no manual setup, and a repo that quietly drifts out of policy — someone adds a banned datastore six weeks after the fact — shows up as failing with the exact check named, not buried in a CI log nobody's watching. Team and Growth plans can also connect a GitHub App from that same page to turn a failing check into an actual required status check on the repo, so a violation blocks the merge instead of just being visible after the fact. The dashboard's Notifications section can also push a Slack message or email the moment a passing repo starts failing, instead of relying on someone noticing on the page.

Everything above is fully offline by default. Add --remote to recipes or install to also reach the public registry at stacktora.com/registry — a curated, admin-reviewed list of community recipes served from a real database. This is opt-in only; neither command ever touches the network without it. Any signed-in account can propose a recipe at stacktora.com/submit.

Sign in with GitHub & Google

Stacktora supports one-click OAuth sign-in with GitHub and Google — no password required. On the sign-in or create account screen, click either provider button and you will be redirected to that provider to authorise access, then returned to Stacktora automatically.

New accounts: if no Stacktora account exists for your email address, one is created automatically on first OAuth sign-in and a welcome email is sent.

Existing accounts: if you previously signed up with an email and password using the same address, OAuth sign-in will link to that existing account — your library, settings and plan are preserved.

Security: Stacktora never receives your GitHub or Google password. OAuth tokens are exchanged server-side over HTTPS and only your verified email address and display name are stored.

Library & sharing

When you're signed in, every save becomes a version in your library — re-run or roll back any stack at any time, synced across your devices. Anonymous work is kept in your browser until you sign in.

Need a teammate to see a stack? Create a share link — a short /s/<token> URL that opens the exact stack in Stacktora. Share links expose only the stack recipe, never your code or secrets.

Plans & limits

The full generator and every output file are free — paid plans add scale and team features, not core capability.

Team and Growth are single workspace subscriptions, not per-seat — the owner pays once and invited members get full workspace features at no extra cost. See the pricing page for the full comparison.

Account & data

Your account holds only your email, a hashed password, and the stack recipes you save — not your application or its data. Connections use HTTPS, passwords are hashed, and we never sell data or run ads.

Billing

All payments run through Stripe (a PCI-DSS Level 1 certified processor). Card details are entered on Stripe's secure checkout and are never seen or stored by Stacktora — we keep only a Stripe customer reference. Manage your card, invoices, or cancellation any time from the billing portal in your account.

Deleting your account

Open the account menu and choose Delete account, confirm with your password, and we permanently erase your profile, every saved project and version, and your share links — and immediately cancel any active subscription. It's irreversible and complete (in line with GDPR, CCPA and PIPEDA). Files you've already generated onto your machine or pushed to your repos are unaffected.

Get help

Stuck or have a question? Browse the FAQ, open the app, or email support@stacktora.com.