In Hacker News’s hot list this week, a post with an disarming title — «My server is a phone now» — hovered. The author moved his home services from a desktop machine to a budget smartphone CMF Phone 1 and detailed what came of it. The note is interesting not for novelty (many have tried running something in Termux) but because it is a rare case where the person honestly lists the forks at which he had to choose, and the price of each choice.
Let’s analyze the case by forks — because if you copy it, you’ll run into exactly these five.
What hardware is this. CMF Phone 1 — a Nothing budget phone with a MediaTek Dimensity 7300: eight ARM cores, 8 GB RAM, 128 GB flash, Wi-Fi 6, 5G modem. By specs it’s roughly the level of a typical entry-level mini PC, only with a display, battery, and modem included — and priced around a used Raspberry Pi 5 with peripherals.
Fork 1. Wipe Android or keep it
An instinctive choice for a self-hoster is to install a proper Linux. The author tried exactly that: postmarketOS. Outcome — loss of Wi‑Fi, Bluetooth and graphics acceleration, and on the first firmware attempt a “soft brick” that had to be recovered with the vendor’s Windows utility.
The reason is simple and not specific to this model. Mobile SoCs run on vendor binary drivers and a fork of the kernel that the manufacturer won’t release. Mainline kernel for postmarketOS on many devices can do exactly what enthusiasts port manually, and Wi‑Fi with the modem usually ends up at the bottom of that list.
Before buying a phone “for a server”, find your exact model in the postmarketOS device list and see what’s marked as working. The spread is huge: on some devices almost everything works, on others Wi‑Fi won’t even come up. Planning a project around “they’ll probably port it” is a sure way to end up with an expensive paperweight.
The author’s final choice: stay on the stock Android firmware and build everything on top of it. Drivers work, the modem works, the battery charges correctly — and the Linux environment lives inside.
Fork 2. PRoot or chroot
Classic Termux runs distributions through PRoot — an emulation of chroot in user space, without root privileges: PRoot intercepts system calls via ptrace and rewrites paths. It works anywhere, but you pay CPU and latency for every system call interception.
The author rooted the device and switched to a real chroot with a Debian filesystem. The original wording is a not subtle growth; it’s about running Chromium under a remote browser, i.e., a workload with a lot of system calls. He doesn’t provide numeric measurements, so treat it as a qualitative observation, not a benchmark.
Practical takeaway for those who replicate: if you put something long-running and lightweight on the phone (bot, metrics collector, RSS reader, git mirror) — PRoot will do, and rooting the phone isn’t necessary. If the workload is sensitive to latency and heavily uses system calls (browser, transcoding, DB under requests) — either root with chroot, or don’t bother.
Fork 3. How to get inside at all
The phone in mobile networks does not have a public IP — it’s behind CGNAT, and port forwarding to it is basically impossible. Even on a home Wi‑Fi, the address is usually private. The author chose three different tools for three different tasks:
- Cloudflare Tunnel — for HTTP services that must be publicly accessible via a normal domain;
- Tailscale in always-on VPN mode — for administration, i.e., SSH and anything that shouldn’t be public;
- DDNS — for the backend of a remote browser where a direct stream is needed, not HTTP.
A separate interesting trick from the post: the TLS stream of the remote browser had to be wrapped in WebSocket, because Cloudflare Tunnel doesn’t pass arbitrary TCP. This is a typical headache for anyone trying to push non-HTTP through an HTTP tunnel, and it’s a solution to remember.
The scheme “Tailscale for management + tunnel for publication” is a good default for any home server, not just a phone one. The admin panel should not be exposed to the Internet; only what truly needs to be public should be exposed. On the forum this logic is discussed in more detail in the home server roadmap.
Fork 4. How not to let Android kill your processes
This is the place where nine out of ten attempts fail. Android aggressively suspends background processes and puts the device to sleep — for a phone this is a feature, for a server it’s a disaster. The set of measures the author applied is fairly standard:
- Termux:Boot — a separate add-on to Termux that runs scripts from
~/.termux/boot/at device startup (the startup files run in sorted order). A key detail from the documentation: you must launch the app once manually after installation, otherwise auto-start permission won’t activate. termux-wake-lock— the first command in the startup script, keeping the device from sleeping. The official docs recommend this exact approach.- Disable battery optimization for Termux in system settings.
- runit as a supervisor inside the environment — so a crashed service would come back up.
The startup chain ends up like this: Android boot → always-on VPN → Termux:Boot → runit → services in chroot.
What you definitely should not do — count on stock Android to keep all this running for months without supervision. A firmware OTA, vendor skin optimizations, or a reboot after a discharge — each can quietly stop your “server,” and you’ll learn about it from dropped monitoring rather than immediately. External liveliness checks (uptime monitoring from another node) are not a luxury here, but a must.
Diagram: how auto-start is arranged and where it breaks. Author’s own illustration
Fork 5. Battery — a UPS or a bomb
The pretty part of the idea: the built-in battery acts as a small UPS. The author explicitly notes that the phone survives moving between networks and brief power outages because it has its own battery. For a home server in an apartment with unstable power this is a strong argument — a separate UPS for a mini PC costs more than the phone itself.
The flip side to think about in advance: a lithium-polymer battery, years old, sitting at 100% charge under constant load and in heat, degrades and can swell. Industrial solutions for “phone as a server” usually assume either limiting charge via firmware (some models and skins cap at 80–85%) or physically removing the battery. If your device can’t do that, budget for a planned battery replacement as part of total cost of ownership and don’t place the phone in a closed cabinet.
A screenshot of the author’s own dashboard — seg6.space
What to place on this server, and what not to
The author’s case is services with either zero load or bursts: remote browser, personal finance tracker on SQLite, screen sharing, several small web apps, an observability dashboard, Caddy acting as a router. This is the right class of tasks.
A bad class is anything that relies on constant writes and reliable storage. Smartphone flash memory (UFS/eMMC) is not designed for the workload profile of a DB server; SMART in the usual sense isn’t available; no ECC memory; and hot-swapping a disk is physically impossible. Treat the phone as a disposable node: everything valuable should be backed up to an external system, and restoration should be tested, not assumed to work.
The author didn’t measure power consumption. A reasonable expectation: a phone SoC idle draws a few watts, versus tens of watts for a mini PC, but you should verify with a wattmeter, not with marketing claims.
The main value of this case study is not that “a phone can be a server”—perhaps there are no questions there. It is that an old smartphone in a drawer is a ready ARM computer with autonomous power, two radio modules, and a backup communication channel via the cellular network. As the main node it is dubious. As a second, independent node—for monitoring that must survive the main server’s outage, for emergency access to the home network, for DNS—it’s surprisingly good, because it doesn’t depend on your router or your provider.
Sources
- seg6.space — My server is a phone now — original source, case under analysis
- Discussion on Hacker News — context and critique in the comments
- termux/termux-boot — official documentation on autostart and
termux-wake-lock - postmarketOS — project and list of supported devices
- Related forum topics: Home server: roadmap, Homelab stack 2026
Does anyone actually run an old smartphone as an infrastructure node in their household — and what did you attach to it? Especially interested in those who reached postmarketOS: which model and what ends up not working on it?