The API deployable had no packaging of its own: its runtime deps lived only in the integration's dev group, so there was no way to deploy the service without dragging the test venv along. Package the API as a container image (Dockerfile, multi-stage slim build, non-root) with the deployable's own manifest api/requirements.txt, and run it via deploy/compose.yaml with the SQLite file on the named volume nestquest-db so recreating the container keeps household data. Secrets are supplied by the environment (ignored deploy/.env, example with placeholder names only). TLS/reverse proxy, Authentik wiring and network separation are later Feature 17 tasks; the port is bound to localhost until they land.
16 lines
661 B
Plaintext
16 lines
661 B
Plaintext
# Runtime dependency manifest for the NestQuest API deployable.
|
|
#
|
|
# The monorepo's pyproject.toml carries fastapi/uvicorn/pyjwt/httpx in
|
|
# the INTEGRATION's dev group only (so the test venv can exercise the
|
|
# API); they are deliberately NOT integration runtime dependencies.
|
|
# Per that manifest's own comment, the API deployable declares its own
|
|
# runtime dependencies HERE — this file is what the container image
|
|
# installs (see the Dockerfile at the repository root).
|
|
#
|
|
# Compatible ranges mirroring the dev group's floors; the API is a
|
|
# server, so these are the only packages its runtime needs.
|
|
fastapi>=0.115
|
|
uvicorn>=0.30
|
|
pyjwt[crypto]>=2.9
|
|
httpx>=0.28
|