DEV Community: ChenXX

"Managing a CLI Subprocess from Rust: Lifecycle, Logs, and Graceful Shutdown (Tauri)"

ChenXX — Mon, 20 Jul 2026 08:02:46 +0000

Most "wrapper" apps do the same thing: launch a CLI binary in the background, pipe its logs into the UI, and tear it down when the user quits. It sounds trivial — until you actually build it.

I recently worked through this while building MoonProxy, a GUI desktop client that wraps the frp CLI (frpc). The Rust side has to own the full lifecycle of that child process: spawn it on demand, surface a ring buffer of its stdout/stderr to the frontend, detect "are we actually connected?" from log heuristics, stop it cleanly on window close, and restart it atomically when the binary updates itself on disk.

This post is the pattern that emerged. It's framework-aware (Tauri v2) but the core ideas apply to any Rust app that needs to babysit a long-running CLI.

The naive version (and why it bites you)

let mut child = Command::new("frpc")
    .args(["-c", "frpc.toml"])
    .stdout(Stdio::piped())
    .stderr(Stdio::piped())
    .spawn()?;

This compiles, runs, and is wrong in four ways you won't notice until production:

You never read the pipes. When the OS pipe buffer fills (~64 KB on Linux), the child process blocks on its next write and silently stalls. The app shows "starting…" forever.
No way to ask "is it healthy?" A spawned PID tells you the process exists, not that it's connected to the server.
On window close you call child.kill(). That sends SIGKILL (or TerminateProcess on Windows). The server side never sees a clean disconnect — its connection table leaks until a keepalive timeout.
You can't swap the binary while it's running. File is locked on Windows; replacing it in-place on macOS is a race.

Let's fix each.

1. Drain the pipes into a ring buffer

A dedicated reader thread per stream, writing into a fixed-size ring buffer that the frontend can poll:

use std::sync::{Arc, Mutex};
use std::collections::VecDeque;

pub struct LogRing {
    buf: Mutex<VecDeque<String>>,
    cap: usize,
}

impl LogRing {
    pub fn push(&self, line: String) {
        let mut g = self.buf.lock().unwrap();
        if g.len() == self.cap { g.pop_front(); }
        g.push_back(line);
    }
    pub fn snapshot(&self) -> Vec<String> {
        self.buf.lock().unwrap().iter().cloned().collect()
    }
}

fn spawn_reader<R: Read + Send + 'static>(stream: R, ring: Arc<LogRing>) {
    std::thread::spawn(move || {
        let reader = BufReader::new(stream);
        for line in reader.lines().flatten() {
            ring.push(line);
        }
        // stream closed = child exited
    });
}

Key point: the ring is unbounded-consumer, bounded-memory. Logs from a chatty CLI never OOM the app; the oldest line just rolls off. The frontend gets a get_logs() command that snapshots the current contents — cheap to call on a timer.

2. Health = evidence, not just "process exists"

child.try_wait() returning None means "still running." It does not mean "doing useful work." For an frpc-style client the interesting state lives in its own log output: it prints something like [I] [proxy.go:xxx] start proxy success when a tunnel is actually up.

So model the connection as a small state machine driven by log lines:

#[derive(Clone, Copy, PartialEq)]
pub enum FrpcState { Stopped, Connecting, Connected, Error }

pub fn classify(line: &str, current: FrpcState) -> FrpcState {
    if line.contains("login to server failed") || line.contains("token is incorrect") {
        FrpcState::Error
    } else if line.contains("start proxy success") && current == FrpcState::Connecting {
        FrpcState::Connected
    } else {
        current
    }
}

This matters because a running process with the wrong token will happily sit there retrying forever. You want the UI to show "Error: token rejected," not a fake green "Connected."

A 30-second fallback timer that flips Connecting → Error covers the case where the log never emits a decisive line (firewalled, DNS wedged, etc.).

3. Graceful shutdown: ask, then escalate

Don't go straight to kill(). On Unix, send SIGTERM and give it a beat to flush; on Windows, the equivalent is harder, so we lean on the CLI's own shutdown path if it has one.

pub async fn stop_gracefully(child: &mut Child, timeout: Duration) {
    // Prefer a clean path
    #[cfg(unix)]
    {
        use nix::sys::signal::{kill, Signal};
        let _ = kill(
            nix::unistd::Pid::from_raw(child.id() as i32),
            Signal::SIGTERM,
        );
    }
    #[cfg(windows)]
    {
        // Best-effort: on Windows we drop directly; for a well-behaved CLI
        // that traps the console close event this still lets it clean up.
    }

    // Wait up to `timeout` for it to exit on its own
    let start = Instant::now();
    while start.elapsed() < timeout {
        if let Ok(Some(_)) = child.try_wait() { return; }
        tokio::time::sleep(Duration::from_millis(100)).await;
    }
    // Escalate
    let _ = child.kill();
    let _ = child.wait();
}

In a Tauri app you also want to hook ExitRequested so that closing the window while a tunnel is up pops a confirm dialog (or, for "minimize to tray" mode, just hides the window and keeps frpc alive in the background — the whole reason the user installed a GUI client).

4. Atomic binary replacement

The problem: you want to update frpc from v0.69 to v0.70 without making the user reinstall the app, and without leaving a half-written file behind.

Pattern: download to a temp path → SHA256-verify → rename into place. Rename is atomic on the same filesystem.

// Pseudocode for the happy path
let tmp = bin_dir.join("frpc.new");
download_and_verify(&release_url, &expected_sha256, &tmp)?;

// Stop the running child FIRST (see §3), then:
fs::rename(&tmp, &final_path)?;   // atomic on same fs
// Restart on next "start" click, or auto-restart

The two things that bite you here:

Windows holds an exclusive lock on a running .exe. You cannot rename over it while the child is alive. The order is non-negotiable: stop → replace → start.
SHA256 before rename, not after. A truncated or MITM'd binary that "looks like" frpc but isn't would otherwise get swapped in silently. Verify the bytes you downloaded against a digest fetched over a trusted channel (the GitHub Release API + a pinned algorithm), then promote.

A frpc_update.json next to the binary tracks current / pending versions, so a crash mid-update is recoverable on next launch rather than leaving the user with a broken install.

5. The part Tauri adds on top

All of the above is plain Rust. Tauri's job is to (a) ship the binary inside the app bundle via the sidecar mechanism — tauri.conf.json declares it and the build renames the per-target binary to the sidecar convention (frpc-x86_64-pc-windows-msvc.exe, etc.) — and (b) expose invoke_handler commands so the Vue frontend can call start_frpc, stop_frpc, get_state, get_logs, update_frpc over the IPC bridge.

The tempting mistake is to put lifecycle logic in the frontend and just have Rust be a thin Command::spawn wrapper. Don't. The frontend can be reloaded, the window can be closed, the process tree cares about neither — the Rust side is the single source of truth for "what is the child doing right now."

