Der Open-Source-Infrastructure-Stack: Production-Grade PostgreSQL, Redis, MinIO, n8n und Observability

Von Null auf DevOps in 2026: Der komplette Karrierepfad von Linux bis zur AI-Infrastructure

Ein vollständiger Lernpfad vom absoluten Anfänger bis zum produktionsreifen DevOps-Professional. Beginnen Sie mit den Linux-Grundlagen, arbeiten Sie sich über Container und Kubernetes vor, ergänzen Sie Observability und Automatisierung und schließen Sie mit AI-Infrastruktur ab. Alles Open-Source, vendor-neutral, inklusive zugeordneter Zertifizierungen und produktionsreifer Stacks.

Jede Produktionsanwendung benötigt dieselbe Kerninfrastruktur: eine Datenbank, einen Cache, Object Storage, Workflow-Automatisierung und Observability. Im Jahr 2026 sind die besten Tools für jede dieser Schichten Open-Source, selbst hostbar und in großem Maßstab bewährt.

Dieser Leitfaden zeigt, wie sie zusammenpassen – nicht nur als isolierte Dienste, sondern als ein kohärenter Infrastruktur-Stack, den Sie auf jedem Linux-Server bereitstellen können. Welche Fähigkeiten für das Deployment und die Verwaltung dieses Stacks erforderlich sind, finden Sie in Zero to DevOps in 2026: The Complete Career Path from Linux to AI Infrastructure. Warum diese Fähigkeiten so wichtig sind, lesen Sie in Linux, DevOps, and AI: Why Fundamentals Matter More Than Ever in 2026.

Inhaltsverzeichnis

• Die Architektur
• Layer 1: Der Reverse Proxy — Ihr einziger Einstiegspunkt
• Layer 2: Die Datenschicht — PostgreSQL, Redis, MinIO
• Layer 3: Workflow-Automatisierung — n8n
• Layer 4: Observability — Metriken, Logs und Dashboards
• Layer 5: Automatisierung und Konfigurationsmanagement
• Kostenaufschlüsselung
• Erste Schritte

Die Architektur

Jeder Pfeil repräsentiert eine Netzwerkverbindung. Jeder Dienst verfügt über persistenten Speicher. Jede Komponente sendet Metriken und Logs an die Observability-Schicht. Dies ist keine theoretische Architektur – so sehen Produktions-Deployments in Startups, mittelständischen Unternehmen und sogar in einigen Enterprise-Teams aus, die Open-Source gegenüber einem Vendor Lock-in bevorzugen.

Layer 1: Der Reverse Proxy - Ihr einziger Einstiegspunkt

Jeder Dienst hinter Ihrer Infrastruktur sollte unzugänglich sein, außer über einen einzigen, gehärteten Einstiegspunkt. Dies ermöglicht Ihnen eine zentralisierte TLS-Terminierung, Rate Limiting, WAF-Schutz und Zugriffskontrolle.

Was er übernimmt

• TLS-Terminierung: Automatische Let's Encrypt-Zertifikate, automatisierte Erneuerung
• Routing: Domain-basiertes und Pfad-basiertes Routing zu internen Diensten
• Sicherheit: HTTP-Header (CSP, HSTS, X-Frame-Options), Rate Limiting, Bot-Erkennung
• WAF: Verhaltensbasierte Erkennung via CrowdSec – SQLi, XSS, Brute-Force, Credential Stuffing

Nginx vs Traefik

Für die meisten selbst gehosteten Infrastrukturen ist Nginx + Certbot + CrowdSec die am meisten praxiserprobte Kombination. The SSL Reverse Proxy Stack bündelt genau dies mit Produktions-Defaults.

Was es kostet

Ein Reverse Proxy verbraucht etwa 128 MB RAM und vernachlässigbare CPU-Leistung. Der CrowdSec Bouncer benötigt weitere 64 MB. Gesamt: ~200 MB RAM für eine vollständig gesicherte Ingress-Schicht.

Layer 2: Die Datenschicht - PostgreSQL, Redis, MinIO

