On most phones PhoneRig installs a full Ubuntu system, without root and without a computer. You get a root shell inside the guest, apt, SSH from your laptop, a web server, and public HTTPS through an outbound tunnel. The phone you stopped using is a small always-on server with a battery already attached.
Get PhoneRig on Google PlayNo root needed · Android 8+ · 64-bit (arm64) · 3 GB of RAM or more
The app presets install into the guest, get connected to the web server and the tunnel, and hand you the login in the app. No compose file, no reverse-proxy config, no certificate chore.
Your own private Git server: repositories, issues, pull requests and a web UI, hosted on hardware you can put your hand on.
VS Code in the browser, running on the phone. Open a tab on any laptop and you are editing files on the server itself.
Device-to-device folder sync. The phone becomes the always-on node that the laptop and the desktop both sync against.
The complete stack, PHP and database included, at your own HTTPS address. How WordPress on a phone works.
Reach the guest from a laptop on your Wi-Fi or over the internet, use the built-in web terminal, or attach VS Code with one-tap Remote-SSH. The shell is not a preset, it is the baseline.
One preset owns the phone's web root at a time, so they are deliberately exclusive and switch cleanly in place. Presets are part of the App Presets unlock, $14.99 one time, and are included in PhoneRig Pro at $17.99 one time. The server itself, the free subdomain, the site builder, photo albums, SSH and the web terminal are free.
The presets are shortcuts, not the boundary. Inside the guest, on a phone running the Linux engine, you have a root shell on an ordinary arm64 Ubuntu system, so most of what you would put on a small VPS installs the same way it does anywhere else.
| What you want to run | How it runs on a PhoneRig |
|---|---|
| Node, Python, PHP, Go | Install the runtime from apt and run your app on a local port, the same commands you would use on a VPS. |
| A small web app or API | Point the built-in Caddy at your app's port and it is public over HTTPS through the tunnel. Leave Caddy alone and the app stays reachable only on your LAN or over SSH. |
| A webhook receiver | A public HTTPS address is exactly what webhooks need, and the tunnel gives you one without a router, a static IP or a port to forward. |
| Telegram or Discord bots | Bots connect outward, and outbound networking always works, so a bot needs no address of its own and runs happily on a phone. |
| Scheduled scripts | Backups, scrapers, feed pollers, home nudges: write the script, start it from the shell, and let the phone be the machine that is always on. |
| Hugo, Jekyll and friends | Static site generators build on the device, and the web server publishes the output directly. No build machine in the loop. |
| Classic PHP self-host apps | PHP-FPM installs from apt and sits behind the same web server the WordPress preset uses, which is what a DokuWiki wiki or a FreshRSS reader wants. |
| Databases | SQLite is the sweet spot on a phone: one file, no daemon, nothing to babysit. PostgreSQL and MariaDB install from apt, but you start them yourself (see the constraints below). |
How public access works. Caddy owns the phone's web root and is the one process holding the tunnel's traffic. To publish something you wrote, point Caddy at its port with a Caddyfile edit and it appears at your address over HTTPS. To keep it private, do nothing: an app listening on a local port is reachable from your own network and through SSH, and from nowhere else.
The guest is an unprivileged userspace on an Android kernel. That is what makes root unnecessary, and it is also where the limits come from. None of these are bugs waiting to be fixed.
Containers need kernel features and privileges an unprivileged userspace does not have, and you cannot load kernel modules. Install software from apt instead, which covers most of what people reach for a container image to get.
There is no init system in the guest, so an apt-installed service will not come back by itself. PhoneRig manages its own services; anything extra you start from the shell is yours to start again.
Privileged ports are out of reach. In practice it rarely matters, because the tunnel terminates 443 for you and your app can listen on any high port it likes.
A real VPN needs privileges the guest does not have, so PhoneRig cannot host one. For browsing through your home connection while abroad there is the travel proxy, which is a convenience feature, not an anonymity tool.
Where a phone's system blocks the Linux engine, PhoneRig still runs a server, but there is no Ubuntu userland and so nothing on this page's apt list applies. That limit is the phone's rather than PhoneRig's, which is what makes it different from the rest of this section. Which engine your phone gets.
x86 binaries will not run, and the floor is 3 GB of RAM or more. Storage and CPU are a phone's, which is plenty for personal and small-business workloads and nothing like a datacenter.
The server runs as an Android foreground service and keeps serving with the screen off. An app update does restart it: your server and its data are kept, and the server comes back when you next open the app. Still: leave it on a charger, and let the app's battery-care guidance keep the vendor's power saver out of the way.
The storage is soldered in and has a finite number of writes in it, and small random writes spend them fastest. PhoneRig cuts the writes it controls and is direct about which jobs do not belong on a phone: the whole storage story is below.
Two things that make an always-on phone easier to trust: automatic weekly backups covering the guest's /root, which is where your site and app data live, and notifications when the server drops offline and again when it recovers.
A phone's storage is soldered in place and flash memory wears out as it is written to, so "how much does this thing write?" is a fair question to ask before leaving a server running for years. The honest answer has three parts: why the worry is legitimate, what the app actually does about it, and which workloads you should keep off a phone entirely.
What stays true no matter what we do. Flash endurance is finite. Small random writes cost more of it than large sequential ones: a log line appended here, a database commit there, a filesystem metadata update behind both. An older budget phone with eMMC has materially less headroom than a recent flagship with UFS, and a used phone has already spent some of what it had. You also cannot really watch it happen. There is no SMART data on a phone. The UFS and eMMC chips do keep a coarse lifetime estimate in 10 percent steps, but Android walls it off: on our own test device the health descriptor exists in sysfs, is marked world-readable, and is still refused by SELinux to every app and even to the adb shell. So no app can honestly show you a wear gauge, this one included, and any that claims to is either rooted or guessing. What you can measure is your own write volume, which is the number that actually drives wear.
Caddy streams each access line over a local socket straight to the app, which counts in memory and persists only small per-day totals, on a throttled schedule. The raw request lines, and the visitor IP addresses they carry, are never written to storage at all. That is a privacy property and a write-reduction property in the same move.
The WordPress preset configures its SQLite database in WAL journal mode with synchronous=NORMAL. That replaces the default fsync on every commit with batched, mostly sequential writes. It is verified working on a real device, not a setting we assume behaves.
The classic quiet killer on a low-RAM VPS or a Pi is a swap file thrashing the disk for months. The guest is unprivileged, so creating swap is not possible, and Android's own memory relief is zram, which is compressed RAM rather than a file on flash. One classic wear path is simply absent here. That is one path closed, not a clean bill of health.
A web server is read-heavy in steady state. WordPress on SQLite writes when you publish a post or someone leaves a comment, not when a visitor loads a page. Traffic on its own is not what wears storage down. Churn is.
The big writers are handled, which is not the same as nothing writing. PHP-FPM keeps its own logs and PHP writes session files, and neither of those is tuned. Something is always writing on a running system; the point is to keep the constant, avoidable writes out of the way rather than to claim there are none.
What does not belong on a phone's internal storage. A busy Gitea taking large, frequent pushes. Syncthing pointed at a folder that changes all day. Any hot, write-heavy database. Verbose debug logging you switched on yourself and then left on. The rule of thumb is short: if the data churns all day, the phone is the wrong home for that data. Run those on hardware with replaceable storage and keep the phone for the read-heavy work it is good at.
Measure your own workload instead of guessing. Two counters are worth knowing, and Android treats them differently. Per service, from inside the guest: /proc/<pid>/io reports write_bytes for any process your server started, so you can attribute writes to Caddy, to PHP-FPM, or to whatever you installed yourself. Device-wide, the total lives in /proc/diskstats, which Android restricts to the adb shell, so that reading has to be taken from a computer rather than from the guest: with USB debugging on, run adb shell cat /proc/diskstats, find the row for the phone's storage, and read the seventh number after the device name, which counts 512-byte sectors written. Read it again a few days later, subtract, and multiply by 512 for bytes. Both counters reset when the phone reboots, so take your readings inside a single uptime window.
And if storage does give out. Automatic weekly backups cover the guest's /root, which is where the site and app data live, and a backup restores onto a different phone. That is the recovery plan for a worn phone and for a dropped one alike.
Planned, not shipped. On the roadmap: using a memory card as server storage, so churny data can live on a cheap replaceable card instead of the soldered internal flash. It is a design on paper today and is not in the app yet, so do not plan around it.
Yes, on a phone that can run PhoneRig's Linux engine. It installs a full Ubuntu system for arm64 in an unprivileged runtime, so the phone stays unrooted and nothing about Android is modified, and inside the guest you have a root shell where apt works normally. Some newer phones block that engine; they still run a server, but without the Ubuntu userland and so without apt.
No. Containers need kernel privileges and module loading that an unprivileged userspace cannot have. On a phone running the Linux engine, software installs natively from apt instead: Node, Python, PHP, Go, SQLite, PostgreSQL, MariaDB and the rest of the Ubuntu archive, which covers most of what people pull a container image for. The web server, Caddy, is already there.
Yes, on a phone running PhoneRig's Linux engine. Gitea installs in one tap, with repositories, issues, pull requests and a web UI, wired to the web server and the tunnel so you can reach it from your LAN or over HTTPS at your own address. Gitea needs that engine, so it is not offered on phones whose system blocks it.
Two ways, both on a phone running PhoneRig's Linux engine. code-server installs in one tap and gives you VS Code in any browser, running on the phone. Or attach desktop VS Code over SSH with one-tap Remote-SSH and edit the phone's files from your laptop. Both need that engine; VS Code's remote server needs glibc, which the direct-on-Android engine does not provide.
Yes, on a phone running PhoneRig's Linux engine. Install the runtime from apt, run your app on a local port, and either point the built-in Caddy web server at it for public HTTPS through the tunnel, or leave it reachable only on your own network. Remember there is no systemd, so you start the process yourself.
Yes. Syncthing installs in one tap and keeps folders in sync between the phone and your other devices, and photo albums share files through a link and a passcode. The storage is the phone's, so there is no monthly bill and no per-gigabyte tier.
Serving pages is mostly reading, so traffic on its own is not what wears storage down; constant writing is. PhoneRig removes the biggest constant writers it controls: the visitor counter keeps no access log on disk, and the WordPress preset runs SQLite in WAL mode with synchronous=NORMAL instead of an fsync on every commit. There is also no swap file, because an unprivileged guest cannot create one. What stays true is that phone flash is soldered in, finite, and worn faster by small random writes, and an older phone has already spent part of its headroom. So keep genuinely write-heavy jobs off it: a busy Gitea, Syncthing on a folder that changes all day, a hot database, verbose debug logging. You can measure the real figure rather than guess at it: /proc/<pid>/io gives write_bytes per service inside the guest, and adb shell cat /proc/diskstats gives the device-wide total from a computer. Weekly backups cover the guest's /root and restore onto a different phone. The longer version is here.
No Docker or containers, no systemd (so apt-installed services do not autostart), no binding to ports below 1024, and no hosting a VPN server. It is arm64 only, needs 3 GB of RAM or more, and is sized for personal and small-business workloads rather than datacenter ones.
Install PhoneRig, let the guided setup build the Ubuntu guest, and SSH into your own machine before the kettle boils.
Get PhoneRig on Google Play