Multi-Tenant Docker Without Accidental Shared Fate

A current, production-oriented follow-up that turns vendor guidance into operating controls, migration decisions, and verifiable release criteria.

What changed in 2026

We revisited this subject because the operating boundary has moved. The durable principles remain useful, but current versions make several old shortcuts incomplete or unsafe. This follow-up starts with the vendor documentation available on 14 July 2026, separates facts from local choices, and treats every configuration change as a controlled production intervention.

Current primary sources

How we use the update

Read the sources first, record the versions actually deployed, and define the observable result before changing a setting. Test the smallest reversible intervention in a representative environment. A successful command is not the acceptance criterion: service health, data integrity, latency, security boundaries, and rollback time are. Where the earlier guide offers a useful diagnostic sequence, we retain it below as an operating foundation; version-specific examples must still be checked against the current documentation.

Operating foundation

How to create a template-based, multi-tenant development environment with 16 containerized services that works offline yet remains accessible online through subdomain-based routing

Managing development environments for multiple clients often means choosing between complex manual setups or expensive cloud solutions. Manual deployments are time-consuming and error-prone. Cloud platforms are convenient but create vendor lock-in and ongoing costs that scale with usage.

Today, we’ll walk through building a scalable multi-tenant development stack that gives you both: complete isolation between client environments with automated deployment capabilities, all while maintaining full control over your infrastructure. This approach builds on our philosophy of self-hosted solutions—similar to how we’ve shown you can self-host n8n for workflow automation and deploy Windmill with Docker for complete operational control.

The Tools We’re Using

Let’s start by understanding what each piece does in our comprehensive 16-container architecture:

Docker: Your Containerization Foundation

Docker provides the isolation and consistency we need for multi-tenant environments. Each client gets their own containers with identical configurations, ensuring that what works in development will work in production. Think of it as having multiple completely separate servers running on the same hardware.

The key advantage? Perfect isolation between clients. One client’s data, configurations, and customizations never interfere with another’s. This matters when handling multiple business clients with different requirements and security needs.

Traefik: Smart Reverse Proxy and Load Balancer

Traefik acts as an intelligent traffic director, automatically routing requests to the correct client environment based on domain names. Instead of manually configuring complex Apache or Nginx rules, Traefik reads labels from your Docker containers and sets up routing automatically.

Think of Traefik as a smart receptionist who knows exactly which office (container) each visitor (request) should go to, without you having to give directions every time. In our setup, Traefik handles SSL termination, automatic service discovery, and provides detailed monitoring dashboards.

Cloudflare Tunnels: Secure External Access

Cloudflare Tunnels provide secure access to your local development stack without complex firewall configurations or VPNs. Each client domain gets its own tunnel, ensuring complete separation at the network level while maintaining enterprise-grade security.

The beauty is that your development environments remain local and secure, but clients can access their specific services from anywhere with proper authentication—similar to how we configured secure external access in our n8n hosting guide.

The Complete Service Stack: Everything Your Clients Need

Our multi-tenant stack includes seven core service categories across 16 containers per client:

Workflow Automation & Business Logic:

n8n: Complete workflow automation platform for business process automation

Authentik: Enterprise-grade single sign-on and identity management (3 containers: server, worker, Redis cache)

Database & Backend Services:

PostgreSQL: Robust database backend supporting all services with optimized connection pooling

Supabase Stack: Complete backend-as-a-service with 5 specialized containers (Studio, Auth, REST API, Realtime, Kong Gateway)

NocoDB: No-code database interface for client data management

AI & Intelligence:

Ollama: Local AI language models with GPU acceleration for intelligent automation

Qdrant (optional): Vector database for advanced AI workflows and similarity search

Infrastructure & Monitoring:

Cloudflare Tunnel: Secure external connectivity

Traefik: Reverse proxy with automatic SSL and monitoring dashboard

How It All Works Together

Here’s the complete flow when a client accesses their environment:

Client navigates to their custom domain (e.g., workflows.client-a.com)

Cloudflare Tunnel routes the request to your local Traefik instance

Traefik reads the domain, applies middleware (authentication, SSL, rate limiting), and forwards to the correct client container

