CMF Phone 1 as a Home Server: Termux Replaced a Hetzner VPS

The VPS did not get cheaper. The phone was already paid for.

On August 4, 2026, Berlin engineer seg6 published my server is a phone now — a personal-infra essay that hit Hacker News at about 175 points and 72 comments by August 9. The claim is specific, not a stunt headline: a Nothing CMF Phone 1 rooted and hosted under Termux replaced a cheap Hetzner VPS that ran web apps, Caddy, and a remote browser called Surf. Shared CPU starved Chrome. Dedicated CPU felt ridiculous for a personal browser. DRAM prices made buying another box look timed for masochists. The phone already had 8 ARM cores, 8 GB RAM, 128 GB flash, Wi-Fi 6, 5G, and a battery UPS.

This is explainx.ai’s read of the live essay plus the HN thread — what actually runs, which two “clean” ideas failed, and whether you should copy it instead of the levelsio Hetzner + Tailscale + Cloudflare pattern most of this audience already knows. Follow recaps like this on explainx.ai and @explainx_ai.

TL;DR — what people are asking

Why replace a Hetzner VPS with a phone?

The starting stack was ordinary personal infra: a few web apps, Surf, Caddy, “the usual supporting cast.” Nothing production-SLA. The pain was Chrome. Cheap shared Hetzner machines were fine until the browser had real work. Then they felt starved. Dedicated-CPU SKUs fix that and also make a personal remote browser look like a monthly subscription you resent.

Buying another machine was the obvious escape hatch — until memory. seg6’s line is the one HN quoted: DRAM prices have gone completely stupid. That is not vibes. Stanford’s MemoryDAX charts and the mobile DRAM surge are the same 2026 story from two altitudes: HBM ate fab capacity, consumer DIMMs and phone LPDDR both got ugly, and assembling a “comfortable” new mini PC stopped being the default homelab move.

Used mini PCs and “turn the desktop on when I am not using it” both got a look. Then the CMF Phone 1 already sitting in a drawer won on a brutal spreadsheet: hardware paid for, eight cores, eight gigs, flash, modern radios, and a battery that behaves like a tiny UPS when you unplug it and walk.

Compare that to the other 2026 VPS religion on this site. levelsio’s year of Claude Code on Hetzner still makes sense when the box is a dev/prod agent host. Claude Code on the web + Railway makes sense when GitHub is already the deploy trigger and you do not want a pet at all. seg6’s case is narrower: a handful of personal services, one of which is a latency-sensitive remote Chrome, on hardware that was already sunk cost.

What actually runs on the CMF Phone 1 now?

Two layers, one kernel.

Today the phone runs Surf and its managed Chrome, a personal finance tracker (SQLite, automated off-device backups, tested restore), a screen-sharing service, and smaller web apps. They survive reboot, deploy from Git (from the workstation — there is no Git checkout on the phone), and stay reachable when the phone moves networks.

Surf is why the project exists at the quality bar it does. It brings modern Chromium to old iPhones and iPads: the phone runs a recent arm64 desktop Chrome plus the Surf backend inside Debian; an original iPad mini gets H.264 video and audio and sends touch, keyboard, tabs, and navigation back. That is a 2012 client talking to 2026 Chrome. PRoot’s extra syscall tax showed up immediately. A static blog would not have forced the root.

If your “personal infra” is closer to self-hosted photos than to a remote desktop browser, pause. Immich wants disks, transcode headroom, and a real backup story. A 128 GB phone is the wrong shape. seg6’s finance DB is small and explicitly backed up off-device. That constraint is load-bearing.

Why not flash postmarketOS and get a “real” Linux box?

That was bad idea one, and it is the section people should read before they buy a used CMF “because the wiki has green boxes.”

The CMF Phone 1 has a postmarketOS device port. It boots. The page looks optimistic if you ignore the red. Wi-Fi, Bluetooth, hardware acceleration, and most of the other things that make a phone useful as a small server were already marked broken. seg6 got the splash screen and a black display. Neither a server nor a phone.

Recovering stock Nothing OS became its own side quest: the flashing utility wanted Windows, so Windows went into QEMU, USB passthrough and MediaTek drivers fought back, the tool hung, and the process eventually moved to a real Windows install and factory images. Mid-recovery the phone was soft-bricked — black screen, paperweight energy.

Lesson, in the essay’s own framing: Android already has working drivers for Wi-Fi, power, battery, GPU, modem, and every vendor weirdness. Throwing that away for a conventional userspace was the wrong trade. The need was not “make the phone a normal Linux machine.” The need was run Linux applications reliably while Android keeps doing hardware.

