Sign inRequest DemoTry for free
managing twingate
additional resources

How to Set Up and Secure OpenClaw with Docker Compose

Deploy OpenClaw locally or on any Docker host with Zero Trust security using Twingate

Overview

This guide walks you through deploying OpenClaw (formerly ClawdBot and MoltBot), an AI-powered WhatsApp/Telegram assistant, using Docker Compose on any Docker host—local machine, homelab server, VPS, or cloud VM. You’ll start with local-only deployment, then optionally add Twingate for secure remote access without SSH tunneling or public port exposure.

Why Secure with Twingate? By default, OpenClaw is only accessible on the machine where it runs. When you need remote or team access, exposing ports publicly or setting up SSH tunnels introduces risk and complexity. Adding Twingate gives you:

  • Zero Trust access control — authenticate and authorize every connection with per-user policies
  • No public ports — the gateway stays completely off the internet
  • Audit logging — track who accessed what and when
  • MFA enforcement — require multi-factor authentication for every session
  • No VPN complexity — teammates connect with a lightweight client instead of managing VPN credentials

What You’ll Build:

  • OpenClaw Gateway running in Docker with Caddy reverse proxy (local access)
  • Optional: Twingate Connector for secure remote/team access

Infrastructure:

  • Any Docker host (local machine, homelab, VPS, cloud VM)
  • Docker Compose for infrastructure-as-code deployment
  • Optional: Twingate for Zero Trust remote access (no VPN or public ports)

Who This Is For:

  • Developers wanting local AI assistant deployment
  • Homelab users and self-hosters
  • Teams needing secure remote access without exposing ports
  • Anyone wanting infrastructure-as-code deployment

Time to Complete: 10 minutes (local only), 20 minutes (with remote access)

Note: This guide focuses on deployment and secure remote access. For overall security best practices, see the OpenClaw documentation.

Architecture Overview

Base Deployment (Steps 1-3)

[Docker Host]
     ↓
[Caddy Reverse Proxy] ← HTTP on port 80 (host-local only)
     ↓                  ← Shares the gateway's network namespace
[OpenClaw Gateway] ← Binds to localhost:18789 inside container
     ↓              ← Never exposed directly to host or network
[Claude/OpenAI APIs] ← AI providers

Use this for: Local development, single-user deployment, testing

Remote/Team Access Deployment (Step 4 - Optional)

[Docker Host]
     ↓
[Caddy Reverse Proxy] ← HTTP on port 80
     ↓                  ← Shares the gateway's network namespace
[OpenClaw Gateway] ← Binds to localhost:18789 inside container
     ↓
[Claude/OpenAI APIs]


Security Layer:
[Twingate Connector] ← Runs on host network
     ↓
[Twingate Cloud] ← Enforces Zero Trust policies
     ↓
[Team Members] ← Twingate Client enables secure remote access
                 (no VPN, no SSH tunneling, no public ports)

Use this for: Remote access, team collaboration, accessing from multiple devices

Why Caddy? The gateway binds to localhost inside the container by default—it isn’t reachable from the host or Docker network directly. Caddy shares the gateway’s network namespace (network_mode: service:openclaw-gateway), so it can reach localhost:18789 and expose it as port 80.

Why Twingate? Provides Zero Trust security—control who accesses the gateway, get audit logs, enforce MFA. Enables secure remote access without exposing ports or managing VPN credentials.

Network Architecture:

  • Shared Network Namespace: Caddy and the CLI share the gateway container’s network namespace, so they can reach the gateway on localhost:18789 without exposing that port to the host or Docker network.
  • Port 80 is the only port mapped to the host (bound to 127.0.0.1 by default).
  • Host Network: Twingate Connector uses host network mode (required for proper operation).

Benefits of Remote Access Setup:

  • ✅ Zero Trust Access — Authenticate and authorize every connection
  • ✅ No Public Ports — Complete network lockdown with no inbound access
  • ✅ No SSH Tunneling — Caddy provides HTTP access through Twingate
  • ✅ No VPN Required — Twingate Client replaces traditional VPN
  • ✅ Audit Logging — Track all connections and resource access
  • ✅ MFA Enforcement — Require multi-factor authentication

Prerequisites

Required (All Deployments)

  • Docker Engine 20.10+ or Docker Desktop
  • Docker Compose v2 (docker compose command, not legacy docker-compose)
  • 4GB+ RAM available for containers
  • 10GB+ disk space
  • AI provider API key:

Verify Docker installation:

