R-Bot wraps seven cloud providers in a Java client you never see

Seven cloud providers behind one operator interface

R-Bot targets the person juggling several small VPS fleets rather than one large cluster. Its feature table names Oracle Cloud, AWS, GCP, Azure, DigitalOcean, SolusVM and VirtFusion as the providers it drives, and the Telegram side advertises more than 30 cloud operations spanning power state, resizing, disk work and monitoring alerts. The browser panel reaches further than the chat window in places, exposing instance creation, network and volume edits, user management, DNS records, object storage and a serial console for machines that no longer answer SSH.

The audience is narrow and easy to name: someone who already pays several providers, wants to power a machine on from a chat app while away from a laptop, and dislikes juggling seven consoles. Host synchronisation exists for that reason, importing hosts from OCI, AWS EC2, AWS Lightsail, GCP, Azure, DigitalOcean, SolusVM and VirtFusion into a single session list. Terminal features lean the same way, with batch command dispatch to several hosts at once and a result workbench that chains the next command onto the previous run.

The tree ships binaries while the Java code stays unpublished

Java is the primary language of this project, yet the top level of the tree holds only .gitattributes, a README, the md/ directory, the screenshots/ directory and two loose images. No source directory appears in that listing, and neither does a build file or a test directory. What a user installs is a prebuilt archive selected by architecture: gz_client_bot_x86.tar.gz for AVX2 hardware, gz_client_bot_x86_compatible.tar.gz as the fallback, gz_client_bot_aarch.tar.gz for ARM64, and gz_client_bot_mac_aarch.tar.gz for Apple Silicon. The startup script detects the architecture and downloads the matching package.

That gap weighs heavier here than it would for an ordinary tool, because this is the process that receives your cloud API private keys and then issues power, disk and network commands in your name. An operator deciding whether to trust it has prose, screenshots and a Telegram channel, with nothing to read. The tree also carries no LICENSE file; the only terms anywhere are a notice saying the scripts are for testing and study, are barred from commercial use, and ask users to wipe everything within 24 hours of download.

Your cloud keys sit in a client the Telegram bot has to reach

The architecture is deliberately two ended. Cloud API private keys live only in the client running on your own server, while the bot forwards your instructions to that client and keeps no keys itself. The data flow the README draws puts the bot between you and the client, so the bot service has to be able to reach the process you just started.

Getting there begins at first launch, when the client generates a credential pair and the page shows an activation prompt at the top. You copy the /bindclient command from that prompt into the Telegram chat, or you edit client_config, set username= and password= yourself, and restart. The chat you send it to belongs to the project operator, and the same panel also offers a client upgrade control, a restart button and a log viewer, so a session already holding cloud credentials can also fetch and run a fresh binary. The offered opt-out, stopping the client when you are done, is total rather than partial: both the bot and the panel lose their path once that process is down.

The install line downloads a script and runs it in the same breath

Quick start puts the client in its own directory before anything else:

mkdir rbot && cd rbot

The single install command then fetches the installer from the releases page, marks it executable and runs it immediately, so the first thing this project executes on your machine is code you have not opened:

wget -O sh_client_bot.sh https://github.com/semicons/java_oci_manage/releases/latest/download/sh_client_bot.sh && chmod +x sh_client_bot.sh && bash sh_client_bot.sh

That same file stays useful as the service control script for the life of the client. Passing a different number to it changes the port, and the rest of the verbs cover the daily loop:

bash sh_client_bot.sh
bash sh_client_bot.sh 8888
bash sh_client_bot.sh status
bash sh_client_bot.sh log
bash sh_client_bot.sh stop
bash sh_client_bot.sh restart
bash sh_client_bot.sh upgrade
bash sh_client_bot.sh uninstall

Once started, the panel answers on port 9527 over HTTPS at your server's own address. Activation comes next, through the /bindclient command or through credentials written into client_config, and cloud API parameters are accepted only after that step.

