Deployment strategy using kubernates

## Ticket 1: Supercharged Single-Server Production Deployment (Docker Compose)

**Priority:** High
**Type:** Chore / Infrastructure

### Description

Implement a highly resilient, self-healing, and production-grade deployment model on a single physical host using Docker Compose. This bridges the operational gap between basic Docker setups and Kubernetes without adding excessive infrastructure complexity or overhead.

### Business Value

Allows CoopData to run in a reliable, production-grade environment on a single low-cost server, saving up to $9,000/year compared to AWS EKS, while maintaining high availability, self-healing containers, and minimal update downtime.

### Technical Implementation Steps

#### 1. Container Healthchecks

- Add native `healthcheck` stanzas inside `docker-compose.yml` for critical services:
- `backend`
- `postgres`
- `keycloak`
- Example for Backend API:

```yaml
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/api/v1/health"]
interval: 15s
timeout: 5s
retries: 3
start_period: 10s
2. Auto-Healing Service
Integrate a lightweight auto-heal container such as willfarrell/autoheal.
Mount the host's /var/run/docker.sock.
Configure it to monitor container health states.
Automatically restart any container that enters an unhealthy state.
3. Cgroup Resource Limits
Configure resource constraints under the deploy.resources.limits block in the Compose file.
Define CPU and memory limits for each container.
Restrict the Staging environment resource limits, if co-located, to prevent staging workloads from starving the Production environment.
4. Log Rotation

Configure Docker log rotation globally in /etc/docker/daemon.json or explicitly in docker-compose.yml.

Example:

logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
5. Zero-Downtime Updates
Incorporate the docker-rollout CLI plugin or Traefik/Nginx path-swap scripts.
Allow backend and frontend containers to be updated without routing disruptions.
Target a maximum connection interruption window of under one second.
6. Offsite Database Backups
Configure a host-level system Cron job.
Execute pg_dump against the PostgreSQL container nightly.
Compress the resulting dump.
Securely upload the backup to offsite object storage such as:
AWS S3
A secondary MinIO bucket
Ensure backup retention and access controls are configured appropriately.
Acceptance Criteria
All containers successfully boot and report their health status via docker ps.
Forcing an unhealthy state on the backend API triggers autoheal to restart the container in under 30 seconds.
Containers are bounded by memory constraints and cannot consume resources beyond their defined limits.
Code updates can be pushed and rolled out with a maximum connection drop window of under 1 second.
Nightly PostgreSQL backups are automatically archived and uploaded to offsite storage.
Backup failures are detectable through logs or monitoring.
Production and staging resource consumption remain isolated when running on the same host.