Sidecar Proxy Tunnels in DevContainers: Der moderne Standard für sichere lokale Entwicklung

Stoppen Sie die Installation von Tunneling-Tools auf Ihrer Host-Maschine. Die Praxis, ngrok, cloudflared oder andere Tunneling-Daemons als Rogue-Prozess auf Ihrem Laptop laufen zu lassen, ist ein Anti-Pattern, das der Vergangenheit angehört. Im Jahr 2026 ist der richtige Ansatz, Ihre gesamte Netzwerktopologie — inklusive öffentlichem Tunnelzugang — in Ihrer devcontainer.json zu kodifizieren. Dieser Leitfaden zeigt, wie man es richtig macht, welche Tools zu wählen sind und warum dieser architektonische Wandel wichtig ist.

---

Warum der alte Weg scheitert

Der klassische Entwickler-Workflow sieht so aus: Repo klonen, Abhängigkeiten installieren, ngrok global installieren, einen Tunnel starten, die URL irgendwo einfügen und bei Ablauf der Sitzung wiederholen. Es funktioniert — bis es nicht mehr funktioniert.

Die Probleme verschärfen sich mit wachsendem Team:

• Nicht-Reproduzierbarkeit. Die Version des Tunneling-Tools auf Ihrer Maschine unterscheidet sich von der Ihres Kollegen. Das Verhalten divergiert. Bugs werden auf die falsche Ebene geschoben.
• Sicherheitsverschiebung. Ein global installierter Daemon mit Netzwerkkonfiguration sitzt auf Ihrem Host-Betriebssystem, außerhalb jeder Container-Grenze. Seine Anmeldeinformationen sind oft unverschlüsselt im Home-Verzeichnis gespeichert.
• Port-Kollisionen. Hardcodierte Ports wie 3000 oder 8080 kollidieren zwischen Projekten. Sie fangen an, sich zu merken, welches Projekt welchen Port besitzt. Das ist keine Ingenieurskunst; das ist Archäologie.
• Onboarding-Hindernisse. Jeder neue Entwickler benötigt eine separate Setup-Anleitung nur für das Tunneling-Tool. Diese Anleitung wird veraltet.

Die DevContainer-Spezifikation, die gemeinsam von Microsoft und der Community gepflegt wird, löst dieses Problem auf der Environment-Ebene. Durch die Definition einer dockerComposeFile in devcontainer.json zusammen mit einem Sidecar-Service machen Sie den Tunnel zu einer erstklassigen, versionierten Komponente Ihrer Software-Lieferkette — ephemer standardmäßig, reproduzierbar durch Design.

---

Die Architektur: Sidecar-Container erklärt

Das Sidecar-Muster stammt aus der Microservices-Architektur. Ein Sidecar ist ein sekundärer Container, der neben Ihrem primären Anwendung-Container läuft, sein Netzwerk-Namespace teilt, aber eine eigene operative Aufgabe übernimmt — in diesem Fall das Tunneling. Ihr Anwendungscode berührt den Tunnel nie. Der Tunnel berührt Ihren Anwendungscode nie. Beide sind disposable; keiner ist eine Schneeflocke.

In Docker Compose-Notation sieht das so aus:

.devcontainer/
├── devcontainer.json
├── docker-compose.yml
└── (optional) Dockerfile

Der primäre app-Service läuft Ihren Code. Der Tunnel-Sidecar — ob cloudflared, zrok oder eine Alternative — läuft als abhängiger Service, startet nach der Gesundheit des app-Services und beendet sich sauber, wenn der Compose-Stack heruntergefahren wird.

---

Option 1: Cloudflare Tunnel (cloudflared)

Cloudflare Tunnel, zugänglich via den cloudflared-Daemon, ist die am weitesten verbreitete Option für Teams, die bereits Cloudflare für DNS nutzen. Es stellt ausgehende Verbindungen zum Edge-Netzwerk von Cloudflare her, erfordert keine eingehenden Firewall-Regeln oder öffentliche IP-Adressen.

Token erhalten

Erstellen Sie einen benannten Tunnel im Cloudflare Zero Trust Dashboard. Während der Einrichtung generiert Cloudflare einen TUNNEL_TOKEN. Kopieren Sie ihn sofort — er wird nicht erneut angezeigt. Speichern Sie ihn als lokale Umgebungsvariable oder in Ihrem Secrets-Manager (GitHub Codespaces Secrets, GitLab CI Variablen etc.), niemals im Repository.

