serv00-play: a keepalive and auto-login harness for free hosting accounts

What the project is actually for

The repository description lists a lot at once: Argo and various proxy protocol setups, a file listing panel, a probe agent, a status panel, webssh, automated deployment, batch account keeping, process protection and message pushing. It reads like a kitchen sink until you find the sentence that explains it. Because serv00 requires a login every 3 months, an account that nobody touches gets reclaimed. That single rule is what the whole project is built around.

So the primary job is scheduled logins across many accounts at once, which the README lists first under its keepalive actions. Everything else, the deployment scripts and the panels, rides along because you have a shell on the host anyway and might as well install them.

The prerequisites section is short and sets expectations. You need a serv00 or hostUNO account, you run the install command, you log back in, and you type `ss` and press enter to get into the interface. That last instruction is a hint about the environment: these are shared FreeBSD-style accounts where you manage your own processes, so the tooling has to assume a shell that is not yours and cron jobs that can vanish.

One install command and one credential blob

Installation is a single piped shell command with an `--install` flag.

bash <(curl -Ls https://raw.githubusercontent.com/frankiejun/serv00-play/main/start.sh) --install

Credentials are not configured per host on disk. They go into a single variable called `HOSTS_JSON`, marked as required and typed as a secret, which can hold any number of server records.

 {
   "info": [
    {
      "host": "s2.serv00.com",
      "username": "kkk",
      "port": 22,
      "password": "fdsafjijgn"
    }
  ]
}

Putting every account in one variable is what makes batch operations possible, and it also makes this the single most sensitive line in the setup. The README is clear about the override rule: per-host configuration wins over the shared configuration, so you can push one notification setup for all hosts and then adjust an individual account when it needs something different.

The tree is small and tells you where the logic lives: `start.sh` for installation, `keepalive.sh` and `revive.sh` for liveness and recovery, `revive_node.sh` and `utils.sh` as shared pieces, `tgsend.sh` and `wxsend.sh` for notifications, plus `keepalive/`, `singbox/`, `ssl/` and `domains-support/` directories. The language is Shell and there is no build step.

Seven keepalive behaviours, and why the alert fires rarely

The README enumerates what a keepalive cycle actually does, and it is worth reading as a list of failure modes rather than a feature list. It logs into each host on a timer, which is the account-keeping part. It runs a fallback liveness strategy. It checks whether the keepalive cron job on the host still exists and recreates it if it was deleted. It updates the serv00-play code on the server. It syncs notification parameters such as Telegram and WeChat settings.

The sixth item is the design decision that makes this project worth reading about. By default you get a Telegram message only when a login fails, and the README puts the reasoning bluntly: in normal operation it will not message you, and when it does message you, that is the day you get banned. A second variable, `LOGININFO`, flips this to a daily summary for every login, and the author recommends against it.

There is also an optional web keepalive path guarded by a `TOKEN` secret, which the README notes does not involve an SSH login but still counts toward extending the server's validity, meaning the three-month login is no longer needed.

Two more variables shape the schedule. `LOGINONCE` set to Y logs into a single account per day instead of all of them, and `AUTOUPDATE` controls whether the code on the server updates itself, defaulting to Y.

Notifications through Telegram, WeChat or both

Push support covers Telegram and WeChat, chosen with a `SENDTYPE` variable where 1 is Telegram, 2 is WeChat and 3 is both. Telegram needs two secrets, `TELEGRAM_TOKEN` for the bot and `TELEGRAM_USERID` for the recipient.

WeChat goes through a separate project by the same author, `wxpush`, which needs a `WXPUSH_URL` pointing at that project's request endpoint and a `WX_TOKEN` for its API. The README links two configuration videos, one for Telegram and one for WeChat, and the author notes that if you cannot configure it, the video is the way in.

One small nicety is the `BUTTON_URL` variable, which sets a button link inside Telegram messages and expands the placeholders `#HOST`, `#USER` and `#PASS`. That is a genuinely useful detail for this kind of alert, since the message tells you which account failed and the button takes you straight to the right host.

The README also shows an older notification route as deprecated in the variables table. The server-push key for WeChat messages is struck through and marked no longer in use, which suggests the author moved WeChat support behind his own `wxpush` service rather than maintaining a third-party integration.

An outbound proxy is supported for the login step

Four optional variables cover an outbound proxy for connecting out: `PROXY_HOST` as the address, `PROXY_PORT` as the port, and `PROXY_USER` and `PROXY_PASS` for credentials. The example values in the table are the obvious local ones, host `127.0.0.1` and port 1080.

Why this matters more here than in most scripts is that a scheduled login from the same IP every day, from many accounts at once, is a pattern any hosting provider can flag. The README does not discuss that risk, and the alert design described earlier, where a message means a likely ban, is the closest it comes to acknowledging it. A proxy option exists; the operational reasoning around it is left to the reader.

The same applies to the scale of the setup. The `HOSTS_JSON` example shows two accounts on the same `s2.serv00.com` host, and the documentation on batch behaviour plus the daily summary toggle suggests the design assumes more than a handful. Nothing in the README caps that number or discusses rate limiting.

The disclaimer, the acknowledgements and what they say about the project

The README ends with a disclaimer that is worth quoting in substance because it defines the intended use. It states the program is for study and understanding, non profit, that it should be deleted within 24 hours of downloading, and that it must not be used for commercial purposes, with copyright asserted over the code, data and images and attribution required on reprinting. It adds that users must follow the laws of the server's location, their own country and their own country, and that the author is not responsible for improper use.

That is an unusually narrow licence posture, and the repository's metadata reflects the ambiguity: the license field is NOASSERTION even though a `LICENSE` file sits in the tree.

The acknowledgements section is a good map of the ecosystem this depends on, naming sing-box, the AlistGo file listing project, a Telegram MTProto proxy server, the Nezha probe agent, a webssh project, the sun-panel dashboard and a one-time message project. It also credits the sponsors, including two projects providing free permanent servers, which is a reminder that a piece of infrastructure like this depends on somebody's free tier.

The repository is not archived, last pushed 2026-09-27, with 2128 stars, 1968 forks and 1 open issue. Fork count within a whisker of the star count is a strong signal that most of those forks are people running their own copy of a script rather than contributing changes back.

Editorial conclusion

serv00-play solves one narrow problem in a way worth understanding: free hosting accounts that expire unless you log into them, and shell scripts that need to keep running on a host you do not control. Its real contribution is the notification design, where silence means everything is fine and a message means your account is probably about to be gone, plus the recovery logic that rebuilds the cron job when the host deletes it. The boundary is equally clear. This is not a proxy client or a VPN despite the protocol names in the description, it depends on the free account still offering SSH, and its own disclaimer states it is for study, non commercial, with deletion after 24 hours. Expect shell, not Go: `start.sh` installs it, `keepalive.sh` and `revive.sh` handle liveness, and the credentials live in one `HOSTS_JSON` secret rather than in per-host files.

Frequently asked questions

Official sources

1. frankiejun/serv00-play on GitHub
2. Issues
3. README