DEV Community: Vibhanshu Garg

Why Pooling Local RAM Beats Buying Bigger Machines

Vibhanshu Garg — Fri, 19 Dec 2025 16:36:26 +0000

We've all been there.

You’re running a heavy build, training a model, or processing a massive dataset. Suddenly, everything grinds to a halt. You check htop and see the red bar of death: Swap. Your 32GB MacBook is gasping for air.

Meanwhile, your coworker’s laptop is sitting idle on the desk next to you. The office server is humming along at 5% utilization.

In that moment, the typical engineer’s instinct (including mine) is: "I need a bigger machine."

We instinctively reach for the credit card to upgrade to 64GB or 128GB. But lately, I’ve realized that this instinct isn’t just expensive—it’s technically backwards.

The "Bigger is Better" Trap

The conventional wisdom goes like this:

More RAM on one machine = better performance

It feels true because local memory is usually the fastest thing we have. But there’s a catch that I learned the hard way while building distributed systems.

As you scale up a single machine, you hit a wall.

When you buy a massive workstation or a high-memory cloud instance, you aren't just getting more RAM; you're getting more headaches:

Bandwidth bottlenecks: A single memory bus can only push so much data.
NUMA penalties: On big multi-socket servers, accessing RAM on the "other" CPU plays havoc with latency.
The Blast Radius: If that one expensive machine crashes, your entire workload dies with it.

Compare that to the laptop or server sitting next to you. It has its own memory controller, its own bus, and its own CPU.

Memory bandwidth scales linearly when you go wide. Two machines with 64GB RAM have roughly double the aggregate bandwidth of one machine with 128GB.

Why We Don't Share

So if "going wide" is better, why don't we do it for memory?

Because it's hard.

We have great tools for sharing CPU (Kubernetes) and storage (S3, network drives). But memory? Memory has always been trapped inside the box. It’s strictly "local."

This leads to what I call Stranded RAM.

Right now, if you look around your office or data center, about 60-80% of the total RAM is doing absolutely nothing. It's provisioned, paid for, and powered on—but it's completely inaccessible to the one process that actually needs it.

It's like having five cars in your driveway but being unable to drive to work because the one you're sitting in is out of gas.

Enter MemCloud

I built MemCloud because I wanted to break this limitation. I wanted to treat the RAM across my local network—my laptop, my desktop, my Raspberry Pi cluster—as one single, giant pool of memory.

MemCloud doesn't replace your local RAM. That would be silly; network latency is real.

Instead, it fits into the "warm" layer of the hierarchy:

CPU Cache (Instant)
Local RAM (~100 nanoseconds)
MemCloud / Remote RAM (~10-30 microseconds)
NVMe SSD (~100 microseconds)
Disk (Milliseconds)

Remote RAM is still 5-10x faster than an NVMe SSD.

For things like build caches, ML embeddings, temporary compiler artifacts, or analytics scratch space, it is the perfect middle ground. You get the speed of memory without the cost of a monster workstation.

Real Numbers

To prove to myself this wasn't just a fun theory, I benchmarked it.

Storage Type	Latency	What it feels like
Local RAM	~0.1 µs	Instant
Pooled RAM (LAN)	~10–30 µs	Extremely Snappy
NVMe SSD	~100 µs	Fast I/O
Cloud Object Store	~50,000 µs	Waiting for a download

When you offload a few gigabytes of "warm" data to a neighbor node, your local machine breathes a sigh of relief. The swap thrashing stops. The UI becomes responsive again.

The Vision: Infrastructure as a Commons

There is a cost argument here—using what you already have is cheaper than buying new gear. But for me, the exciting part is the shift in mindset.

When we view memory as a shared resource rather than a private possession of a single kernel, amazing architectures become possible:

CI pipelines can borrow 100GB of RAM from office workstations at night.
Edge devices can pool resources to run AI models they couldn't handle individually.
Teams can share a massive in-memory dataset without everyone needing a copy.

I’m building MemCloud in Rust because I believe this is where systems are heading. We're moving away from monolithic giants toward collaborative, peer-to-peer swarms.

