Moving templates between the repository and storage.
Templates are code-owned. Shipped templates live in applications/main/src/templates/ and
are listed in applications/main/src/templates/registry.ts. There is no in-app or HTTP write path
(the template viewer is read-only).
Publishing happens on deploy. Explicit application initialization (the first request or worker that awaits readiness — never a read or a build-time import) compiles every registry template and compares it with the stored latest registration for that key:
[templates] published <key> (new) …);[templates] published <key> execution=<old>→<new> presentation=<old>→<new>).One log line is written per published key. Versions are immutable and retained: a process that
is already running stays bound to the execution it started on (binding.executionId); only new
starts use the newly published version. Publishing happens inside the deployment-owner guard, and
publishing identical digests is idempotent, so concurrent web and worker initialization is safe.
A versioned template is different: its new version is published only by the release step
(npm run release, run at the start of the process-platform start command), together with its migration of every process,
live and finished, in one transaction; startup only publishes another build of the version already
published. See template versions and migrations.
Entries that exist only in storage (db-only, from the former editor) are left untouched.
npm run templates:status
| State | Meaning |
|---|---|
same | repo and storage agree |
DIFFERS | storage has a different copy than the repo (the next deploy/restart will publish the repo copy) |
MISSING | in the registry but not yet published to the configured store |
db-only | legacy entry authored through the former editor; no repo definition |
updatedAt is ignored in the comparison — it is stamped on every write and would
otherwise make everything differ.
npm run templates:seed -- --force # every repo template npm run templates:seed -- --force curve-topup ib-payouts # only these
Startup already publishes changed templates, so this is rarely needed. It exists to publish into a store without restarting the app (for example a local store, or to check a change before a deploy).
The command prints what it is about to overwrite and asks first; --yes skips the
prompt for scripting. Prefer naming keys. Without --force, seed publishes only keys without a
latest registration.
npm run templates:export -- spell-process-test-app
Writes applications/main/src/templates/<key>.ts from the stored copy. Use it to bring a legacy
db-only template (authored in the former editor) into version control. It is not shipped until it
is also listed in REPO_TEMPLATES in applications/main/src/templates/registry.ts; the next deploy
then publishes it.
The commands read MONGO_URL exactly as the app does, so they act on whichever backend
your .env points at — local files, a local Mongo, or a copy of production.
Check before running anything destructive:
grep MONGO_URL .env
See develop against prod data.
Application initialization compiles and publishes the repository registrations. The standalone
backend instead needs explicit compiled registrations in its configuration (PROCESS_BACKEND_CONFIG),
published with the same digest comparison. Isolated verification can add trusted compiled
registrations with PROCESS_EXTRA_TEMPLATES. See
deployment bindings.
db-only is inferred from absence in
REPO_TEMPLATES, not from a field on the template.