Defguard review: self-hosted WireGuard VPN with connection-level MFA

What Defguard actually replaces in a WireGuard setup

Plain WireGuard gives you encrypted tunnels and public keys. It does not give you a user directory, a way to revoke one laptop without touching every config file, or a second factor at connect time. Teams normally fill that gap with a VPN management UI, an identity provider and a spreadsheet of peer keys. Defguard's pitch is that those three things are one product.

The README lists the pieces: a WireGuard VPN with multiple locations and per-location access control, an internal OIDC provider for SSO plus external OIDC through Google, Microsoft or a custom provider, LDAP and Active Directory sync, TOTP and WebAuthn/FIDO2 factors, and a firewall with allow and deny rules per VPN location by user or group. The audience is an infrastructure or platform team that already understands WireGuard and wants the access layer above it, not a consumer looking for a commercial VPN endpoint.

One detail is worth separating from the marketing. The project describes itself as Zero-Trust with connection-level MFA, which is a different claim from "we have a login page". The MFA is attached to the VPN connection itself, not only to the web dashboard.

Core, Edge and Gateway: how the components divide the work

The architecture is deliberately split, and the split is the most interesting engineering decision in the repository. The README describes three roles. Core is the management plane: identity, authentication, authorization and policy. Edge is the public-facing entry point and exposes selected Defguard services; it lives in a separate repository at DefGuard/proxy. Gateway enforces network access policy for protected resources and has its own repository at DefGuard/gateway.

The docker-compose.yaml in the repository root shows how that maps onto containers. Core runs the REST API on port 8000 and a gRPC port on 50055. Gateway listens on 50051/udp for the WireGuard endpoint and on 50066 for its gRPC port, and it is the only service granted NET_ADMIN. Edge publishes its REST API on 8080 and its gRPC port on 50051. PostgreSQL 17 runs alongside them with a pg_isready healthcheck.

The practical consequence is that the attack surface is segmented: the WireGuard endpoint container holds the network capability, while the management plane does not. The cost is operational. You are deploying four services plus a database, and the gRPC ports between them are part of your internal network design, not an implementation detail you can ignore.

Installing Defguard with the one-line installer

The README points at a one-line installer as the fastest way to evaluate Defguard. It downloads and runs a setup script from the deployment repository, which provisions the Docker Compose stack.

