Commit and share your pipeline

git add .scarn .devcontainer
git commit -m "Add Scarn pipeline"

Your pipeline and step definitions are source code. Commit them, and review changes to them in pull requests like any other file.

What’s in .scarn/

• Directorymy-repo/

  • Directory.scarn/

    • scarn.jsonc the project, as owner/slug — commit
    • .env.example secret variable names, no values — commit
    • .env your real secret values — never commit
    • Directorypipeline-builder/

      • <your-pipeline>.ts one file per pipeline — commit
      • <your-pipeline>.json its build, what you publish — commit
      • default.ts and default.json, the default automation — commit
      • package.json, tsconfig.json, .gitignore — commit
      • Directorynode_modules/ ignored

        • …
      • push.ts ignored
      • bun.lock ignored, like every lockfile
  • Directory.devcontainer/

    • devcontainer.json commit, if your steps use it

What’s ignored, and why

.scarn/pipeline-builder/.gitignore is written for you and leaves out generated files only:

Ignored	Why
node_modules/	Installed dependencies
Lockfiles (bun.lock, package-lock.json, pnpm-lock.yaml, yarn.lock, …)	scarn pipelines push picks its runtime from whichever lockfile it finds here, so a committed one would force every teammate onto the same package manager
push.ts	Regenerated by every scarn pipelines push
work-item-fields.ts	Pulled from the platform
.run-offer-gate-failure.json	A failed post-push dry run, read and deleted by your next design session

The studio also leaves a helper, .scarn-studio-collect.mjs, in that directory. It isn’t a definition and the .gitignore doesn’t list it yet; leave it out of your commit.

Secrets: .env.example vs .env

.scarn/.env.example exists only if a step needs a secret. The designer writes the variable names there, never values — commit it so teammates know what to set. .scarn/.env holds the real values; you create it, Scarn never writes or uploads it, and nothing ignores it for you. Add it to your repository’s .gitignore:

.scarn/.env

Which runtime reads it: Secrets.

When a teammate picks it up

They get the definitions from git. Then, from the repository root:

1. Sign in with scarn auth login. The committed scarn.jsonc already names the project.
2. Copy .scarn/.env.example to .scarn/.env and fill in the values.
3. Install the builder’s dependencies with their own package manager — npm install (or bun/pnpm/yarn) inside .scarn/pipeline-builder/. scarn pipelines design does this for them.

To change the pipeline, they re-run the designer or edit the files and push. If the server has definitions that never made it into git, bring them in with scarn pipelines pull. It asks before overwriting files and writes its own layout (one steps.ts, one file per pipeline), so review the diff before you commit it.