PostgreSQL - Das relationale Rückgrat

PostgreSQL ist im Jahr 2026 die fortschrittlichste Open-Source-relationale Datenbank. Sie bewältigt alles, vom Anwendungsstatus bis hin zu Analytics-Workloads.

Die Produktionskonfiguration ist entscheidend. Die Standard-postgresql.conf einer Paketinstallation ist für einen Laptop optimiert, nicht für einen Server. Wichtige Einstellungen, die angepasst werden müssen:

# Memory
shared_buffers = 512MB          # 25% of available RAM
effective_cache_size = 1.5GB    # 75% of available RAM
work_mem = 16MB                 # Per-operation sort memory
maintenance_work_mem = 128MB    # For VACUUM, CREATE INDEX

# Write-ahead log
wal_level = replica             # Required for replication
max_wal_size = 2GB
min_wal_size = 512MB
wal_compression = zstd          # Saves ~50% WAL space

# Planner
random_page_cost = 1.1          # For SSD storage
effective_io_concurrency = 200  # For SSD

Backup-Strategie:

• Tägliche pg_dump mit Komprimierung (spart ~60 % Speicherplatz)
• 30-Tage-Aufbewahrung auf der lokalen Festplatte
• Optionaler S3-Sync via MinIO für die Off-Site-Wiederherstellung
• Point-in-Time-Recovery via WAL-Archivierung für kritische Workloads

Der Database Foundation Stack bündelt PostgreSQL mit genau diesen Tuning-Einstellungen sowie automatisierten täglichen Backups und S3-Sync.

Redis - Cache, Queue, Session Store

Redis sitzt zwischen Ihrer Anwendung und Ihrer Datenbank, absorbiert Lesezugriffe und bietet einen schnellen In-Memory-Datenzugriff.

Wofür man es einsetzt:

• Cache-Schicht: Caching von API-Antworten, Datenbankabfrage-Ergebnissen
• Session Store: Benutzersitzungen außerhalb des Anwendungsprozesses
• Message Queue: n8n Queue-Modus, Sidekiq, Bull
• Rate Limiting: Sliding-Window-Counter (atomares INCR + EXPIRE)
• Pub/Sub: Echtzeit-Benachrichtigungen, WebSocket-Broadcasting Persistenz-Konfiguration:

# Enable both RDB snapshots and AOF append-only log
save 900 1       # Snapshot after 900s if >=1 key changed
save 300 10      # Snapshot after 300s if >=10 keys changed
save 60 10000    # Snapshot after 60s if >=10000 keys changed
appendonly yes   # Append-only log for durability
appendfsync everysec  # Good balance of performance vs durability

Überlegungen für die Produktion: Redis ist single-threaded. Eine einzelne Redis-Instanz verarbeitet ca. 100K Ops/Sek. Für einen höheren Durchsatz verwenden Sie Redis Cluster oder mehrere Redis-Instanzen, die nach Anwendungsfall gescharded sind (Cache vs. Queue vs. Sessions).

MinIO - S3-kompatibler Object Storage

MinIO bietet dieselbe API wie AWS S3, Google Cloud Storage und Azure Blob Storage – läuft jedoch auf Ihrer eigenen Hardware und ohne Egress-Gebühren.

Was auf MinIO gespeichert werden sollte:

• Backups: Datenbank-Dumps, Dateiarchive, Konfigurations-Snapshots
• Medien: User-Uploads, Bilder, Videos, Dokumente
• Logs: Langzeitarchivierung von Logs (nach Ablauf der Loki-Retention)
• Anwendungsdaten: Jede Datei, die Ihre Anwendung persistent speichern muss

Erasure Coding schützt Ihre Daten ohne Hardware-RAID. Ein MinIO-Setup mit 4 Laufwerken und 8 Daten- + 4 Paritäts-Shards kann den Ausfall von beliebigen 4 Laufwerken verkraften und Daten weiterhin bereitstellen.

