# Access — reverse_proxy (Caddy)

Rendered from the role's `access__*` data (`roles/reverse_proxy/defaults/main.yml`) —
the source of truth that also drives `/check-access`. Regenerate from the data; edit the
data, not the tables. Host: `askari` (off-site Hetzner; ADR-007/016).

## Access paths

The documented ways in, by tier (rendered from `access__*`):

| Tier | Path | Invocation |
|---|---|---|
| primary | `wt0` mesh SSH | `ssh askari` (over the NetBird mesh — pending M5; see notes) |
| secondary | LAN/WAN SSH from `ubongo` | `ssh ansible@askari` (from the control node; Hetzner firewall allows only ubongo's WAN) |
| — | container exec + compose | `docker compose -p reverse_proxy -f /opt/services/reverse_proxy/docker-compose.yml ps` / `… exec caddy sh` |
| — | logs | `docker logs caddy` now; Loki labels `{service: caddy}` once the ADR-018 pipeline lands |
| — | admin API | n/a — Caddy admin API bound to container localhost `:2019`, never exposed (`access__api.enabled: false`) |

## Break-glass

Mesh-and-LAN-independent fallback for this host's class (recorded, not routine):

- **Hetzner rescue system + Cloud Console** (VNC) for `askari` — boot the rescue image
  or attach the web console from the Hetzner Cloud panel if SSH is unreachable.

## Operational notes

- **Mesh not yet enrolled (M5).** Until `askari` joins the NetBird mesh, the `wt0`
  primary path does not exist — the only SSH route is the secondary one (from `ubongo`'s
  WAN IP, which the TF-managed Hetzner Cloud Firewall allowlists). Promote `wt0` to
  primary once M5 lands.
- **Caddy wedged / bad config:** the Caddyfile is rendered read-only by Ansible; to
  recover, fix `reverse_proxy__routes` in `group_vars` and re-run the role (it reloads
  Caddy via the handler). To inspect live config: `docker exec caddy caddy validate
  --config /etc/caddy/Caddyfile`.
- **Cert issuance failing:** check that port 80 is reachable from the internet (HTTP-01
  needs it) and watch `docker logs caddy` for ACME errors before assuming a routing fault.