wiredoor: Expose Private Services Through Secure Tunnels

Overview

Wiredoor provides a self-hosted way to make services on private networks reachable without opening inbound connections to those networks. Nodes initiate encrypted WireGuard tunnels to a Wiredoor Server, which handles incoming traffic and routes it to configured services.

It is a fit for operators who want control over ingress, routing, and operational data, rather than relying on a hosted tunneling provider. Client Nodes serve a computer’s local services, while Gateway Nodes can reach services across Docker, Kubernetes, or private networks.

Key Features

• Exposes HTTP, TCP, and UDP services through a central server.
• Uses node-initiated WireGuard tunnels to reach networks behind NAT or firewalls.
• Routes HTTP traffic by domain and path, and supports public ports for other traffic.
• Manages TLS certificates, including automatic Let’s Encrypt certificates for eligible public domains.
• Provides OAuth2 authentication and IP-based access restrictions.
• Supports Client Nodes and Gateway Nodes for Linux, Windows, macOS, Docker, and Kubernetes deployments, with platform-specific gateway caveats.
• Offers a web dashboard, CLI management, and optional Prometheus and Grafana monitoring.

Use Cases

• Home lab owners can publish selected applications without exposing their LAN directly to inbound connections.
• Infrastructure operators can provide access to services in on-premises or restricted networks through a server they control.
• Developers can share a local or Docker-based service for remote access or testing, while keeping the service on its private network.
• Kubernetes administrators can route approved traffic from a Wiredoor Server to services inside a private cluster.
• IoT and industrial operators can connect services in private networks where opening inbound VPN connections is undesirable.

Project Facts

• Language: TypeScript
• License: Apache-2.0
• Stars: 1.6k
• Forks: 78
• Topics: api-server, ingress-service, management-system, nginx, reverse-proxy, self-hosted, tunneling, vpn, wireguard
• Archived: No

Getting Started

The documented setup uses Docker Compose on a reachable Linux server. Start with the quickstart and the Docker setup repository:

git clone https://github.com/wiredoor/docker-setup.git
cd docker-setup
cp .env.example .env

Configure the environment, start the server with docker compose up -d, then install and register a node using the Wiredoor CLI. See the README for the full setup, node options, and service configuration.

Alternatives

• NPMplus: NPMplus manages proxy hosts through a web interface, while Wiredoor routes services on private networks through WireGuard tunnels.
• netgoat: NetGoat focuses on reverse-proxy controls such as authentication and caching, while Wiredoor provides WireGuard-based access to private services.
• openresty-manager: OpenResty Manager centralizes proxy, certificate, and container management, while Wiredoor connects public ingress to private services over WireGuard.

Considerations

• The server setup requires a reachable Linux host with Docker Engine, Docker Compose, and Git. The documented default also needs TCP ports 80 and 443 and UDP port 51820 open, unless the VPN port is changed.
• Gateway routing depends on Linux iptables. Native CLI installations on Windows and macOS support Client Node mode; local Gateway Node deployments on those systems require Docker Desktop.
• Public DNS is optional, but a public domain is useful for obtaining publicly trusted Let’s Encrypt certificates. Local or internal domains have different certificate considerations.
• Self-hosting makes operators responsible for server and node updates, credential and key storage, backups, and restricting access to administrative services and gateway networks.
• The project is licensed under Apache-2.0; versions before 1.5.1 used MIT, according to the README.