docker --version
# Should show: Docker version 20.10+ or higher


docker compose version
# Should show: Docker Compose version v2.x.x or higher

Required for Remote/Team Access Only (Step 4)

Step 1: Prepare Docker Environment (~2 minutes)

1.1 Create Project Directory

# Create project directory
mkdir -p ~/openclaw-docker
cd ~/openclaw-docker


# Create subdirectories for volumes
mkdir -p config workspace

What this does:

  • ~/openclaw-docker: Main project directory
  • config/: Stores gateway token, user preferences, channel configurations
  • workspace/: Stores agent workspace files and persistent data

1.2 Verify Docker Installation

# Check Docker is running
docker info


# Check Docker Compose is available
docker compose version

Expected output: Docker info displays system information, Docker Compose shows v2.x.x or higher.

✅ Checkpoint: Docker environment is ready. Next, we’ll configure Docker Compose.

Step 2: Configure Docker Compose (~3 minutes)

2.1 Create Caddyfile

Create Caddyfile in your project directory:

:80 {
    reverse_proxy localhost:18789
}

What this does: Caddy shares the gateway’s network namespace, so it can reach the gateway on localhost:18789 and serve it on port 80.

2.2 Create docker-compose.yml

Create docker-compose.yml in your project directory:

services:
  # OpenClaw Gateway — binds to localhost only inside the container.
  # All access goes through the Caddy reverse proxy on port 80.
  openclaw-gateway:
    image: ghcr.io/openclaw/openclaw:latest
    container_name: openclaw-gateway
    restart: unless-stopped
    ports:
      - "127.0.0.1:80:80"  # Caddy reverse proxy (host-local only)
    volumes:
      - ./config:/home/node/.openclaw
      - ./workspace:/home/node/.openclaw/workspace
    environment:
      - CLAUDE_AI_SESSION_KEY=${CLAUDE_AI_SESSION_KEY:-}
      - OPENAI_API_KEY=${OPENAI_API_KEY:-}
      - OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}
    networks:
      - openclaw-network
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:18789/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s


  # OpenClaw CLI — on-demand interactive CLI for onboarding, config, and diagnostics.
  # Shares the gateway's network namespace so it can reach localhost:18789.
  openclaw-cli:
    image: ghcr.io/openclaw/openclaw:latest
    container_name: openclaw-cli
    entrypoint: ["node", "openclaw.mjs"]
    profiles: ["cli"]  # Only runs when explicitly invoked
    volumes:
      - ./config:/home/node/.openclaw
      - ./workspace:/home/node/.openclaw/workspace
    environment:
      - OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}
    network_mode: "service:openclaw-gateway"
    stdin_open: true
    tty: true
    depends_on:
      - openclaw-gateway


  # Caddy reverse proxy — provides HTTP access to the gateway.
  # Shares the gateway's network namespace so it can proxy localhost:18789 → port 80.
  caddy:
    image: caddy:latest
    container_name: caddy
    restart: unless-stopped
    network_mode: "service:openclaw-gateway"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
    depends_on:
      - openclaw-gateway


networks:
  openclaw-network:
    driver: bridge

Configuration explained:

  • Port binding 127.0.0.1:80:80: Caddy’s port 80 is mapped to the host, bound to localhost only. This is the sole entry point to the gateway.
  • Shared network namespace: Caddy and the CLI use network_mode: "service:openclaw-gateway" to share the gateway’s network namespace. This lets them reach the gateway on localhost:18789 without exposing that port.
  • CLI entrypoint: Overrides the default gateway command so the CLI accepts subcommands like onboard, health, and dashboard.
  • Volumes: Bind mounts for easy access and backup (not named volumes)
  • Health check: Monitors gateway container health
  • CLI profile: Prevents CLI container from auto-starting (used for manual commands only)
  • Restart policy: Gateway and Caddy restart automatically if they crash

2.3 Create .env File

Create .env in your project directory:

# AI Provider Configuration
# Choose ONE provider and uncomment/set the appropriate API key:


# Option 1: Anthropic Claude (recommended)
CLAUDE_AI_SESSION_KEY=your-claude-api-key-here


# Option 2: OpenAI
# OPENAI_API_KEY=your-openai-api-key-here


# Gateway Token (generated in Step 3)
OPENCLAW_GATEWAY_TOKEN=

Important: Replace your-claude-api-key-here or your-openai-api-key-here with your actual API key. The OPENCLAW_GATEWAY_TOKEN will be generated in the next step.

