# Examples

One working template per deployment shell. All three consume the same `dist/`, produced by
`corpora build` on a machine that has the signing key, and none of them holds a key or keeps
state.

| Template | Runtime | You operate |
| --- | --- | --- |
| [`worker/`](worker) | Cloudflare Workers | Nothing. A script, replicated. |
| [`container/`](container) | Node in a container | An image and a scheduler |
| [`standalone/`](standalone) | Node under systemd | A machine |

Which to pick, what changing your mind later actually involves, and the two ways a deployment
can look healthy while serving the wrong thing: [docs/DEPLOYING.md](../docs/DEPLOYING.md).

## Depending on Corpora

**Corpora is not published to npm.** Each template declares `"corpora": "file:../.."`, which
resolves while the template sits inside this repository. Copy one somewhere else and that path
stops meaning anything, so change it to whichever of these suits you:

| | `dependencies` entry | Notes |
| --- | --- | --- |
| Clone alongside your project | `"corpora": "file:../corpora"` | What the reference deployment uses. Verified. |
| Pack a tarball | `"corpora": "file:./corpora-0.1.0.tgz"` | `npm pack` in this repo. Verified, and what the container image build needs, since a sibling path is outside the Docker build context. |
| Straight from git | `"corpora": "git+ssh://…"` | Untested here. |

The container template is the one where this bites hardest: `npm ci` runs *inside* the image, so
a `file:` path pointing outside the build context cannot resolve. Put the tarball next to the
Dockerfile and `COPY` it in with `package.json`.