Authentik handles SSO authentication across all services if configured

The client gets their completely isolated environment with their data and configurations

All other clients remain completely unaffected and inaccessible

Everything stays organized and separated, with each client getting their own subdomain structure like auth.client-a.com, database.client-a.com, backend.client-a.com, etc.

Setting This Up: The Practical Steps

Getting the Foundation Ready

First, you’ll need Docker Desktop installed and a domain management setup. We recommend setting up a wildcard DNS structure for easy client onboarding:

Creating the Template System

The magic happens through a template-based approach. Instead of manually setting up each client, we create templates that can be instantly deployed with client-specific configurations.

Create the comprehensive directory structure:

Complete Multi-Service Template Configuration

Create a comprehensive docker-compose.yml template with all 16 services:

Complete Environment Template

Create .env.template for comprehensive client-specific variables:

Database Initialization Scripts

Create comprehensive database initialization in init/01-create-multiple-databases.sql:

Supabase Kong Gateway Configuration

Create supabase/kong.yml for API gateway routing:

Automated Deployment Script

The comprehensive deployment script that creates new client environments in minutes:

Using Your Multi-Tenant Stack

Deploying New Clients

Creating a new client environment becomes trivial with our comprehensive script:

Each deployment creates:

Completely isolated Docker network with 16 containers

Separate data volumes for persistent storage

Unique service containers with health monitoring

Individual Cloudflare tunnel configuration

Custom domain routing with SSL certificates

Enterprise-grade SSO infrastructure ready for activation

Managing Multiple Environments

Monitor all client environments from a central location:

Container Architecture Deep Dive

Our complete 16-container architecture per client includes:

Infrastructure Layer (4 containers):

cloudflare-tunnel: Secure external connectivity

traefik: Reverse proxy with automatic SSL and service discovery

postgres: Central database with connection pooling

whoami: Health monitoring and routing verification

Application Layer (7 containers):

n8n: Workflow automation with PostgreSQL backend

nocodb: No-code database interface

supabase-studio: Backend development dashboard

supabase-meta: Database introspection service

supabase-auth: Authentication and user management

supabase-rest: Auto-generated REST API

supabase-realtime: Real-time subscriptions and updates

AI & Gateway Layer (2 containers):

ollama: Local AI with GPU acceleration support

supabase-kong: API gateway with rate limiting and CORS

Enterprise Security Layer (3 containers):

authentik-server: SSO authentication server

authentik-worker: Background tasks and notifications

authentik-redis: Session management and caching

Scaling Resources Per Client

Adjust resources based on client needs and usage patterns:

Real Benefits for Your Business

Complete Client Isolation with Enterprise Features

Each client gets their own comprehensive universe including enterprise-grade SSO, AI capabilities, and full backend infrastructure. Data, configurations, customizations, and security policies remain completely contained. A problem with one client never affects others, similar to the isolation we achieve with our individual n8n deployments.

Rapid Client Onboarding with Full Feature Set

New clients can be up and running with a complete development and automation stack in under 10 minutes. The deployment script handles all complex configuration, DNS setup, service initialization, and security configuration automatically—far more comprehensive than traditional approaches.

Predictable Enterprise Costs

After initial setup, there are no per-client hosting costs beyond your base infrastructure. Unlike SaaS solutions that charge per seat, per workflow, or per API call, you pay once for the hardware and run unlimited client environments with full enterprise features.

Professional Brand Consistency

Each client gets their own branded domains with professional subdomains (workflows.client.com, auth.client.com, etc.) and can customize their environments completely. No “powered by” footers or shared interfaces that dilute their brand identity.

The n8n Integration: Enterprise Workflow Automation at Scale

Here’s where things get really powerful. Just as we’ve shown you how to self-host n8n for workflow automation, this multi-tenant setup gives each client their own complete n8n instance integrated with a full enterprise stack.

Each client can build sophisticated workflows that:

Connect to their own databases (NocoDB, Supabase PostgreSQL)

Use their own AI models (Ollama) for intelligent automation

Authenticate through enterprise SSO (Authentik)

Integrate with their specific business tools and APIs

Process their data with complete isolation and security

The combination creates a powerful client delivery platform where you can:

Deploy standardized automation capabilities rapidly

Customize workflows per client without affecting others

Scale your service delivery without linear cost increases

Maintain complete data sovereignty for each client

Offer enterprise-grade security and compliance

This approach builds on the same principles we used in our Windmill Docker setup guide, but extends it to a complete multi-tenant architecture.

Advanced Configuration Options

Implementing Enterprise SSO with Authentik

Enable single sign-on across all client services by configuring Authentik forward authentication:

Then update your service labels to use the middleware:

Adding Vector Database for Advanced AI

Enhance AI capabilities with Qdrant vector database:

Implementing Hybrid AI Architecture

For optimal performance, consider a hybrid approach combining containerized and native AI:

This provides 5-6x performance improvement through direct GPU access while maintaining container isolation for other services.

Monitoring and Observability Stack

Add comprehensive monitoring per client:

Common Issues and Solutions

“Service Unavailable” or HTTP 502 Errors

Usually means Traefik can’t reach the target container. Check that:

DNS Resolution Problems

Wildcard DNS setup is crucial for subdomain routing:

Resource Exhaustion Across Multiple Clients

Monitor resource usage across all client environments:

Database Connection Pool Exhaustion

PostgreSQL connection limits can be hit with many clients. Configure per deployment:

Authentik SSO Configuration Issues

Common SSO setup problems and solutions:

Cloudflare Tunnel Connection Issues

Debug tunnel connectivity problems:

Infrastructure Considerations

Sizing Your Infrastructure for Multiple Clients

For a typical setup handling 10-15 clients simultaneously with full 16-container stacks:

Minimum Requirements:

CPU: 16-24 cores (2 cores per active client environment)

RAM: 64-128GB (4-8GB per client depending on AI usage)

Storage: NVMe SSD with 2TB+ (databases, AI models, and logs grow over time)

Network: Gigabit connection for responsive client access

Recommended for Production:

Server: Hetzner CCX62 or similar (48 vCPU, 192GB RAM)

Storage: 4TB NVMe with automated backup system

Network: Multiple redundant connections

Monitoring: Full observability stack with alerting

Backup Strategy for Multi-Client Environments

Implement automated backups per client:

Security Hardening for Production

Implement comprehensive security best practices:

Apply security middleware to all client services:

Cost Analysis: The Numbers That Matter

Traditional SaaS Costs (10 enterprise clients with full feature sets)

Per-client monthly costs:

n8n Pro: $50/month per client = $500/month

Supabase Pro: $25/month per client = $250/month

NoCode platform (Airtable): $20/month per client = $200/month

Enterprise SSO (Auth0): $23/month per client = $230/month

AI API costs (OpenAI): $50/month per client = $500/month

Total: $1,500/month = $18,000/year

Self-Hosted Multi-Tenant Enterprise Stack Costs

Annual infrastructure costs:

Dedicated server (Hetzner CCX62): $350/month = $4,200/year

Domain costs (10 clients): $120/year

Cloudflare Pro (optional): $240/year

Total: $4,560/year

Annual savings: $13,440 (75% cost reduction)

Plus you get:

Complete data sovereignty and privacy

Unlimited customization and white-labeling

No vendor lock-in or API rate limits

Enterprise-grade security and compliance

Ability to offer reseller services

Full control over updates and features

This is particularly powerful when you consider that our setup provides enterprise features that would typically cost much more in SaaS subscriptions, similar to the cost benefits we demonstrated in our n8n self-hosting analysis.

From configuration to an operating decision

The practical question is not whether a platform can be configured. It is whether the team can explain ownership, detect drift, recover without improvisation, and demonstrate that the change improved the intended outcome. We therefore pair configuration with an owner, a baseline, a rollback path, and a readback window. That turns a one-off fix into an operating capability. The production record should include the reason for the change, the evidence reviewed, the exact scope, and the person authorised to stop or reverse it. After release, compare the agreed indicators with the baseline and keep the result with the change record. If the expected improvement is absent, rollback is a valid outcome rather than a failure. This discipline matters more than any individual configuration value. The same record gives the next operator a trustworthy starting point and makes later optimisation a measured decision rather than another round of guesswork.