My Server Is a Phone: Turning a $199 Android into a Home Server

The DRAM market had gone “completely stupid.” The cheap VPS was starved whenever Chrome had real work to do. And the dedicated-CPU upgrade cost more per month than a personal browser deserved.

So the developer behind seg6.space did something that sounds ridiculous and is increasingly rational: they rooted a CMF Phone 1 they already owned and turned it into their home server.

Eight ARM cores. 8 GB of RAM. 128 GB of flash. Wi-Fi 6. A 5G modem. And a battery that behaves like a tiny UPS — all already paid for, all sitting in a drawer.

Today that phone runs a remote browser (Surf + Chrome), a personal finance tracker, a screen-sharing service, and several web apps — surviving reboots, deploying from Git, and staying reachable when it moves between networks. The VPS is gone.

Here’s the full architecture, the hard-won lessons, and the honest caveats.

The first bad idea: replacing Android

The cleanest-sounding path was flashing a real Linux distribution. The CMF Phone 1 has a postmarketOS port — and its device page has enough green boxes to make a reckless person optimistic.

The author was that person. What they missed: everything marked broken. Wi-Fi, Bluetooth, hardware acceleration — the things that make a phone useful as a server. The result was a splash screen, a black display, and neither a server nor a phone. Recovering stock Nothing OS required a QEMU Windows VM, MediaTek driver fights, and eventually a physical Windows machine.

Lesson learned: Android already has working drivers for every piece of this hardware — Wi-Fi, power management, battery, GPU, modem, every vendor quirk. Throwing that away for a conventional userspace was the wrong trade.

“I didn’t actually need the phone to become a normal Linux machine. I needed it to run Linux applications reliably while Android continued doing the hardware-specific work it is good at.”

Termux is the host operating system

The second attempt kept stock Android and made Termux the host environment. It provides OpenSSH, runit (service supervision), Caddy, Cloudflared, package management, and “normal enough Unix tooling.”

The architecture is two layers:

Termux isn’t a VM — its processes run against Android’s Linux kernel, but its Bionic-based userspace differs enough from Debian that existing Linux images can’t drop in. That split turned out to be a feature: Termux stays the small control plane while each application brings the filesystem it expects.

Services are supervised by runit. The recovery chain is what matters:

Android boots → Tailscale always-on VPN → Termux:Boot → runit → resident services → health checks

The phone can reboot without anyone noticing.

The second bad idea: PRoot

Most applications shipped as Linux ARM64 OCI images, and proot-distro made them run under Debian without modification. PRoot intercepts filesystem and process operations in userspace — no root, no special kernel. Ordinary web services ran fine.

The Surf browser workload was the exception. Starting processes, opening libraries, walking paths, reading profiles, shuffling capture data — everything crossed PRoot’s translation layer. There was CPU available; Chrome just couldn’t reach it efficiently.

The fix: root the phone — not to replace Android, but to mount the Debian filesystem properly and enter it with a real chroot. Same lifecycle (runit from Termux), same config, same data location — but native syscalls against Android’s kernel instead of PRoot’s ptrace overhead.

“The improvement was not subtle!”

A root helper creates a private mount namespace, binds required paths, chroots in, drops privileges, and starts the image entrypoint. Neither Docker nor a compiler needs to exist on the phone.

Infrastructure, not a pile of shell history

No pet server assembled from commands you’d forget in a week. The entire host is Ansible-managed state in one private repo:

release/OCI image → digest pinned in Git → Ansible over SSH → versioned files → atomic "current" symlink → runit service → health checks

• Releases pinned by digest/checksum, installed behind an atomic current symlink; failed checksum or health check stops the deploy; rollback = revert the pin.
• Secrets live encrypted in Ansible Vault. The vault password is derived by asking the workstation’s 1Password SSH agent to sign a fixed challenge — the private key never touches the phone. Runtime values are rendered into Termux’s private storage at deploy time.
• Disaster recovery is the real payoff: if the phone dies, another rootable ARM64 phone can be brought to the same state from Git — no shell history reconstruction.

Getting traffic to a phone behind home internet

No static IP, no inbound rules, and the phone should stay a phone — unplug it, take it somewhere else, and the server follows.

• Cloudflare Tunnel for HTTP apps: cloudflared makes one outbound connection; Cloudflare routes each hostname through it to Caddy on localhost. No router rules. The tunnel reconnects on any network.
• Tailscale for administration: stable private address, ssh cmf from anywhere on the tailnet.
• Surf’s special case: it’s latency-sensitive and pins TLS (old iPad client). At home: Cloudflare DDNS + one forwarded port. For roaming: the entire Surf TLS stream is wrapped inside an ordinary WebSocket — Cloudflare forwards the WebSocket while the authenticated connection stays encrypted end-to-end inside it.

The phone’s battery bridges the move. Public services don’t care which Wi-Fi is underneath them.

What actually runs on it

• Surf — the demanding workload: modern Chromium on old iPhones/iPads, streaming H.264 video/audio while receiving touch and keyboard input. Why the author cared about syscall overhead.
• Personal finance tracker — SQLite-backed, with automated off-device backups and a tested restore path.
• Screen sharing service + a handful of smaller web apps.
• Observability dashboard — a native service collecting CPU (all 8 cores), memory, storage, uptime, battery, thermals, and every runit resident, served as an embedded Vue UI reachable only over LAN/tailnet. Log view discovers service directories at runtime — adding a resident doesn’t require teaching the UI its name.

Should you do this?

The honest case for: if you have a reasonably modern, rootable ARM64 phone sitting unused, this is much less ridiculous than it sounds. Quiet hardware, low power, flash storage, Wi-Fi, a built-in display for recovery, a battery that behaves like a tiny UPS. Stock Android supports the hardware; Termux + rooted chroot runs a surprising amount of normal Linux software. When the alternative is paying indefinitely for a VPS that’s slow or annoyingly expensive, it’s a genuinely useful option — not just a stunt.

The honest caveats:

1. Automated off-device backups are non-negotiable. Never trust irreplaceable data to a single phone.
2. Rooting expands the trust boundary. Chroot is a compatibility environment, not hostile-workload isolation — residents share Android’s kernel, network stack, and system UIDs.
3. The mount trap. Community warning: deleting container files (rm -rf) while Android directories are still mounted can wipe the phone’s physical partitions. Unmount before cleanup.
4. No GPU acceleration. VirGL/Vulkan bridges produced corrupt pages and worse performance — software rendering won the day.
5. Android is still Android. It periodically wants to “optimize” your server, and a future update could create a new surprise.

Conclusion

“It is quiet, battery backed, fast enough, reachable from anywhere, reproducible from Git, and already sitting in my house. I started this trying to save money on a VPS. I ended up with a rooted phone running my personal infrastructure — and somehow that is much more satisfying.”

The phone-as-server pattern sits at the intersection of several 2026 trends: DRAM prices that make new hardware poorly timed, VPS costs that keep climbing, phones that are dramatically overprovisioned for their daily job, and tooling (Termux, proot-distro, Tailscale, Cloudflare Tunnel) mature enough to make it work.

The infrastructure lessons transfer beyond phones: native syscalls beat userspace translation, outbound-only tunnels beat port forwarding, and a Git-managed host beats a pet server every time. The phone is just the most satisfying place to apply them.