That is also why this is not a GrapheneOS story. GrapheneOS duress-PIN legal risk is about a hardened Pixel as a phone. Here the device is a server that still boots Android so the radios stay alive. Different trust model, same reminder: once you unlock and root, you expanded the boundary on purpose.

Is Termux enough to be the host OS?

Second attempt: stock Android, Termux as the host control plane.

Termux is not a VM. Processes hit Android’s Linux kernel; the Bionic userspace is not Debian. That split turned out useful. Termux stays small and boring. Each app brings the Linux filesystem it expects.

What Termux actually provides here:

• OpenSSH
• runit (not systemd)
• Caddy and Cloudflared
• package management and “normal enough” Unix tooling
• Termux:Boot to start the supervisor and SSH after reboot
• Tailscale for a stable private address — from any tailnet machine: ssh cmf

Android’s battery management is excellent at being a phone and hostile at being a server. The Ansible Android host profile therefore:

1. Installs a persistent wake lock
2. Disables light and deep idle
3. Exempts Termux, Termux:Boot, and Tailscale from background restrictions
4. Disables the child process limiter
5. Prevents Wi-Fi suspend
6. Sets Tailscale as the always-on VPN

The recovery chain matters more than any one toggle:

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

After a reboot, the phone comes back without waiting for a human to notice. There is no systemd and no Docker daemon. Pretending otherwise is how you get angry at the hardware.

If your mental model of “phone + Termux” is Claude Code remote control or pocketdev / Cursor iOS / OpenClaw, invert it. Those posts treat the phone as a client that SSHs into a real box. This essay treats the phone as the box. Same apps (Termux, Tailscale, wake locks). Opposite gravity.

Do you need root, or is PRoot fine?

Bad idea two: proot-distro for ARM64 OCI images.

Most of the apps already shipped as Linux ARM64 images. PRoot intercepts filesystem and process ops in userspace so a regular Termux process believes it lives inside Debian. It is not a container. Everything still shares Android’s kernel, network namespace, and Termux UID. As a compatibility layer it is excellent: no root, no special kernel.

Ordinary web services ran fine this way. Each app got a verified root filesystem, a loopback port, and a runit unit. Caddy in Termux routed hostnames to those ports.

Surf/Chrome did not. Starting processes, opening libraries, walking paths, reading browser profiles, and shuffling capture data all crossed PRoot’s userspace translation. CPU was available. Chrome could not reach it efficiently. So the phone got rooted — not to replace Android, but to mount the same Debian filesystem properly and enter it with a real chroot.

The improvement was “not subtle.” Once that path worked, leaving smaller residents under PRoot stopped making sense. They now share the same mechanism:

1. Workstation pins each ARM64 image to an exact digest and exports the filesystem
2. Ansible verifies and installs it on the phone
3. A small root helper creates a private mount namespace, binds required paths, chroots, drops privileges, and starts the original image entrypoint

Neither Docker nor a compiler needs to exist on the phone. These are compatibility environments, not security boundaries. Private mount namespaces mainly keep mounts and cleanup predictable.

Graphics side quest, briefly: bridging Debian’s stack to the Mali GPU via VirGL and Android Vulkan produced hardware-compositing checkmarks, corrupt pages, and worse performance. Software render was faster. Do not spend a weekend chasing GPU passthrough for this class of workload.

HN was blunt about the gate: bootloader unlock is required for this quality of setup. Termux without root is slow. You cannot bind low ports without root. Plenty of Android phones will never unlock without an exploit — the community “wall of shame” lists exist for a reason. If your drawer phone is carrier-locked silicon, this essay is a museum piece, not a shopping list.

How do you keep it from becoming a pile of shell history?

By the time everything ran, the risk was a pet. The whole host moved into Ansible-managed state: versions, service definitions, routes, power settings, secrets, and health checks in one private repository.

Deploy flow:

release or OCI image
  -> checksum/digest pinned in Git
  -> Ansible over SSH
  -> versioned files on the phone
  -> atomic current symlink
  -> runit service
  -> local health check
  -> public edge check

Releases land in versioned directories behind an atomic current symlink. Failed checksum or health check stops the deploy. Rollback is revert the pin and apply again. App data lives separate from releases.

Manual bootstrap is small: install the three Android apps, root the phone, grant Termux superuser, authorize SSH. After that, from the workstation:

make phone
make phone-status
make phone-edge-check

Re-applying does not replace unchanged runtime files or restart healthy residents. If this phone dies, another rootable ARM64 phone can be brought toward the same state without reconstructing shell history.