docker-compose.yml

version: '3.8'

services:
  app:
    image: mcr.microsoft.com/devcontainers/node:20
    volumes:
      - ../:/workspace:cached
    command: sleep infinity
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 15s

  cloudflared:
    image: cloudflare/cloudflared:latest
    command: tunnel --no-autoupdate run
    environment:
      - TUNNEL_TOKEN=${CLOUDFLARE_TUNNEL_TOKEN}
    depends_on:
      app:
        condition: service_healthy
    restart: unless-stopped
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

devcontainer.json

{
  "name": "Node.js + Cloudflare Tunnel",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspace",

  "remoteEnv": {
    "CLOUDFLARE_TUNNEL_TOKEN": "${localEnv:CLOUDFLARE_TUNNEL_TOKEN}"
  },

  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint"
      ]
    }
  }
}

Das ${localEnv:VARIABLE_NAME}-Schema weist die DevContainer-Engine an, den Wert aus der Host-Umgebung des Entwicklers beim Start zu lesen und in den Compose-Kontext zu injizieren. Keine Anmeldeinformationen berühren jemals das Repository. Der Tunnel authentifiziert, verbindet und ist bereit vor Ihrem ersten npm run dev.

Sicherheitshinweis: Stellen Sie immer network_mode für den cloudflared-Container so ein, dass nur über das interne Docker-Netzwerk kommuniziert wird — nicht mit network_mode: host. Dadurch kann der Tunnel-Sidecar den app-Container per Service-Name erreichen, aber nicht direkt die Netzwerkschicht des Hosts probeweise ansprechen.

---

Option 2: Zrok — Zero-Trust Ephemeral Tunnels

Während Cloudflare in verwalteten Umgebungen dominiert, hat zrok — gebaut auf dem OpenZiti Zero-Trust-Netzwerk-Overlay — bei Entwicklern an Bedeutung gewonnen, die vollständige Infrastrukturkontrolle oder vollständig ephemeral, disposable URLs wünschen. Zrok erreichte den Meilenstein 1.0 Ende 2025, mit einem neuen Agent-Console, reservierter Share-Persistenz und erweiterten Self-Hosting-Optionen via Docker Compose mit Caddy für automatische TLS.

Der entscheidende Unterschied: Wenn Sie einen zrok-Share stoppen, ist die URL sofort weg. Es gibt keinen lingernden DNS-Eintrag, keinen Zombie-Tunnel, keine verwaiste Anmeldeinformation. Für einen DevContainer-Kontext — der selbst ephemer ist — genau das richtige Verhalten.

Zrok unterstützt auch private Shares, bei denen Ressourcen niemals an einen öffentlichen Endpunkt exponiert werden und die gesamte Kommunikation Ende-zu-Ende verschlüsselt ist. Das ist nützlich für Team-internes Review-Umfeld, bei dem keine öffentliche URL gewünscht ist.

docker-compose.yml

version: '3.8'

services:
  app:
    image: mcr.microsoft.com/devcontainers/python:3.11
    volumes:
      - ../:/workspace:cached
    command: sleep infinity
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

  zrok-sidecar:
    image: openziti/zrok:latest
    environment:
      - ZROK_ENABLE_TOKEN=${ZROK_TOKEN}
    depends_on:
      app:
        condition: service_healthy
    command: 
      sh -c "zrok enable $$ZROK_ENABLE_TOKEN 
             zrok share public http://app:8000 --headless"

Wenn der Stack startet, aktiviert der Sidecar die Zrok-Umgebung mit Ihrem Token, stellt sofort eine temporäre öffentliche URL bereit, die auf die Python-Anwendung auf Port 8000 routet. Die URL wird in den Container-Logs ausgegeben. Bei docker compose down wird der Zrok-Prozess beendet und der Share gelöscht.

Um die generierte URL abzurufen, inspizieren Sie die Sidecar-Logs:

docker logs <projekt>-zrok-sidecar-1

Oder konfigurieren Sie den Sidecar, um die URL in einem geteilten Volume zu schreiben, das Ihr postStartCommand lesen und in das VS Code-Terminal ausgeben kann.

