Stacks / Creating Stacks

Build your own stack

A stack doesn't contain any project files of its own — it's a thin manifest, anesis.stack.json, that names one template and an ordered list of already-published addons. Creating one is mostly a planning exercise: get the composition and order right, then let the CLI drive the same template and addon pipelines it always uses.

References existing templates + addonsOrdered addon listPinned addon inputsNo new file-processing logic

Open the builder Using stacks

1. Plan the composition

Everything a stack references — the template and every addon — must already exist in the registry before you write the manifest. A stack cannot introduce new template or addon behavior, only sequence existing ones.

Pick exactly one template — the same name you'd pass to anesis new <name> <template>. It must already exist in the registry.
List the addons to layer on top, in the order they should run. Each id must already be published — a stack never bundles addon or template source, only references to them.
If an addon declares requires, include those addons in the list too (earlier in the order) — the CLI refuses to run a stack that skips a hard dependency.
Decide which addon inputs you want to pin with inputs, so users aren't re-prompted for choices the stack already made, and which ones should stay open.

2. Use the builder instead of hand-writing JSON

The stack builder walks through the same decisions as the manifest, then generates both the terminal command sequence and a downloadable anesis.stack.json.

Pick a project name and a template — the builder lists every template currently in the registry.
Select the addons to layer on top. If an addon requires another one you haven't selected, the builder flags it with an “Add required addons” shortcut.
Configure each selected addon's install inputs — the builder reads each addon's manifest and renders the right field for every input (text, boolean, select).
Optionally add extra terminal commands — anything not covered by an addon, like bun add tailwindcss or a one-off codegen call. These land in the copyable command list so you (and anyone following your stack by hand) don't lose track of them, but they are not written into anesis.stack.json since the manifest format only understands template + addon references.
Copy the generated command block to sanity-check the sequence yourself, then download anesis.stack.json as your starting manifest.

Extra terminal commands are a builder convenience

The anesis.stack.jsonschema only understands a template plus addon references — there's no field for raw shell commands. The builder's Extra commands step appends free-form lines like bun add tailwindcssto the copyable command block so you don't lose them while assembling a stack, but they stay out of the downloaded manifest and out of anything you publish. If a command needs to travel with the stack, wrap it in a real addon instead.

3. Fill in the manifest fields

Whether you download it from the builder or write it by hand, every stack manifest has the same shape.

{
  "schema_version": "1",
  "id": "nest-drizzle-stack",
  "name": "NestJS + Drizzle",
  "description": "NestJS starter with Drizzle ORM already wired up.",
  "template": "nestjs",
  "addons": [
    { "id": "dotenv", "command": "install" },
    {
      "id": "nest-drizzle",
      "command": "install",
      "inputs": { "driver": "postgres", "use_ssl": "false" }
    }
  ]
}

Field rules

id is the identifier used everywhere in the CLI — anesis new my-app --stack <id>, anesis stack install <id>, etc. Keep it URL-safe: lowercase letters, numbers, and hyphens.
name is the human-readable title shown in the registry UI — spaces and casing are fine here.
description is a one-line summary shown on stack cards and the detail page.
addons must be in the exact order you want them applied — the CLI does not reorder or sort the array for you.

4. Get the addon order right

Order matters because each addon in the list runs sequentially, the same way anesis use would run it by hand.

If addon B declares "requires": ["A"], A must appear earlier in the addons array — the CLI checks anesis.lock as it works through the list and stops with a clear error if a dependency is missing. The builder handles this for you automatically: selecting an addon that requires another one prompts you to add the dependency, and the generated command list is always ordered so requirements run first.

5. Validate before publishing

Stacks don't have a local link/test command the way templates and addons do (anesis template link, anesis addon link) — validation means actually running the sequence once.

Run the copied commands yourself in a scratch directory — scaffold the template, apply each addon in order, and confirm nothing errors out or needs a manual fix.
Double-check every addons[].id exists in the registry under that exact id — a typo fails at scaffold time for anyone using the stack, not at publish time.
If you added extra terminal commands in the builder, fold anything essential into an actual addon (or note it in your stack's README) — the published manifest won't carry them.
Push the finished anesis.stack.json (plus an optional README) to a GitHub repo before publishing — the registry stores a reference to that repo and commit, not the file itself.

6. Publish

Once the manifest lives in a GitHub repo and you've confirmed the sequence works end to end, publish it the same way as any other registry entry.

anesis stack publish https://github.com/owner/repo
anesis stack update https://github.com/owner/repo

See Publishing a stack for the full flag list and what happens on the backend, and the command reference for every stack subcommand.

Next steps

If the template or an addon you need doesn't exist yet, build that first.

Creating Templates — build the base project the stack scaffolds first.
Creating Addons — build the addons the stack applies on top, in order.
Once both exist in the registry, open the builder to assemble and download your stack manifest.

Using Stacks

Local State & Schema