Recap

Drain stdout/stderr into a bounded ring buffer, always.
Treat "running" and "healthy" as different questions; derive health from the child's own output.
Shutdown is SIGTERM-then-SIGKILL with a timeout, never the other way around.
Binary updates are atomic rename after verify, and Windows forces a strict stop-before-replace order.
In Tauri, the Rust core owns the state machine; the frontend is a view onto it.

The full implementation of this lives in src-tauri/src/ — process.rs for lifecycle, frpc_state.rs for the log classifier, proxy_relay.rs for the traffic-counting TCP middle layer, and frpc_update.rs for the verified-then-atomic update path. Comments and corrections welcome.

MoonProxy is MIT-licensed and on macOS + Windows — if you're shipping a Tauri app that wraps a CLI, the patterns above are field-tested.

How to Host a Minecraft Server Friends Can Join from Anywhere (No Port Forwarding)

ChenXX — Sat, 18 Jul 2026 08:04:48 +0000

The Problem: "Connection Refused"

You set up a Minecraft server. Your friends type in your IP. Nothing. The dreaded "Connection refused" or endless "Connecting to server..." timeout.

The culprit is almost always the same: NAT. Your home router sits behind your ISP's network address translation, so your server's local port (25565) is invisible to the public internet.

The classic answer is port forwarding — log into your router, open port 25565, point it at your server's local IP. But that approach has real problems:

It doesn't work behind carrier-grade NAT (CGNAT), which most mobile and many home ISPs now use.
It exposes your home IP directly to the internet.
Every router UI is different, making it a frustrating guessing game.

There's a better way.

The Fix: A Reverse Tunnel with FRP

FRP (Fast Reverse Proxy) is an open-source tool that creates a reverse tunnel: your server connects outward to a public relay, and players connect to the relay instead of your home network. No port forwarding, no exposed home IP, and it works behind CGNAT.

The catch: FRP's official client (frpc) is a command-line binary. Running it means editing a .toml config, opening a terminal, and babysitting a process. For a lot of people who just want to play Minecraft with friends, that's friction.

That's exactly the problem MoonProxy was built to solve.

MoonProxy: A GUI for FRP

MoonProxy is a free, open-source desktop app that wraps frpc in a graphical interface. You fill in your FRP server details (address, port, token), add a proxy rule for port 25565, and click Start. That's it.

macOS (Apple Silicon + Intel) and Windows x64
Built with Tauri v2 + Rust — small binary, low memory, no Electron bloat
System tray so the tunnel keeps running in the background
Auto-connect on boot so your server is reachable 24/7 without you thinking about it
Scheduled connect / disconnect if you only want it up on weekends
The FRP engine ships bundled — you never install frpc separately

Step-by-Step: Minecraft Server Over FRP with MoonProxy

1. Get an FRP server

You need a machine with a public IP running frps (the FRP server). Options:

A cheap VPS ($3-5/month) from any provider
A free-tier cloud instance (Oracle Cloud, Google Cloud, AWS)
A friend's server that already has a public IP

On that machine, download FRP and run frps with a minimal config exposing a port range for tunnels. Note down the server's public IP, the bind port (usually 7000), and the token.

2. Download MoonProxy

Grab the latest release for your platform from the releases page:

macOS Apple Silicon: the aarch64.dmg
macOS Intel: the x64.dmg
Windows: the x64-setup.exe

3. Configure your FRP server

Open MoonProxy, go to Settings > Server, and enter:

Server address: your VPS public IP
Port: 7000 (or whatever frps binds)
Token: your FRP auth token
Username: any unique name for this client

4. Add a proxy rule for Minecraft

Go to Settings > Proxies and add a rule:

Type: TCP
Local IP: 127.0.0.1
Local port: 25565 (your Minecraft server port)
Remote port: 25565 (the port players will connect to on your VPS)

5. Start the tunnel

Back on the home screen, click Start. The status indicator turns green when frpc has connected to your FRP server.

6. Share the address

Give your friends the address <your-vps-public-ip>:25565. They add it as a server in Minecraft and they're in.

That's the whole flow — no terminal, no config files, no router gymnastics.

Keeping It Up 24/7

If you want your server reachable around the clock:

Enable Launch at login in MoonProxy's settings.
Enable Auto-connect — the tunnel starts automatically whenever the app launches.
Minimize to the system tray so it runs quietly in the background.

Now your Minecraft world is reachable whenever your computer is on, with zero manual steps.

Why Not Just Use a Hosting Service?

You absolutely can pay for managed Minecraft hosting ($5-15/month typically). But:

Running it yourself on your own hardware is free.
You keep full control over mods, worlds, and backups.
You learn networking along the way.

MoonProxy + a $3 VPS gives you a self-hosted server with the same reachability as a paid plan, for a fraction of the cost.

Wrap-Up

The combination of FRP (the protocol) and MoonProxy (the GUI) removes the last piece of friction in self-hosting a Minecraft server: the networking. No port forwarding, no command line, no exposed home IP.

MoonProxy website: https://moonproxy.app/en/
Source code (MIT): https://github.com/MoonProxyHQ/moonproxy-desktop
Download: https://github.com/MoonProxyHQ/moonproxy-desktop/releases/latest

Happy building.

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

ChenXX — Fri, 17 Jul 2026 08:04:39 +0000

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

A practical walkthrough of FRP — what it is, how it works, and why you might want a GUI on top of it.

The problem every self-hoster hits

You built something. A local API. A Minecraft world for your friends. A self-hosted dashboard. An ERP running on the office machine. It works great — on your LAN.

The moment you want someone outside to reach it, the fun begins:

Port forwarding? Good luck if you're behind CGNAT, a corporate firewall, or an ISP that doesn't give you a public IP.
VPN? Now every person who wants access has to install a client, join a network, and stay connected. Overkill for "let me show you this one page."
Cloud deploy? Now you're maintaining two environments, paying for a VPS you didn't need, and shipping data somewhere it doesn't have to live.

What most people actually want is simpler: take this one local port, give it a public address, done.

That's exactly what FRP does.

What FRP is

FRP (Fast Reverse Proxy) is an open-source tool by fatedier that exposes a local service behind a NAT or firewall to the public internet. It's battle-tested, written in Go, and has been the go-to answer in self-hosting communities for years.

The model is clean — two pieces:

frps (the server) — runs on a machine with a public IP (a $5 VPS is plenty).
frpc (the client) — runs on your local machine, the one with the service you want to expose.

The client opens an outbound tunnel to the server. The server listens on a public port and forwards traffic back through the tunnel. NAT and firewalls don't matter because the connection is initiated from inside.

