6.6 KiB
6.6 KiB
Deployable Runtime Image Contract
Purpose
Define the minimum deployable runtime contract for backend and frontend images. This document is the canonical source for what must be present, what must not be present, and what behavior deployment environments can rely on.
This contract supports issue PP-58 and establishes a baseline for future automation work under epic #66.
Scope
Included:
- Backend deployable runtime image requirements.
- Frontend deployable runtime image requirements.
- Runtime entrypoint, ports, health behavior, startup behavior, and environment contracts.
- Explicitly disallowed non-runtime tooling classes in deployable images.
Excluded:
- CI workflow rewiring.
- Test execution redesign.
- New runtime hardening implementations not required to define contract.
Backend Runtime Contract
Runtime Artifact Definition
- Container build source:
Dockerfile.backend. - Build shape: two-stage build with a dependency stage and a minimal runtime stage.
- Runtime base image:
python:3.14-slim. - Runtime process:
uvicorn backend.main:app --app-dir /app/src --host 0.0.0.0 --port 8000. - Exposed runtime port:
8000.
Required Runtime Dependencies
The runtime artifact must include versions compatible with:
fastapi==0.120.2psycopg==3.2.12sqlalchemy==2.0.44uvicorn==0.38.0
The lockfile in backend/uv.lock is the dependency source of truth.
Required Runtime Environment Contract
DATABASE_URLis required.- Accepted form:
postgresql://...or SQLAlchemy async form. - Runtime normalization to async psycopg dialect is performed in
backend/src/backend/database.py.
- Accepted form:
BACKEND_REQUIRED_PYTHONis optional and defaults to3.14.
Backend Health and Startup Behavior
- Startup must fail fast if runtime policy checks fail.
- Source:
backend/src/backend/main.pylifecycle (lifespan) validation.
- Source:
- Health endpoint contract:
GET /healthreturns200with{"status":"healthy","database":"connected"}when database probe succeeds.GET /healthreturns503with{"status":"unhealthy","database":"disconnected"}when probe fails.
- Compatibility diagnostics endpoint:
GET /compatibilityreports policy and package compatibility status.
Backend Runtime Checklist
- Runtime image built from
Dockerfile.backend. - Runtime process is uvicorn serving
backend.main:appwith app dir/app/srcon0.0.0.0:8000. DATABASE_URLis set in deployment runtime.GET /healthbehavior matches contract.- Startup fails on runtime policy mismatch.
- Deployable artifact excludes CI-only and test-only tooling classes.
Frontend Runtime Contract
Frontend Runtime Artifact Definition
- Container build source:
Dockerfile.frontend(targetproduction). - Build shape: two-stage build with a dependency/build stage and a minimal nginx runtime stage.
- Runtime base image:
nginx:alpine. - Runtime process:
nginx -g "daemon off;". - Exposed runtime port:
80. - Runtime artifact payload: static assets from
/app/distcopied to/usr/share/nginx/html.
Frontend Runtime Entry and Routing Contract
- Nginx configuration source:
frontend/nginx.conf. - SPA routing behavior must use fallback to
index.htmlfor unknown routes. - API requests under
/api/are proxied to backend service endpointhttp://backend:8000/in compose deployments.
Frontend Health and Startup Behavior
- Startup expectation: nginx process starts and serves static assets on port 80.
- Runtime health expectation for deployment checks:
GET /should return200and serve frontend entry document.
- API proxy readiness is dependent on backend runtime availability.
Frontend Runtime Environment Contract
- No required runtime environment variables are defined for nginx static serving.
- Build-time frontend mode is production-oriented and not part of runtime env contract.
Frontend Runtime Checklist
- Runtime image built from
Dockerfile.frontendproduction target. - Runtime process is nginx serving on port 80.
- SPA route fallback behavior is present.
/api/proxy behavior aligns with backend service wiring.- Deployable artifact excludes CI-only and test-only tooling classes.
Disallowed Tooling Classes in Deployable Runtime Images
Deployable runtime artifacts must not include tooling classes that are only needed for CI, validation, or local development workflows.
Disallowed classes:
- Linters and formatters (example: ruff, eslint, prettier).
- Type checking and static analysis tooling (example: pyright, vue-tsc).
- Test frameworks and test drivers (example: pytest, vitest, playwright).
- Browser test binaries and CI runner helper tools.
- Build-only package managers and build toolchains not needed at runtime.
Note:
- Multi-stage builds may use these tools in build stages.
- These tools must not be required by or present in final deployable runtime image layers.
Acceptance Criteria Traceability (PP-58)
- Backend runtime requirements are documented and approved.
- Covered by: "Backend Runtime Contract" and backend checklist.
- Frontend runtime requirements are documented and approved.
- Covered by: "Frontend Runtime Contract" and frontend checklist.
- Runtime contracts include health endpoint expectations and startup behavior.
- Covered by: backend health/startup section and frontend health/startup section.
- Non-runtime tool classes are explicitly excluded from deployable image
definition.
- Covered by: "Disallowed Tooling Classes in Deployable Runtime Images".
Enforcement Hooks
Current enforcement implemented in CI:
- Dockerfile target boundary checks:
- Script:
scripts/check-dockerfile-boundaries.sh - Workflow:
.gitea/workflows/cicd.yaml
- Script:
- Deployable runtime image purity checks:
- Script:
scripts/verify-deployable-image-purity.sh - Workflow:
.gitea/workflows/cicd.yaml - Checks include binary presence and profile-specific package metadata probes to detect CI/development tooling leakage.
- Script:
- Runtime black-box integration checks against deployed backend container:
- Workflow:
.gitea/workflows/cicd.yaml(integration-testsjob) - Inputs: deployable backend commit tag reference and immutable digest reference from main build dispatch.
- Assertions: digest/tag consistency and live endpoint behavior for
/,/compatibility, and/healthon started runtime containers.
- Workflow:
Future follow-up automation under epic #66 may expand this with:
- Contract tests that assert documented health/startup behavior.
- Additional policy checks for drift detection and broader runtime compliance.