# FRP-Panel Multi-Node Management and WireGuard Networking

> FRP-Panel is a Web UI for managing multiple fatedier/frp servers and clients through a central Master. It supports scheduled configuration, credential distribution, edge Workers, and beta WireGuard networking, with Linux-only and public-IP constraints for that networking layer.

**VaalaCat/frp-panel** — a multi node frp webui and for https://github.com/fatedier/frp server and client management, which makes this project a Cloudflare Tunnel/Tailscale Funnel/Ngork platform and agent open source alternative

- Repository: https://github.com/VaalaCat/frp-panel
- Stars: 1,859 · Forks: 176
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/vaalacat-frp-panel

## FRP-Panel's Multi-Node Control Plane

FRP-Panel addresses the operational work that appears when fatedier/frp is no longer limited to a single server and one client. Instead of editing JSON configuration on each node, operators work through a Web UI and a central service called Master. The repository describes this as centralized configuration, unified credentials, dynamic scheduling, and management of any number of frpc clients and frps servers. Its intended users are therefore administrators or platform engineers operating tunnels across several machines, rather than someone who only needs a short-lived local port forwarding command.

The core unit is not an isolated tunnel configuration file. A deployment consists of a Master, one or more Servers, and one or more Clients. The Master handles authentication and configuration, Servers provide the public-facing entry point, and Clients run internal proxies. This division creates a clear administrative boundary, but it also means the deployment has more moving parts than standalone frpc and frps configuration.

The repository includes Go packages and a top-level Go module, while the project is described as primarily TypeScript. Based on the directory layout, the backend, command entry points, services, protocol definitions, and build files are substantial parts of the codebase, with the web interface likely maintained separately under `www`. That distinction matters for contributors because frontend work and backend work may follow different build and review paths. The README does not provide a contributor setup guide, so the repository alone is not enough to establish a complete development workflow.

## Master, Server, and Client Request Flow

The architecture assigns different responsibilities to each component. Master is the control plane and must be reachable by all Servers and Clients. It centralizes authentication, stores and distributes configuration, and provides the management surface. Server is the public endpoint that receives traffic on behalf of connected Clients. Client is the internal side of the tunnel and also serves as the execution environment for Workers and WireGuard networking.

This arrangement means FRP-Panel is not simply a static frontend over an existing FRP setup. The README explicitly calls Server and Client managed nodes within its architecture, and it says startup commands can be generated and distributed with credentials. The repository dependencies support the implementation areas that users would expect from such a control plane. They include `github.com/fatedier/frp v0.65.0`, Gin for HTTP handling, gRPC and protobuf packages, WebSocket support, SQLite support through GORM adapters, Casbin for authorization, scheduling through `go-co-op/gocron/v2`, and WireGuard-related packages.

That dependency set supports the documented claims, but it does not by itself prove the behavior of any particular deployment. For example, the presence of SQLite support does not confirm that SQLite is always the production database. The Dockerfile sets `DB_DSN` to a SQLite path under `/data`, which confirms the container image defaults to that database, while the `.env.sample` does not define `DB_DSN`. Operators who intend to change persistence need to consult the Wiki rather than infer a complete database configuration from these files.

## Deploying the Master Container and First Web Session

The README directs users to the FRP-Panel Wiki for deployment, usage, and configuration details. It does not include a complete installation command, a Docker Compose example, or the command sequence for adding the first Server and Client. For that reason, there is no justified first-run CLI tutorial to reproduce from the available documentation. The concrete deployment reference is `https://vaala.cat/frp-panel/en/`.

The repository includes `install.sh`, `install.ps1`, `Dockerfile`, `Dockerfile.standalone`, and a `.env.sample`, but their contents or invocation syntax are not shown here beyond the filenames. Copying an unverified installer command would risk introducing flags or behavior that the project has not documented. Start with the Wiki, select the deployment method it describes, and use the files that method names.

For container configuration, `.env.sample` contains these values. `APP_GLOBAL_SECRET` is shown with a placeholder value, and `MASTER_RPC_HOST` defaults to loopback. Replace the sample secret before any shared deployment and confirm the RPC host against the network topology required by the Master.

```bash
APP_GLOBAL_SECRET="123"
MASTER_RPC_HOST=127.0.0.1
```

The first concrete check after startup should be access to the Web UI on port `9000`. The Dockerfile exposes `9000` for the web port and `9001` for the RPC port. Its default command starts the `master` process, and its database environment setting points to `/data/data.db` with WAL journal mode. These are deployment facts, not a guarantee that a reverse proxy, TLS configuration, firewall policy, or first-account workflow is already correct.

## Port Exposure, Persistence, and Container Defaults

The default container image is based on Alpine. It installs `curl`, `bash`, and `sqlite`, copies the FRP-Panel binary and `etc` files into `/app`, creates `/data`, exposes ports `9000` and `9001`, and starts `master` by default. Persistence is therefore tied to the `/data` directory if SQLite remains the selected backend. A container replacement without preserving that directory can leave the container image intact while losing the database file, so volume planning belongs in the initial deployment rather than a later maintenance task.

The image configures the following database variable:

```dockerfile
ENV DB_DSN /data/data.db?_pragma=journal_mode(WAL)
```

The web and RPC ports should not be treated as interchangeable. Port `9000` serves the Web UI, while port `9001` is labeled for RPC. The architecture says every Server and Client must access Master, so network policy must account for the Master RPC path separately from browser access to the dashboard. The README does not document TLS termination, authentication hardening, firewall examples, or whether either port should be published directly on a public interface.