✅ Checkpoint: Docker Compose configuration is ready. Next, we’ll configure and start OpenClaw.

Step 3: Configure and Start OpenClaw (~5 minutes)

3.1 Run Onboarding Wizard

# Run interactive onboarding wizard
docker compose run --rm openclaw-cli onboard

Follow the prompts:

  • Select your AI provider (Claude, OpenAI, etc.)
  • Enter your API key (from your AI provider console)
  • Configure default settings (model, temperature, etc.)

What this does: Creates initial configuration files in ./config directory.

3.2 Generate Gateway Token

OpenClaw automatically generates a secure gateway token during onboarding. To retrieve it, run:

# Display the auto-generated gateway token and dashboard URL
docker compose run --rm openclaw-cli dashboard --no-open

Expected output:

Gateway Token: abc123def456...
Dashboard URL: http://localhost/?token=abc123def456...

Copy the token from the output. You’ll need it in the next step.

Can’t find your token later? Re-run the command above at any time to display the current token. The token is also stored in ./config/gateway-token if you need to retrieve it directly.

3.3 Update .env with Gateway Token

Edit .env and add your generated token:

OPENCLAW_GATEWAY_TOKEN=abc123def456...

Replace abc123def456... with your actual token from Step 3.2.

3.4 Start OpenClaw

# Start gateway and Caddy
docker compose up -d


# Verify services are running
docker compose ps

Expected output:

NAME                IMAGE                              STATUS
caddy               caddy:latest                       Up About a minute
openclaw-gateway    ghcr.io/openclaw/openclaw:latest   Up About a minute (healthy)

3.5 View Gateway Logs

# View logs to confirm successful startup
docker compose logs openclaw-gateway


# Follow logs in real-time
docker compose logs -f openclaw-gateway

Look for: Messages indicating successful startup and API provider connection.

3.6 Access Gateway Locally

Open your browser and navigate to:

http://localhost/?token=<your-token>

Replace <your-token> with your gateway token from Step 3.2.

Expected result: OpenClaw dashboard loads successfully via Caddy reverse proxy.

✅ Checkpoint: OpenClaw is running and accessible locally! You can now use it from your machine. To enable remote/team access, continue to Step 4. Otherwise, skip to Step 5 for messaging channel configuration.

Step 4: Enable Remote Access with Twingate (Optional, ~10 minutes)

This section adds a Twingate Connector to your deployment for secure remote access without SSH tunneling or public port exposure. Caddy is already part of the base deployment from Step 2.

4.1 Update docker-compose.yml

Add the Twingate Connector service to your existing docker-compose.yml:

# Twingate Connector — optional, for secure remote access.
  # Comment out this section if you only need local access.
  twingate-connector:
    image: twingate/connector:latest
    container_name: twingate-connector
    restart: unless-stopped
    environment:
      - TWINGATE_NETWORK=${TWINGATE_NETWORK}
      - TWINGATE_ACCESS_TOKEN=${TWINGATE_ACCESS_TOKEN}
      - TWINGATE_REFRESH_TOKEN=${TWINGATE_REFRESH_TOKEN}
      - TWINGATE_LOG_LEVEL=3
      - TWINGATE_LOG_ANALYTICS=v2
    network_mode: host
    sysctls:
      net.ipv4.ping_group_range: "0 2147483647"

Configuration explained:

  • Twingate Connector: Uses host network mode (required for proper operation)
  • Connector sysctls: Enables ICMP/ping support for connectivity testing

4.2 Create Twingate Account and Remote Network

  • Sign up at twingate.com/signup
  • Create your Twingate network: yourcompany.twingate.com
  • Navigate to Admin Console → Remote Networks
  • Click Add Remote Network
  • Configure:
    • Name: OpenClaw Docker
    • Location: Match your Docker host location (optional)
  • Click Create

4.3 Generate Connector Tokens

  • In your Remote Network, click Add Connector
  • Select Docker as the deployment method
  • Click Generate Tokens
  • Copy the Access Token and Refresh Token (you’ll need these in the next step)

Important: Keep these tokens secure. They provide access to your Twingate network.

4.4 Update .env with Twingate Credentials

Edit your .env file and add Twingate configuration:

# AI Provider Configuration
CLAUDE_AI_SESSION_KEY=your-claude-api-key-here


# Gateway Token
OPENCLAW_GATEWAY_TOKEN=abc123def456...


# Twingate Configuration
TWINGATE_NETWORK=yourcompany  # Without .twingate.com
TWINGATE_ACCESS_TOKEN=your-access-token-here
TWINGATE_REFRESH_TOKEN=your-refresh-token-here

