# deploy/

The configuration that makes this application a running service, under version
control.

## Why this directory exists

`STAGING-STATE.md` recorded `mechcomp.service` as delivered at
`deploy/mechcomp.service` on 2026-09-11. The unit was real; the directory was
not. The file existed only on CT 100, so the repository claimed to hold
something it did not, and the only way to answer a question about the service
was to read the container.

That is the failure mode this directory closes. The repository is the single
source of truth. Where these files and the hosts disagree, the disagreement is
a finding — and the direction of travel is from here outward, not from the host
back.

## What is here

| File | Lives on | Installed at |
|---|---|---|
| `mechcomp.service` | CT 100 | `/etc/systemd/system/mechcomp.service` |
| `nginx/mechanical-compiler.conf` | CT 101 | `/etc/nginx/sites-available/mechanical-compiler`, symlinked from `sites-enabled/` |

Both are imported **verbatim** as they ran on 2026-09-12. The first commit of a
configuration file records reality, not intentions; any improvement is a later
diff that can be read against a known-good starting point.

## What is deliberately not here

**`/etc/mechcomp/mechcomp.env`.** It is the deployment's own answers —
`MECHCOMP_BIND`, `MECHCOMP_PORT`, `MECHCOMP_BASE_URL` — and it is
`root:mechcomp 0640` because a deployment's bindings belong to the deployment.
A committed copy would be a second source of truth for the one file that is
supposed to differ between instances. `ENVIRONMENT.md` documents the keys; the
values stay on the host.

**Certificates and keys.** `/etc/ssl/mechcomp/` on CT 101 holds a leaf signed by
the local staging CA. Keys are never committed.

## Two facts about the nginx vhost worth knowing before editing it

**CT 101 does not know the public name.** Its `server_name` is
`mechanical-compiler.dev.infra`, a hosts-file name resolvable on `srv-b`, CT 100
and CT 101 only, and its certificate is signed by the local staging CA. Public
TLS terminates at `wg-pk`, which proxies inward over the WireGuard tunnel to a
DNAT on `srv-b`. `dev.mechcomp.kane-il.us` appears nowhere in this file and does
not need to.

**Both server blocks are `default_server`.** CT 101 answers whatever `Host`
arrives, which is why the public name works without being named. That is
acceptable because `10.20.0.0/24` is a portless service bridge with LAN traffic
dropped, so the only thing that can reach port 443 is the tunnel — but it means
`server_name` is documentation here rather than a filter, and adding a second
site to CT 101 will require that to change.

## Applying a change

Infrastructure mode (`PROCESS.md` §2). One command group, read-only first, a
rollback copy of the file before editing, `nginx -t` before `reload`, and the
change proven from outside the container rather than from within it.

A change to either file lands in the repository first and is copied outward.
Editing on the host and back-porting reintroduces exactly the drift this
directory was created to end.