# FR24 ingest compose skeleton

## Goals
- PostgreSQL + PostGIS as the single database
- separate ingest placeholder service
- healthcheck/status scaffolding
- predictable volume layout
- environment-driven configuration

## Proposed runtime layout
- `compose/` — Docker Compose manifests and env examples
- `db/postgres/` — persistent PostgreSQL data
- `db/init/` — bootstrap SQL for extensions and initial schema
- `ingest/` — capture/preprocess implementation lives here later
- `logs/ingest/` — service logs
- `logs/status/` — heartbeat/status artifacts
- `backup/` — pg_dump and restore artifacts

## Environment variables
- `POSTGRES_DB`
- `POSTGRES_USER`
- `POSTGRES_PASSWORD`
- `POSTGRES_PUBLISHED_PORT`
- `RAW_RETENTION_DAYS`
- `OVERLAP_MINUTES`
- `CAPTURE_SOURCE`
- `TZ`
- `APP_ENV`

## Status scaffolding
The current skeleton includes a minimal `status` container that writes a heartbeat file. This is only a placeholder and should be replaced or extended by a real monitoring endpoint later.

## Open questions
- whether capture and preprocess should become separate services immediately
- whether API/viewer belongs in the first compose cut or later
- whether a dedicated monitoring container is needed before hardware verification