Five commands end with a WireGuard profile
The README assigns wgcf 5 jobs: registration, license updates, profile generation, account status, and WARP trace output. Registration saves account data in wgcf-account.toml, while generation writes wgcf-profile.conf for ordinary WireGuard software. This is useful on a router, server, container host, or another machine where the official 1.1.1.1 application is unavailable.
wgcf does not manage a persistent connection, firewall policy, route exclusions, or a kill switch. After profile generation, the README points to WireGuard's own quick start. The output is portable and easy to inspect, which suits headless systems. Desktop users who want one supported application should use Cloudflare's client.
Two commands still leave routing and DNS to you
The 2-command path is short: download a release, run wgcf register, then run wgcf generate. The profile uses an MTU of 1280, matching the value cited for Cloudflare's Android client. wgcf also has status for account details and trace for checking whether connected traffic reports warp=on or warp=plus. Those commands make enrollment easy to inspect.
Operating the tunnel calls for more work than the 2-command example shows. WireGuard needs administrator access and correct routes, DNS, firewall behavior, and service startup on the target host. The generated account and profile contain credentials, so both files need restricted permissions. Our lab could build and test the program without secrets, but that result does not prove that a given network will carry all required traffic.
What happened when we ran it
Our sandbox installed 63 Go packages in 35 seconds at commit b0ffa96. We used an unprivileged golang:1.24-bookworm container with 3 CPUs and 8 GB of RAM. The build completed in 39 seconds. The test step took 11 seconds and reported 3 passed with 0 failures. Nothing in those steps exposed a missing package, compiler failure, or broken unit test.
The repository itself was compact: 97 files, about 11,259 lines of source, and a 0.5 MB checkout. It included 2 CI workflow files and a Dockerfile, although it had no separate tests directory. Those are codebase facts rather than tunnel benchmarks. We did not measure bandwidth or latency, and the supplied lab record contains no claim about live WARP registration.
WARP+ binding can require a fresh account
WARP+ support comes with several conditions. The README accepts subscriptions bought directly through the official 1.1.1.1 app and says other keys are unsupported. One subscription can have at most 5 linked devices. Users copy the license key from the app, apply it with wgcf update, and generate a new profile. Device removal remains an account-management task in Cloudflare's app.
The awkward part is issue #85, which the README treats as a Cloudflare-side bug. An account that has already connected to WARP may continue to show warp=on after a valid WARP+ key is bound. The documented workaround starts with a fresh account and binds the key before any connection. That sequence is manageable for one machine, but it deserves an acceptance check before anyone repeats it across 5 device slots.
Issue 601 puts IPv6 and issue 619 puts HTTPS on the test list
Issue #601 reports that newly registered profiles were IPv4-only while older profiles still carried IPv4 and IPv6 on the same client and network. The reporter tested multiple keys and did not identify a local routing difference. It is one unresolved report, so it does not establish universal behavior. It does establish a sensible purchasing rule: if dual stack is required, verify a newly generated profile before deployment.
Issue #619 describes a different failure on Linux: WireGuard handshakes, DNS, ping, and some Cloudflare-hosted HTTPS worked, while requests to Google and GitHub timed out after 10 seconds. The reporter tried IPv4, multiple endpoints, two clients, and MTU values of 1280 and 1420. That report remains open. A production check should cover several real destinations and transfers, not stop at wg show or wgcf trace.
July's compatibility fix and August's push show maintenance
Release v2.2.32 shipped on July 23, 2026. It restored an older TLS fingerprint after issue #613 recorded HTTP 429 responses when version 2.2.31 created several profiles in succession. The fix and closed report show the maintainer reacting to a service compatibility change. They also show the cost of relying on enrollment behavior controlled outside the repository.
The last push was August 24, 2026, and recent activity included user reports plus dependency and build-action pull requests. GitHub listed 8,641 stars and 29 combined issues and pull requests when fetched. That is active maintenance around a six-year-old, MIT-licensed Go project. wgcf remains a good narrow utility when profile portability matters, provided the resulting tunnel is tested as carefully as any other network path.