singbox-deploy puts a multi-protocol Sing-box server on a bare Linux host

The scripts cover the whole path from bare host to client link

singbox-deploy is a collection of shell scripts that install a Sing-box server on a Linux machine and hand back a usable client link. The README describes the tool as a cross platform, automated, one-click deployment script for Sing-box, and the primary language of the repository is Shell. The protocol coverage is the first thing it advertises: SS, HY2, TUIC, VLESS Reality and AnyTLS Reality, with the choice left to the operator.

The pipeline covers several steps that would otherwise be manual. The script fetches the latest Sing-box server build, generates the keys and the configuration file, and for Reality it can either pick an SNI or accept a default one. It then registers the service so the node comes back after a reboot and is restarted if the process dies.

The repository is built as a family of scripts rather than a single file. The top level holds install-singbox.sh alongside install-singbox-all.sh, install-singbox-panel.sh, install-singbox-yyds.sh and numbered variants install-singbox-yyds0.sh through install-singbox-yyds5.sh. The variants presumably cover different protocol or topology combinations, but the README does not spell out the mapping, so treat the numbered names as an entry point to read rather than a menu you can trust blind. The README also documents a management command, sb, which opens an interface for viewing node links, resetting the port and controlling the server process.

Installation is one curl command piped into bash

The deployment command in the README is a single line that downloads the script and runs it immediately:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/caigouzi121380/singbox-deploy/main/install-singbox-yyds.sh)"

That one line covers the install, the key generation, the config file, the boot-time service setup and the client link output. Because the pipeline fetches the newest Sing-box server build rather than a pinned version, running it again is how you would move to a newer release, which also means the version you end up with is whatever the upstream release happens to be on the day you run it.

Before running it, open the script in the repository and read it. The curl and bash pipeline pattern executes code that is not pinned to a commit, so the content can change between the moment you read it and the moment you run it. The repository ships the script files directly, so you can download a copy, read it end to end, and run the same file locally if you prefer that to piping a remote URL into a shell.

The service management part differs by operating system. The README lists support for Alpine, Debian, Ubuntu, CentOS, RHEL and Fedora, and it names both Systemd and OpenRC as the mechanism for boot-time startup and automatic restart after a crash. Alpine being in the list explains the OpenRC mention, since that is the init system used there.

The sb command is the only documented control surface after install

Once the script finishes, the documented way to interact with the deployment is the sb command. The README describes entering it to open a management interface that shows the node links, resets the port, and controls the server, including viewing its status.

That is a narrow surface, and the narrowness is worth weighing. The management interface is a menu inside a shell script rather than a documented API, so there is no stable way to script against it. Anything you want to automate, such as changing the port on a schedule or rotating credentials across a fleet, ends up as SSH access to the host and direct edits to the generated configuration instead.

The reset-port function also implies that the port can be regenerated, which is the kind of operation that becomes awkward when a client link has already been distributed to other people, since a regenerated port invalidates every link that was handed out. The README does not describe how existing links are updated after such a change, and it does not describe a rollback path or a way to restore an earlier configuration. If your use case involves many clients, that gap is the first thing to test.

Reality and AnyTLS sit next to the older SS, HY2 and TUIC options

The protocol list is the most substantive design choice here. SS is the Shadowsocks option, HY2 is a QUIC based protocol with its own transport characteristics, and TUIC is also QUIC based, and the Reality family of options, VLESS Reality and AnyTLS Reality, uses TLS handshake mimicry so that a server presenting those credentials looks like an ordinary TLS site to a scanner.

Reality matters for this deployment style because the script can generate the keys and configuration without a domain name or a publicly trusted certificate. The README states that the script either selects an SNI for the Reality configuration or applies a default one, which means a first deployment can complete without you holding a domain. The trade-off is that the SNI value becomes a meaningful part of the profile of that node, and the documentation does not say how it is chosen, whether the list of candidate values is validated, or how the configuration changes if the chosen SNI stops behaving like a real site.

Because the script writes all of this itself, there is no per-protocol tuning documentation in the README. Anyone who needs to adjust buffer sizes, alter routing rules, or add a different inbound has to read the generated configuration and the script that produces it.

The relay mode turns a second box into a VLESS Reality hop

Beyond the single-host deployment, the README describes a second topology that it calls the relay machine, and the mechanism is worth understanding because it changes what you operate.

From the landing machine, the script can generate an installation script for the relay machine. Running that on a second host sets up a VLESS Reality inbound there, either by looking for a free port automatically or by accepting a port you specify, and it configures traffic forwarding to the SS node on the landing machine. The result is a VLESS Reality client link that points at the relay.

The practical effect is that the second host becomes the point clients connect to, and the landing machine is reached through it. That is useful when you want the client-facing address to be a different machine from the one terminating the protocol, and it also means two hosts to configure, two services to keep alive, and one extra hop where traffic can fail.

The split of responsibility is uneven in a way that matters for debugging. The relay terminates the Reality side and forwards to the landing host's SS node, so a connectivity problem can live in either hop, and the documentation does not describe how to tell which one is failing from the sb interface. Ports are also a shared resource across the two machines, and the automatic free port search applies to the relay side only.

There is no tagged release and no licence file

Maintenance signals for this repository are thin, and they cut in different directions. The repository is not archived, and the last push was on 2026-07-26, which is recent enough that the scripts are being touched. There are no GitHub releases, so there is no version to pin, and the README points only at the latest server build for Sing-box itself. Upgrade therefore means re-running the installer and accepting whatever upstream release that fetch pulls in, with no published changelog for the scripts themselves.

The licensing position is weaker still. The top level of the repository contains README.md, the install scripts and a sponsor logo file, and no licence file appears among them. Without an explicit licence, the default position under copyright law is that no permission is granted to copy, modify or redistribute the scripts, even though the README invites anyone to run them. Anyone planning to embed these scripts in an internal deployment pipeline, or to publish a fork, should get that permission in writing first. This is a description of the situation rather than legal advice.

There is also no rollback. Nothing in the README describes what happens to the keys, the configuration or the service registration if a run fails part way through, and no uninstall command is mentioned.

Installing Sing-box by hand is the honest alternative

The alternative to this script is not another deployment tool with a nicer interface. It is installing Sing-box manually, which means fetching a release you choose, writing the configuration yourself, creating a service unit and managing it with the init system on that host.

The difference in approach is control. A manual install pins the server version, so an upgrade is a deliberate decision with a rollback to the previous binary. The configuration is a file you own, in a form you can read and diff, and the service definition is yours, so the same host tooling you use for every other service applies. The cost is that you rebuild the pieces the script automates: key generation, a correct client link with the right parameters, a working unit file with restart on failure, and the relay configuration that forwards to the landing node.

The script wins when you want a node quickly and have no strong reason to pin anything. It loses when reproducibility matters, when the script is the only record of how the server was configured, or when the licence question needs an answer before the code enters your infrastructure. A middle path is to run the script once on a scratch host, read the files it leaves behind, and rebuild the deployment around the configuration it produced.

Editorial conclusion

Use singbox-deploy when you want a working proxy node on a fresh Linux box in minutes and are comfortable letting a remote script fetch and configure everything for you. Do not use it where pinned versions, an auditable config or a clear licence are required, and do not treat it as a hardened production platform. Before the first run, read install-singbox-yyds.sh in the repository to see exactly what it downloads and writes, and confirm that the generated client link uses the host you expect rather than a wrong public IP.

Frequently asked questions

Official sources

1. caigouzi121380/singbox-deploy on GitHub
2. Issues
3. README