Secrets: there is no Git checkout on the phone. Ansible Vault values live encrypted in the infra repo. The vault password is derived by asking a 1Password SSH agent to sign a fixed challenge, so the private key stays in 1Password and the phone never needs it. Ansible renders only the runtime values each service needs into Termux private storage.

That is closer to how serious homelabs age than to a Termux screenshot thread. It is also why copying the idea without copying the repo will feel like a weekend and then a year of rot.

How does traffic reach a phone that moves networks?

Home internet is not a VPS. No static server setup, and no appetite for exposing SSH or a pile of app ports on the router. The phone also had to remain a phone in one sense: unplug it, take it somewhere, connect to whatever network, still have the server.

HTTP apps: Cloudflare Tunnel. Cloudflared makes one outbound connection. Cloudflare sends each hostname through it. Caddy on 127.0.0.1 routes to the loopback service.

Internet
  -> Cloudflare Tunnel
  -> Caddy on 127.0.0.1
  -> application on 127.0.0.1

No inbound router rule for those services. Move networks, tunnel reconnects, hostnames follow. Tailscale does the same for admin. The battery bridges the move.

Surf is different. The direct connection is latency-sensitive, terminates its own TLS, and the old iPad pins the server identity. At home: Cloudflare DDNS (DNS-only) at the current public address, router forwards one port to Surf, and on LAN the iPad talks to the phone directly.

Roaming breaks the usual tunnel model: a normal Cloudflare Tunnel terminates TLS at Cloudflare, which is exactly what a pinned Surf client does not want. The fix wraps the complete Surf TLS stream inside a WebSocket. Cloudflare sees and forwards the WebSocket. The authenticated Surf connection stays encrypted end to end inside it. Cost: about one extra network RTT. First iPad test from outside home: around 60 ms. Works through outbound-only connectivity, on an OS from 2012, without installing Tailscale on the iPad.

The office punchline is the one that sold HN: phone plugged in at home, engineer at the office, SSH via Tailscale from a MacBook into workstation and phone, old iPad using phone-hosted Surf. The VPS was no longer in the loop. If that sentence sounds like levelsio SSHing from iPhone via Termius, it is the same muscle — except the remote end is a handset, not a Hetzner VM.

How do you observe a weird server?

SSH, runit, logs, public routes, and Android queries still work. They are no longer required for a glance.

A native service collects all 8 cores, memory, storage, uptime, battery, thermals, local and public reachability, and every discovered runit resident. Bounded history. Embedded Vue UI at https://dash.cmf, reachable only on LAN or tailnet. The log view discovers service directories at runtime, so a new resident does not need a UI name hardcoded.

That dashboard is the tell that this stopped being a party trick. Pets get htop when you remember. Cattle-shaped pets get a board you open from the couch.

What people are asking on Hacker News

The thread (item 49226636, ~175 points / 72 comments as of August 9, 2026) is more useful than another architecture diagram. These are the arguments people actually had.

Is 24/7 plug-in a battery fire hazard?

Top-of-thread energy. Recommendation in the wild is often “pull the battery if a phone or laptop is a server.” CMF Phone 1 has no bypass charging, so seg6 limited charge to 80%. Commenters: LiPo fails over time if left fully charged; if you do not need the pack, keep it near ~40%; 80% is “usually good enough” when it is the only knob. Many phones will not boot without a battery, and some shut down when they think they have drawn more than nameplate capacity even if voltage is still high. Ammo-can storage jokes showed up immediately; so did the counter: a running phone makes heat, a sealed can is a different thermal story than a cold drone pack. Lithium fires laugh at many extinguishers. Metal box on a non-flammable surface is the serious version of the meme. This is not settled science in one HN thread — it is a risk you own.

Do you need an unlocked bootloader?

Yes, for this quality of setup. Termux on locked, unrooted Android is a different product: slower, no real chroot, cannot bind ports below 1024, and often a Cloudflare Tunnel proxy papering over the bind problem. postmarketOS also wants unlock. A large set of shipping phones will not unlock without an exploit. Check before you “just use the old Samsung.” Someone in-thread claimed a kube node on an old Samsung via postmarketOS rebuilds; someone else noted newer Samsungs are on the unlock wall of shame. Your drawer is not a homogeneous fleet.

Why not an old quiet desktop, used Xeon, NUC, or fanless AliExpress router?

Because most people already have one of those, or can buy one used cheaper than a new phone. Idle watts: modern small Dells cited around ~10 W; a Mac mini anecdote under 5 W; a NUC 9 extreme with a 10GbE card at 69 W. Quiet Xeon workstations with ECC still dump on the used market. Fanless AliExpress “router” boxes with a real SSD and 32 GB RAM can be OPNsense plus VMs on the machine that was going to run 24/7 anyway. Phones win on silence, size, spare hardware you already own, and battery UPS. They lose on NVMe endurance, Docker/KVM, RAM upgrade paths, and “I already have a tower between the vacuum and the cat food.” Factor noise and idle power, not just capability per dollar.

