Wiregate: a WireGuard and AmneziaWG server with zones, Tor exit and DNS stack

The port exposure problem it is built around

Wiregate is described as a fully automated Docker based WireGuard and AmneziaWG VPN server deployment and management tool, with an attachable intranet via Docker private networks and support for Tor as an exit proxy.

The concrete problem is in the About section and it is worth stating precisely, because it is the design driver. The tool lets users host other web applications on their existing server and connect to them securely without exposing those applications to the open internet. The mechanism is the WireGuard protocol combined with Docker networks and containers, so applications hosted behind the WireGate private network need not expose any ports and can only be reached through a WireGuard connection registered to an existing server interface on the deployed instance.

That is a real pattern: a small VPS acts as a VPN concentrator and the services you run on it stay private, reachable only over the tunnel. Most people who want this end up assembling it by hand, and the assembling is the tedious part.

The tool also carries a second, less advertised role. The README says Wiregate also acts as an ISP DNS query logging bypass, and that by default it is configured to have minimal or no logging.

One security property is enforced by the deployment itself rather than by configuration. The WireGuard dashboard and other services are only accessible on first deployment, through the master configuration that is generated at install and encrypted after being output to the console. The README adds a one-line warning in capitals: do not expose your dashboard.

Four zones decide what a peer can reach

The access control model is a set of four zones, and the zone a peer belongs to dictates its network access permissions. The README gives the whole matrix in one table.

Admin has everything: internet access, WireGuard dashboard access, Docker network access and peer to peer access. Members have internet access, Docker network access and peer to peer access, but no dashboard access. LAN Users have only peer to peer access, with no internet, no dashboard and no Docker network. Guest has internet access and nothing else, so no dashboard, no Docker network and no peer to peer access.

That matrix is the difference between a VPN server and a VPN server with an access policy. A Guest peer is the shape most self-hosted VPN providers offer, and in Wiregate it is a config option rather than a different service. A LAN User peer is a peer that can reach other peers on the tunnel but has no route outward, which is unusual to find in a consumer VPN and useful for a device that should only see local services.

The Admin zone carrying dashboard access is the one to think about, since the dashboard is the control plane for peers, and therefore the place where a peer configuration can be rewritten. The zone design is sound as long as the Admin zone stays small and the dashboard stays off the public interface, which is exactly what the master configuration and the exposure warning are there to enforce.

The container topology explains the feature list

The docker-compose.yml in the repository root is the clearest single view of what the tool actually is, and it is more informative than the feature bullets.

The network is a bridge named private_network, attachable, not internal, with a fixed subnet.

networks:
  private_network:
    driver: bridge
    driver_opts:
      com.docker.network.bridge.enable_icc: "true"
    attachable: true
    internal: false
    ipam:
      config:
        - subnet: 10.2.0.0/24

The services are then laid onto that network with static addresses. The wiregate service itself is built from a templated image reference and needs the tun device.

  wiregate:
    image: noxcis/${STATE}:${TAG}
    container_name: wiregate
    hostname: wiregate
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun  
    restart: unless-stopped

The NET_ADMIN capability and the tun device mapping are the two things that make a WireGuard server possible in a container, and the templated image reference tells you the build is parameterised by a state and a tag rather than pinned.

The DNS side is a chain. dnscrypt depends on wiregate and sits at 10.2.0.42. unbound depends on nothing but is given NET_ADMIN and a drill-based healthcheck against dnssec.works, and it lands at 10.2.0.200. adguard depends on unbound, mounts persistent config and data directories from ./configs/adguard, and sits at 10.2.0.100. A fourth service, darkwire, carries NET_ADMIN plus the ip_forward and src_valid_mark sysctls, which are the kernel settings a Tor exit or router container needs.

So the stack is: an encrypted tunnel, an authoritative resolver, a filtering resolver in front of it, a DNS-over-encryption resolver, and a Tor-capable gateway, all on one bridge network with fixed IPs.

Choosing an image channel is the first real decision

The Docker install path is where most people will start, and the README splits the published images into three named channels with a clarity that is unusual and useful.

The dev channel is the acid-rain-beta-v0.4.2 image, labelled as ongoing debugging and explicitly marked as having bugs. The edge channel is the jasper-beta image, labelled as pre-release images under ongoing production testing. The stable channel is the vidar image, described as prod tested stable tested images.

