0003 - Hybrid Local Development with Docker Compose
| Classification | CONFIDENTIAL |
| Organization | DroneUp |
| Date | April 2026 |
| Status | Pending |
Decision
Use a hybrid Docker Compose approach for local development: new/modified backend services run locally in Docker Compose, while stable services (geodata, etc.) are proxied from the dev environment.
Context
Three approaches were debated:
| Option | Pros | Cons |
|---|---|---|
| Fully self-contained Docker Compose (Remek) | No external dependencies, fast AI iteration loops, portable demo | Must replicate or mock every service; team collaboration harder (pull changes constantly) |
| Reuse deployed Uncrew services (Ihor) | Zero new infra, database exists, CI/CD exists | Deployment friction, VPN dependency, slower iteration |
| Hybrid: local Docker Compose + proxy to dev (Ihor’s PR) | Fast iteration on new code, stable services stay deployed, AI agents get local feedback | Requires network bridging config, some services need both local and remote awareness |
The team chose hybrid because:
- Frontend runs via
yarn(hot reload), backend services run in Docker Compose - Stable services (geodata, airspace API) proxied from dev — no need to replicate
- New Talos services iterate locally with fast rebuild (
docker compose build) - AI agents can inspect local Docker logs for debugging
- Ihor demonstrated a working PR with this setup in
uncrew-apollo-frontend
Consequences
- Docker Compose file lives in a central location (Talos platform repo or Apollo frontend)
- Engineers need a
.envfile with dev environment secrets for proxy connections - Services not running locally must be accessible via dev environment (VPN or direct)
- Frontend proxy config routes API calls to either local or remote services
Last updated on