If you've ever stared at a "Out of Memory" crash while surrounded by idle computers, you know why this matters.

Give MemCloud a spin

📖 Read the docs: memcloud.vercel.app/docs/cli
💻 Browse the code: github.com/vibhanshu2001/memcloud

I'd love to hear if this solves a real headache for you. Let's discuss in the comments!

🔒 Inside MemCloud’s Secure Peer Authentication: How Devices Safely Share RAM Over LAN

Vibhanshu Garg — Thu, 11 Dec 2025 16:38:34 +0000

When I released MemCloud (a distributed RAM engine for macOS & Linux), the biggest question I got was:

“Isn’t letting other devices store your RAM risky? How is it secured?”

So here’s a deep-dive into the authentication, encryption, and trust model behind MemCloud — written for engineers who love protocols, threat models, and cryptographic design.

This post focuses purely on the Security & Authentication layer.

(If you're new to MemCloud, see the intro blog — this assumes familiarity.)

🧩 Threat Model

Before designing the protocol, I outlined real-world LAN threats:

Threat	Example
Impersonation	Rogue device pretends to be a trusted peer
MITM Attack	Attacker intercepts or mutates handshake traffic
Replay Attack	Reusing old handshake messages
Unauthorized Memory Access	Device silently joins the cluster
Session Hijacking	Stealing or predicting traffic keys

MemCloud’s protocol addresses all of them.

🛂 1. Persistent Identity Keys (Ed25519)

Every device has a long-term identity keypair:

~/.memcloud/identity_key

Ed25519 (fast + secure)
Only used to sign handshake transcripts
Never used for encryption

This behaves like a device certificate without the complexity of PKI.

🔐 2. Noise-Style Handshake (XX Pattern)

MemCloud uses an authentication flow inspired by the Noise Protocol Framework — specifically Noise_XX, chosen because:

Both sides begin unauthenticated
Supports Trust-On-First-Use (TOFU)
Offers mutual authentication
Ensures forward secrecy

Simplified handshake:

A → B : eA, nonceA
B → A : eB, nonceB
A → B : identity proof (encrypted)
B → A : identity proof (encrypted)

Where eA and eB are ephemeral X25519 public keys.

📜 3. Transcript Hashing

Every handshake message is hashed into a transcript:

H = Hash(H || message)

This prevents:

Replay attacks
Downgrade attacks
Cross-session confusion
MITM tampering

The transcript is later fed into key derivation.

🧾 4. Encrypted Identity Proofs

Once ephemeral keys are exchanged, both sides compute:

shared_secret = DH(eA, eB)

Using this encryption key, each device sends:

signature = Sign(TranscriptHash, IdentityKey)

This signature:

is encrypted
is bound to the transcript
cannot be replayed
proves identity with forward secrecy

If signature verification fails → connection closed immediately.

🔑 5. Session Key Derivation (HKDF)

Final traffic keys are derived using:

session_key = HKDF(shared_secret + transcript_hash)

Properties:

✔ Unique keys per session

✔ Handshake keys ≠ traffic keys

✔ Forward secrecy (ephemeral DH)

✔ Resistant to key compromise

Traffic encryption uses:

ChaCha20-Poly1305 AEAD

Perfect for high-speed LAN communication.

👁 6. Trust-On-First-Use (TOFU)

Requesting device:

On first contact, the user must explicitly approve the peer:

Trusted peers are stored in:
~/.memcloud/trusted_devices.json

Future connections:

Still cryptographically authenticated
Skip interactive approval
Cannot be silently spoofed or replaced

🚫 What Happens When Auth Fails?

MemCloud rejects the session if:

identity signature fails
transcript mismatch occurs
handshake is malformed
device is untrusted
the consent layer blocks authorization

Rejected peers cannot:

read your RAM
receive block data
join the cluster
impersonate a previous peer

🔍 Why Not TLS?

TLS is powerful, but not ideal for a P2P LAN memory engine.

❌ Requires PKI or certificate distribution

MemCloud is designed to be zero-config.

❌ Not optimized for TOFU

Noise is.

❌ More overhead for LAN P2P

MemCloud aims for sub-10ms latency.

✔ Noise-style handshake advantages:

Mutual authentication
Identity hiding
Forward secrecy
TOFU support
Lightweight binary protocol
Perfect for peer-to-peer systems

🧪 Fuzzing & Attack Testing

I tested the handshake against:

Attack Attempt	Result
Replay	Blocked via transcript mismatch
MITM	Blocked (identity proof mismatch)
Impersonation	Blocked (signature invalid)
Downgrade attempt	Impossible
Payload tampering	Blocked (MAC failure)

So far the protocol has held up extremely well in real-world LAN conditions.

🛠 Security Roadmap

Planned improvements:

🔄 Trust revocation broadcasting
🖥 GUI trust manager
🛡 Optional hardware-backed identity keys
🔁 Session resumption
📦 Encrypted replication across peers

Contributors welcomed.

📦 Source Code

👉 Authentication Code: /memnode/src/net/auth

👉 Main Repo: https://github.com/vibhanshu2001/memcloud

👉 Documentation: https://memcloud.vercel.app/docs/cli
👉 CLI Trust Manager: memcli trust

❤️ Final Thoughts

MemCloud may look simple on the surface:

“Devices sharing RAM over LAN.”

But underneath is a carefully engineered secure protocol designed to make that actually safe.

If you'd like a follow-up on the:

P2P binary protocol
memory isolation model
quota enforcement
zero-copy streaming design

Just let me know!

🚀 Introducing MemCloud — Pool Unused RAM Across Machines on Your LAN (Rust, Zero-Config)

Vibhanshu Garg — Sun, 07 Dec 2025 20:05:35 +0000

Hey DEV community! 👋

I’ve been working on a side project that turned into something surprisingly useful, fun, and very Rust-y.

Meet MemCloud — a distributed in-memory data store that lets multiple machines on your LAN pool their RAM into a single ephemeral “memory cloud.”

Use case: Have a Mac, a Linux machine, and a spare mini-PC sitting around?

MemCloud turns them into one big RAM cache — automatically.

💡 Why I Built This

I often run ML experiments, dev servers, and log processors that overflow RAM on one machine while another machine sits idle right next to it.

I wanted a tool that:

works offline
runs locally
requires zero configuration
discovers peers automatically
lets me store/load data across devices in milliseconds

So I built MemCloud, a tiny Rust daemon + CLI + SDKs that create a peer-to-peer RAM mesh on your LAN.

⚡️ Key Features

🕸️ P2P RAM Pooling

Every memnode contributes its RAM to the cluster.

A write on Machine A can be read from Machine B in under 10ms.

🔍 Zero-Config Discovery (mDNS)

Just start the daemon — peers auto-discover each other.

No IPs, no ports, no YAML files, no Kubernetes.

🌐 Works Fully Offline

No cloud. No accounts. No central server.

⛓️ CLI + SDKs

memcli for terminal workflows
Rust SDK for systems work
TypeScript SDK for JS/Node devs

🔑 Two Storage Modes

Block Store: raw bytes & streams
Key-Value Store: Redis-style set / get

🧱 Architecture

You can view the architecture diagrams here:

➡️ https://github.com/vibhanshu2001/memcloud/blob/main/ARCHITECTURE.md

Each node runs a small daemon (memnode).

SDKs and CLI talk only to the local daemon.

The daemon handles routing and storage across peers.

⚙️ Installation

Quick Install (macOS & Linux)

curl -fsSL https://raw.githubusercontent.com/vibhanshu2001/memcloud/main/install.sh | sh

🛠️ Build from Source

git clone https://github.com/vibhanshu2001/memcloud.git
cd memcloud
cargo build --release

👨‍💻 Open Source

GitHub: https://github.com/vibhanshu2001/memcloud

Docs: https://memcloud.vercel.app/
NPM: https://www.npmjs.com/package/memcloud

I’d love feedback on:

performance ideas
networking improvements
memory/eviction strategies
real-world use cases

Thanks for reading!

— Vibhanshu