Will eMMC/UFS die under SQLite?

Reasonable fear. Phone flash is not a datacenter SSD. seg6’s finance tracker is exactly the scary workload — state you care about on onboard flash — which is why automated off-device backups and a tested restore are in the essay, not a footnote. HN’s calmer take: a database is still “writes to a file”; it is not automatically more murderous than logging. Still: backups required. An SD card for write-heavy paths is a swap-when-it-dies tactic, not a substitute for off-device copies. Flash wear is on seg6’s own honest list.

Why is the title “my server is a phone now” and not “my phone is a server now”?

Half the thread. Alternate title implies you repurposed a phone. Actual title, per seg6, is from the server’s point of view: VPS before, phone now. Other readers heard VoIP, or a server turned into a telephone. The essay clears it in a paragraph. The provocative word order did its CTR job.

Is Surf just Camoufox?

No. A commenter said they run 10× Camoufox on an $8 VPS. seg6: Camoufox has no iOS 6 client. Surf is built around that client — omnibox, tabs, history, uploads/downloads, touch, audio/video targeting 60 fps. Camoufox is an anti-detect agent browser. Different job. Do not collapse “remote Chrome” into “bot browser farm” when you cite this piece.

Should you do this?

seg6’s own closer is the right one. If you already have a reasonably modern, rootable ARM64 phone sitting unused, this is less ridiculous than it sounds: quiet hardware, low power, flash, Wi-Fi, a built-in display for recovery, a battery UPS. Stock Android already supports the silicon. Termux plus a rooted chroot runs a surprising amount of normal Linux software.

Do not put irreplaceable data on it without automated off-device backups. Do not treat chroots as hostile-workload isolation. Rooting expands the trust boundary. Android remains an unusual server host. A future Android update can break the host profile. Software-rendered desktop Chrome will not beat a workstation GPU. Flash wear is real. It is still a weird server sharing one kernel, and Android will occasionally try to “optimize” it to death.

For a handful of personal services — especially versus paying forever for a VPS that is either slow or annoying — it is a useful option, not only a stunt. That is the honest ceiling. explainx.ai’s read: copy the recovery chain, digest pins, and backup discipline even if you stay on Hetzner. Copy the phone only if the hardware is already sunk and you like this kind of weird.

Summary

August 4–9, 2026: seg6 replaced a cheap Hetzner VPS with a rooted CMF Phone 1. postmarketOS soft-bricked the device; PRoot was too slow for Surf/Chrome; Termux + runit + Ansible + Cloudflare Tunnel + Tailscale is the host that stuck. Ingress follows the phone. Secrets never live in a Git checkout on the handset. HN’s useful objections are battery fire, bootloader unlock, used x86, flash endurance, the title POV, and Surf ≠ Camoufox.

Official essay: seg6.space/posts/phone-server. Discussion: news.ycombinator.com/item?id=49226636.

Related reading

• Claude Code on VPS only — levelsio production workflow — the Hetzner + Tailscale + Cloudflare baseline this phone inverts
• Claude Code VPS + SSH from iOS / MacinCloud — phone as client into a real VPS
• You don’t need a VPS to publish — Railway + Claude Code web — skip owning a box when Git is already the deploy trigger
• Stanford MemoryDAX — 65 years of DRAM, HBM, NAND prices — why “buy another machine” felt ill-timed
• Mobile DRAM price surge — AI squeeze on smartphones — the same memory super-cycle from the phone BOM side
• Run AI coding agents from your phone — pocketdev, Cursor, OpenClaw — Termux/Tailscale as a remote, not as the server
• Control Claude Code from your phone — native remote, Orca, mosh, tmux
• Self-host photos — Immich 3.0 cost and privacy — when a 128 GB phone is the wrong self-host shape

Official / primary: my server is a phone now — seg6 · HN thread · Cloudflare Tunnel docs · Termux:Boot

Essay facts reflect seg6.space/posts/phone-server as fetched August 9, 2026 (story dated August 4, 2026). HN score ~175 points / ~72 comments on item 49226636 the same day — counts move. Android OEM updates, Termux packages, Cloudflare Tunnel behavior, CMF Phone 1 charge firmware, and flash wear characteristics can change; verify unlock support, backups, and fire-safety before copying a 24/7 plugged-in phone. Published August 9, 2026 on explainx.ai.