[Visitor] → [frps on public VPS:7000] ⇄ tunnel ⇄ [frpc on your laptop] → [localhost:8080]

That's the whole idea. It works for TCP, UDP, HTTP, HTTPS. People run Minecraft servers, remote desktops, internal dashboards, and dev previews through it every day.

The catch: config files

FRP works great. The friction isn't the protocol — it's the workflow.

To run frpc, you write a TOML/INI config file:

serverAddr = "203.0.113.10"
serverPort = 7000
auth.token = "your-secret-key"

[[proxies]]
name = "my-web"
type = "tcp"
localIP = "127.0.0.1"
localPort = 8080
remotePort = 8080

Then you run it from a terminal. If it crashes, you find out when someone texts you "is the server down?" If you want it to start on boot, you write a systemd unit. If you want to change one port, you edit the file and restart. If you're on Windows, you're juggling a console window or a scheduled task.

None of this is hard. But it adds up. And for users who aren't comfortable in a terminal — a small business owner running an ERP, a parent hosting Minecraft for their kid, a designer previewing a static site — it's a wall.

The piece I actually wanted to share

This is where I mention a project I think is worth knowing about, because it directly addresses that friction.

MoonProxy is an open-source desktop GUI for FRP. MIT licensed, built with Tauri v2 + Vue 3 + Rust, runs on macOS and Windows. The frpc binary is bundled — you don't install FRP separately.

What it does is take the config-file workflow above and turn it into a form:

Add a tunnel by filling in fields (local port, remote port, type, key) — no text editor, no syntax to get wrong.
Start/stop with one button — a circular toggle with four visual states (stopped, connecting, connected, error). "Connected" is derived from real frpc output, not an optimistic flag.
Health polling — it checks whether your local port is actually reachable every 3 seconds, so you find out your service is down before your users do.
System tray resident — close the window, the tunnel keeps running. Launch-at-login means it comes back after a reboot.
Scheduled connect — set weekdays and a time window; tunnels only stay open during working hours.
Engine self-update — pulls new frpc releases from the upstream FRP GitHub Releases, SHA256-verifies them, and atomically swaps the binary without reinstalling the app.

You still bring your own frps (self-hosted or a community-public one you trust) — MoonProxy is strictly the client side. It doesn't relay your traffic through any third-party infrastructure. The auth key stays with you.

It's independent of the upstream FRP project — FRP is fatedier's work, licensed and maintained by its original authors. MoonProxy is just a desktop client for it.

A quick walkthrough

Say you have a local dev server on localhost:5173 and an frps running on your VPS at 203.0.113.10:7000.

With plain FRP, you'd write the config, run ./frpc -c frpc.toml, and leave a terminal open.

With MoonProxy, you:

Open the app.
Click "Add tunnel."
Fill in: name vite-dev, type tcp, local 127.0.0.1:5173, remote port 5173, server address + your token.
Click the toggle.

The button goes connecting → connected. Your dev server is now reachable at 203.0.113.10:5173. Close the laptop lid, open it again — the tunnel comes back. You didn't write a config file or touch a terminal.

When to use what

Plain frp CLI if you live in the terminal, want to script everything, or run headless servers. FRP is excellent. This isn't a replacement — it's a layer on top.
A GUI like MoonProxy if you want set-and-forget tunnels, you're sharing the machine with non-technical users, or you're tired of debugging a YAML file at midnight because a colleague can't reach the staging URL.
Managed relays (Ngrok, Cloudflare Tunnel) if you want zero infrastructure and don't mind routing through a vendor's network. Different tradeoff — convenience for dependency.

Wrapping up

FRP remains one of the cleanest ways to put a local service on the public internet. The protocol is solid; the friction has always been in the operating of it.

If you've been meaning to try FRP but bounced off the config-file workflow — or you're already running it and want a tray icon instead of a terminal window — MoonProxy is worth a look.

🌐 Website: moonproxy.app
💻 Source (MIT): github.com/MoonProxyHQ/moonproxy-desktop
⬇️ Releases: macOS (Apple Silicon + Intel) and Windows x64

If you build something with it, I'd love to hear what you're tunneling. 👋

5 Real-World Scenarios Where a GUI FRP Client Beats the Command Line

ChenXX — Thu, 16 Jul 2026 08:15:10 +0000

If you've ever set up frp — the go-to open-source reverse proxy for NAT traversal — you know the drill: SSH into a VPS, install frps, write a frpc.toml on your local machine, wrestle with ports and tokens, run it as a background service, and hope nothing drifts.

It works. But for a lot of people — self-hosters, remote workers, small teams, anyone who isn't a sysadmin — the CLI workflow is friction they'd rather avoid. That's exactly why I built MoonProxy: an open-source desktop GUI for frp (macOS + Windows, MIT-licensed, built on Tauri v2).

Rather than pitch features, here are five concrete scenarios where reaching for a GUI client saves real time and headaches.

1. The "I Just Want to SSH Into My Home Server" User

You're at a coffee shop. You need to fix something on the mini-PC running under your desk at home. No public IP, carrier-grade NAT, no VPN.

CLI path: write a frpc.toml with a tcp proxy stanza, make sure the remote port on your VPS matches, start frpc, keep it alive, SSH to vps-ip:remote-port.

GUI path: open MoonProxy, type your frps server address + token, add one TCP proxy rule (local port 22 → remote port 6000), click Start. The public address is shown right on the home screen. Done.

The win isn't speed for an expert — it's that a non-Linux-savvy family member can do it after a one-time setup.

2. Debugging Webhooks and OAuth Callbacks Locally

Third-party services (Stripe, GitHub, Slack) need to POST to a publicly reachable URL. Your dev server runs on localhost:3000.

With MoonProxy you spin up an HTTP proxy rule pointing at localhost:3000, and you get a public domain on your frps server that forwards straight to your laptop. No ngrok account, no tunnel-as-a-service limits — just your own infra.

The bonus: MoonProxy's home tab shows a live traffic chart for the tunnel, so you can see the webhook hitting your machine in real time. That's surprisingly useful when debugging "did the callback actually fire?"

3. Sharing a Local Service With a Non-Technical Colleague

You've got a demo running locally and want a teammate to take a look — but they're on a different network and you don't want to deploy to a cloud VM just for a 10-minute review.

Start a tunnel in MoonProxy, hand them the public URL. When they're done, click Stop. The URL dies. No lingering exposure, no cloud bill, no kubectl.

4. Keeping a Tunnel Up 24/7 Without Babying It

Long-running tunnels (home NAS access, a personal blog hosted on a Raspberry Pi, a Minecraft server for friends) need to survive reboots, sleep/wake cycles, and network hiccups.

MoonProxy handles this with three built-in features:

System tray resident — close the window and the tunnel keeps running.
Launch at login + silent start — boots hidden to the tray.
Scheduled connect — pick weekdays and start/stop times; the scheduler hot-reloads every minute.

