My home server needs 2 GB for the app, and more for the dev tooling. So I moved the tooling off it.

Junwon Lee — Mon, 31 Aug 2026 13:55:50 +0000

RAM got expensive. When you build a home server or grab a used Mini PC for a side project, you try to match the spec to what the service actually needs. Mine need about 2 GB. They run fine on that.

The problem showed up somewhere else entirely. On a project with any real size, the tooling I bring to the server eats more than the service does:

VS Code's remote server and its daemons
background AI agents like Claude Code or Codex — heavy enough that memory usage is a known, tracked pain
monitoring tools that sit resident and sip resources forever

So I've got a lean little box that runs the service fine, and I keep getting pushed to over-spec it — not for the workload, for the tools.

"Just develop locally and git-deploy"

Sure — and I do. Shipping a feature is still local build → git → deploy, and I wouldn't change that.

But git covers exactly one moment: code reaching the server. After the deploy, a different set of jobs is waiting — read the logs, check resource usage, figure out why a container died, fix one line in a config in a hurry. "What is this box doing right now" isn't answered by the repo, so eventually someone SSHes in. And if that someone brings heavy tools, you're back to square one.

The question I got stuck on:

Can the server's resources go entirely to the service, while the dev tools and the AI run from outside without weighing it down?

That's the whole reason I built LiteDeck (open source, Apache-2.0).

The idea: the tools live on your machine, not the server

LiteDeck is agentless (Go). It talks to the server over the one SSH port you already have open, and the heavy work — the UI, the editor, the AI — runs on your local machine. The server just answers SSH — nothing installed, and almost nothing left running. (There's exactly one honest exception, and it's in the monitoring section below.)

Zero-overhead monitoring

You can monitor a server meaningfully with basically no footprint on it.

LiteDeck's monitoring tab reads /proc and df — those numbers already exist; the kernel keeps them whether you look or not. CPU split into user / kernel / iowait / steal, per-core, memory, disk I/O, network counters, PSI (how long things waited, not just how much was used), open descriptors. GPU (VRAM, temperature, utilization) comes from nvidia-smi, which ships with the driver — so still nothing new installed.

The one honest exception to "nothing resident": GPU monitoring keeps a single nvidia-smi running on a 2-second loop while you're watching that host — re-launching it every poll would re-initialize NVML each time, which is the slow, wasteful part. It's the only thing LiteDeck leaves running on the server, and it stops the moment you disconnect. The /proc and df reads for CPU, memory, disk and network need nothing resident at all — they're plain reads.

No exporter, no time-series database, no agent living on the box. For a few servers you don't need Prometheus + node_exporter + Grafana to answer "is this thing swapping right now" — you need to read /proc over the SSH connection you already have.

Is that enough for everyone? No. If you need history, alerting, or dozens of hosts, you want the real stack. But for a lean home server, this is the bet — and it's the difference between a monitoring tool that costs you RAM and one that costs you nothing.

Containers, grouped the way Compose sees them

The other half of "what is this box doing right now" is Docker. LiteDeck lists containers, images and volumes over the same SSH connection — it shells out to the docker CLI, so no daemon socket is exposed and nothing new lands on the server.

Containers are grouped by their Compose project, read straight from the com.docker.compose.project label. So you act on a whole project or a single service inside it — start, stop, restart — and it keeps working even when the compose file is long gone, because it drives docker compose --project-name <name> off the labels Docker keeps, not a YAML file on disk. The images and volumes views flag what nothing references — the usual answer to a full disk.

The AI runs on your machine too — and sits in the same seat you do

Offloading the tooling includes the AI. A local MCP client (Claude Code, Claude Desktop) sits in the same seat the GUI does: the same adapter, the same already-authenticated SSH connection, the same Command Log. No second credential handed to the model, nothing extra listening on the server. The inference runs on your machine, not the box.

It gets 17 tools — 12 read, 5 write. The write side runs through an approval gate:

The default isn't "nag on everything." A file write gets a diff dialog — because LiteDeck can show the change against what's on the server right now, which the AI client can't. Service, container and process actions pass through, since the client already showed you those in the same words. (Two other modes, per host: strict asks before anything, for the box you can't afford to be wrong about; bypass asks nothing — and expires on its own, max 8 hours. There is no "forever".)
Here's the catch that keeps it safe: you set the mode, per host, in the app. No MCP tool changes it, no request field relaxes it — so a prompt injection buried in a log can't say "turn bypass on" and be believed.
With bypass on, an injected instruction can run. What's left then isn't prevention — it's attribution and blast radius: every command in the Command Log verbatim, the mode auto-expiring, and production able to stay gated while staging doesn't. sudo is never added silently either. And a file it changed can be rolled back — LiteDeck keeps the previous contents (a service restart or a killed process, of course, can't be un-rung).

The trust boundary is you and the app — not the model's good intentions.

claude mcp add --transport http litedeck http://127.0.0.1:<port>/mcp \
  --header "Authorization: Bearer <token>"

The five rules I hold

LiteDeck is really five constraints, and a couple are genuinely arguable:

Zero server install. (Push back: "then your monitoring is weaker than an agent's." True — that's the /proc bet above. Where's the line for you?)
SSH only. The port you already have. SFTP and the terminal come from SSH itself, so even a box with no adapter still gives you files and a shell.
Nothing hidden. Every command — yours or the AI's — is in the Command Log, verbatim.
No account, no telemetry, open source.
Lightweight. Not Electron. A 5–10 MB download, cold start under a second.

The one I keep getting asked about: there's no resident watcher, so no background alerting. If the disk fills at 3 a.m. while nobody's looking, LiteDeck won't page you — that job belongs to something built to be always-on — a purpose-built monitor like Uptime Kuma or Netdata. Too strict? Maybe. I'd like to hear it.

"But is any of this actually tested?"

The repo ships a What's verified vs not page that separates what I've actually run on real hardware from what merely ought to work. "Not verified" doesn't mean the code is missing — it means I haven't personally driven it yet, and I say so.

That page exists because of stories like this: on Windows, downloading a directory from a Linux server, a file the server named ..\..\PWNED.txt landed two folders above the one I chose — a backslash is an ordinary character in a Linux filename and a path separator on Windows (same class as scp's CVE-2019-6111). I reproduced it on a real Windows box, added a guard, and re-verified the fix on the same machine. That loop — reproduce on real hardware, fix, re-verify — is the bar I try to hold before I write "verified."

What it deliberately does not do

So nobody has to ask "why not just Ansible": not dozens of servers at once (Ansible/Salt), not declarative state (Terraform), not a remote IDE (VS Code Remote-SSH), not screen streaming (RDP/VNC). LiteDeck is for a few servers, over SSH, with nothing installed, and with what it runs visible while it runs.

Try it / tell me where it breaks

Builds for macOS, Windows and Linux are on the releases page (unsigned for now; the notes explain the Gatekeeper/SmartScreen prompts). It's an early project — the rough edges are real, and feedback or PRs from anyone running lean home servers, old Mini PCs, or low-end GPU boxes are exactly what I want.

⭐ https://github.com/cpprhtn/LiteDeck

Two open questions I'd like opinions on:

Is "agentless, read /proc over SSH" enough monitoring — or does real observability need an agent on the box?
"AI in the same seat, human approves every write" — too cautious, or about right?

DEV Community: Junwon Lee