Parallel Tasks, Single Developer: Orchestrating FRP Setup

Parallel Execution: How a Single Developer Orchestrated 8 Tasks on an Admin Panel

The borisovai-admin project needed something that had been on the backlog for weeks: proper FRP (Fast Reverse Proxy) tunneling support for the single-machine deployment setup. The challenge wasn’t complex in isolation—but it required coordinating file creation, template generation, configuration management, and documentation updates. Most developers would tackle this sequentially. This developer chose a different approach.

The situation was clear: the infrastructure had four server-side configuration files that needed to exist, plus four existing files that needed surgical updates to wire everything together. Instead of creating files one by one and testing incrementally, the developer made a bold decision: create all four new files in parallel, then modify the existing ones in a coordinated batch.

First came the heavy lifting—an installation script at scripts/single-machine/install-frps.sh (~210 lines) that handles the entire FRP server setup from scratch. This wasn’t just a simple download-and-run affair. The script orchestrates binary downloads, systemd service registration, DNS configuration, and firewall rules. It’s the kind of file where one missing step breaks the entire deployment chain. Alongside it went the Windows client template in config/frpc-template/frpc.toml—a carefully structured TOML configuration that developers would use as a starting point for their local setups.

The pre-built infrastructure pieces followed: a systemd unit file for frps.service that ensures the tunnel survives server restarts, and a Traefik dynamic configuration for wildcard routing through the FRP tunnel (port 17480). This last piece was particularly clever—using HostRegexp patterns to make FRP transparent to the existing reverse proxy setup.

Then came the coordination phase. The configure-traefik.sh script gained step [6/7]—dynamic generation of that tunnels.yml file, ensuring consistency across environments. The upload script was updated to include the new installation binary in its distribution list. Configuration templates got four new fields for FRP port management: control channel (17420), vhost (17480), dashboard (17490), and service prefix.

Here’s something interesting about FRP: unlike traditional tunneling solutions, it’s designed for both internal network bridging and public-facing tunnel scenarios. The three-port arrangement here is deliberate—17420 stays accessible for control, 17480 hides behind Traefik (so clients never need direct access), and 17490 stays strictly localhost. This architecture pattern, where a middle service proxies another service, is what makes complex infrastructure actually maintainable at scale.

By the end of the session, all eight tasks landed simultaneously. The documentation got updated with a new “frp Tunneling” section in CLAUDE.md. The install-config.json.example file gained its FRP parameters. Everything was interconnected—each file knew about the others, nothing was orphaned.

The developer walked away with a complete, deployable FRP infrastructure that could be spun up with a single command on the server side (sudo ./install-frps.sh) and a quick template fill on Windows. No piecemeal testing, no “oops, forgot to update this reference” moments. Just eight tasks, orchestrated in parallel, landing together.

Sometimes the fastest way through is to see the entire picture at once.