Infrastructure and Deployment

Overview

The Membership platform is designed for cloud-native deployment on Hetzner Cloud (Kubernetes) while maintaining the option for on-premises installation. The infrastructure supports a small team (4 people) by maximizing automation: infrastructure as code, CI/CD pipelines, automated testing, and zero-downtime deployments. The initial target market is Germany and Austria, with the architecture ready for multi-region European expansion.

Deployment Architecture

Cloud-Native (Primary)

Container Architecture

Each component runs in its own Docker container:

On-Premises Option

For organizations that require data sovereignty or have existing infrastructure:

A single Docker Compose file is provided for small deployments (< 500 members, single organization). For larger deployments, the Kubernetes manifests are the recommended path.

Hetzner Cloud Specifications

The primary production deployment uses Hetzner Cloud, selected for its German data center locations, competitive pricing, and GDPR compliance (data stays in Germany).

Locations: - Primary: Nuremberg (nbg1) -- all production workloads - DR: Falkenstein (fsn1) -- backup replication, failover target - RTO: 4 hours | RPO: 1 hour

CI/CD Pipeline

Pipeline Architecture

Pipeline Stages

Total pipeline target: < 50 minutes from push to production.

Deployment Strategy

• Development: Direct deployment on every merge to develop branch
• Staging: Automatic deployment on every merge to main branch
• Production: Canary deployment (10% traffic for 15 minutes, automatic rollback on error rate > 1%)

Rollback

• Automated: If canary deployment shows elevated error rates or latency, Kubernetes automatically rolls back to the previous version
• Manual: helm rollback membership <revision> for instant rollback to any previous release
• Database: Flyway migrations are forward-only. Rollback scripts are pre-written for each migration and tested in CI.

Docker Compose (Local Development)

# docker-compose.yml (for local development)
services:
  postgres:
    image: postgres:18-alpine
    environment:
      POSTGRES_DB: membership
      POSTGRES_USER: membership
      POSTGRES_PASSWORD: ${DB_PASSWORD:-devpass}
    ports:
      - "5432:5432"
    volumes:
      - postgres-data:/var/lib/postgresql/data
      - ./db/init:/docker-entrypoint-initdb.d
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U membership"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]

  rabbitmq:
    image: rabbitmq:4-management-alpine
    ports:
      - "5672:5672"
      - "15672:15672"
    environment:
      RABBITMQ_DEFAULT_USER: ${RMQ_USER:-guest}
      RABBITMQ_DEFAULT_PASS: ${RMQ_PASS:-guest}

volumes:
  postgres-data:

Monitoring and Observability

Metrics (Prometheus + Grafana)

Infrastructure Monitoring (Icinga)

In addition to Prometheus/Grafana for application and business metrics, Icinga provides classical infrastructure monitoring with a focus on external service checks and SSL/TLS certificate oversight:

Icinga deployment: Self-hosted on Hetzner infra node (Docker container). Checks run from outside the Kubernetes cluster to provide an independent monitoring perspective. Integrates with Grafana for unified dashboards and with Telegram/email for alerting.

Monitoring layers: Prometheus handles application metrics and pod-level health (inside the cluster). Icinga handles infrastructure checks and external endpoint monitoring (outside the cluster). Together they provide defense-in-depth observability.

TLS Certificate Management (Dehydrated)

All HTTPS/TLS certificates for origin servers (Hetzner Load Balancer, internal services) are managed via Dehydrated, a lightweight ACME shell client for Let's Encrypt:

Dehydrated configuration: - Runs as a cron job (daily check, renews at 30 days before expiry) - DNS-01 challenge via Cloudflare API hook (supports wildcard certificates) - Certificates deployed to Hetzner Load Balancer via Hetzner API post-hook - Kubernetes Ingress certificates updated via kubectl post-hook - All renewals logged and monitored by Icinga (certificate expiry check) - Failure alerts sent via email and Telegram

Why Dehydrated over cert-manager: Dehydrated is simpler to operate for a small team, works both inside and outside Kubernetes, and the team already has operational experience with it. cert-manager remains a viable alternative for pure Kubernetes environments.

Alerting Rules

Logging

• Structured JSON logging via SLF4J + Logback
• Log aggregation via Loki (Grafana stack) or ELK (Elasticsearch, Logstash, Kibana)
• Correlation IDs: Every request gets a unique X-Request-Id header, propagated through all service calls and logged in every log line
• PII redaction: Automatic log filter that masks email addresses, IBANs, and phone numbers in log output
• Retention: Application logs retained for 30 days, audit logs retained for 7 years

Health Checks

The application exposes Spring Actuator health endpoints:

Database Infrastructure

PostgreSQL Configuration

Flyway Migrations

Database schema changes are managed exclusively through Flyway migrations:

• Location: src/main/resources/db/migration/
• Naming: V{version}__{description}.sql (e.g., V001__initial_schema.sql)
• Execution: Automatically on application startup (dev/staging) or via init container (production)
• Validation: flyway.validateOnMigrate=true ensures schema consistency
• Rollback scripts: Every migration V{n}__*.sql has a corresponding R{n}__*.sql rollback script, tested in CI

Redis Configuration

Environment Configuration

Development Environments

Configuration Management

Configuration follows the 12-factor app methodology: all environment-specific values are injected via environment variables, never hardcoded.

Secret management: Application secrets (database passwords, API keys, JWT private keys, encryption keys) are stored in Kubernetes Secrets encrypted with SOPS (Sealed Secrets) and mounted as environment variables into pods at startup. Team-accessed credentials (admin panels, third-party portals, infrastructure access) are stored in Vaultwarden (self-hosted Bitwarden-compatible password manager). For on-premises deployments, HashiCorp Vault serves both purposes. See Chapter 13 for the full credential management model.

CDN and Static Assets

CDN Strategy

Offline Mode

Mobile apps support offline operation for critical workflows:

Scalability

Horizontal Scaling

Multi-Region Readiness

The initial deployment targets Hetzner Cloud Nuremberg (nbg1) for Germany/Austria, with disaster recovery in Falkenstein (fsn1). The architecture supports multi-region expansion:

• Data residency: PostgreSQL replication to regional instances. Tenant data pinned to a specific region.
• CDN: Edge locations across Europe for static assets.
• DNS routing: GeoDNS to route users to nearest API cluster.
• Compliance: Per-region configuration for tax rules, payment methods, and data protection requirements.

Regional expansion is not required for v1.0 but the architecture avoids decisions that would prevent it (e.g., no region-specific hardcoding, all timestamps in UTC, locale-aware formatting at presentation layer).