DPTCloud
Back to articles
Technology Insight

Scaling Modern Architecture: Automating Microservices with Traefik v3 as a Reverse Proxy on Docker Swarm Multi-VPS

May 30, 2026

Introduction: The Multi-Node Routing Dilemma

In modern cloud-native architectures, scaling applications across multiple Virtual Private Servers (VPS) is a standard practice to ensure high availability and fault tolerance. However, managing traffic routing, load balancing, and SSL/TLS certificates across a distributed cluster can quickly become an operational bottleneck. Traditional reverse proxies often require manual configuration updates and service restarts every time a new container is deployed or scaled.

This is where Docker Swarm and Traefik v3 create a powerful synergy. Docker Swarm provides native container orchestration across a multi-VPS pool, while Traefik acts as an edge router that natively understands Swarm's architecture. By reading Swarm labels, Traefik v3 dynamically discovers new services, updates its routing tables in real-time, and provisions Let's Encrypt certificates automatically—all without a single line of static routing configuration.

---

1. Understanding the Architecture

Before diving into the configuration, it is essential to understand how Traefik operates within a Multi-VPS Docker Swarm environment. A typical production setup consists of:

  • Manager Nodes: Responsible for cluster management, orchestration, and maintaining the swarm state. Traefik must communicate with a manager node to access the Docker API.
  • Worker Nodes: Nodes dedicated strictly to running application containers.
  • Overlay Network: A software-defined network spanning all VPS nodes, allowing containers on different hosts to communicate securely.

Because Traefik v3 requires access to the /var/run/docker.sock to listen for Swarm events, security is a paramount concern. In a multi-VPS setup, we strategically deploy Traefik to a Manager node while isolating workloads on an overlay network, ensuring that backend services are never exposed directly to the public internet.

---

2. Prerequisites and Environment Setup

To successfully implement this infrastructure, ensure you have the following components ready:

  1. A Docker Swarm Cluster: At least two VPS instances initialized in a Swarm cluster (one Manager, one Worker).
  2. Public IP & DNS Records: A wildcard domain pointing to your Swarm Manager IP (e.g., *.example.com and example.com).
  3. Open Ports: Ensure firewalls allow traffic on ports 80 (HTTP), 443 (HTTPS), and Swarm management ports (2377, 7946, 4789).
Security Note: Always secure your Swarm data path traffic using the --opt encrypted flag when creating overlay networks across public VPS networks.

Execute the following command on your Manager node to create the secure overlay network for Traefik and your applications:

docker network create --driver overlay --attachable traefik-public
---

3. Step-by-Step Traefik v3 Deployment Strategy

Traefik v3 introduces several performance improvements and stricter syntax validation compared to v2. We will deploy Traefik as a Swarm service using a structured docker-compose.yml file.

The Traefik Core Configuration File

Create a directory named traefik on your manager node and define the service configuration. Instead of maintaining a complex static file, we will leverage environment variables and CLI arguments for maximum portability.

Here is the definitive production deployment manifest (traefik-swarm.yml):

version: '3.8'

services:
  traefik:
    image: traefik:v3.0
    command:
      - "--providers.docker=true"
      - "--providers.docker.swarmMode=true"
      - "--providers.docker.exposedByDefault=false"
      - "--providers.docker.network=traefik-public"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.myresolver.acme.tlschallenge=true"
      - "[email protected]"
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
      - "--api.dashboard=true"
    ports:
      - target: 80
        published: 80
        protocol: tcp
        mode: host
      - target: 443
        published: 443
        protocol: tcp
        mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - traefik-certificates:/letsencrypt
    networks:
      - traefik-public
    deploy:
      placement:
        constraints:
          - node.role == manager
      labels:
        - "traefik.enable=true"
        # Dashboard Configuration
        - "traefik.http.routers.dashboard.rule=Host(`traefik.example.com`)"
        - "traefik.http.routers.dashboard.service=api@internal"
        - "traefik.http.routers.dashboard.entrypoints=websecure"
        - "traefik.http.routers.dashboard.tls.certresolver=myresolver"

volumes:
  traefik-certificates:
networks:
  traefik-public:
    external: true

Key Configurations Explained

  • providers.docker.swarmMode=true: Instructs Traefik to poll the Swarm Manager API rather than standard standalone container runtimes.
  • mode: host for Ports: Bypassing the Swarm ingress routing mesh for ports 80 and 443 preserves client source IPs, which is crucial for logging, geofencing, and security auditing.
  • node.role == manager: Enforces that the Traefik replica only spawns on nodes capable of reading the cluster state.
---

4. Automatic Service Discovery in Action

With Traefik running smoothly, deploying a new microservice onto the multi-VPS cluster becomes completely declarative. There is no need to log into the proxy node, edit configuration structures, or reload services.

Let us deploy a sample high-availability Nginx application across multiple worker nodes to demonstrate dynamic service discovery.

version: '3.8'

services:
  web-app:
    image: nginx:alpine
    networks:
      - traefik-public
    deploy:
      replicas: 3
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.webapp.rule=Host(`app.example.com`)"
        - "traefik.http.routers.webapp.entrypoints=websecure"
        - "traefik.http.routers.webapp.tls.certresolver=myresolver"
        - "traefik.http.services.webapp.loadbalancer.server.port=80"

networks:
  traefik-public:
    external: true

When this stack is deployed via docker stack deploy -c app.yml myservice, Traefik v3 catches the orchestration event immediately. It identifies that three replicas are running across the multi-VPS pool, creates a single unified router, connects to Let's Encrypt to validate the app.example.com certificate, and balances incoming requests across all three nodes using a round-robin algorithm.

---

5. Best Practices for Production

Operating a distributed routing layer requires strict adherence to security and performance standards. Consider implementing the following strategies as you scale:

Global HTTP to HTTPS Redirection

Never serve unencrypted assets. Configure a global redirect directly in Traefik's entrypoints to automatically upgrade all connections to TLS.

Securing the Docker Socket

Exposing /var/run/docker.sock directly to any container carries inherent risks. To mitigate this, consider implementing a Docker Socket Proxy (such as tecrist/docker-socket-proxy) that intercepts requests from Traefik and allows only read-only access to the necessary Swarm resources, blocking any container creation or deletion requests.

---

Conclusion

Traefik v3 shifts the paradigm of edge routing within Docker Swarm multi-VPS deployments. By turning infrastructure definitions into container labels, development teams can scale microservices seamlessly while operations teams maintain a secure, automated, and highly resilient ingress gateway. Implementing this pattern guarantees that your network routing architecture is just as elastic, modular, and dynamic as your containerized workloads.

Scaling Modern Architecture: Automating Microservices with Traefik v3 as a Reverse Proxy on Docker Swarm Multi-VPS | DPTCloud