bash <(curl -sSL https://raw.githubusercontent.com/defguard/deployment/main/docker-compose2.0/setup.sh)

The README carries an explicit warning next to that command: the method is intended for testing, demonstrations and evaluation only, and is not recommended for production. For production the project points to its deployment documentation, which covers architecture recommendations and high-availability configurations. Treat the installer as a way to see the product, not as the way to run it.

If you would rather run the stack yourself, the repository's docker-compose.yaml is the reference. It expects an IMAGE_TAG environment variable for the container images, and the .env.example file in the repository root lists the configuration the Core service reads.

DEFGUARD_DB_HOST="localhost"
DEFGUARD_DB_PORT=5432
DEFGUARD_DB_NAME="defguard"
DEFGUARD_DB_USER="defguard"
DEFGUARD_DB_PASSWORD="defguard"
DEFGUARD_HTTP_PORT=8000
DEFGUARD_GRPC_PORT=50055

Those keys define the database connection and the two ports Core binds. The same file has a commented DEFGUARD_COOKIE_INSECURE line marked "For localhost only", which is the switch you would leave alone on anything reachable from a network. After the stack is up, the remaining work happens in the web UI: create a VPN location, enroll a device, and install one of the desktop clients for Linux, macOS or Windows from the download page.

The client story: desktop, mobile and QR onboarding

Defguard is not browser-only. The README lists a desktop client for Linux, macOS and Windows with VPN management, MFA, multi-instance and multi-location support, and real-time connection statistics. The mobile clients for Android and iOS do VPN management with MFA and QR code onboarding, and the Android build is on Google Play while iOS is on the App Store.

The QR onboarding path matters for the mobile case, because it avoids typing a config onto a phone. What the README does not document is how a device that loses its MFA factor recovers, or what an administrator does when a user's phone is replaced. That is a re-enrollment question, and it is the kind of gap that only shows up during a real incident. The activity log with filtering and search is the place to look for the audit trail, but the README does not spell out the recovery workflow.

Where Defguard is the wrong tool

If you want a VPN that is one binary and one config file, Defguard is heavier than you need. WireGuard alone, or a thin management wrapper, will do. Defguard's value comes from the identity and policy layer, and you pay for it with PostgreSQL, four services, gRPC ports between them and a web UI to administer.

There is also a licensing boundary inside the repository. The README states that the code is dual licensed: everything except the contents of crates/defguard_core/src/enterprise is AGPL, and the enterprise directory is covered by a separate Enterprise License with its own LICENSE.md. Real-time SIEM streaming is listed as an Enterprise capability. If your deployment plan assumes that feature, the licence question is not theoretical, and it is worth reading that file before you build a roadmap around it.

Finally, the release cadence visible in the repository includes alpha and beta tags, for example v2.2.0-alpha1 and v2.1.0-beta1. A team that cannot absorb pre-release artifacts should track the stable releases and watch the default branch, which is stable/2.x.

Defguard compared with running WireGuard and an IdP separately

The realistic alternative is not another VPN product. It is assembling the same capability from parts: WireGuard for the tunnel, an identity provider such as Keycloak for SSO, and a device management layer you write or buy. That approach gives you best-of-breed components and independent upgrade paths. It also means the join between them is yours to maintain, and the enforcement point where "this user is disabled" becomes "this tunnel is closed" is code you own.

Defguard's difference is that the OIDC provider is internal to the product and the firewall rules are per VPN location by user or group, so revocation and policy live in the same database as the identity. The trade-off is the opposite of modularity: you adopt the whole stack, including its PostgreSQL schema and its release cadence. The repository does publish SBOMs, penetration test reports and architecture decision records, which is more disclosure than most projects at this stage offer, and it is a reasonable signal for teams that have to justify a dependency to a security reviewer.

Licence, maintenance and upgrade cost

The last push to the repository was on 2026-09-24, and the most recent stable release listed is v2.1.0 from 2026-09-04, with v2.2.0-alpha1 following on 2026-09-21. The repository is not archived. On licensing: the AGPL applies to the open core, and the contents of crates/defguard_core/src/enterprise fall under a separate Enterprise License. AGPL obligations for a self-hosted network service are a question for your own legal review, not something this article can settle, but the directory boundary is explicit and easy to check in the tree.

Upgrade cost is driven by the component split. Core, Edge and Gateway are separate images pinned by IMAGE_TAG in docker-compose.yaml, and Edge and Gateway live in their own repositories. That means a version bump is a coordinated change across images rather than a single container pull. The Dockerfile builds the web UI with pnpm and the Rust binary with cargo-chef, so building from source is possible but not a quick path. Teams that deploy from the published images avoid that build entirely.

Editorial conclusion

Adopt Defguard if you already run WireGuard and want identity, device enrollment and MFA tied to the tunnel rather than bolted on top, and you accept that the enterprise directory under crates/defguard_core/src/enterprise is licensed separately from the AGPL core. Do not adopt it if you want a managed service or a single-binary VPN: Defguard is a multi-component deployment with Core, Edge, Gateway and PostgreSQL. Before committing, verify three things in your own environment: that the desktop client covers the platforms your users run, that the enterprise licence terms in crates/defguard_core/src/enterprise/LICENSE.md are acceptable for the features you need, and that you have a production deployment plan, because the one-line installer is documented as evaluation-only.

Frequently asked questions

Official sources

1. DefGuard/defguard on GitHub
2. Issues
3. Project website
4. README
5. Releases