The Open-Source Infrastructure Stack: Production-Grade PostgreSQL, Redis, MinIO, n8n, and Observability

Software Testing That Earns Its Keep: A Field Report from Three Codebases

Evidence-based testing practice from production codebases — property-based invariants, seeded fault injection, contract tests, benchmark-verified performance, and quality gates that are enforced, not aspirational.

Zero to DevOps in 2026: The Complete Career Path from Linux to AI Infrastructure

A complete learning path from absolute beginner to production-ready DevOps professional. Start with Linux fundamentals, progress through containers and Kubernetes, add observability and automation, and finish with AI infrastructure. All open-source, vendor-neutral, with mapped certifications and production-ready stacks.

Every production application needs the same core infrastructure: a database, a cache, object storage, workflow automation, and observability. In 2026, the best tools for each layer are open-source, self-hostable, and proven at scale.

This guide shows how they fit together — not just as isolated services, but as a coherent infrastructure stack that you can deploy on any Linux server. For the skills needed to deploy and manage this stack, see Zero to DevOps in 2026: The Complete Career Path from Linux to AI Infrastructure. For why these skills matter, see Linux, DevOps, and AI: Why Fundamentals Matter More Than Ever in 2026.

Table of Contents

• The Architecture
• Layer 1: The Reverse Proxy — Your Single Entry Point
• Layer 2: The Data Layer — PostgreSQL, Redis, MinIO
• Layer 3: Workflow Automation — n8n
• Layer 4: Observability — Metrics, Logs, and Dashboards
• Layer 5: Automation and Configuration Management
• Cost Breakdown
• Getting Started

The Architecture

Every arrow represents a network connection. Every service has persistent storage. Every component emits metrics and logs to the observability layer. This is not a theoretical architecture - it's what production deployments look like at startups, mid-size companies, and even some enterprise teams that prefer open-source over vendor lock-in.

Layer 1: The Reverse Proxy - Your Single Entry Point

Every service behind your infrastructure should be inaccessible except through a single, hardened entry point. This gives you centralized TLS termination, rate limiting, WAF protection, and access control.

What It Handles

• TLS termination: Automatic Let's Encrypt certificates, automated renewal
• Routing: Domain-based and path-based routing to internal services
• Security: HTTP headers (CSP, HSTS, X-Frame-Options), rate limiting, bot detection
• WAF: Behavior-based detection via CrowdSec - SQLi, XSS, brute-force, credential stuffing

Nginx vs Traefik

For most self-hosted infrastructure, Nginx + Certbot + CrowdSec is the most battle-tested combination. The SSL Reverse Proxy Stack packages exactly this with production defaults.

What It Costs

A reverse proxy consumes approximately 128MB RAM and negligible CPU. The CrowdSec bouncer adds another 64MB. Total: ~200MB RAM for a fully secured ingress layer.

Layer 2: The Data Layer - PostgreSQL, Redis, MinIO

PostgreSQL - The Relational Backbone

PostgreSQL is the most advanced open-source relational database in 2026. It handles everything from application state to analytics workloads.

Production configuration matters. The default postgresql.conf from a package install is tuned for a laptop, not a server. Key settings to adjust:

# 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 strategy:

• Daily pg_dump with compression (saves ~60% space)
• 30-day retention on local disk
• Optional S3 sync via MinIO for off-site recovery
• Point-in-time recovery via WAL archiving for critical workloads

The Database Foundation Stack packages PostgreSQL with these exact tuning settings plus automated daily backups and S3 sync.

Redis - Cache, Queue, Session Store

Redis sits between your application and your database, absorbing read traffic and providing fast in-memory data access.

What to use it for:

• Cache layer: API response caching, database query results
• Session store: User sessions outside the application process
• Message queue: n8n queue mode, Sidekiq, Bull
• Rate limiting: Sliding window counters (atomic INCR + EXPIRE)
• Pub/Sub: Real-time notifications, WebSocket broadcasting

Persistence configuration:

# 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

Production consideration: Redis is single-threaded. A single Redis instance handles ~100K ops/sec. For more throughput, use Redis Cluster or multiple Redis instances sharded by use case (cache vs queue vs sessions).

MinIO - S3-Compatible Object Storage

MinIO provides the same API as AWS S3, Google Cloud Storage, and Azure Blob Storage - but runs on your own hardware with no egress fees.

