frpmgr: Windows GUI for managing FRP reverse proxy configurations

A form-based GUI that removes the FRP TOML config file

FRP (Fast Reverse Proxy) requires users to write and maintain TOML configuration files to define proxies, visitors, authentication and transport settings. frpmgr replaces that workflow with a GUI. Changes are made through forms, and frpmgr generates and manages the underlying configuration files without requiring the user to edit them by hand.

Multi-node deployments are a specific case it addresses. Connecting to several different FRP servers ordinarily means maintaining separate configuration files and managing separate frpc processes. frpmgr treats each server connection as a named configuration item that the GUI tracks and controls in one place.

Windows users who already run FRP for tunneling local services through NAT or firewalls, and who want to avoid the friction of a text editor and a separate launcher, are the audience the README targets.

Launched configurations become Windows services, not processes tied to the GUI window

Starting a configuration in frpmgr registers it as a Windows service. That service runs independently of the GUI, so closing the application window does not stop the proxy. This is the closable GUI feature the README names first in its feature list.

Auto-start is built into this service registration. A configuration launched through frpmgr starts automatically at system boot without requiring a user login, because the service runs in the Windows service layer rather than as a user-session process.

Status tracking gives a direct view of proxy state in a table inside the GUI. Checking whether a proxy is active requires no log file inspection: the table shows status directly.

This service-based architecture also means uninstalling a configuration requires explicitly stopping and removing the service, not just closing the GUI. The Wiki covers that procedure; the README does not.

Installing the binary or building from source on Windows

Binary installs and upgrade instructions are in the Wiki at github.com/koho/frpmgr/wiki rather than in the README. The README requires Windows 10 or Server 2016 as the minimum platform.

Building from source requires five dependencies: Go, Node v22, the Windows SDK, MinGW, and WiX Toolset v3.14. After installing them, set the `WindowsSdkVerBinPath` environment variable to point to the Windows SDK version's bin path, and add MinGW's bin directory to PATH. Then:

git clone https://github.com/koho/frpmgr
cd frpmgr
build.bat

Installation files land in the bin directory. Passing -p to the build command skips installer creation and produces a portable application instead, cutting the required dependencies down to just Go and MinGW and eliminating the need for Windows SDK and WiX Toolset entirely:

build.bat -p

For a debug run, compile resources once with `go generate`, which does not need to run again unless the project's resources change, then run `go run ./cmd/frpmgr` to launch the application directly.

Hot reload applies proxy changes without dropping the running service

Changing a proxy in a running FRP configuration normally means stopping the frpc process, updating the config file and restarting. frpmgr's hot reload applies changes to a running configuration without restarting the service and without losing proxy state.

This matters in production tunnels where a restart would interrupt a connection mid-session. Adding, removing or modifying a proxy rule can happen while the tunnel is active.

Hot reload is listed as a separate feature alongside service registration and auto-start, which means it is designed to work on already-running services rather than only on configurations that were just launched. The README does not describe any constraints on which types of proxy changes can be hot-reloaded versus which require a restart, so the Wiki is the reference for edge cases.

Self-destructing configurations and three configuration import sources

A self-destructing configuration is one that disappears and becomes unreachable after a certain amount of time. frpmgr lists this as a feature; the README names it but does not describe the mechanism for setting the expiration time or the behavior when it triggers. The Wiki is the documented reference.

Configuration import accepts three sources: a local file, the clipboard and HTTP. Local file covers importing an existing frpc TOML configuration. Clipboard import avoids a file save step when copying a configuration from elsewhere. HTTP import pulls the configuration from a URL, which suits configurations distributed via an internal service or a provisioning endpoint.

Export is also available, so a configuration created through the GUI can be saved as a TOML file for use in a plain frpc installation or for sharing with another frpmgr instance.

frp v0.71.0 in go.mod and why the server version must match

go.mod lists `github.com/fatedier/frp v0.71.0` as a direct dependency. frpmgr bundles frpc, the FRP client, at that version. FRP's server-side protocol evolves across versions, and a mismatch between the client version embedded in frpmgr and the frps version on the server can cause connection failures.

Any deployment that upgrades the FRP server needs to verify frpmgr compatibility at the same time. Upgrading frpmgr itself is the way to move to a newer frp client version; the embedded frpc version is not configurable at runtime.

go.mod also declares Go 1.25.0 as the minimum toolchain version for anyone building from source. Two key Windows-specific dependencies appear as direct requirements: `github.com/lxn/walk` for the Windows GUI layer and `github.com/Microsoft/go-winio` version 0.6.2 for Windows service integration. Configuration parsing uses go-toml version 2.2.0, and low-level system calls go through golang.org/x/sys version 0.47.0. The dependency tree includes quic-go 0.60.0 and kcp-go 5.6.13 as transport libraries, inherited from frp 0.71.0's transport layer.

frpmgr is distributed under Apache-2.0.

When frpmgr is limited by platform or deployment scope

frpmgr runs only on Windows. The build toolchain requires Windows SDK and a Windows-native batch script. There is no documented path for running frpmgr on Linux or macOS, and the repository topics list windows as the only operating system.

Building the installer version requires five separate tools, including WiX Toolset v3.14. That is a significant setup cost for a first build. The portable build path reduces this to Go and MinGW, but it also skips installer generation, which means no Windows Add/Remove Programs entry and no Start Menu shortcut.

Code signing for distributed builds is provided by SignPath Foundation under their free code signing program. A custom build distributed outside that program would lack the certificate, which triggers security warnings on modern Windows systems.

frpmgr manages only the FRP client (frpc) side. Server management (frps configuration and administration) is outside its scope: for that, a separate tool or direct server configuration is required.

Editorial conclusion

frpmgr suits Windows users who find FRP's TOML configuration file approach tedious and want a GUI that manages multiple FRP client nodes as persistent Windows services. It does not run on Linux or macOS, and its frp client version (v0.71.0 per go.mod) must match the frp server version on the other end of the tunnel. The self-destructing configuration and per-instance hot reload are features uncommon in proxy manager GUIs. Before deploying, check whether your frp server is compatible with frp v0.71.0, then read the Wiki at github.com/koho/frpmgr/wiki for installation steps, since the README links there rather than embedding them.

Frequently asked questions

Official sources

1. Issues
2. koho/frpmgr on GitHub
3. License: Apache-2.0
4. README
5. Releases