Der MinIO S3 Backup Stack enthält automatisierte Lifecycle-Policies, Versionierung und Remote-Sync – dieselbe Konfiguration, die in produktiven Object-Storage-Deployments verwendet wird.

Layer 3: Workflow-Automatisierung - n8n

n8n ist die Open-Source-Workflow-Automatisierungs-Engine, die alles verbindet, was keine native Integration besitzt.

Warum sowohl PostgreSQL als auch Redis benötigt werden

n8n benötigt in der Produktion ein zweiteiliges Backend:

Im Queue-Modus trennt n8n den Webhook-Empfänger vom Workflow-Executor:

Diese Architektur bedeutet:

• Webhook-Antworten erfolgen sofort (Enqueue + Acknowledge)
• Lange Workflows laufen im Hintergrund, ohne zu blockieren
• Sie können Worker während Spitzenzeiten unabhängig skalieren
• Fehlgeschlagene Ausführungen werden automatisch wiederholt, ohne den Webhook zu verlieren

Pruning ist in der Produktion obligatorisch. Ohne dieses wird die Datenbank durch abgeschlossene Ausführungen gefüllt:

environment:
  - EXECUTIONS_DATA_PRUNE=true
  - EXECUTIONS_DATA_MAX_AGE=168 # hours (7 days)
  - EXECUTIONS_DATA_PRUNE_TIMEOUT=3600000 # 1 hour

Der n8n Production Stack wird mit all diesen vorkonfigurierten Einstellungen ausgeliefert – Queue-Modus, Postgres-Persistenz, Redis-Backend und Execution-Pruning mit sinnvollen Standardwerten.

Was Sie automatisieren können

• Webhook-gesteuerte Workflows: Eingehende E-Mail → Parsen → in Datenbank einfügen → Slack-Benachrichtigung
• Geplante Jobs: Stündliche Datenbankbereinigung, tägliche Backup-Berichte, wöchentliche CSV-Exporte
• API-Orchestrierung: Datentransformation zwischen CRMs, ERPs und Marketing-Plattformen
• Integrations-Glue: Verbindung von self-hosted Tools mit Cloud-APIs (Slack, GitHub, Stripe, Plausible)

Layer 4: Observability - Metriken, Logs und Dashboards

Man kann nicht managen, was man nicht messen kann. Der Observability-Layer sammelt Metriken und Logs von jedem Service im Stack und präsentiert sie in vereinheitlichten Dashboards.

Prometheus - Metrics Collection

Prometheus scrapes metrics endpoints from every service:

scrape_configs:

- job_name: 'postgresql'
  static_configs:
  - targets: ['postgres-exporter:9187']
- job_name: 'redis'
  static_configs:
  - targets: ['redis-exporter:9121']
- job_name: 'n8n'
  static_configs:
  - targets: ['n8n:5678']
- job_name: 'node'
  static_configs:
  - targets: ['node-exporter:9100']
- job_name: 'cadvisor'
  static_configs:
  - targets: ['cadvisor:8080']

Loki - Log Aggregation

Loki aggregates logs from all containers via Alloy (or Promtail):

# docker-compose service for Alloy
alloy:
  image: grafana/alloy:v1.6
  command:
    - run
    - /etc/alloy/config.alloy
    - --server.http.listen-addr=0.0.0.0:12345
  volumes:
    - /var/log:/var/log:ro
    - /var/lib/docker/containers:/var/lib/docker/containers:ro
  ports:
    - "12345:12345"

Grafana - Unified Visualization

Grafana brings everything together into a single view. The Observability Stack comes with pre-built dashboards for:

• Node Exporter Full: CPU, memory, disk, network, load - every host metric
• Docker Container Monitoring: Per-container CPU, memory, network, restart count
• Custom per-service dashboards: PostgreSQL query performance, Redis hit ratio, n8n execution rate

What to Monitor (and Alert On)

Layer 5: Automation and Configuration Management

Once your infrastructure is running, you need to manage it declaratively.

Backup Automation

Every service in the stack needs a backup strategy:

Configuration as Code

All configurations should be version-controlled:

infrastructure/
├── docker-compose.yml
├── .env.example
├── nginx/
│   └── conf.d/
├── prometheus/
│   └── prometheus.yml
├── grafana/
│   └── dashboards/
├── postgres/
│   └── init.sql
└── minio/
    └── lifecycle.json

Genau so sind die production stacks strukturiert – jede einzelne ist eine Git-freundliche, dokumentierte Konfiguration, die Sie direkt in Ihr Infrastructure-Repository übernehmen können.

Kostenaufstellung

Hier ist die Aufschlüsselung der Kosten für den Betrieb dieses vollständigen Stacks:

*Die Software ist kostenlos. Die Hosting-Kosten hängen von Ihrem Anbieter ab – ein Hetzner AX102 mit 8 Kernen, 32GB RAM, 2×2TB NVMe kostet ca. €35/Monat und betreibt den gesamten Stack.

Erste Schritte

Sie können diesen gesamten Stack an einem Nachmittag bereitstellen:

1. Linux-Server besorgen – jeder Anbieter funktioniert (Hetzner, Netcup, OVH oder eigene Hardware)
2. Docker installieren – Docker Engine 24+ mit Compose v2
3. Mit dem Reverse Proxy starten – sichern Sie Ihren Ingress mit dem SSL Reverse Proxy Stack
4. Datenbank-Layer hinzufügen – Database Foundation Stack für PostgreSQL + Redis
5. Object Storage hinzufügen – MinIO S3 Backup Stack für persistente Dateispeicherung
6. n8n bereitstellen – n8n Production Stack für Workflow-Automatisierung
7. Observability hinzufügen – Observability Stack für Metriken, Logs und Dashboards

Jeder Stack ist ein einzelnes docker compose up -d. Jeder für sich ist bereits nützlich. Zusammen bilden sie eine vollständige Produktionsinfrastruktur, die mit allem mithalten kann, was Cloud-Anbieter anbieten – ohne Lock-in und ohne hohe Rechnung.

Siehe auch

• Zero to DevOps in 2026: Linux, Containers, Cloud, and AI Infrastructure – Der Lernpfad, um die für diese Infrastruktur erforderlichen Fähigkeiten aufzubauen
• Linux, DevOps, and AI: Why the Fundamentals Matter More Than Ever in 2026 – Warum das Verständnis der Grundlagen für die Verwaltung von Produktionsinfrastrukturen entscheidend ist
• n8n vs Dify: Choosing the Right Self-Hosted AI Workflow Engine in 2026 – Tiefgehender Vergleich von Workflow-Automatisierungstools für diesen Stack
• Self-Hosted AI Stack: Ollama + Open WebUI + LiteLLM - Complete Setup Guide – Fügen Sie KI-Inferenz zu Ihrer Infrastruktur hinzu
• Running n8n in Production: Docker Compose, Queue Mode, and Postgres Backend – Deployment-Strategie für diesen Stack

Heute bereitstellen

Alle Production Stacks durchstöbern →

🎁 Kostenlose Infrastruktur-Checkliste

Stellen Sie Produktionsinfrastrukturen wie ein Profi bereit. Diese 20-Punkte-Checkliste deckt Sicherheit, Backups, Monitoring und Skalierung für jede Komponente im Stack ab.

Kostenlose Infrastructure Deployment Checklist herunterladen →

💰 Production Stacks - Wählen Sie Ihr Bundle

Stellen Sie die Komponenten aus diesem Artikel mit praxiserprobten Konfigurationen bereit:

Diese Architektur teilen

Kennen Sie jemanden, der eine Produktionsinfrastruktur aufbaut? Teilen Sie diesen Guide:

Auf Twitter teilen Auf LinkedIn teilen

Über den Autor

Tobias Weiss erstellt produktionsreife Docker Compose Konfigurationen, die einfach funktionieren. Seine Stacks betreiben die Infrastruktur für Startups, Agenturen und Unternehmen weltweit.

Benötigen Sie Hilfe bei Ihrem Deployment? Production Stack Beratung buchen →