---

Option 3: pgrok — Selbstgehostete Multi-Tenant-Tunnels

Für Teams, die Enterprise-Tunneling ohne den Enterprise-Preis suchen, bietet pgrok eine SSH-basierte Multi-Tenant-Lösung, die auf Ihrer eigenen Domain läuft. Es unterstützt OIDC-Authentifizierung, sodass Entwickler sich über Ihren bestehenden SSO-Anbieter (Okta, Auth0, Google Workspace etc.) authentifizieren, bevor eine Tunnel-URL ausgegeben wird. Die resultierenden URLs folgen dem Muster https://feature-x.alice.dev.example.com — stabil, menschenlesbar und auf den einzelnen Entwickler zugeschnitten. Ein Kubernetes-Operator kann pgrok automatisch als Sidecar injizieren, sodass jeder Pod eine reviewbare URL erhält, ohne dass eine spezielle Konfiguration erforderlich ist.

Für Teams, die bereits eine Domain und einen SSO-Anbieter betreiben, bietet dies die meisten “Enterprise ngrok”-Erfahrungen bei Infrastrukturkosten im Bereich weniger Dollar pro Monat.

---

Das Tunneling-Tool-Landschaft im Jahr 2026

Der Wettbewerbsdruck auf ngrok hat zugenommen. Im Februar 2026 öffnete das Open-Source-Projekt DDEV ein Issue, um die Standard-Share-Provider-Option auf ngrok zu verzichten, aufgrund der verschärften Limits im kostenlosen Tarif. Der Markt hat mit brauchbaren Alternativen auf allen Preispunkten reagiert:

Tool	Modell	Beste Nutzung	Kostenloser Tarif
Cloudflare Tunnel	Managed SaaS	Teams auf Cloudflare DNS	Ja (großzügig)
zrok	Open Source / SaaS	Ephemer, Zero-Trust, self-hostable	Ja
pgrok	Selbstgehostet	Teams mit eigener Domain + SSO	Nur Infrastrukturkosten
Tailscale Funnel	Mesh VPN	Privater Team-Zugang, WireGuard-basiert	Ja (persönlich)
Inlets	Selbstgehostet / SaaS	Kubernetes-native, Prometheus-Metriken	Nein ($25+/Monat)
ngrok	Managed SaaS	Gut dokumentiert, weit verbreitet	Eingeschränkt ab 2026

Für Webhook-Tests — den häufigsten Anwendungsfall in DevContainers — sind sowohl Cloudflare Tunnel (persistente benannte URL) als auch zrok (ephemere URL pro Sitzung) starke Optionen. Cloudflare ist die Wahl, wenn Sie einmal einen Webhook-Endpunkt in einem Drittanbieter-Service (Stripe, GitHub) konfigurieren und belassen möchten. Zrok ist die Wahl, wenn Sie keinen persistenten Zustand wollen und maximale Isolation pro Sitzung.

---

Beste Praktiken

1. Immer Gesundheitschecks und depends_on-Bedingungen verwenden

Der häufigste Fehler bei Sidecar-Tunnel-Setups ist, dass der Tunnel online kommt, bevor die Anwendung vollständig hochgefahren ist, was zu 502 Bad Gateway-Fehlern während des Startfensters führt. Die Lösung sind explizite Gesundheitschecks für den app-Service und condition: service_healthy im depends_on-Block des Sidecars. Das ist keine Option.

depends_on:
  app:
    condition: service_healthy

Ohne das garantiert Docker Compose nur den Start-Order der Container, nicht die Bereitschaft der Anwendung.

2. Hardcodierte Host-Port-Mappings vermeiden

Wenn Sie den Traffic durch einen Sidecar-Tunnel leiten, brauchen Sie keine Container-Ports mit ports: - "3000:3000" an den Host zu binden. Entfernen Sie diese Mappings. Das eliminiert Port-Kollisionen vollständig — ein anderes Projekt kann Port 3000 auf derselben Maschine nutzen, ohne Konflikt. Wenn Sie während der Entwicklung auch lokalen Browser-Zugriff benötigen, verwenden Sie die integrierte Port-Weiterleitung von VS Code anstelle eines statischen Docker-Ports.

3. Sichere Secret-Injektion

