wiredoor is a free, open source networking & connectivity project written in TypeScript and released under Apache-2.0. It has 1,623 GitHub stars, 78 forks and 9 open issues, and was last pushed 10 hours ago. On this registry it ranks #46 of 61 tracked projects in Networking & Connectivity, with 5 head-to-head comparisons available.

What is wiredoor?

wiredoor is a self-hosted ingress-as-a-service platform for developers and infrastructure operators who need to expose HTTP, TCP, and UDP services running behind NAT or firewalls in private networks to the internet.

What it is

Wiredoor is an open-source, self-hosted ingress platform written in TypeScript and licensed under Apache-2.0. It lives in the infrastructure and networking ecosystem as a reverse proxy and tunneling system, and it replaces hosted tunneling services such as Cloudflare Tunnel or ngrok by letting operators own the public entry point, tunnel configuration, routing rules, and operational data on their own server.

The concrete problem it solves is publishing services that cannot accept direct inbound connections. Remote nodes initiate encrypted WireGuard tunnels outward to Wiredoor Server, so private services can stay behind NAT or a firewall without opening inbound VPN ports. Wiredoor Server terminates HTTP TLS connections, manages nodes and domains, and routes traffic through NGINX, while the private network only makes outbound connections.

Key capabilities

  • Exposes HTTP, TCP, and UDP services through a single ingress server.
  • Establishes encrypted WireGuard tunnels initiated from the private node side, so the private network never accepts a public inbound VPN connection.
  • Uses NGINX routing for domains, paths, and public ports, with WebSocket support for HTTP services.
  • Issues automatic Let's Encrypt certificates for eligible public domains and self-signed certificates for local and internal domains.
  • Enforces OAuth2 authentication and IP-based access restrictions on published services.
  • Offers management through both a web dashboard and the Wiredoor CLI, with Client Nodes available for Linux, Windows, and macOS.
  • Provides optional Prometheus metrics and Grafana dashboards for observing traffic.

Who uses it and how

  • Developers running services in home labs, private LANs, and Docker Compose environments who want a public entry point they control themselves.
  • Operators of on-premises servers and restricted networks who deploy a Linux Gateway Node to route to several services in an approved subnet over iptables.
  • Teams running private Kubernetes clusters who install a Kubernetes Gateway via the official Helm chart to reach services through Kubernetes networking and DNS.
  • IoT and industrial network operators who expose approved devices without permitting inbound connections to the network.
  • Developers whose private service runs on the same machine as the Wiredoor CLI, using Client Node mode natively on Linux, Windows, or macOS.

Getting started

The README points to a Quickstart and documentation, with a Docker image published as wiredoor/wiredoor on Docker Hub and official Helm Charts for Kubernetes deployment.

How it compares

Wiredoor stands alongside NGINX-based reverse proxying and WireGuard-based tunneling tools, combining both into a single managed ingress layer rather than requiring operators to assemble them separately. Its distinguishing position in this registry is that it is self-hosted under the Apache-2.0 licence, keeping the server, network paths, configuration, and operational data under the operator's control instead of depending on a hosted tunneling service.

When to use it — and when not

Gateway routing depends on Linux iptables rules, so a self-hoster must run and maintain Wiredoor Server, the WireGuard tunnels, NGINX routing, and certificate management, and should be comfortable operating Docker or a Kubernetes chart. Native CLI Gateway Node mode is unavailable on Windows and macOS, where a local gateway requires Docker Desktop with the Wiredoor Docker Gateway. It is a poor fit for teams that want a fully managed service with no infrastructure to operate, or that need inbound VPN connectivity initiated from the public side.

project readme (upstream, from github) — read inline

Wiredoor logo

Self-hosted ingress for HTTP, TCP, and UDP services on private networks.

Documentation | Quickstart | Wiredoor CLI | Helm Charts

CI Status Wiredoor Release CLI Release Docker License

What Is Wiredoor?

Wiredoor is an open-source, self-hosted ingress platform for exposing applications and services from private networks. Remote nodes initiate encrypted WireGuard tunnels to Wiredoor Server, so private services can remain behind NAT or a firewall without accepting direct inbound connections.

Wiredoor Server provides the public or internal entry point, manages nodes and domains, terminates HTTP TLS connections, and routes traffic through NGINX. You retain control of the server, network paths, configuration, and operational data.

Who Wiredoor Is For

Wiredoor is designed for developers and infrastructure operators who need to publish or remotely access services running in:

  • Home labs and private LANs.
  • On-premises servers and restricted networks.
  • Docker Compose environments.
  • Private Kubernetes clusters.
  • IoT and industrial networks.

It is a practical fit when you want to own the public entry point, tunnel, routing configuration, and operational data instead of depending on a hosted tunneling service.

How Wiredoor Works

flowchart LR
  user[User or application]
  server[Wiredoor Server]
  node[Client or Gateway Node]
  service[Private service]

  user --> server
  server <== WireGuard tunnel ==> node
  node --> service
  • Wiredoor Server receives HTTP, TCP, or UDP traffic and selects the configured route.
  • A Client Node exposes a service running on the same Linux, Windows, or macOS computer.
  • A Gateway Node provides access to approved services in a Docker network, Kubernetes cluster, or private subnet.
  • The node initiates the WireGuard connection, so the private network does not need to accept a public inbound VPN connection.

