Not a VPN: A Two-Peer RAM-Only Tunnel (Cluddy)

Hi all! This post explains how to exchange data through a cryptographic tunnel that runs on your own VPS.
No setup commands here — this is the design and trust model. Full docs: Cluddy Documentation

I’m the author of Cluddy; happy to answer questions in the comments.
You don’t need to be a programmer, but basic Linux skills (SSH, DNS, TLS) helps.

What’s the difference?

Okay, firstly, you need to know Cluddy is not a VPN. As I mentioned above, we will build the cryptographically secure tunnel.

A VPN reroutes all of your traffic through a provider. That changes your network path, but it doesn’t change how platforms handle your content — data may still be stored and tied to profiles.

Cluddy works differently. It builds a dedicated tunnel only for the data you choose to exchange. Packets remain end-to-end encrypted, are routed via your VPS, and are not stored. Keys stay with users.

Why VPN is not enough
A VPN can hide where you connect from, but the services you use can still keep your content and link it to an account. Cluddy addresses this by transporting encrypted data without profiles or storage:
The data you transport:

• encrypted end-to-end under your own keys,
• never written to disk on the host,
• lives in RAM only and vanishes after delivery,
• never tied to an account.

So you don’t need to hide your identity first. By design, no one can know what you are transporting, and nothing persists after delivery.

After seeing the difference, you might expect a deep technical dive right away.
But instead of overwhelming you with implementation details, let’s first look at practical use cases: modern problems in data exchange, and how this model addresses them.

Later in the article, I’ll walk you through the implementation, explain how the tunnel works under the hood, and why Cluddy’s approach can be trusted.

Implementation & Trust

Ownership & trust boundary
A Cluddy tunnel runs on one peer’s VPS (the owner). Exchange only with peers you trust to operate a VPS correctly. The host acts as a neutral transporter: it forwards encrypted payloads between exactly two peers and deliberately avoids persistence.

Your Data. Your Rules. Automation helps, but control stays with the owner. That’s by design: each owner can set stricter OS/network rules on top of the baseline.

What the setup utility does (and doesn’t)
Baseline hardening performed by the utility:

• obtains TLS certificates and enables WSS,
• configures firewall and minimal transport logs (never payload),
• keeps application data in memory only during transit.

What it doesn’t do:

• it does not take away root/SSH or otherwise confiscate control from the owner,
• it does not store payloads or create user profiles,
• it does not hold private keys.

Roadmap: stronger defaults and temporary session lock-down (blocking any non-tunnel access during an active session).

Session model: exclusivity, lifetime, teardown

• Two peers only. A session is 1:1. If the active-peers list is already populated, new connections are rejected; no third party can join in the middle.
• Time-boxed. By default a session lasts 30 minutes. After that the host stops and must be restarted to continue—this limits risk by design.
• RAM-only lifecycle. Payloads are buffered in memory just long enough to route and acknowledge. If either peer disconnects or the session ends, in-memory state is cleared.

Connectivity requirements (owner side)
Use a Linux VPS and a domain with an A record pointing to it; the utility will fetch TLS certs and enforce WSS.

Key management & exchange

• Keys live with users. Generate them locally (e.g., via Cluddy KeyGen or your own tooling) and keep private keys on your devices.
• Exchange only what’s public. The host merely relays public material so peers can authenticate and derive a session secret; it never sees plaintext.
• Rotate per tunnel. Treat keys as ephemeral for exchange: don’t reuse keys you use for servers or other infrastructure; create fresh ones for each session.
• Static within a session. Keys don’t change mid-session unless you explicitly re-key.

What the client does vs. the host

• Local clients (on both peers) handle encryption/decryption, signing/verification, packet framing, and sending ACKs for delivery.
• The host is deliberately boring: it routes already-encrypted packets, keeps only minimal in-memory session state, and then forgets.

Current scope & Roadmap
Cluddy currently transports text-based data (including links/structured text).
File/media transport is on the roadmap with the same no-logs, RAM-only principle.

Conclusion

Cluddy narrows the trust surface: the owner’s VPS routes, buffers in RAM, then forgets. There are no accounts, content databases, or “soft deletes”; responsibility stays where it should — at the endpoints and with the VPS owner’s hygiene. If your goal is to move sensitive information without handing it to a platform, a time-boxed, two-peer tunnel under your own keys is a clear, auditable way to do it.