This commit is contained in:
@@ -0,0 +1,36 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user