# Deployment topology

See ADR-003 for the reasoning behind this. This doc states the current, factual state — update it the moment reality changes.

## Current state (M0)

**Nothing is deployed anywhere yet.** There is no application code, no Coolify connection, no webhook. This document exists now so the repo is shaped correctly once there is something to deploy.

## Intended long-term topology

| Branch | Environment | Trigger | Deployed by |
|---|---|---|---|
| `main` | Production | Merge to `main` | Coolify, via Gitea webhook |

- **Gitea** is the Git source of truth. All code, config, and infra-as-code live there.
- **Coolify** handles build and deployment only — it has no independent source of truth, it builds whatever `main` currently contains, using `infrastructure/docker/docker-compose.prod.yml`.
- **No staging environment yet.** The MVP is read-only (Knowledge Agent, no write actions), so the blast radius of a bad production deploy is low — wrong answers, not broken infrastructure. A staging environment is deferred until **v0.5**, when the Execution Guard starts allowing real write actions against homelab infrastructure. At that point, this doc should be updated to add a `staging` branch mapped to a second Coolify app.

## What's explicitly not done yet

- Coolify is not installed/connected to this repo.
- No webhook secret exists.
- `docker-compose.prod.yml` is scaffolded and valid but not referenced by any live Coolify app.

This section should be deleted, not just checked off, once Coolify is actually wired up — at which point this doc gets rewritten to describe the real, live setup (including a `coolify-setup.md` companion doc with the actual one-time configuration steps taken).