Replace:

  • yourcompany with your Twingate network name (the <name> in <name>.twingate.com)
  • your-access-token-here with your Access Token from Step 4.3
  • your-refresh-token-here with your Refresh Token from Step 4.3

4.5 Start Twingate Connector

# Start the Twingate Connector
docker compose up -d twingate-connector


# Verify all services are running
docker compose ps

Expected output:

NAME                   IMAGE                              STATUS
caddy                  caddy:latest                       Up 10 minutes
openclaw-gateway       ghcr.io/openclaw/openclaw:latest   Up 10 minutes (healthy)
twingate-connector     twingate/connector:latest          Up About a minute

4.6 Verify Connector is Online

  • Go to Admin Console → Remote Networks
  • Select your Remote Network
  • Click on Connectors
  • Your connector should show status: Connected

If status shows “Disconnected”: Check connector logs:

docker compose logs twingate-connector

4.7 Create Twingate Resource

  • Go to Admin Console → Resources
  • Click Add Resource
  • Configure:
    • Name: OpenClaw Gateway
    • Address: Enter your Docker host IP address:
      • Local/homelab: Use your machine’s local IP (e.g., 192.168.1.100)
      • VPS/cloud: Use the host’s private IP (e.g., 10.0.0.5)
      • Docker Desktop: Use host.docker.internal (macOS/Windows) or host machine IP (Linux)
    • Protocols: HTTP
    • Port: 80 (Caddy reverse proxy)
    • Remote Network: Select the Remote Network where you deployed the Connector
  • Click Add Resource

Finding your Docker host IP:

# macOS/Linux
ip addr show | grep "inet " | grep -v 127.0.0.1


# Alternative (works on most systems)
hostname -I

4.8 Configure Resource Access

  • In the Resources tab, select your OpenClaw Gateway resource
  • Click Access tab
  • Click Add Access
  • Select the groups or users who should have access
  • Click Add

Recommended: Create a dedicated group (e.g., “OpenClaw Users”) for easier access management.

4.9 Test Remote Access

On your laptop, phone, or another device:

  • Install Twingate Client

  • Connect to Twingate

    • Open Twingate Client
    • Sign in with your Twingate account
    • Connect to your network

  • Access OpenClaw Gateway

    • Open browser and navigate to: http://<docker-host-ip>/?token=<your-token>
    • Replace <docker-host-ip> with the IP address you used in Step 4.7
    • Replace <your-token> with your gateway token from Step 3.2

Expected result: OpenClaw dashboard loads successfully from your remote device!

Troubleshooting: If connection fails, see the Troubleshooting section below.

✅ Checkpoint: Remote access is enabled! You and your team can now securely access OpenClaw through Twingate without SSH tunneling or public port exposure.

Troubleshooting

Issue: Gateway not accessible locally

Symptoms: Browser shows “Connection refused” at http://localhost

Debug Steps:

  • Verify gateway and Caddy are running

    docker compose ps
    # Both openclaw-gateway and caddy should show: Up

  • Check gateway logs

    docker compose logs openclaw-gateway
    # Look for: "listening on ws://127.0.0.1:18789"

  • Check Caddy logs

    docker compose logs caddy
    # Look for: Configuration errors or startup failures

  • Verify port binding

    docker compose port openclaw-gateway 80
    # Should show: 127.0.0.1:80

  • Check for port conflicts

    # macOS/Linux
    lsof -i :80
    

    # If another process is using port 80, stop it or change the port in docker-compose.yml

Solution: If gateway won’t start, check environment variables in .env are correct, especially OPENCLAW_GATEWAY_TOKEN.

Issue: Gateway not accessible via Twingate (remote access)

Symptoms: Timeout or connection refused when accessing via Twingate

Debug Steps:

  • Verify Twingate Client is connected

    # Check client status
    # macOS/Linux: Menu bar icon should show "Connected"
    # Windows: System tray icon should show "Connected"

  • Verify Connector is online

    • Go to Admin Console → Remote Networks → Connectors
    • Status should show: Connected
    • Check “Last Seen” timestamp (should be recent)

  • Check Connector logs

    docker compose logs twingate-connector
    # Look for: Connection errors or authentication failures

  • Verify Caddy is running

    docker compose ps caddy
    # Should show: Up

  • Test Caddy locally

    # From Docker host machine
    curl http://localhost/?token=<your-token>
    # Should return: OpenClaw dashboard HTML

  • Verify Resource configuration

    • Admin Console → Resources → OpenClaw Gateway
    • Check Address matches your Docker host IP
    • Check Port is set to 80 (not 18789)
    • Check Protocol is HTTP
    • Check Remote Network matches where Connector is deployed

  • Verify user has access

    • Admin Console → Resources → OpenClaw Gateway → Access
    • Confirm your user or group is listed

