Stacktora
Define once, run anywhere.
Start new thread

Stacktora - Define once, run anywhere.

by•
This is developer onboarding infrastructure. The end of configuration drift for every engineer — it’s over. Stacktora isn't a docker-compose generator. It's the workflow that keeps every developer's environment identical, current, and runnable — from the first clone to the hundredth hire. Define your stack — languages, databases, services — and Stacktora generates a production-ready, runnable bootstrap: docker-compose, Makefile, CI, and 15+ files. Clone, to running in minutes.

Add a comment

Replies

Best
Maker

Define once. Run everywhere.

Stacktora turns the stack you pick into a complete, runnable bootstrap — docker-compose, Makefile, Dockerfile, CI and 15+ files — so your whole team runs the identical environment, every clone, every time.

The teaser copy itself is sharp, that line about ending configuration drift lands hard. Curious how the 15+ generated files stay coherent as stacks get more complex without turning into another maintenance burden.

Maker

 — the generated files are never meant to be hand-maintained individually — stacktora.json is the single source of truth, and every file (compose, Makefile, CI, README, the works) is deterministically regenerated from it. So "staying coherent" isn't something you have to manage yourself, it's the actual mechanism. Change a runtime version or add a service in the recipe, re-run `stacktora sync`, and the whole set updates together instead of drifting apart the way hand-edited configs do.

That's also why the CLI has a `check` command separate from `sync` — it diffs your working files against what the recipe would generate, so you can see drift before it becomes a production surprise, even if someone on the team hand-tweaked a file directly.

The honest tradeoff: if you need something the generator doesn't support yet, you're stuck editing a generated file directly (which then technically "drifts" until the recipe catches up) or waiting on us to add it. We're expanding coverage steadily, but it's worth knowing going in.

Appreciate you actually digging into the mechanics instead of just kicking Stacktora's tires — exactly the kind of question I like getting on launch day.

Ezra

Maker

🚀 Big news for our Product Hunt community: Stacktora is now available in 14 languages.

When we launched, developers from around the world asked: "When can I use Stacktora in my language?"

Today, that answer is "now."

We've added full interface support for:

🇺🇸 English · 🇫🇷 Français · 🇩🇪 Deutsch · 🇪🇸 Español · 🇵🇹 Português · 🇮🇳 हिन्दी · 🇮🇳 ਪੰਜਾਬੀ · 🇮🇩 Bahasa Indonesia · 🇯🇵 日本語 · 🇰🇷 한국어 · 🇨🇳 中文 · 🇻🇳 Tiếng Việt · 🇮🇹 Italiano · 🇹🇷 Türkçe

Same Stacktora. Same reproducible environments. Now in your language.

Ship globally. Start locally. → []

Maker

Image versions are pinned, services have healthchecks, and depends_on gates the app on healthy dependencies — so "clone to running" is minutes, not a debugging session.

Maker

Launch Video!

Maker

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

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 — 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 . 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? 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.

Everything above is fully offline by default. Add --remote to recipes or install to also reach the public registry at — a static, no-account list of community recipes. This is opt-in only; neither command ever touches the network without it.

Maker

The bigger bet

Where we said stacktora.json was headed — and how much of it is already real.

Maker

Can you submit a stack recipe on Stacktora?

Yes — lets any signed-in account propose a recipe. It lands as pending review; the Stacktora team approves or declines it before it appears in the public registry. You can track the status of your own submissions right on that page. In the meantime, .stacktora/recipes/ also lets you and your team share recipes internally with zero setup — see stacktora recipes in the CLI docs.

Maker
Maker

Two-factor authentication

Scan the code into your authenticator app (Google Authenticator, 1Password, Authy…), or enter the code manually.

First
Previous
1234
Next