Das ${localEnv:VARIABLE_NAME}-Schema in devcontainer.json ist der richtige Ansatz für alle Umgebungen. Für GitHub Codespaces speichern Sie Ihren CLOUDFLARE_TUNNEL_TOKEN oder ZROK_TOKEN in der Secrets-Interface des Codespaces — sie werden automatisch beim Start als Umgebungsvariablen injiziert, wo ${localEnv:...} sie abholt. Schreiben Sie niemals Tokens in .env-Dateien, die git-geführt sind. Fügen Sie .env zu .gitignore hinzu und behandeln Sie es als lokale Datei.

4. Log-Übersicht für Sidecar-Container

Da der Sidecar im Hintergrund läuft, erscheinen seine Logs nicht im Haupt-VS Code-Terminal. Entwickler müssen sie aktiv abrufen. Es gibt drei praktische Optionen:

• Nutzen Sie die Docker-Erweiterung in VS Code, um einzelne Container-Logs im Sidebar zu tailen.
• Führen Sie docker logs <projekt>-zrok-sidecar-1 --follow in einem Host-Terminal aus.
• Konfigurieren Sie einen postStartCommand in devcontainer.json, der eine URL liest, die vom Sidecar in einem geteilten Volume geschrieben wurde, und geben Sie sie im Terminal aus.

Die dritte Option bietet die beste Entwickler-Erfahrung — die öffentliche URL erscheint automatisch im VS Code-Terminal beim Container-Start, ohne manuelles Log-Inspektion.

5. Image-Versionen in Produktions-Teams pinnen

Für individuelle Experimente ist cloudflare/cloudflared:latest oder openziti/zrok:latest ausreichend. Für Team-DevContainers, die in ein Repository eingecheckt werden, pinnen Sie auf eine spezifische Digest oder Version-Tag. Das verhindert, dass ein stilles Upstream-Image-Update die Umgebung aller gleichzeitig zerbricht, was besonders relevant ist, da sowohl cloudflared als auch zrok häufig neue Versionen veröffentlichen.

image: cloudflare/cloudflared:2025.2.0

---

Alles zusammen: Ein vollständiger Workflow

Hier ist das End-to-End-Entwickler-Erlebnis, wenn alles richtig eingerichtet ist:

1. Entwickler klont das Repository.
2. VS Code erkennt .devcontainer/devcontainer.json und fordert auf, in den Container neu zu öffnen.
3. Docker Compose startet den app-Container und den Tunnel-Sidecar.
4. Der app-Container führt seinen Gesundheitscheck aus; nach der Gesundheit startet der Sidecar.
5. Der Sidecar authentifiziert, stellt den Tunnel bereit und schreibt die öffentliche URL in ein geteiltes Volume.
6. Der postStartCommand liest die URL und gibt sie im integrierten Terminal aus.
7. Der Entwickler sieht innerhalb weniger Sekunden nach Laden der Umgebung etwas wie https://mein-projekt.beispiel.com im Terminal.
8. Er fügt diese URL in die Webhook-Konfiguration von Stripe ein und beginnt zu coden.
9. Wenn er Ctrl+C drückt und der Container stoppt, wird der Tunnel zerstört. Kein Aufräumen erforderlich.

Keine host-installierten Tools. Keine manuelle Token-Verwaltung. Keine Port-Kollisionen. Keine veralteten URLs, die auf einen Laptop zeigen, der seitdem den Deckel geschlossen hat.

---

Fazit

Das Sidecar-Proxy-Muster in DevContainers ist kein Nischen-Architektur-Experiment — es ist der richtige Weg, localhost-Tunneling im Jahr 2026 zu handhaben. Ob Sie Cloudflare Tunnel für seine verwaltete Zuverlässigkeit, zrok für sein Zero-Trust-ephemeres Modell oder pgrok für vollständige Infrastrukturkontrolle wählen, das Prinzip ist dasselbe: Tunneling-Infrastruktur gehört in die Container-Definition, versioniert neben dem Anwendungscode, nicht ad-hoc auf der Host-Maschine des Entwicklers installiert.

Das Ergebnis ist schnellere Einarbeitung, bessere Sicherheitslage, reproduzierbares Netzwerkverhalten und ein Ende der “funktioniert auf meinem Rechner”-Probleme beim Tunneling. Docker wurde genau dafür entwickelt — nutzen Sie es.