Solution: Most common issue is incorrect Resource address. Ensure you’re using the correct Docker host IP address that the Connector can reach.

Issue: Caddy reverse proxy not working

Symptoms: Caddy container is running but requests fail

Debug Steps:

  • Check Caddy logs

    docker compose logs caddy
    # Look for: Configuration errors or reverse proxy failures

  • Verify Caddyfile syntax

    # Check Caddyfile exists and has correct content
    cat Caddyfile
    

    # Should show:
    # :80 {
    #     reverse_proxy localhost:18789
    # }

  • Test connectivity via shared namespace

    # Verify Caddy can reach gateway on shared localhost
    docker compose exec caddy curl http://localhost:18789/health

  • Restart Caddy

    docker compose restart caddy

Solution: Caddy shares the gateway’s network namespace (network_mode: service:openclaw-gateway). If it can’t reach the gateway, ensure the gateway container is running and healthy first.

Issue: Twingate Connector offline

Symptoms: Connector shows “Disconnected” in Admin Console

Debug Steps:

  • Check Connector service

    docker compose ps twingate-connector
    # Should show: Up

  • Review Connector logs

    docker compose logs twingate-connector
    # Look for: Authentication errors, network connectivity issues

  • Verify environment variables

    # Check .env has correct values
    cat .env | grep TWINGATE
    

    # Should show:
    # TWINGATE_NETWORK=yourcompany
    # TWINGATE_ACCESS_TOKEN=...
    # TWINGATE_REFRESH_TOKEN=...

  • Test network connectivity

    # Verify host can reach Twingate Cloud
    ping yourcompany.twingate.com

  • Regenerate tokens if needed

    • Admin Console → Remote Networks → Connectors
    • Click on your Connector
    • Click Regenerate Tokens
    • Update .env with new tokens
    • Restart Connector: docker compose restart twingate-connector

Solution: If tokens are expired or incorrect, regenerate them in Admin Console and update your .env file.

Issue: Authentication failing

Symptoms: Gateway returns 401 Unauthorized or “Invalid token” errors

Debug Steps:

  • Verify Gateway token is set

    cat .env | grep OPENCLAW_GATEWAY_TOKEN
    # Should show: OPENCLAW_GATEWAY_TOKEN=abc123def456...

  • Regenerate Gateway token if needed

    docker compose run --rm openclaw-cli dashboard --no-open
    # Copy new token and update .env

  • Restart gateway after token change

    docker compose restart openclaw-gateway

  • Clear browser cache

    • Old tokens may be cached
    • Try incognito/private browsing mode

Solution: Ensure you’re using the token from the URL parameter: ?token=<your-token>

Issue: AI provider errors

Symptoms: Gateway runs but AI requests fail

Debug Steps:

  • Verify API key is set

    cat .env | grep -E "(CLAUDE|OPENAI)"
    # Should show your API key

  • Check API key validity

  • Review gateway logs for API errors

    docker compose logs openclaw-gateway | grep -i "error\|api"

  • Test API key directly

    # Anthropic
    curl https://api.anthropic.com/v1/messages \
      -H "x-api-key: $CLAUDE_AI_SESSION_KEY" \
      -H "anthropic-version: 2023-06-01" \
      -H "content-type: application/json" \
      -d '{"model":"claude-3-5-sonnet-20241022","max_tokens":1024,"messages":[{"role":"user","content":"Hello"}]}'
    

    # OpenAI
    curl https://api.openai.com/v1/chat/completions \
      -H "Authorization: Bearer $OPENAI_API_KEY" \
      -H "Content-Type: application/json" \
      -d '{"model":"gpt-4","messages":[{"role":"user","content":"Hello"}]}'

Solution: If API key is invalid, generate a new one and update .env, then restart gateway.

Issue: Volume permission errors (Linux)

Symptoms: Gateway fails to start with permission denied errors

Debug Steps:

  • Check volume permissions

    ls -la config/ workspace/
    # Should show: Your user owns the directories

  • Fix permissions

    # Option 1: Change ownership to your user
    sudo chown -R $(id -u):$(id -g) config/ workspace/
    

    # Option 2: Make directories world-writable (less secure)
    chmod 777 config/ workspace/

  • Restart gateway

    docker compose restart openclaw-gateway

