These aren't side projects — they're the builds I think about constantly but haven't had the time, money, or skills to pull off yet. Ranked by how badly I want to make them happen.
#1 — Modular Cyberdeck In Progress
Hardware · Raspberry Pi 5 · Python · Shell · CircuitPython
A fully custom, hand-built portable computer — not a laptop, not a tablet, something entirely mine. Based on the open-source DFCD (DesignatedFreeCadDevice): Raspberry Pi 5 8GB brain, sliding 10.1" touchscreen, hidden NOS C-450 TKL mechanical keyboard, Logitech Marble trackball, NP-F battery, and a rotary encoder scroll handle. Every part is either 3D-printed or off-the-shelf — nothing is welded or machined. The point is a machine shaped around how I actually work — the keyboard I want, one-handed trackball navigation, and a rotary encoder for scrolling long documents and code.
The video below is the upstream build this is based on:
What's already built (software side):
✓ Full custom OS layer for Raspberry Pi OS — idempotent installer,
systemd boot scripts, zram memory tuning, themed terminal
✓ Opt-in AI layer — Claude Code + Ollama, memory-tuned for Pi 5
✓ Opt-in extras — deck-mode (stealth/work/bright), deck-vault (LUKS2
encrypted container), Conky status bar, RTL-SDR radio
✓ Grimoire — offline documentation search engine (SQLite + BM25
FTS5, ingest from DevDocs .zim files)
✓ Clamp-on Comms module — Pico USB bridge, NFC (PN532) + LoRa
(RFM9x, 923 MHz AS923), custom CAD enclosure, CircuitPython
firmware
✓ Custom 3D-printed parts — raised GFPIO lid, modified screen frame
with status LED
✓ Full build guide (PDF), bill of materials, shopping lists (USD +
THB)
What's blocking the physical build:
Cost of the mechanical keyboard components and the 3D printing time for the chassis parts. I've been planning this since June 2026, and the software side is done — the OS and app layers install cleanly today. What's left is the enclosure and buying the parts, so it's purely a cost and time problem at this point.
Full project page →
#2 — Petri In Progress
Rust · egui · Docker · Linux
This one started with Rubber Ducky USB attacks — I wanted somewhere to run something sketchy without handing it my actual laptop. What it turned into is a defensive Linux sandbox manager: a desktop app where you create a named sandbox, choose exactly what it's allowed to do, run a program inside it, and watch it. If something looks wrong, the plan is for Petri to isolate the sandbox immediately, record what happened, and let you decide whether to keep it locked down or destroy it.
What's built so far:
✓ Full lifecycle from the GUI — create, run, stop and destroy a
sandbox, driven by a real state machine (Created → Starting →
Running → Stopping → Stopped / Ran → Destroyed) that refuses illegal
transitions instead of tolerating them
✓ Every sandbox is a real Docker container — built on create,
started on run, paused on isolate, removed on destroy
✓ Locked down by default — all Linux capabilities dropped,
no-new-privileges, a 256 MB memory cap and a 128-process limit, and
nothing runs as root inside the container
✓ Permissions actually enforce something — no NetworkAccess means
no network at all, no WriteFiles means a read-only filesystem; a new
sandbox starts with none of them
✓ Per-sandbox storage under
sandboxes/sandbox-<id>/ — a saved
config.toml, a files/ folder mounted into
the container, and a logs/ folder
✓ Live status — the app polls Docker, notices when a program exits
on its own, and warns you if the Docker daemon isn't reachable
✓ egui desktop app, one card per sandbox, with the buttons driven by
the state machine so only legal actions are ever offered
What isn't built yet — being straight about it:
The watching half. Nothing monitors a running sandbox yet, so isolation is a button you press, not something Petri does on its own when it spots trouble — and the event and security logs aren't written yet either. The container flags are a solid first layer, but the seccomp, AppArmor and fanotify policies that would make it a real boundary aren't in, and it's only been tested under WSL2. So it's not a detonation environment: nothing real goes in it. What's left is time, and learning Rust at the rate the problem actually needs — I'd rather say that than ship something that only looks like a sandbox.
Read the source and the build log →
#3 — Raspberry Pi Kubernetes Cluster Planned
Raspberry Pi · Kubernetes (k3s) · Docker · Linux · Networking
A small stack of Raspberry Pis wired together into one Kubernetes cluster that I own end to end. Most of my projects are deployed on someone else's platform — Vercel, Streamlit Cloud, Cloudflare. This is about learning what those platforms do for me: scheduling containers across machines, restarting them when they crash, routing traffic to them, and keeping the whole thing running when one board is unplugged.
The plan:
○ Hardware — several Raspberry Pis on a shared network switch, one
as the control plane and the rest as workers
○ k3s — a lightweight Kubernetes that runs on ARM boards like the
Pi
○ Host my own projects on it — take things I've already built and
run them as containers on the cluster instead of a cloud host
○ Break it on purpose — pull a node's power mid-request and watch
Kubernetes move the work to the boards still running
○ Monitoring — dashboards for CPU, memory and temperature on every
node
○ Security — lock the cluster down with the same "nothing allowed
until granted" thinking behind Petri
What I want to learn from it:
How real infrastructure works underneath the "deploy" button: containers, orchestration, networking between machines, and what "high availability" actually means when a machine dies. It also builds on what's already here — Petri already runs everything as locked-down Docker containers, and the Cyberdeck is already a Raspberry Pi build.
Back to top