What to store on MinIO:

• Backups: Database dumps, file archives, configuration snapshots
• Media: User uploads, images, videos, documents
• Logs: Long-term log archival (after Loki retention expires)
• Application data: Any file your application needs to store persistently

Erasure coding protects your data without hardware RAID. A 4-drive MinIO setup with 8 data + 4 parity shards can lose any 4 drives and still serve data.

The MinIO S3 Backup Stack includes automated lifecycle policies, versioning, and remote sync - the same configuration used in production object storage deployments.

Layer 3: Workflow Automation - n8n

n8n is the open-source workflow automation engine that connects everything that doesn't have a native integration.

Why It Needs Both PostgreSQL and Redis

n8n in production requires a two-part backend:

In queue mode, n8n separates the webhook receiver from the workflow executor:

This architecture means:

• Webhook responses are instant (enqueue + acknowledge)
• Long workflows run in the background without blocking
• You can scale workers independently during peak hours
• Failed executions auto-retry without losing the webhook

Pruning is mandatory in production. Without it, completed executions accumulate and fill your database:

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

The n8n Production Stack ships with all of this pre-configured - queue mode, Postgres persistence, Redis backend, and execution pruning set to sane defaults.

What You Can Automate

• Webhook-triggered workflows: Incoming email → parse → insert into database → notify Slack
• Scheduled jobs: Hourly database cleanup, daily backup reports, weekly CSV exports
• API orchestration: Transform data between CRMs, ERPs, marketing platforms
• Integration glue: Connect self-hosted tools with cloud APIs (Slack, GitHub, Stripe, Plausible)

Layer 4: Observability - Metrics, Logs, and Dashboards

You cannot manage what you cannot measure. The observability layer collects metrics and logs from every service in the stack and presents them in unified 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

This is exactly how the production stacks are structured - each one is a Git-friendly, documented configuration that you can drop into your infrastructure repository.

Cost Breakdown

Here's what this complete stack costs to run:

*Software is free. Hosting costs depend on your provider - a Hetzner AX102 with 8 cores, 32GB RAM, 2×2TB NVMe costs approximately €35/month and runs the entire stack.

Getting Started

You can deploy this entire stack in an afternoon:

1. Get a Linux server - any provider works (Hetzner, Netcup, OVH, or your own hardware)
2. Install Docker - Docker Engine 24+ with Compose v2
3. Start with the reverse proxy - secure your ingress with SSL Reverse Proxy Stack
4. Add the database layer - Database Foundation Stack for PostgreSQL + Redis
5. Add object storage - MinIO S3 Backup Stack for persistent file storage
6. Deploy n8n - n8n Production Stack for workflow automation
7. Add observability - Observability Stack for metrics, logs, and dashboards

Each stack is a single docker compose up -d. Each one is independently useful. Together, they form a complete production infrastructure that rivals anything a cloud provider offers - without the lock-in and without the bill.

See Also

• Zero to DevOps in 2026: Linux, Containers, Cloud, and AI Infrastructure - The learning path to build the skills needed for this infrastructure
• Linux, DevOps, and AI: Why the Fundamentals Matter More Than Ever in 2026 - Why understanding fundamentals is crucial for managing production infrastructure
• n8n vs Dify: Choosing the Right Self-Hosted AI Workflow Engine in 2026 - Deep comparison of workflow automation tools for this stack
• Self-Hosted AI Stack: Ollama + Open WebUI + LiteLLM - Complete Setup Guide - Add AI inference to your infrastructure
• Running n8n in Production: Docker Compose, Queue Mode, and Postgres Backend - Deployment strategy for this stack

Deploy Today

Browse all production stacks →

🎁 Free Infrastructure Checklist

Deploy production infrastructure like a pro. This 20-point checklist covers security, backups, monitoring, and scaling for each component in the stack.

Download Free Infrastructure Deployment Checklist →

💰 Production Stacks - Choose Your Bundle

Deploy the components from this article with battle-tested configurations:

Share This Architecture

Know someone building production infrastructure? Share this guide:

Share on Twitter Share on LinkedIn

About the Author

Tobias Weiss creates production-ready Docker Compose configurations that just work. His stacks power infrastructure for startups, agencies, and enterprises worldwide.

Need help with your deployment? Book a Production Stack Consultation →