Your VPSs talking to each other, without opening ports to the internet

Here's what it looks like in the panel

The SSH tunnel you always built by hand

Now with a wizard, live status and best practices on by default.

• Receiver and initiator: Each VPS can accept tunnels, open them, or both at once. You design the topology.
• Nothing exposed to the internet: The service still listens only on the receiver's localhost. 5432 isn't opened, nor 3306, nor 6379: traffic comes in through the tunnel or it doesn't come in.
• One-click install: The receiver is ready in seconds. The initiator installs autossh on its own, without you touching a config file.
• Restricted tunnel user: The receiver creates a dedicated user with no password, no sudo and no shell, that can only do port forwarding. Even if someone got the key, they'd have nowhere to stand.
• ed25519 keys registered for you: The initiator generates its key pair and the panel authorizes it on the receiver, between VPSs in the same Company. No copy-paste, which is where mistakes slip in.
• Connection string ready to use: The receiver gives you the connection string using the VPS's DNS name, so you don't have to hand the IP around.
• Shortcuts for databases: Ready-made suggestions for PostgreSQL (5432), MySQL (3306) and Redis (6379), which is 90% of cases.
• Always connected: Each tunnel runs as a systemd service with autossh: if the network drops, it comes back on its own. And you can restart it from the panel without going in over SSH.
• Live status: Whether the receiver is up, whether the port is listening, how many tunnels there are and what state each one is in. No guessing.
• Any port, not just databases: An internal API, an Elasticsearch, an admin panel you don't want to publish: if it listens on a port, it can be tunneled.

5-step wizard

1. Enable the receiver: On the VPS that has the private service. It ends up listening on port 2222 with its restricted tunnel user.
2. Enable the initiator: On the VPS that's going to consume the service. It installs autossh and generates its ed25519 key pair.
3. Register the key: One click in the panel authorizes the initiator's public key on the receiver. Nothing to copy and paste.
4. Create the tunnel: You pick the local port on the initiator and the destination port on the receiver. PostgreSQL, MySQL and Redis come suggested.
5. Use it on localhost: Your app connects to localhost:5432 as if the database were on the same machine. Nothing to change in the code but the host.

How it works underneath, and what to keep in mind

• It's plain old SSH port forwarding, but set up and maintained by the panel: the receiver runs an sshd with a dedicated user and the initiator keeps the connection alive with autossh inside a systemd unit.
• The tunnel user has no password, no sudo and no shell. Its only capability is opening port forwardings, so a leaked key doesn't give access to the server.
• The receiver uses port 2222, which needs its redirect active. It's the only port that gets opened, and it gives nobody a shell.
• The initiator needs internet access to install autossh the first time. After that it works the same even if you restrict outbound traffic.
• Local ports can't be repeated across tunnels on the same initiator: if 5432 is already taken by one database, the second one goes to a different local port.
• Reinstalling the receiver generates a new tunnel user. You have to authorize the keys again and recreate the tunnels: it isn't a bug, it's that the previous identity no longer exists.
• It needs systemd and a Debian or Ubuntu base. It's verified in production on Ubuntu 22.04 and compatible with 24.04 and 26.04.
• It isn't available on Ubuntu 20.04 or earlier, and each case has its own specific reason: 16.04 ships OpenSSH 7.2, which doesn't understand the Include directive and never reads sshd_config.d; 18.04's sshd_config simply doesn't include that directory; and on 20.04 the VPS's base configuration writes KbdInteractiveAuthentication, which OpenSSH 8.2 doesn't know, so sshd -t fails and the change is rolled back on its own.
• The tunnel encrypts the transport, it doesn't authenticate your application: the database still needs its user and its password. What goes away is the exposure to the internet, not the authentication.
• Real root over SSH: the panel is a shortcut, not a cage. Anything it does with a button, you can also do by hand.

Or just ask Claude, ChatGPT or Cursor

Everything you see in the panel, your AI agent can do through the ArduMaker MCP server: with your authorization, within the scope you grant, and with every action audited. See what the MCP does

Frequently asked questions

Services that go well together

• PostgreSQL: Install PostgreSQL and manage databases, users and permissions without the command line.
• Redis: Install Redis, tune memory and persistence, and search, edit and delete keys from the panel.
• Database manager: A web grid for PostgreSQL and MySQL: edit rows, run SQL and EXPLAIN, and import/export CSV and Excel over a private tunnel.