37 lines
1.3 KiB
Markdown
37 lines
1.3 KiB
Markdown
# 0003: Development infrastructure
|
|
|
|
- Status: Accepted
|
|
- Date: 2026-07-12
|
|
|
|
## Context
|
|
|
|
Developers need reproducible PostgreSQL and object-storage services without requiring host-level
|
|
database installation. Application source does not yet exist, so containerizing the whole
|
|
toolchain would add friction without value.
|
|
|
|
## Decision
|
|
|
|
Run PostgreSQL 18.4 and an S3-compatible object store in Docker Compose. Pin reviewed image
|
|
versions, enable health checks, use persistent named volumes, bind host ports to loopback, and use
|
|
explicitly development-only credentials. Run Node applications on the host during normal
|
|
development.
|
|
|
|
This Compose file is a development baseline, not the production deployment topology.
|
|
|
|
## Alternatives
|
|
|
|
Locally installed services make onboarding inconsistent. Containerizing editors and the complete
|
|
Node toolchain is unnecessary at this phase. Kubernetes is premature for a modular monolith
|
|
foundation.
|
|
|
|
## Consequences
|
|
|
|
Docker is required for infrastructure testing but not for code-only validation. Production
|
|
backups, high availability, secret injection, image digests, and deployment topology require a
|
|
later decision.
|
|
|
|
## Migration implications
|
|
|
|
The future Core storage service targets S3 behavior rather than a provider-specific client, so
|
|
development and production providers can change after contract testing.
|