Examples

Each example is a whole repository root in miniature: the environments file, the list of secrets it reads and the files its kind adds. They are exactly what replicator init --profile <name> writes (see The command line), and a test keeps them that way: every example is read the same offline way a new repository is, built with its secrets in a dry run, and checked by replicator doctor, so none of them can go stale unnoticed.

The files are in the repository under examples/infra/.

ExampleProfileWhat it shows
static-sitestatic-siteA static site on its own staging and production names: the site’s project and domain in replicator.config.ts, how the built site is published in its static block, and an empty secrets block to fill in when it needs one.
workerworkerAn edge Worker with a text variable, a secret and a domain per stage. worker/index.mjs is uploaded as it is. sessionKey is generated on the runner; zoneId is a setting you give in a private values file.
site-and-workersite-and-workerBoth in one file: the site on the apex, the Worker on its api name, one set of stages, one secrets block.

Start from one:

replicator init --profile worker --name shop --zone shop.example \
  --account <state account id> --ref <40-character release commit>
replicator infra secrets ensure --config replicator.config.ts --stage staging \
  --values-file <file holding zoneId=…>
replicator infra diff --config replicator.config.ts --stage staging

What every example does the same way

  • Stages. staging and production; production keeps its data when the program drops it.
  • Names. replicator.hostnames gives the apex to production and a flat-dashed name (api-staging.shop.example) to the others.
  • Secrets are declared. The secrets block lists each name the file reads with ctx.secret. replicator infra secrets check says what a stage lacks, and infra diff and infra deploy stop with every missing name and the command that sets it before planning anything. A setting that is not a credential (a zone id) is listed under plain so an address built from it may be an output.
  • The account is named. state.accountId is the account that holds the state; the examples carry a made-up one, which you replace.
  • A caller workflow pinned to a release is written by init but not kept in the examples: its pins are yours. See Modular repositories.

The full list of options behind these files is in the configuration reference.