Note: macOS and Windows Docker Desktop handle permissions automatically. This is primarily a Linux issue.

Solution: Ensure your user has read/write permissions on config/ and workspace/ directories.

Managing Your Deployment

Start/Stop Commands

# Start all services
docker compose up -d


# Stop all services
docker compose down


# Stop but keep volumes
docker compose stop


# Restart a specific service
docker compose restart openclaw-gateway

View Logs

# View all logs
docker compose logs


# View logs for specific service
docker compose logs openclaw-gateway
docker compose logs caddy
docker compose logs twingate-connector


# Follow logs in real-time
docker compose logs -f openclaw-gateway


# View last 100 lines
docker compose logs --tail=100 openclaw-gateway

Monitor Container Health

# Check all services status
docker compose ps


# Check specific service health
docker compose ps openclaw-gateway


# View health check status
docker inspect openclaw-gateway | grep -A 10 Health

Backup Configuration

Important: Always back up your configuration before updates or major changes.

# Create backup with timestamp
tar -czf openclaw-backup-$(date +%Y%m%d-%H%M%S).tar.gz \
  config/ workspace/ .env docker-compose.yml Caddyfile


# Restore from backup
tar -xzf openclaw-backup-20260213-143000.tar.gz

What gets backed up:

  • config/: Gateway token, user preferences, channel configurations
  • workspace/: Agent workspace files, persistent data
  • .env: Environment variables (API keys, tokens)
  • docker-compose.yml: Service configuration
  • Caddyfile: Reverse proxy configuration

Recommended: Set up automated backups with cron:

# Add to crontab (daily backup at 2 AM)
0 2 * * * cd ~/openclaw-docker && tar -czf ~/backups/openclaw-backup-$(date +\%Y\%m\%d).tar.gz config/ workspace/ .env docker-compose.yml Caddyfile

Update OpenClaw

# Pull latest images
docker compose pull


# Recreate containers with new images
docker compose up -d --force-recreate


# View updated versions
docker compose images

Note: Always back up before updating.

Monitor Connector Health

  • Admin Console → Remote Networks → Connectors
  • Check Connector status:
    • Connected: Healthy and operational
    • Disconnected: Check logs and troubleshooting section
  • Review connection metrics:
    • Last Seen timestamp
    • Active connections
    • Data transferred

Set up alerts:

  • Admin Console → Settings → Notifications
  • Enable “Connector offline” alerts
  • Add email or Slack webhook

Support & Resources

Twingate Resources

OpenClaw Resources

Docker Resources

Conclusion

You now have a production-ready OpenClaw deployment with Docker Compose that provides:

✅ Flexible Deployment: Runs on any Docker host—local, homelab, VPS, or cloud ✅ Infrastructure as Code: Reproducible deployment with docker-compose.yml ✅ Private by Default: Gateway on localhost, secure by design ✅ Optional Remote Access: Caddy + Twingate for secure remote/team access ✅ No Public Ports: Zero Trust access without exposing infrastructure ✅ No SSH Tunneling: HTTP access through Caddy reverse proxy ✅ Easy Management: Docker Compose commands for all operations

Next Steps:

  • Configure custom skills for your use cases
  • Set up automated backups with cron or scheduled tasks
  • Add team members via Twingate groups and policies
  • Enable MFA for production deployments
  • Explore messaging integrations (WhatsApp, Telegram, Discord)
  • Monitor logs and health for proactive maintenance

Deployment Flexibility:

This Docker Compose setup works anywhere Docker runs:

  • Local development: Laptop or desktop
  • Homelab: Raspberry Pi, NAS, dedicated server
  • VPS: DigitalOcean, Linode, Vultr, etc.
  • Cloud VMs: AWS EC2, GCP Compute Engine, Azure VM
  • Multi-cloud: Deploy across providers with same configuration

Security Benefits of Zero Trust Architecture:

By adding Twingate, you get:

  • Granular access control: Per-resource, per-user policies
  • Audit logging: Track all connections and access attempts
  • MFA enforcement: Require multi-factor authentication
  • No VPN complexity: Modern alternative to traditional VPN
  • Defense in depth: Even if server is compromised, gateway remains protected

Questions? Check the troubleshooting section above or reach out on our Twingate Subreddit.

Happy deploying! 🚀

Last updated 1 month ago