mvscode/frps-onekey: a shell installer for the frp server on Debian and Ubuntu

The problem frps-onekey solves, and who it is for

Running an frp server means getting three things right at once: a downloaded frps binary for the right architecture, a frps.toml whose key names match the frp version you installed, and a service unit that keeps the process alive. The frps project itself ships the binary and the documentation, not a Linux installer. mvscode/frps-onekey fills that gap with a single shell script, install-frps.sh, which the README describes as a one-click configuration script that obtains the latest frp version by default.

The intended user is someone with a VPS running Debian, Ubuntu, CentOS or Fedora who wants to expose services behind NAT and would rather answer prompts than write configuration. The README states support for 32-bit and 64-bit systems, and the 1.0.6 changelog entry adds RHEL, Rocky and AlmaLinux to the supported list. If you already manage servers with Ansible, cloud-init or a container image, the interactive script is a step backwards, not a convenience.

What the installer actually does on the host

The script is a configuration generator wrapped around a download and a service install. It fetches an frp release tarball, unpacks the frps binary, and writes a config file. The 1.0.2 changelog records a format migration from the old INI keys to the current camelCase TOML names (bind_addr to bindAddr, bind_port to bindPort, kcp_bind_port to kcpBindPort), and the 1.0.1 entry records the switch of the config file from frps.ini to frps.toml. That history matters when you read older frp tutorials: the key names on this script's output are the current ones, not the legacy ones.

Service control is delegated to /etc/init.d/frps, an init script kept in the repository as frps.init. The README lists its interface as start, stop, restart, status, config, info and version. The info command was added in the 2.0.0 cycle and prints the frps configuration panel. Version selection is where the script makes a decision for you: it pulls the latest frp release by default, and a GitHub Actions workflow named sync-frp-releases.yml mirrors fatedier/frp release assets into frp-releases/<tag>/ and republishes them as releases in this repository. The 1.0.8 changelog entry notes the download URL was fixed to fetch assets directly from fatedier/frp releases rather than a mirror, so where the binary comes from depends on which script version you are running.

Installing frps on Ubuntu or Debian with the one-key script

The README gives two download routes, Gitee and GitHub, with identical steps. Run the script as a user who can write to /etc and install a service. The GitHub variant below is the one the README shows:

wget https://raw.githubusercontent.com/mvscode/frps-onekey/master/install-frps.sh -O ./install-frps.sh
chmod 700 ./install-frps.sh
./install-frps.sh install

After the chmod, the script is executable only by its owner. The install run is interactive: it asks for the values that become frps.toml, including bind port and dashboard settings. The 2.0.0 changelog adds an SSH Tunnel Gateway configuration step and a webServer TLS step for the dashboard, where certificate and key files are validated and can be auto-generated when missing. Once it finishes, control the daemon through the init script:

/etc/init.d/frps start
/etc/init.d/frps status
/etc/init.d/frps info

The info call is the fastest way to see what the script wrote, including whether the dashboard URL is http or https. The 2.0.0 changelog records a fix for that URL being printed as http:// when TLS was enabled. If the daemon fails to start, the same release notes say errors are now propagated and startup logs captured, so read the output of the start command rather than assuming success.

Upgrades, uninstalls and the version you did not choose

Two subcommands cover lifecycle. The README lists ./install-frps.sh update and ./install-frps.sh uninstall. The update path is where the default-to-latest behaviour becomes a real constraint. Because the script obtains the latest frp version by default, an update can move you across frp releases whose configuration keys changed, exactly as the 1.0.2 migration shows happened once already. The 1.0.4 changelog entry says the shell update function asks the user whether to update, which gives you a chance to decline, but the script does not document a way to pin a specific frp tag during install.

That is the sharpest limitation here. Version pinning, reproducibility and rollback are not described in the README. If an update breaks your tunnels, the documented recovery is to run update again or to reinstall, not to roll back to the previous tag. For a homelab server you can absorb that. For a production relay carrying other people's traffic, an unattended update that changes key names in frps.toml is a failure mode you should plan around by keeping your own copy of the config and the frps binary.

frps-onekey against installing fatedier/frp by hand

The real alternative is the upstream project it wraps. fatedier/frp publishes release archives containing frpc and frps binaries plus example configuration; you unpack the archive, write frps.toml, and create your own systemd unit. The difference is not capability, since both end up running the same frps binary. It is who makes the decisions. Upstream leaves version choice, config layout, service supervision and upgrade timing to you. frps-onekey makes those decisions through prompts and an init script, and adds conveniences upstream does not ship: a config panel via /etc/init.d/frps info, certificate auto-generation for the dashboard, and a release-sync workflow that republishes frp tags in this repository.

The cost is transparency. With a hand-written unit you know exactly which binary path and config path are in play. With the script you have to read install-frps.sh and frps.init to learn the same thing, and the README does not spell out those paths. The script is also tied to an init.d style of service management; hosts that expect systemd units will find /etc/init.d/frps unusual, even where it works.

Licence and the maintenance cost you are taking on

The repository is licensed GPL-3.0, and the LICENSE file sits at the top level. The script is a derivative of clangcn's onekey_install_shell, credited in the README, and it downloads and installs fatedier/frp, which carries its own licence. Redistributing a modified install-frps.sh means honouring GPL-3.0 terms; running it on your own server does not. This is a description of the licence identifier, not legal advice, and if you plan to ship the script inside a product you should read the licence text yourself.

Upgrade cost is mostly about the frp version, not this script. The repository's last push was on 2026-08-15, the same day as the v0.71.0 release, so the release-sync workflow is current as of that date. The changelog shows long quiet periods followed by bursts: 1.0.7 is dated 2024-07-24, then 1.0.8 on 2026-07-17, then the 2.0.0 and 2.0.1 work in August 2026. Expect the script to track frp releases through automation and to receive interactive-feature work intermittently. If your environment needs a support contract or a predictable release cadence, that pattern will not satisfy it.

Editorial conclusion

Use mvscode/frps-onekey if you want frps running on a Debian or Ubuntu host in one interactive pass and you are willing to let the script choose the frp version. Do not use it if you need pinned versions, non-interactive provisioning, or configuration the interactive prompts do not cover; in those cases install the fatedier/frp release yourself. Before adopting it, read install-frps.sh and frps.init to confirm which ports and paths the script writes, then run /etc/init.d/frps info after install to see the resulting frps.toml.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. mvscode/frps-onekey on GitHub
4. README
5. Releases