So a tunnel can run Monday–Friday 9–18 and turn itself off otherwise — without a cron job or a systemd timer you'll forget about.

5. Knowing Immediately When a Tunnel Breaks

The silent failure mode of a backgrounded frpc process is brutal: everything looks fine until you try to connect and realize the tunnel died three hours ago.

MoonProxy polls local endpoint reachability at adaptive intervals (exponential backoff from 3s up to 24s) and surfaces the result as colored health dots on the home screen. A broken tunnel shows red within seconds, not after you've already left the house relying on it.

The Broader Point

frp the protocol is excellent. The workflow around it — hand-edited TOML, process supervision, port juggling — is where most non-experts give up. A GUI doesn't make frp more powerful; it makes it accessible to the people who need NAT traversal but don't want a side quest in systems administration.

If any of those five scenarios sound familiar, MoonProxy is free and open source:

GitHub: MoonProxyHQ/moonproxy-desktop
Website: moonproxy.app
Platforms: macOS (Apple Silicon + Intel), Windows x64
License: MIT

You bring your own frps server (self-hosted or any community endpoint you trust) — MoonProxy handles configuration, lifecycle, monitoring, and updates. The bundled frpc engine even self-updates from upstream releases, so you never have to wget a binary again.

Questions, feature ideas, or war stories? The Discussions tab is open. 🌙

Bundling a CLI Binary as a Tauri v2 Sidecar: Architecture and Lessons from Building MoonProxy

ChenXX — Tue, 14 Jul 2026 08:07:44 +0000

When you build a desktop app that needs to ship a CLI binary alongside it, the Tauri v2 sidecar mechanism is the cleanest solution. This post is a deep-dive into how MoonProxy (an open-source FRP GUI client for macOS & Windows) uses it to bundle the frpc binary so users never have to install it separately.

MoonProxy v1.2.0+ — Tauri v2 + Vue 3 + Rust, MIT licensed, moonproxy.app

Why sidecar?

A FRP client is intrinsically a client-server tool:

The user runs frpc (client) on their machine
frpc connects to frps (server) running on a public cloud

Options for distributing frpc:

Tell users to install frp separately — too many support tickets
Spawn frpc via system PATH lookup — fragile, version drift
Bundle frpc binary inside the app — ✅ best UX

Tauri v2's sidecar feature lets you ship a binary that the app spawns as a child process, with the same lifecycle management as the app itself.

Step 1 — Naming convention

Tauri identifies sidecar binaries by file-name suffix per target platform:

Platform	File name
macOS Apple Silicon	`frpc-aarch64-apple-darwin`
macOS Intel	`frpc-x86_64-apple-darwin`
Windows x64	`frpc-x86_64-pc-windows-msvc.exe`
Windows ARM64	`frpc-aarch64-pc-windows-msvc.exe`

The base name (frpc) is what you reference from tauri.conf.json.

Step 2 — Place binaries in `src-tauri/binaries/`

Tauri v2 looks for sidecar binaries in src-tauri/binaries/ at compile time and embeds them into the app bundle.

src-tauri/
  binaries/
    frpc-aarch64-apple-darwin
    frpc-x86_64-apple-darwin
    frpc-x86_64-pc-windows-msvc.exe
    frpc-aarch64-pc-windows-msvc.exe

A sync-frpc.sh script downloads the matching frpc release and renames it to the above pattern.

Step 3 — Declare in `tauri.conf.json`

{
  "bundle": {
    "externalBin": [
      "binaries/frpc"
    ]
  }
}

Note: Tauri strips the platform suffix automatically; you only write the base name (frpc).

Step 4 — Spawn the sidecar from Rust

Tauri exposes the tauri-plugin-shell for command-based sidecar execution. In our case we use a Rust wrapper that gives us stdout streaming + log buffering + restart on failure:

use tauri_plugin_shell::ShellExt;

let sidecar_command = app.shell()
    .sidecar("frpc")
    .expect("failed to create sidecar")
    .args(["-c", "/path/to/frpc.toml"]);

let (mut rx, mut child) = sidecar_command.spawn().expect("failed to spawn");

// Stream stdout → in-memory ring buffer + log UI
tauri::async_runtime::spawn(async move {
    use tauri_plugin_shell::process::CommandEvent;
    while let Some(event) = rx.recv().await {
        match event {
            CommandEvent::Stdout(line) => { /* push to log ring buffer */ }
            CommandEvent::Stderr(line) => { /* push to log ring buffer */ }
            CommandEvent::Terminated(payload) => { /* mark exit */ }
            _ => {}
        }
    }
});

Step 5 — Log ring buffer (for the UI)

The Vue UI shows a real-time log feed. We don't want unbounded memory growth, so we use a RingBuffer<String> with a 2000-line capacity in frpc_state.rs:

pub struct LogRing {
    inner: Arc<Mutex<VecDeque<String>>>,
    capacity: usize,
}

impl LogRing {
    pub fn push(&self, line: String) {
        let mut q = self.inner.lock().unwrap();
        if q.len() >= self.capacity {
            q.pop_front();
        }
        q.push_back(line);
    }
}

Step 6 — Auto-restart with backoff

If the frpc process dies (network glitch, server reboot), we want to retry with exponential backoff. State machine in frpc_state.rs:

enum ConnState {
    Stopped,
    Connecting { attempt: u32 },
    Connected { since: Instant },
    Error { reason: String, next_retry: Instant },
}

fn schedule_retry(&mut self) {
    let backoff = 2u64.saturating_pow(self.attempt.min(6));  // 1, 2, 4, 8, 16, 32, 64s
    self.state = ConnState::Connecting { attempt: self.attempt + 1 };
    self.timer = Some(Instant::now() + Duration::from_secs(backoff));
}

Step 7 — Self-update of the sidecar binary

When upstream frpc releases a new version, we want users to get it without reinstalling the app. We ship an updater that:

Downloads the new frpc release tarball
Verifies SHA256
Atomically replaces the binary
Restarts frpc

async fn update_frpc(app: AppHandle, new_version: &str) -> Result<()> {
    let url = format!("https://github.com/fatedier/frp/releases/download/v{}/frp_{}_darwin_amd64.tar.gz", new_version, new_version);
    let tmp_path = app.path().app_config_dir()?.join("frpc.new");
    download_and_verify(&url, &tmp_path, &expected_sha).await?;

    // atomic rename
    let final_path = app.path().app_config_dir()?.join("frpc");
    std::fs::rename(&tmp_path, &final_path)?;
    Ok(())
}

