Two dead phones, two home servers

I read seg6's "my server is a phone now" the same day I finished turning an old OnePlus 6T into an always-on Linux box. Different phones, nearly identical instinct — take an SoC that's overqualified for sitting in a drawer and make it earn its keep. Here's how the two builds line up, and where they diverge.

The shared spine

Neither of us threw away Android. seg6 tried first — flashed postmarketOS onto a CMF Phone 1, got a splash screen and a black display, soft-bricked the device, and spent a side quest inside QEMU-Windows restoring stock Nothing OS. The lesson they landed on is the same one that makes this whole pattern work:

Android already has working drivers for every piece of this hardware. Wi-Fi, power management, the battery, the GPU, the modem — throwing all of that away in pursuit of a more conventional userspace was the wrong trade.

So both builds keep stock Android on the metal and run Termux as the host control plane. And both converge on the same durable stack:

The recovery chain is the part worth stealing regardless of what you run on top:

Android boot
-> Tailscale always-on VPN
-> Termux:Boot
-> runit
-> resident services
-> health checks

The phone reboots without waiting for a human to notice. That's the whole point — a server you forget about.

Where the builds part ways

What runs on it. seg6's phone replaced a paid Hetzner VPS: it hosts Surf (a remote Chromium browser streaming to an old iPad), a personal finance tracker, screen sharing, and a handful of smaller web apps. Mine is a spare-capacity node whose first job is a camera watchdog — a Tapo cam snapshots every minute, a Mac-side on-device Vision model checks for a human, and only a real person triggers a Telegram alert. seg6 replaced infrastructure; I added a worker.

How hard they pushed the runtime. This is the big divergence. Most of seg6's apps ship as Linux ARM64 OCI images, so they leaned on proot-distro to run a Debian rootfs without root. That was fine for ordinary web services — but Surf is latency-sensitive, and every process spawn, library open, and path walk crossed PRoot's userspace translation layer. Chrome had CPU available but couldn't reach it efficiently. So they rooted the phone — not to replace Android, but to mount the same Debian filesystem and enter it with a real chroot and native syscalls. "The improvement was not subtle."

My node does none of that. It's Termux-native — ffmpeg, sshd, a compiled Swift detector — no Debian rootfs, no chroot, no root. My heaviest workload is capturing a frame and shipping it off the device, which doesn't justify the syscall overhead surgery. seg6 needed a browser to feel local; I needed a phone to take a photo. Different ceilings, different depth of hack.

Ingress. seg6 solved the harder version of this problem. HTTP apps ride a Cloudflare Tunnel (one outbound connection, no router rules, follows the phone between networks). The tricky bit was Surf's TLS-pinned connection to a 2012-era iPad that a normal tunnel would break by terminating TLS at Cloudflare — so they wrapped the entire Surf TLS stream inside a plain WebSocket that Cloudflare forwards blind. My node has no public ingress at all: it lives on the LAN and the tailnet, and the camera pipeline pushes out to Telegram. Nothing needs to reach in.

Reproducibility. seg6 went all the way to Ansible + Git — versions, service definitions, routes, power settings, secrets, and health checks in one private repo, releases pinned by digest behind an atomic current symlink, secrets via Ansible Vault with the vault password signed by a 1Password SSH agent so the phone never holds the key. make phone brings a fresh rootable phone to the declared state. Mine is honestly still a pile of shell history plus a memory note — reproducible by me re-reading my own notes, not by a machine. That's the gap I'd close next if this node graduates from "spare" to "load-bearing."

Same gotchas, independently discovered

• Android's battery manager is the enemy. Both of us had to explicitly stop the OS from "optimizing" the server to death — wake locks and disabled idle for seg6, battery-optimization-off for me. Left alone, Android kills the process.
• The chroot/PRoot layers are compatibility, not isolation. seg6 is blunt that the residents share Android's kernel and network stack — "I would not treat the chroots as hostile workload isolation." Rooting expands the trust boundary. Worth remembering before you put anything sensitive on one.
• Old phone, real ABI friction. My fresh Termux ffmpeg threw a libplacebo.so linker error until a full pkg upgrade synced libc++ to its deps — and that upgrade pegged the 2019 SoC hard enough that sshd refused new session forks for a few minutes. Old silicon punishes you at exactly the wrong moment.

Should you do this?

seg6's closing take matches mine almost word for word: if you already own a reasonably modern, rootable ARM64 phone that's gathering dust, this is far less ridiculous than it sounds. You get quiet hardware, low power draw, flash storage, Wi-Fi, a screen for recovery, and a battery that behaves like a tiny UPS. Stock Android already drives the hardware; Termux (plus a chroot if you push it) runs a surprising amount of normal Linux.

The caveats are also shared: automated off-device backups for anything irreplaceable, no illusions about workload isolation, and an acceptance that Android is a weird server host that a future update could surprise you on.

But the payoff is real. seg6 killed a VPS bill and got a browser that reaches an ancient iPad from anywhere. I got a camera watchdog running on hardware that was otherwise landfill. Two people, two dead phones, the same quietly satisfying conclusion: the best server is sometimes the one already sitting in your house.

Written after building the OnePlus 6T node on 2026-08-08. Original inspiration: seg6.space/posts/phone-server.