The Dockerfile also sets `TZ` to `Asia/Shanghai` and links `/app/etc/Shanghai` to `/etc/localtime`. That matters for logs and scheduled jobs presented through the application. It is an operational choice rather than a portable locale-neutral image. Teams whose compliance requirements use another time zone or demand UTC presentation should check how the application displays and executes schedules before relying on the default image.

## Workers and Beta WireGuard Networking Boundaries

Workers extend FRP-Panel beyond configuration management. According to the README, custom Workers can be deployed on Clients, exposed through a Server, and adjusted from Master while the system is running. This offers a different control model from manually distributing updates to each edge host. The documented scope is custom Workers managed through the three-part architecture, not a general container platform, function marketplace, or arbitrary cluster scheduler.

WireGuard support has narrower constraints. The README labels networking as beta and states that it supports WireGuard over UDP or WebSocket, multi-hop routing, custom routes and topology, and path selection informed by latency and bandwidth. It also requires at least one Client with a public IP to act as a relay and currently supports Linux only.

Those limitations are material. A deployment cannot assume that any existing Client can become a relay, and a mixed Windows, macOS, or Linux environment cannot use the networking feature uniformly. The repository dependencies include `golang.zx2c4.com/wireguard` and `wireguard/wgctrl`, as well as `go-iptables` and `netlink`, which align with Linux-oriented network configuration. The presence of Windows terminal packages elsewhere in the module does not expand the documented WireGuard platform support. Operators should treat beta status as a product boundary and test routing changes before depending on automatic path selection.

## Maintenance, Releases, and AGPL-3.0 Obligations

The repository is not archived. Its last push was on 2026-04-19, and the listed `v0.1.37` and `latest` releases were published on the same date. An `alpha` release is also listed. These records show recent release activity, but the project uses several release labels and marks networking as beta, so selecting an artifact requires care about which channel is intended.

The module declares Go 1.24.0 with toolchain go1.24.1. It embeds `github.com/fatedier/frp v0.65.0`, which links the panel's lifecycle to compatibility with FRP behavior and its own dependency updates. The repository also contains multiple Dockerfiles, installer scripts for Unix-like systems and PowerShell, a SQLite-based container default, and a networking component with elevated networking dependencies. Upgrade planning should therefore account for more than the frontend bundle. Operators need to check database persistence, FRP compatibility, Client relay requirements, and configuration changes across the chosen release channel.

The declared license is AGPL-3.0. That matters when FRP-Panel is modified, redistributed, or offered as a network service, although this review does not provide legal advice. Teams that embed it into a product or operate a modified deployment should review the applicable license terms and source-code obligations before adoption. Simply copying the `LICENSE` identifier into a compliance checklist is not a substitute for understanding how the deployment and distribution model apply.

## FRP-Panel Compared with Standalone frpc and frps

Standalone frpc and frps are the clearest alternative because FRP-Panel directly manages fatedier/frp servers and clients. The standalone approach keeps tunnel behavior and configuration close to the FRP process. It can fit a small deployment with one server, one client, and a configuration that does not change often. It also removes the central Master from the trust and availability path.

FRP-Panel takes a control-plane approach. Its Web UI centralizes configuration and credentials, supports multiple nodes, shows tunnels, Workers, logs, and statistics, and introduces scheduling. WireGuard networking adds topology and route management rather than only FRP proxy management. This is useful when manual edits, command distribution, and node-specific operational state become difficult to coordinate.

The trade-off is additional complexity. A single-node operator now has to account for Master availability, Server and Client registration, generated startup commands, database persistence, and potentially Worker deployment. A central control plane also concentrates credentials and administrative decisions. The repository does not document a detached fallback mode or a full rollback procedure, so it should not be assumed that the dashboard can manage an installation independently of its Master. For a simple tunnel, standalone FRP is likely the smaller and more direct fit. For repeated multi-node administration, FRP-Panel offers controls that plain configuration files do not.

## Conclusion

FRP-Panel fits operators who need one control plane for several FRP nodes and can accept its central Master, beta networking, and Linux-only WireGuard deployment boundary. It is unsuitable for a simple one-client tunnel or for teams that need WireGuard networking to work on non-Linux clients. Before adoption, verify the deployment instructions in the FRP-Panel Wiki, confirm how your existing FRP topology maps to Master, Server, and Client, and test the public relay requirement before putting production traffic behind the networking feature.

## FAQ

### How do I install FRP-Panel?

The README directs users to the FRP-Panel Wiki for deployment instructions. The repository includes `install.sh`, `install.ps1`, `Dockerfile`, and `Dockerfile.standalone`, but the README does not provide their complete invocation syntax.

### What components does FRP-Panel need?

FRP-Panel uses a central Master, public-facing Server nodes, and internal Client nodes. Master must be accessible from every Server and Client, while Clients can run Workers and participate in WireGuard networking.

### Does FRP-Panel support WireGuard on Windows or macOS?

The README says networking currently supports Linux systems only. It also requires at least one Client with a public IP to act as a relay.

### Can FRP-Panel replace Cloudflare Tunnel, Tailscale Funnel, or Ngrok-style services?

The repository description positions FRP-Panel as an open source alternative in the same broad category of service exposure and agent platforms. Its documented implementation manages fatedier/frp nodes, Workers, and beta WireGuard networking.

## Sources

- [Issues](https://github.com/VaalaCat/frp-panel/issues)
- [License: AGPL-3.0](https://github.com/VaalaCat/frp-panel/blob/main/LICENSE)
- [README](https://github.com/VaalaCat/frp-panel/blob/main/README.md)
- [Releases](https://github.com/VaalaCat/frp-panel/releases)
- [VaalaCat/frp-panel on GitHub](https://github.com/VaalaCat/frp-panel)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vaalacat-frp-panel