The app itself has a separate updater path (Tauri's built-in tauri-plugin-updater).

Gotchas we hit

1. macOS code signing & Gatekeeper

Unsigned binaries downloaded at runtime trigger Gatekeeper on first launch. Solution: ship the binary inside the .app bundle (already code-signed with the app), not downloaded at runtime for the initial version. Runtime updates still work because the new binary inherits the parent app's permissions (mostly).

2. Windows Defender false positive

frpc is sometimes flagged because of its network behavior. We:

Document the SHA256 + source URL in the update flow
Provide a "report false positive" link in the UI
Sign the binary (planned for v1.3.0)

3. Architecture mismatch on Apple Silicon

A common bug: user is on M1 Mac but the app shipped the Intel frpc. With Tauri v2's platform-suffix naming, this is solved at bundle time, but you need to make sure your build matrix covers all 4 platform suffixes (we use GitHub Actions matrix builds).

What I'd do differently

Pin frpc version in Cargo.toml rather than downloading at build time — simpler CI
Use tauri-plugin-shell's structured sidecar API (newer versions have it) — saves the manual stdout stream loop
Expose the sidecar process to the JS frontend via IPC — we do this for status, but logs are still polled; streaming via Tauri events would be smoother

Code links

MoonProxy repository: https://github.com/MoonProxyHQ/moonproxy-desktop
Sidecar wrapper: src-tauri/src/process.rs
Log ring buffer: src-tauri/src/frpc_state.rs
Auto-restart: src-tauri/src/frpc_state.rs::schedule_retry
Self-update: src-tauri/src/frpc_update.rs
Sync script: scripts/sync-frpc.sh

Try it

If you're building a desktop app that needs to bundle a CLI tool, I hope this deep-dive saves you some time. Tauri sidecar is a powerful pattern — once you have the boilerplate right, shipping a "runs offline, talks to my server" app becomes tractable for a small team.

Comparing FRP GUI Clients in 2026: MoonProxy vs frpc-desktop vs frpmgr vs frp-panel

ChenXX — Sat, 11 Jul 2026 08:11:00 +0000

FRP (Fast Reverse Proxy) is one of the most popular open-source tools for exposing local services to the public internet. But FRP is a CLI tool — and for many users, editing TOML config files and running terminal commands feels intimidating.

That's where GUI clients come in. Let's compare the top FRP desktop clients available today.

Why use a GUI for FRP?

No command line knowledge needed
Visual traffic monitoring and connection status
One-click start/stop instead of managing background processes
System tray integration for always-on operation
Easier configuration management across multiple servers

The contenders

1. MoonProxy (cross-platform)

GitHub | macOS + Windows | MIT License

The newest entry, built with Tauri v2 + Vue 3 + Rust. Key features:

Cross-platform: macOS (Apple Silicon + Intel) and Windows x64
Real-time traffic monitoring with live charts
System tray with silent start and auto-connect on boot
Scheduled connections (weekday + time range)
Built-in frpc auto-update (no manual binary management)
App self-update via Tauri updater
Built with Tauri — lightweight (~10 MB), not Electron

Best for: Non-technical users who want a polished, modern experience on both Mac and Windows.

2. frpc-desktop

GitHub | Windows + macOS + Linux

A mature Electron-based FRP client with a large community. Supports proxy management and basic monitoring.

Best for: Users who need Linux support and don't mind Electron's resource footprint.

3. frpmgr

GitHub | Windows only

A Windows-native FRP manager with a clean Win32 UI. Lightweight and focused.

Best for: Windows-only users who want a native, no-frills experience.

4. frp-panel

GitHub | Web-based

A web dashboard for managing FRP servers and clients. Great for multi-machine setups.

Best for: Server administrators managing multiple FRP instances.

Quick comparison

Feature	MoonProxy	frpc-desktop	frpmgr	frp-panel
macOS	Yes	Yes	No	Web
Windows	Yes	Yes	Yes	Web
Linux	Planned	Yes	No	Web
Traffic monitor	Live charts	Basic	No	Yes
System tray	Yes	Yes	Yes	N/A
Auto-connect	Yes	No	No	N/A
Scheduled	Yes	No	No	No
Auto-update	Yes	No	No	No
Framework	Tauri v2	Electron	Win32	Go web
Bundle size	~10 MB	~80 MB	~5 MB	Server

Which one should you choose?

Want the most polished Mac + Windows experience? Try MoonProxy
Need Linux support today? Go with frpc-desktop
Windows only and want minimal overhead? frpmgr
Managing multiple servers? frp-panel

All of these are open-source and free. The FRP ecosystem is better when these projects support each other — many of them maintain mutual cross-references in their READMEs.

This is an independent comparison. I am a contributor to MoonProxy, but I respect all projects in the FRP ecosystem. Star any project that helps you.

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

ChenXX — Fri, 10 Jul 2026 09:55:11 +0000

The problem every self-hoster hits

You built something. A local API. A Minecraft world for your friends. A self-hosted dashboard. An ERP running on the office machine. It works great — on your LAN.

The moment you want someone outside to reach it, the fun begins:

Port forwarding? Good luck if you're behind CGNAT, a corporate firewall, or an ISP that doesn't give you a public IP.
VPN? Now every person who wants access has to install a client, join a network, and stay connected. Overkill for "let me show you this one page."
Cloud deploy? Now you're maintaining two environments, paying for a VPS you didn't need, and shipping data somewhere it doesn't have to live.

What most people actually want is simpler: take this one local port, give it a public address, done.

That's exactly what FRP does.

What FRP is

The model is clean — two pieces:

frps (the server) — runs on a machine with a public IP (a $5 VPS is plenty).
frpc (the client) — runs on your local machine, the one with the service you want to expose.

[Visitor] → [frps on public VPS:7000] ⇄ tunnel ⇄ [frpc on your laptop] → [localhost:8080]

That's the whole idea. It works for TCP, UDP, HTTP, HTTPS. People run Minecraft servers, remote desktops, internal dashboards, and dev previews through it every day.

The catch: config files

FRP works great. The friction isn't the protocol — it's the workflow.

To run frpc, you write a TOML/INI config file:

serverAddr = "203.0.113.10"
serverPort = 7000
auth.token = "your-secret-key"

[[proxies]]
name = "my-web"
type = "tcp"
localIP = "127.0.0.1"
localPort = 8080
remotePort = 8080

The piece I actually wanted to share

This is where I mention a project I think is worth knowing about, because it directly addresses that friction.

MoonProxy is an open-source desktop GUI for FRP. MIT licensed, built with Tauri v2 + Vue 3 + Rust, runs on macOS and Windows. The frpc binary is bundled — you don't install FRP separately.

What it does is take the config-file workflow above and turn it into a form:

Add a tunnel by filling in fields (local port, remote port, type, key) — no text editor, no syntax to get wrong.
Start/stop with one button — a circular toggle with four visual states (stopped, connecting, connected, error). "Connected" is derived from real frpc output, not an optimistic flag.
Health polling — it checks whether your local port is actually reachable every 3 seconds, so you find out your service is down before your users do.
System tray resident — close the window, the tunnel keeps running. Launch-at-login means it comes back after a reboot.
Scheduled connect — set weekdays and a time window; tunnels only stay open during working hours.
Engine self-update — pulls new frpc releases from the upstream FRP GitHub Releases, SHA256-verifies them, and atomically swaps the binary without reinstalling the app.

It's independent of the upstream FRP project — FRP is fatedier's work, licensed and maintained by its original authors. MoonProxy is just a desktop client for it.

A quick walkthrough

Say you have a local dev server on localhost:5173 and an frps running on your VPS at 203.0.113.10:7000.

With plain FRP, you'd write the config, run ./frpc -c frpc.toml, and leave a terminal open.

With MoonProxy, you:

Open the app.
Click "Add tunnel."
Fill in: name vite-dev, type tcp, local 127.0.0.1:5173, remote port 5173, server address + your token.
Click the toggle.

When to use what

Plain frp CLI if you live in the terminal, want to script everything, or run headless servers. FRP is excellent. This isn't a replacement — it's a layer on top.
A GUI like MoonProxy if you want set-and-forget tunnels, you're sharing the machine with non-technical users, or you're tired of debugging a YAML file at midnight because a colleague can't reach the staging URL.
Managed relays (Ngrok, Cloudflare Tunnel) if you want zero infrastructure and don't mind routing through a vendor's network. Different tradeoff — convenience for dependency.

Wrapping up

FRP remains one of the cleanest ways to put a local service on the public internet. The protocol is solid; the friction has always been in the operating of it.

If you've been meaning to try FRP but bounced off the config-file workflow — or you're already running it and want a tray icon instead of a terminal window — MoonProxy is worth a look.

🌐 Website: moonproxy.app
💻 Source (MIT): github.com/MoonProxyHQ/moonproxy-desktop
⬇️ Releases: macOS (Apple Silicon + Intel) and Windows x64

If you build something with it, I'd love to hear what you're tunneling. 👋

MoonProxy: A Desktop GUI Client for FRP (Fast Reverse Proxy)

ChenXX — Wed, 08 Jul 2026 14:00:37 +0000

MoonProxy: The Complete Guide to FRP Intranet Penetration

From setup to real-world use cases. For developers and self-hosters.
Compatible with MoonProxy v1.2.0+

Why FRP + MoonProxy?

FRP (Fast Reverse Proxy) is the most popular open-source tunneling tool (80k+ GitHub stars). But its CLI-only workflow keeps non-technical users away. MoonProxy wraps FRP's frpc into a native desktop app — visual configuration, one-click start/stop, real-time traffic monitoring.

Why not ngrok / Cloudflare Tunnel / Tailscale?

ngrok: Free tier is limited, paid plans are expensive
Cloudflare Tunnel: Closed source, only handles HTTP(S), vendor lock-in
Tailscale: Great for mesh networking, but not traditional port forwarding

FRP + MoonProxy gives you full control with your own server, supports any TCP/UDP/HTTP protocol, and costs nothing.

Architecture

[Your Computer]                     [Public Server]            [Visitor]

  Local Service (NAS:5000)                                      
       ↓                                                       
  MoonProxy (frpc GUI) ←── tunnel ──→  frps (server) ←── public access
       ↓                                                       
  127.0.0.1:5000                                     your-server:6000

Part 1: Set Up frps Server (5 min)

Download FRP

wget https://github.com/fatedier/frp/releases/download/v0.69.1/frp_0.69.1_linux_amd64.tar.gz
tar xzf frp_0.69.1_linux_amd64.tar.gz
cd frp_0.69.1_linux_amd64

Configure frps.toml

bindPort = 7000
auth.token = "your-secret-token-change-me"

Run as systemd service

sudo cp frps /usr/local/bin/
sudo mkdir -p /etc/frp && sudo cp frps.toml /etc/frp/
sudo tee /etc/systemd/system/frps.service << 'EOF'
[Unit]
Description=frps service
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable frps && sudo systemctl start frps

Open firewall ports

sudo ufw allow 7000/tcp   # FRP communication
sudo ufw allow 6000/tcp   # Your tunnel port
# Also check your cloud provider's security group

Part 2: Install MoonProxy

Download from GitHub Releases:

Platform	File
macOS (Apple Silicon)	`MoonProxy_1.2.0_aarch64.dmg`
macOS (Intel)	`MoonProxy_1.2.0_x64.dmg`
Windows (x64)	`MoonProxy_1.2.0_x64-setup.exe`

📸 Main panel: https://moonproxy.app/screenshots/main-full-en.webp
📸 Provider config: https://moonproxy.app/screenshots/server-provider-en.webp
📸 Proxy rules: https://moonproxy.app/screenshots/server-proxy-en.webp

Part 3: Connect in 3 Steps

Step 1: Enter Server Info

Go to Services → Provider tab:

Field	Value
Server Address	Your server's public IP (e.g., `203.0.113.50`)
Bind Port	`7000` (matches frps bindPort)
Token	Same as frps auth.token

Step 2: Add Proxy Rule

Go to Proxy Rules tab → Add Rule:

Expose a Web service (HTTP):

Protocol: http
Local Port: 8080
Custom Domain: myapp.example.com (point DNS to your server)

Expose SSH (TCP):

Protocol: tcp
Local Port: 22
Remote Port: 6000

Then connect with: ssh -p 6000 user@your-server-ip

Expose NAS (TCP):

Protocol: tcp
Local Port: 5000
Remote Port: 5000

Access at: http://your-server-ip:5000

Step 3: Click Start

📸 Home panel: https://moonproxy.app/screenshots/main-full-en.webp

Return to the home screen. The large button changes color:

Gray = Stopped
Blue = Connecting
Green = Connected

The endpoint list shows green dots (reachable) or red dots (unreachable). Click Start — when the button turns green, you're live!

Real-World Use Cases

Remote NAS Access

Expose your Synology NAS (port 5000) to access files from anywhere.

Dev Preview Sharing

Share your localhost:5173 Vue/React project with clients via a public URL.

Minecraft Server

Expose your local Minecraft server (port 25565) so friends can join directly.

Home Automation

Access Home Assistant while traveling — no VPN needed.

Advanced Features

Auto-Start + Silent Mode

📸 Launch settings: https://moonproxy.app/screenshots/settings-launch-en.webp

Auto-start: Launches on system boot
Silent start: Hides to system tray, no window popup
Auto-connect: Automatically starts frpc on boot

Scheduled Connection

Set working hours (e.g., Mon-Fri 9:00-18:00). MoonProxy auto-connects at start time and disconnects at end time. No exposed ports outside working hours.

Real-Time Traffic Monitor

The home panel shows live upload/download speed curves, active connections, and cumulative traffic — powered by a built-in TCP relay counting layer.

Self-Updating Engine

FRP engine updates automatically: checks GitHub releases → downloads → SHA256 verify → atomic replace. No reinstall needed.

FAQ

Can't connect? Check: (1) frps running? systemctl status frps (2) Port 7000 open? (3) Token matches? (4) Remote port open in firewall?

macOS "unidentified developer"? System Settings → Privacy & Security → "Open Anyway"

How many proxy rules? Up to 50 (v1.2.0+).

Data privacy? MoonProxy runs 100% locally. Your data flows: your computer → your server → visitor. No third party involved.

Tech Stack

Layer	Technology
Frontend	Vue 3 + TypeScript + Vite 6
Backend	Rust + Tauri v2
Engine	frp (frpc) v0.69.1
Bundle size	~5MB (far smaller than Electron)

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

ChenXX — Wed, 08 Jul 2026 12:10:52 +0000

The problem every self-hoster hits

You built something. A local API. A Minecraft world for your friends. A self-hosted dashboard. An ERP running on the office machine. It works great — on your LAN.

The moment you want someone outside to reach it, the fun begins:

Port forwarding? Good luck if you're behind CGNAT, a corporate firewall, or an ISP that doesn't give you a public IP.
VPN? Now every person who wants access has to install a client, join a network, and stay connected. Overkill for "let me show you this one page."
Cloud deploy? Now you're maintaining two environments, paying for a VPS you didn't need, and shipping data somewhere it doesn't have to live.

What most people actually want is simpler: take this one local port, give it a public address, done.

That's exactly what FRP does.

What FRP is

FRP (Fast Reverse Proxy) is an open-source tool by fatedier that exposes a local service behind a NAT or firewall to the public internet. It's battle-tested, written in Go, and has been the go-to answer in self-hosting communities for years.

The model is clean — two pieces:

frps (the server) — runs on a machine with a public IP (a $5 VPS is plenty).
frpc (the client) — runs on your local machine, the one with the service you want to expose.

[Visitor] → [frps on public VPS:7000] ⇄ tunnel ⇄ [frpc on your laptop] → [localhost:8080]

That's the whole idea. It works for TCP, UDP, HTTP, HTTPS. People run Minecraft servers, remote desktops, internal dashboards, and dev previews through it every day.

The catch: config files

FRP works great. The friction isn't the protocol — it's the workflow.

To run frpc, you write a TOML config file:

serverAddr = "203.0.113.10"
serverPort = 7000
auth.token = "your-secret-key"

[[proxies]]
name = "my-web"
type = "tcp"
localIP = "127.0.0.1"
localPort = 8080
remotePort = 8080

Then you launch it from a terminal. Change a port? Edit the file, restart the process. Add a second tunnel? Edit again, restart again. Want to know if it's actually working? Check the terminal output — or don't, because you closed that tab two hours ago.

This is fine if you live in the terminal. It's a wall for everyone else — a small-business owner running an ERP, a parent hosting Minecraft for their kid, a designer sharing a local mockup.

MoonProxy: a GUI for FRP

MoonProxy is an MIT-licensed desktop client for FRP. It wraps frpc in a GUI so you don't have to touch config files or terminals.

What it adds over plain frpc:

Form-based tunnel config — no toml/ini files. Add a tunnel like filling out a form.
One-click start/stop — a toggle button with real connection state, derived from frpc output (not an optimistic flag).
Endpoint health polling every 3s — catches a dead local service before your users do.
System tray resident — close the window, the tunnel keeps running. Launch at login, silent start.
Scheduled tunnels — set weekday + time window. Hot-reloaded, no restart.
Engine self-update — pulls new frpc from upstream FRP releases, SHA256-verifies, atomically swaps.

Built with Tauri v2 + Vue 3 + Rust + TypeScript. The frpc binary is bundled via Tauri sidecar — no separate FRP install. macOS (Apple Silicon + Intel) and Windows x64.

You bring your own frps (self-hosted VPS or a community node you trust). MoonProxy only manages the client side — it doesn't relay your traffic through any third-party infrastructure. Auth key stays with you.

It's independent of fatedier/frp — that project deserves all the credit for the protocol. This is just a GUI layer.

Getting started

Download from moonproxy.app or GitHub Releases (DMG for macOS, EXE for Windows).
On macOS first launch, right-click → Open, or run xattr -cr "/Applications/MoonProxy Desktop.app".
Set up your frps on a VPS (plenty of community tutorials exist).
Open MoonProxy, add a tunnel, click start.

That's it. Your local service now has a public address.

Project links

Website: moonproxy.app
Source: github.com/MoonProxyHQ/moonproxy-desktop
License: MIT, permanently free

It's not trying to replace the CLI — if you're happy scripting frp, keep doing that. This is for folks who want a tray icon and a toggle instead of a terminal window.

Happy to answer questions in the comments!

Bundling a CLI Binary as a Tauri v2 Sidecar: Lessons from Building a Desktop App

ChenXX — Sun, 05 Jul 2026 06:25:43 +0000

When you build a desktop app with Tauri v2, sooner or later you'll hit a question: how do I bundle and manage an external CLI binary inside my app?

Maybe it's ffmpeg for video processing. Maybe it's a database engine. Maybe — as in my case — it's frpc, the reverse-proxy client from the popular frp project.

This post walks through the full lifecycle: bundling, spawning, lifecycle management, and even self-updating the binary at runtime — all from Rust.

1. Declaring the Sidecar

In tauri.conf.json, declare the binary under bundle.externalBin:

{
  "bundle": {
    "externalBin": ["binaries/frpc"]
  }
}

Tauri identifies the target platform by a filename suffix convention. You need to place the correctly-named binary in your project:

Platform	Filename
macOS (Apple Silicon)	`frpc-aarch64-apple-darwin`
macOS (Intel)	`frpc-x86_64-apple-darwin`
Windows (x64)	`frpc-x86_64-pc-windows-msvc.exe`

Tauri automatically strips the suffix at runtime and loads the right binary for the current platform.

2. Spawning the Process

Use tauri_plugin_shell to spawn the sidecar:

use tauri_plugin_shell::{ShellExt, process::CommandEvent};

#[tauri::command]
async fn start_frpc(app: tauri::AppHandle) -> Result<(), String> {
    let sidecar = app
        .shell()
        .sidecar("frpc")
        .map_err(|e| e.to_string())?;

    let (mut rx, child) = sidecar
        .args(["-c", "frpc.toml"])
        .spawn()
        .map_err(|e| e.to_string())?;

    // Store the child handle so we can kill it later
    app.state::<std::sync::Mutex<Option<tauri_plugin_shell::process::CommandChild>>>()
        .lock()
        .unwrap()
        .replace(child);

    // Listen to stdout/stderr in a background task
    tauri::async_runtime::spawn(async move {
        while let Some(event) = rx.recv().await {
            match event {
                CommandEvent::Stdout(line) => {
                    // Parse log line, update UI state...
                }
                CommandEvent::Stderr(line) => { /* ... */ }
                CommandEvent::Terminated(_) => {
                    // Process exited — update state machine
                }
                _ => {}
            }
        }
    });

    Ok(())
}

The key insight: always store the CommandChild handle. You'll need it to kill the process cleanly when the user clicks "Stop".

3. Lifecycle: Don't Trust Optimistic Flags

A subtle trap: spawn() succeeding does not mean the process is actually working. It just means the OS started it. The binary might immediately crash due to a bad config, a missing port, or a network error.

The fix is to derive the "connected" state from real evidence. In my app, after spawning frpc, I poll its admin API endpoint (/api/status) with an exponential backoff: 3s → 6s → 12s → 24s. Only when I get a healthy response do I flip the UI to "Connected".

/// Adaptive health polling: 3 → 6 → 12 → 24 seconds
fn next_interval(prev: Duration) -> Duration {
    (prev * 2).min(Duration::from_secs(24))
}

If no healthy response arrives within 30 seconds, I fall back to an "Error" state — much better than showing a fake "Connected" to the user.

4. Self-Updating the Binary at Runtime

This is the fun part. Users shouldn't have to reinstall the entire app just because frpc shipped a new version. Here's the update flow I implemented:

Fetch the latest release info from GitHub's API
Download the binary to a temp path
Verify the SHA256 checksum
Atomically swap: rename old → .old, rename new → target
Restart the sidecar process

pub async fn update_frpc(target_version: &str) -> Result<(), UpdateError> {
    // 1. Download to temp
    let tmp_path = app_config_dir.join(".frpc.downloading");
    download_binary(&url, &tmp_path).await?;

    // 2. SHA256 verify
    let hash = sha256_file(&tmp_path)?;
    if hash != expected_hash {
        return Err(UpdateError::ChecksumMismatch);
    }

    // 3. Kill current process first
    kill_current_frpc().await;

    // 4. Atomic swap
    let final_path = sidecar_path(&app_config_dir);
    fs::rename(&final_path, format!("{}.old", final_path.display()))
        .ok();  // best-effort cleanup
    fs::rename(&tmp_path, &final_path)?;

    // 5. Restart with new binary
    start_frpc(app).await?;

    Ok(())
}

The .old suffix trick lets you roll back if the new binary fails to start.

5. Platform Gotchas

macOS code signing: The sidecar binary must be signed, or Gatekeeper will block it. If you're cross-compiling, you need to sign the binary after downloading it:

codesign --force --sign "Developer ID Application: Your Name" frpc-aarch64-apple-darwin

Windows: Watch out for antivirus false positives. CLI tools that manage network connections tend to trigger heuristics. Digitally signing with an EV certificate helps a lot.

Permissions: On macOS, you may need to request network entitlements in your Info.plist or capabilities. Tauri v2's capability system handles most of this, but double-check your default.json.

Takeaways

Store the CommandChild — you'll need it for clean shutdown.
Don't trust spawn success — verify the process is actually doing its job.
Exponential backoff for health checks keeps your UI responsive.
Atomic swap for updates means no half-written binaries.
Platform signing is not optional for distribution.

Building a desktop app that manages an external CLI taught me a lot about Rust's process management, async lifecycle, and the care needed for cross-platform distribution. It's more work than shelling out via std::process::Command, but the control you get is worth it.

If you're interested in seeing these patterns in a real app, I'm building MoonProxy — a desktop GUI for frp that uses exactly this sidecar architecture. It's open-source (MIT) and the code is all there.

Happy shipping! 🦀

DEV Community: ChenXX

"Managing a CLI Subprocess from Rust: Lifecycle, Logs, and Graceful Shutdown (Tauri)"

The naive version (and why it bites you)

1. Drain the pipes into a ring buffer

2. Health = evidence, not just "process exists"

3. Graceful shutdown: ask, then escalate

4. Atomic binary replacement

5. The part Tauri adds on top

Recap

How to Host a Minecraft Server Friends Can Join from Anywhere (No Port Forwarding)

The Problem: "Connection Refused"

The Fix: A Reverse Tunnel with FRP

MoonProxy: A GUI for FRP

Step-by-Step: Minecraft Server Over FRP with MoonProxy

1. Get an FRP server

2. Download MoonProxy

3. Configure your FRP server

4. Add a proxy rule for Minecraft

5. Start the tunnel

6. Share the address

Keeping It Up 24/7

Why Not Just Use a Hosting Service?

Wrap-Up

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

The problem every self-hoster hits

What FRP is

The catch: config files

The piece I actually wanted to share

A quick walkthrough

When to use what

Wrapping up

5 Real-World Scenarios Where a GUI FRP Client Beats the Command Line

1. The "I Just Want to SSH Into My Home Server" User

2. Debugging Webhooks and OAuth Callbacks Locally

3. Sharing a Local Service With a Non-Technical Colleague

4. Keeping a Tunnel Up 24/7 Without Babying It

5. Knowing Immediately When a Tunnel Breaks

The Broader Point

Bundling a CLI Binary as a Tauri v2 Sidecar: Architecture and Lessons from Building MoonProxy

Why sidecar?

Step 1 — Naming convention

Step 2 — Place binaries in src-tauri/binaries/

Step 3 — Declare in tauri.conf.json

Step 4 — Spawn the sidecar from Rust

Step 5 — Log ring buffer (for the UI)

Step 6 — Auto-restart with backoff

Step 7 — Self-update of the sidecar binary

Gotchas we hit

1. macOS code signing & Gatekeeper

2. Windows Defender false positive

3. Architecture mismatch on Apple Silicon

What I'd do differently

Code links

Try it

Comparing FRP GUI Clients in 2026: MoonProxy vs frpc-desktop vs frpmgr vs frp-panel

Why use a GUI for FRP?

The contenders

1. MoonProxy (cross-platform)

2. frpc-desktop

3. frpmgr

4. frp-panel

Quick comparison

Which one should you choose?

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

The problem every self-hoster hits

What FRP is

The catch: config files

The piece I actually wanted to share

A quick walkthrough

When to use what

Wrapping up

MoonProxy: A Desktop GUI Client for FRP (Fast Reverse Proxy)

MoonProxy: The Complete Guide to FRP Intranet Penetration

Why FRP + MoonProxy?

Architecture

Part 1: Set Up frps Server (5 min)

Download FRP

Configure frps.toml

Run as systemd service

Step 2 — Place binaries in `src-tauri/binaries/`

Step 3 — Declare in `tauri.conf.json`