Provision reproducible staging and production infrastructure

[Vinosaamaa]

Parent

#107 (identified by #238)

Owner direction and deployment decision

The owner has delegated product and infrastructure decisions and requires free resources for the initial launch. No hosting account, domain or staging environment has been provisioned. This replaces the previous assumption that paid managed PostgreSQL/Redis and an owned chanter.app domain were already available.

Prepare a reproducible single-host deployment for an Oracle Always Free A1 allocation, subject to actual account eligibility and capacity. The current published allowance is 2 OCPU and 12 GB memory. Use self-managed PostgreSQL and Redis with explicit persistent volumes, backups and restoration procedures; serve the frontend and API/WebSockets through a same-origin Caddy HTTPS entry point. Cloudflare remains optional for an owned domain. Do not introduce paid plans, credit-card charges or automatic top-ups.

The free host can operate one environment at a time. Separate staging and production Compose projects, secrets and data; validate ephemeral staging in CI and document the stop/switch procedure and downtime when staging must run on the host. Persistent simultaneous staging, high availability and managed databases are not promised by this budget.

Acceptance criteria

• Every application deploy unit has a reproducible non-root OCI image, health/readiness probes, resource limits, graceful shutdown and pinned runtime version.
• Versioned configuration defines the frontend, API/realtime services, PostgreSQL, Redis, secret injection and persistent data; environment identity prevents staging/production volume or secret overlap.
• The provisioned public hostname serves the SPA over valid TLS; API and realtime WebSockets work through the public entry point without exposing internal service ports.
• HTTPS/security headers, allowed origins, firewall boundaries, secret permissions and optional Cloudflare settings are auditable. Do not claim an unowned domain or untested dynamic-DNS address as deployed.
• CI builds and scans release images on free public runners. Deployment uses an immutable release identity, serialized migration ownership, health verification and a tested rollback to the prior compatible release.
• Production does not start unused Redpanda or MinIO components. Each retained dependency has an owning code path and runbook. Store Course Resources durably and quarantine unsafe uploads #244 owns durable private resource storage.
• Secrets and production data never enter repository files, build logs, frontend bundles or demo seed scripts.
• The decision records free-tier limits, resource sizing, capacity/reclamation risks, single-host failure domain, downtime and upgrade triggers.
• Actual account provisioning, HTTPS smoke, migration/rollback smoke and production readiness are recorded separately from repository/CI checks; the issue stays open until the required deployment proof exists.

Blocked by

• Make CI, product E2E, and dependency checks trustworthy release gates #241

Provisioning checkpoint

Complete all repository implementation and dry-run validation first. Account identity, provider eligibility and any required authentication cannot be invented or bypassed. Ask for only a concrete required account action after the deployment package is ready. No paid resources are authorized.

Source: Oracle Always Free resources.

[Vinosaamaa]

Owner direction for the launch program, recorded during the current implementation:

• Make product, design and technical decisions autonomously; the existing design documents may be revised when evidence supports a better product.
• Use free hosting and free resources for the initial release. No paid tier, automatic recharge or billable provider usage is authorized.
• No hosting or provider infrastructure exists yet. Account provisioning and deployment remain part of the launch work.
• Keep AI provider/model choice configurable, including OpenAI, Anthropic, xAI/Grok, compatible endpoints and a no-provider/local option.
• Investigate subscription-backed access only through each provider's supported product integration. Do not describe chat subscriptions as API credits or collect consumer session cookies.
• Retain issue-linked implementation, detailed design and implementation records, system review, exact-head verification and Engineering receipts.

#242 remains the active integration slice. Hosting feasibility is owned by #243; provider abstraction and usage modes are owned by #248. These directions supersede the old design's assumption that deployment must preserve all separate runtime processes.

[Vinosaamaa]

The release-package security gate found 33 high/critical dependency findings in the original backend. The independent repair is #319 / PR #320; no advisory suppression was added. Its integrated local verification passed 360 backend tests and complete coverage of 749 packaged libraries across all ten services, with zero high/critical vulnerabilities or secret findings. The hosted package-security gate also passed; final full CI and review remain required.

PR #315 is rebased locally onto the merged UI and provider foundation. Its next native build waits for #320. The production compatibility policy advances to epoch 3 because new PBKDF2 password hashes cannot be read by the older application. The subsequent #244 quarantine migration requires epoch 4. Deployment tooling tests pass with this policy change.

Public hosting, HTTPS/SMTP provider proof, full-stack capacity and production cutover remain unverified. This is progress evidence, not a launch-complete receipt.