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
📌
The average developer spends their entire first day — sometimes their first week — just getting a project to run locally. That's not just a productivity tax; it's a morale killer. I (we) built Stacktora because we were tired of watching brilliant engineers waste precious time on setup when they could be shipping code. With Stacktora, onboarding takes minutes, not days.

Spun up a Node Postgres Redis stack in a couple minutes and everything just ran on first try. The Makefile targets are a nice touch, saves a ton of tribal knowledge going to new team members.

Maker

 Thanks so much for giving it a spin! That first-run experience is exactly what we obsess over. If a developer can clone, generate, and get running without fighting their environment, we've done our job.

I'm especially glad you called out the Makefile. It's one of those small details that can eliminate a surprising amount of tribal knowledge and onboarding friction across a team. That's ultimately what Stacktora is about—making your stack repeatable, shareable, and consistent from day one.

Really appreciate you taking the time to test it, and if you have any ideas or rough edges you run into, I'd genuinely love to hear them. We're building this alongside the developer community. 🚀

Maker
We have add a changelog to track our product development —
Maker

We're onto something 🤫

Maker
Today, our CLI is stacktora.json What we’re shipping soon: x-company.stacktora.json We are building a standard, with the community, for the community. Stacktora is becoming a front door to software development and shipping great products.
Maker
Currently building an agentic layer, so that now, even AI agents will read the Stacktora manifest. Helping them, help you.
Maker

stacktora is an npm package you run via npx.

To run your stack defined in stacktora.json, navigate to the directory containing that file and run:

bash

npx stacktora

If the tool requires the config file as an argument (some tools do, some default to stacktora.json), try:

bash

npx stacktora stacktora.json

T

o confirm the correct usage, you can check the help menu first:

bash

npx stacktora --help

It is built for CI and AI agents.

The result below is a DeepSeek test:

(DeepSeek) A few things to keep in mind:

  • Make sure you're in the right folder (where stacktora.json lives).

  • npx will download the package temporarily if you don't have it installed globally. If you want to install it globally instead: npm install -g stacktora then just run stacktora.

  • If you run into any errors (e.g., file not found, permission issues, or invalid JSON), paste the error message back here and I'll help you debug.

Maker

We rolled out out new branding now that we are in full-ship. We hope to make a mark!

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
Maker

Path to production

Local compose is for development. Two 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

The included k8s/ is explicit that this is a starting point — before real production add Ingress + TLS, resource requests/limits, 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.

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/ 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.

1234
Next