Deployment¶
Use the smallest deployment shape that fits your engagement.
1. Local single-host (recommended for development)¶
reach server start --role both --port 8000
reach dns serve --host 0.0.0.0 --port 53 --db-zones
Good for feature testing and low-friction local demos.
2. Multi-host (recommended for team/engagement use)¶
All services point to the same DB:
REACH_DB_URL=postgresql://user:pass@DB_IP:5432/reach
Example split:
- admin host:
reach server start --role admin --host ADMIN_IP --port 8001 - public host:
reach server start --role public --host PUBLIC_IP --port 8000 - dns host:
reach dns serve --host DNS_IP --port 53 --db-zones
This setup improves isolation and allows separate network controls.
3. Dockerized backend-only stack (recommended for local operator devices)¶
This shape runs REACH Core (public + admin) in one container, with persistent SQLite state and local plugin/preset mounts.
Start:
docker compose up -d --build
Validate:
curl -s http://127.0.0.1:8001/api/health
Stop:
docker compose down
Notes:
- DNS is also out of scope here; run it separately only if needed.
- DB state is persisted in the Docker volume
reach_data. ./pluginsis mounted read-only so local plugin edits are available immediately.
Cloudflare Tunnel pattern (public HTTP listener on :8000):
cloudflared tunnel --url http://127.0.0.1:8000
4. Dockerized core server via CLI¶
The server command can also launch Docker directly:
reach server start --role both --docker --image reach:local
Common flags:
--rebuildrebuild image before run--nameset container name--dockerfilechoose Dockerfile path--contextchoose build context--detach/--no-detachrun background or foreground
Security baseline¶
- Bind admin to private interfaces only.
- Use strict firewall rules around DNS and admin ports.
- Use short-lived infrastructure and engagement-specific domains.
- Keep explicit authorization artifacts for every deployment.