The panel is reached by IP address while an outside service drives it

The quick start mentions no reverse proxy, no domain name and no certificate of your own, yet the panel is presented at your own IP on port 9527 and the bot needs a route to it. On a home connection that means the port has to be reachable from the internet, which is also the context for the per-account proxy setting, where each cloud account carries its own proxy and an account configuration can be copied into a new region in one click.

The MCP integration widens that same surface. Claude Code, Codex and Cursor are meant to drive servers through the panel using a token, and the project states that passwords and private keys are not handed to the AI. The token still lives on the panel that already holds cloud API credentials.

Set against that, the feature table calls the client lightweight, fast to start, low on memory and capable of running on a router. Hosting a browser SSH terminal with SFTP, port forwarding, automatic Let's Encrypt issuance, a serial console and multi-cloud panels on a consumer router is a heavy claim, and no minimum memory or CPU figures are given to check it against.

An overage rule cuts power and a watchdog rule restores it

Two monitoring features pull in opposite directions. One shuts an instance down when traffic crosses a per-account threshold, and another lifts an instance that has gone down. A quota shutdown and a genuine outage therefore produce the same signal, and the panel exposes both switches without saying which takes priority or what happens when an account is over budget and something fails at the same moment.

Other automation stops short in ways worth knowing. The ARM A1 configuration check sweeps across instances, flags the ones that have outgrown the free tier allowance and steps their shape back down, but it will not delete a machine. The serial console is the recovery path when a host refuses SSH, reaching a Netboot.xyz rescue system while the instance is otherwise unreachable.

Upgrades arrive through the panel too. A web control upgrades, restarts and displays logs for the client, and version tags v10.7.1, v10.6.2 and v10.5.1 carry dates 2026-09-24, 2026-09-07 and 2026-08-21. That is a steady cadence for a project with no build files in its tree, and it means your client changes without a package manager ever seeing it.

The panel claims parity with the bot and the lists disagree

One paragraph states that the web cloud panel is aligned with what the Telegram bot can do. The two bullet lists tell a different story. For DigitalOcean Droplet, SolusVM VPS and VirtFusion instances the bot is scoped to queries and basic power operations, while the panel claims full instance management for those same providers, including VirtFusion rename and password reset. A SolusVM owner can create and inspect a VPS in the browser, yet from the chat window the same machine is a row you can query and switch on or off.

The mismatch runs the other way as well, in a narrower form. Account management on the bot side lists user management, API keys, 2FA reset and quota queries, while the panel's account surface is described as user creation, password reset, email changes and 2FA clearing. Neither list maps one to the other by version, so nothing in the repository settles which side is ahead on any given provider.

What the provider consoles and stock SSH already cover

The direct route to every provider named here is free: each vendor ships its own console and API, and an OpenSSH client already handles the shell, the file transfers and the tunnels the web terminal reproduces. What R-Bot adds on top is aggregation, not raw capability. One session list instead of seven, batch commands to many hosts from a single screen, a chat entry point for power actions while you are away from a keyboard, and one place to watch quota, traffic and certificate expiry across accounts.

That aggregation is also the entire risk. The console you would otherwise open belongs to the vendor and keeps no copy of your credentials. This client is a third party holding keys for seven providers at once, delivered as a binary that the repository never shows you. On a single provider with a console that already works, the trade is thin. Across several, the batch and monitoring tools save work that is awkward to reproduce with a shell script, provided you are comfortable with what the installer fetched.

Editorial conclusion

R-Bot earns its place for the operator who already owns instances on several of these seven providers and wants one session list, batch commands and a chat entry point instead of seven consoles. It fits nobody on a single provider, and it fits no security review that needs to read the code holding cloud API keys, since the tree ships no source, no build file and no tests. Before trusting it, read md/install.md and md/mcp.md, decide who has to reach port 9527, and set the client_config credentials yourself.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. semicons/java_oci_manage on GitHub