That labelling is direct about which one to use. The dev image is a debugging artefact, the edge image is a release candidate under real use, and the vidar tag is the one described as production tested. The corresponding GitHub release is named vidar-pre-release with the WireGuard version 1.0.0, dated 2024-12-10, and earlier releases are named terra-firma-tor and hydra.

The other thing to know is that the project has moved. The first note in the README says it moved to GitLab months ago, at https://gitlab.com/Noxcis/Wiregate, and that AmneziaWG 1.5 support is fully functional but still in development in flat-bridge builds. So the GitHub repository is a mirror of a project whose main development happens elsewhere, and the images are still published to Docker Hub under the noxcis organisation.

For the Docker Compose route, the repository ships a main.docker.compose.yml alongside docker-compose.yml, and the compose file uses ${STATE} and ${TAG} variables, so the channel is chosen by environment values rather than by editing the compose file.

The bare metal path exists for people without Docker

Not everyone running a VPN wants a container stack on the host, and the bare metal install path exists for them.

The README asks you to pull the update staging branch and lists the supported distributions: Ubuntu and Debian, Alpine, Fedora, Arch, SUSE, and CentOS or RHEL, with the note that other distributions may be supported with manual build dependency installation. The packages you need in place first are wireguard-tools, the AmneziaWG Linux kernel module with amneziawg-go already installed, iptables, tor, curl, ip6tables as optional per distro, tzdata and sudo.

The install sequence itself is a clone, a directory change, a privileged install call and a start call.

> git clone -b update-staging https://github.com/NOXCIS/Wiregate.git
> cd Wiregate/Src
> sudo ./wiregate.sh metal_install &&
> cd ../WireGate_Built
> ./wiregate.sh start

The branching is worth noting. The bare metal instructions point at a branch called update-staging, not at the default branch, and the built output lands in a separate directory, WireGate_Built, from which the start command runs. The tree at the repository root backs this up with a Src-oriented layout alongside install.sh, stackscript.sh, AutoInstaller-Functions/, configs/ and WG-Dash/.

For supported hardware, the README states x86-64, arm64, armv7 and armv6 architectures, with Ubuntu LTS and Debian 12 as the test operating systems and a Raspberry Pi 5, an Apple M2 and x86 CPUs as the test devices, with builds produced daily in UTC.

What to check before you expose it to anyone

There are limits that matter for anyone running this on a public IP.

The first is that the whole thing is a VPN server with the usual consequence: the exit node for peers is your server, so your provider sees the traffic and your server's address is associated with whatever your users do. Tor is offered as an exit proxy, and the topics list includes snowflake and obfs4proxy for the other direction, but whether to route traffic through Tor is a policy decision with latency cost, and nothing in the documentation makes a recommendation.

The second is the version churn. The GitHub copy has not been pushed to since 2026-04-09, the development has moved to GitLab, and the stable image predates the current AmneziaWG work. If you take the development path, you are tracking a project whose GitHub presence is a mirror, and the compose file references an image tag parameterised by state and tag, so a careless upgrade can move you between a stable and a beta build.

The third is the operational surface. DNS-over-encryption, an authoritative resolver, an ad-blocking resolver, a Tor gateway and a VPN server means several services whose configuration lives in ./configs/ as mounted volumes, and a healthcheck that queries dnssec.works over the network. When a DNS container misbehaves, the symptom is name resolution failures across the whole tunnel rather than a clear error in one place.

The licence is MIT, and the repository carries a SECURITY.md, so the project does have the paperwork for responsible disclosure.

Editorial conclusion

Adopt Wiregate if you want a self-hosted VPN that also carries private Docker services with per-peer zone permissions and an optional Tor exit, and skip it if you want a maintained upstream project, since the README states the project moved to GitLab months ago and the last push to this repository was on 2026-04-09. Before installing, pick an image channel deliberately, with the stable vidar tag rather than the beta ones, keep the generated master configuration and do not expose the dashboard, as the README warns, and confirm your architecture is one of x86-64, arm64, armv7 or armv6.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NOXCIS/Wiregate on GitHub
4. README
5. Releases