Read How Wiredoor Works for the complete request flow and component responsibilities.

Features

  • HTTP, TCP, and UDP service exposure.
  • Encrypted WireGuard tunnels initiated from private nodes.
  • NGINX routing for domains, paths, and public ports.
  • Automatic Let's Encrypt certificates for eligible public domains.
  • Self-signed certificates for local and internal domains.
  • OAuth2 authentication and IP-based access restrictions.
  • WebSocket support for HTTP services.
  • Web dashboard and CLI management.
  • Client Nodes for Linux, Windows, and macOS.
  • Gateway Nodes for Docker networks, Kubernetes clusters, and private subnets.
  • Optional Prometheus metrics and Grafana dashboards.

Choose a Node Type

Node type Where it runs Use it when
Client Node Linux, Windows, or macOS The private service runs on the same computer as Wiredoor CLI.
Linux Gateway Node Linux One node must route to several services in an approved subnet.
Docker Gateway Linux, Windows, or macOS through Docker Services run in Docker or a private network reachable by Docker.
Kubernetes Gateway Kubernetes through the official chart Services are reached through Kubernetes networking and DNS.

Gateway routing depends on Linux iptables rules. Native Wiredoor CLI installations on Windows and macOS support Client Node mode. To run a local Gateway Node on either system, use Wiredoor Docker Gateway through Docker Desktop.

Quickstart

The complete Wiredoor quickstart explains every step and includes CLI installation instructions for Linux, Windows, and macOS. The condensed journey is shown below.

Requirements

  • A reachable Linux server with Docker Engine, Docker Compose, and Git.
  • TCP ports 80 and 443 open on Wiredoor Server.
  • UDP port 51820 open on Wiredoor Server, unless you configure another VPN port.
  • An existing private HTTP service to expose.
  • A public domain, internal DNS name, or local hosts entry for the service.

1. Install Wiredoor Server

Clone the official Docker setup:

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

Open .env with your preferred text editor and configure the administrator credentials, public VPN hostname or IP address, VPN port, and VPN subnet. Then start Wiredoor:

docker compose up -d
docker compose ps wiredoor

Open the Wiredoor Server address in your browser and sign in with the administrator credentials from .env.

2. Connect a Client Node

Follow the Wiredoor CLI installation instructions for the operating system that runs your private service. Then register the Client Node:

wiredoor login --url https://wiredoor.example.com
wiredoor status

Replace the example URL with the domain or IP address of your Wiredoor Server.

3. Expose a Private Service

The following example exposes an existing HTTP service running on port 3000:

wiredoor http first-app --domain app.example.com --port 3000

Open https://app.example.com and confirm that the private application responds through Wiredoor.

Public DNS Is Optional

Wiredoor does not require a public domain. You can use an internal DNS name or define a local domain in /etc/hosts, the Windows hosts file, or the equivalent hosts file on macOS. Public domains are useful when the service needs a publicly trusted Let's Encrypt certificate.

Read Use Wiredoor Without Public DNS for examples and certificate considerations.

Gateway Deployments

Docker Gateway

Wiredoor Docker Gateway can expose containers on a shared Docker network or services in a private subnet reachable from the gateway container. It also provides a local Linux Gateway environment through Docker Desktop on Windows and macOS.

Configure Wiredoor Docker Gateway

Kubernetes Gateway

Wiredoor Kubernetes Gateway connects a cluster to Wiredoor Server and routes approved traffic to Kubernetes Services through cluster networking and DNS.

Configure Wiredoor Kubernetes Gateway

Optional Monitoring

Prometheus and Grafana are optional integrations. Wiredoor works without them, including nodes, tunnels, domains, certificates, access controls, and HTTP, TCP, or UDP service exposure.

Enable the monitoring stack only when you want historical metrics and Grafana dashboards for NGINX traffic and WireGuard peers.

Monitor Wiredoor with Prometheus and Grafana

Documentation

Security Responsibilities

Wiredoor reduces direct exposure of private services, but each deployment still requires appropriate security controls:

  • Protect administrative services with OAuth2 or a restrictive, tested IP allow list.
  • Store administrator credentials, node tokens, and private keys securely.
  • Expose only the ports and Gateway subnets that are required.
  • Keep Wiredoor Server, Wiredoor CLI, container images, and host systems updated.
  • Back up persistent data before upgrades or configuration changes.

Read Wiredoor Security and Deployment Hardening before exposing administrative or sensitive services.

License

Wiredoor is licensed under the Apache License 2.0.

Versions prior to 1.5.1 remain licensed under the MIT License. Version 1.5.1 and later use the Apache License 2.0.

Frequently asked questions

Is wiredoor free to use?

wiredoor is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does wiredoor do?

Self hosted ingress-as-a-service platform that allows you to expose applications and services running in private or local networks to the internet

What is wiredoor written in?

wiredoor is primarily written in TypeScript. Its source is publicly available at https://github.com/wiredoor/wiredoor, and it has 1,623 GitHub stars.