# Podroid: Rootless Alpine Linux VMs and Containers on Android

> Podroid boots a real Alpine Linux VM on an arm64 Android phone without root, pre-installing Podman, Docker and LXC. Here is how the QEMU and AVF backends differ, what the build script expects, and where the approach breaks down.

**ExTV/Podroid** — A rootless Android app that boots Alpine Linux: run containers (Podman/Docker/LXC) and GUI desktop apps.

- Repository: https://github.com/ExTV/Podroid
- Website: https://extv.github.io/Podroid/
- Stars: 2,962 · Forks: 193
- Language: Kotlin
- License: GPL-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/extv-podroid

## The problem Podroid solves: containers without a rooted phone

Most ways to get a Linux userland onto Android either need root or fake the kernel. A chroot or proot setup shares the host kernel, so anything that touches namespaces, cgroups, iptables or bridge networking tends to fail or need workarounds. Podroid takes the other route: the README describes it as "a real Alpine Linux VM with its own kernel - not a chroot or proot trick", which is why it can promise that "Podman, Docker and LXC behave exactly like they do on a server". That distinction is the whole product. Container runtimes assume a kernel they control, and a guest kernel gives them one.

The audience follows from that. Someone who wants to test a Dockerfile, run a small service, or use a Linux toolchain from a phone is the target. Someone who wants a normal Android app that happens to ship a shell is not. The README also lists USB passthrough, SSH, port forwarding and a guest-to-Android bridge, which points at people treating the phone as a small always-on Linux host rather than as a terminal client.

## Two backends, one guest: QEMU and hardware-accelerated AVF

The README states the VM runs "Alpine Linux on a custom kernel via QEMU, or hardware-accelerated AVF on supported pKVM devices". Those are not the same trade-off. QEMU emulates the machine, so it works on a wider set of arm64 devices but pays for that in CPU overhead. AVF uses the Android Virtualization Framework on devices whose pKVM support allows it, which the README frames as hardware-accelerated. Which one you get is a property of your hardware, not a setting you can freely pick, and the repository does not claim otherwise.

The kernel is built, not borrowed. The Dockerfile starts from debian:bookworm, downloads a Linux tarball with KERNEL_VERSION defaulting to 7.1.5, and copies podroid_kernel.config into the build. A comment in that file explains a design decision worth noting: a fragment of options that "netavark + podman need" is forced to =y "so there's no modprobe round-trip", because "modules caused silent failures in the past". In other words, the networking pieces Podman depends on are compiled into the kernel rather than loaded later. That is a deliberate trade of image size for predictability, and it tells you the project hit module-loading bugs and chose to remove the failure mode rather than document it.

Around the guest sits the Android side: a Kotlin app in app/, a terminal emulator and terminal view in their own Gradle modules, and native sources podroid-bridge.c and podroid-launcher.c at the repository root. The bridge is what the README means by guest-to-Android communication; the launcher is how the VM process is started from the app.

## Installing the APK and running your first container

There is no package manager install. The README's quick start says to download the APK from the releases page and install it, then tap Start VM and wait for Ready before opening the terminal. The APK is built for arm64 and the README states Android 8 and above. After the VM reports ready, the terminal is a full xterm-256color session with themes and fonts, and the container runtimes are already present:

```sh
podman run --rm alpine echo "hello from a container"
docker run -d -p 8080:80 nginx
```

The first command pulls and runs Alpine and prints the echo; the second starts nginx detached with port 8080 inside the guest mapped to 80 in the container. A published port inside the VM is not yet reachable from your phone or LAN, so the README uses the podroid-forward helper for that:

```sh
podroid-forward add 8080 8080 tcp
curl http://<phone-ip>:8080
podroid-forward clean
```

The add call takes a local port, a guest port and a protocol (tcp or udp, and the README notes it works on both the QEMU and AVF backends). The curl then hits the phone's own address. The clean subcommand removes every rule you added, which is the practical way to undo a port you opened by mistake.

SSH is the other entry point, enabled in the setup wizard or Settings:

```sh
ssh root@<phone-ip> -p 9922
```

The README gives the password as podroid. Change it if the VM is reachable from a network you do not control. Building from source is a heavier path: ./build-all.sh all compiles the kernel, rootfs, QEMU and the APK, and the README states it needs Docker plus the Android SDK and NDK. Per-component targets live in CONTRIBUTING.md.

## Where Podroid is the wrong tool

The first constraint is architectural: arm64 only. The README's own badge says so, and the kernel build is an aarch64 cross-compile. If your images are x86_64, you are asking the guest to emulate a foreign architecture, and nothing in the README presents that as a supported path. Container images built for amd64 are simply not the target here.

The second is the cost of a VM on a phone. A QEMU guest with its own kernel, a rootfs and a container runtime is a large amount of storage and a continuous battery draw compared with a chroot. The README does not publish a minimum storage figure, a RAM recommendation, or a battery estimate, so anyone planning to run this as an always-on host is guessing until they measure it themselves. That silence is worth taking at face value rather than assuming the numbers are fine.

The third is the security posture. The README states the VM's SSH password is podroid and that the login is root. That is a convenience default for a device on your desk. Combined with port forwarding that can expose a container to your LAN, it means the guest is only as isolated as your network. The README does not document a hardening guide, so treat the defaults as a starting point you change.

Finally, the repository is not archived and the last push was on 2026-09-21, with v1.2.9 released the same day. That is recent activity, but the release cadence the README's history shows is roughly monthly, so a bug you hit may wait weeks for a fix unless you patch it yourself.

## Podroid compared with Termux and a plain chroot

Termux is the obvious alternative, and the README credits it as the terminal emulator engine rather than treating it as a rival. The difference is where the isolation sits. Termux runs processes directly on the Android kernel, so it needs no VM and starts instantly, but it inherits the host kernel's restrictions and does not give you a container runtime with its own networking stack. Podroid pays the VM cost to get a kernel it controls, which is what lets Podman and Docker work as they do on a server.

A chroot or proot setup sits between the two. It is lighter than a VM and gives you a Linux filesystem, but it shares the kernel, so the namespace and networking behaviour that container runtimes depend on is not guaranteed. The README's framing of Podroid as "not a chroot or proot trick" is aimed exactly at that gap.

There is also a project-internal comparison worth knowing about. The README points to RikkaHub Agent, a fork of RikkaHub by the same author, whose SSH tool can log into a running Podroid VM at localhost:9922. That is not an alternative to Podroid; it is a way to drive it from an on-device agent rather than by typing.

## Licence and the cost of upgrading

Podroid is GPL-2.0. If you only install the APK and run containers, the licence is an ordinary copyleft notice and changes nothing about how you use it. If you modify the app, the terminal modules, or the native bridge and distribute the result, GPL-2.0's source-availability terms apply to what you distribute. The kernel and Alpine components carry their own licences, and the README links a CREDITS.md and a LICENSE file; read those before shipping a modified build. None of this is legal advice.

Upgrade cost depends on which part you touch. Installing a new APK is the cheap path, and the releases page is where those come from. Building from source is the expensive one: ./build-all.sh all rebuilds the kernel, rootfs, QEMU and APK, and the README states it needs Docker plus the Android SDK and NDK. The Dockerfile pins a kernel version through the KERNEL_VERSION argument, defaulting to 7.1.5, so a kernel bump is a deliberate edit rather than something that drifts. The README does not document a rollback procedure for a VM that fails to boot after an upgrade, so keep your container data somewhere you can reach without the guest running.

## Conclusion

Podroid suits engineers who want a real container runtime on an arm64 phone and accept a VM as the price: the README states it needs Android 8+ and arm64, and that the APK comes from the releases page. It is the wrong tool if you need x86 images, if you cannot spare the storage and battery a QEMU guest costs, or if you expected a normal Android app rather than a Linux machine with a phone attached. Before adopting it, check the documentation for which backend your device gets, since the README describes QEMU and hardware-accelerated AVF as separate paths, and confirm the SSH port and default password against your own install.

## FAQ

### How can I run a Linux container on my Android phone with Podroid?

Install the APK from the releases page, tap Start VM and wait for Ready, then open the terminal. Podman, Docker and LXC are pre-installed, so a command such as podman run --rm alpine echo works straight away.

### Which Android devices can run Podroid?

The README states any arm64 device on Android 8 or above, with no root required. The backend differs by hardware: QEMU emulation works broadly, while hardware-accelerated AVF requires a supported pKVM device.

### How do I get the Podroid APK?

The README's quick start links to the latest release on the project's GitHub releases page and says to install the APK from there. There is no package manager or app store route documented.

### Can I reach a container running inside Podroid from my laptop?

Yes, in two steps. Publish the port inside the guest, then use podroid-forward add to map it (for example podroid-forward add 8080 8080 tcp, which accepts tcp or udp and works on both the QEMU and AVF backends). SSH is also available on port 9922 with the password podroid.

## Sources

- [ExTV/Podroid on GitHub](https://github.com/ExTV/Podroid)
- [License: GPL-2.0](https://github.com/ExTV/Podroid/blob/main/LICENSE)
- [Project website](https://extv.github.io/Podroid/)
- [README](https://github.com/ExTV/Podroid/blob/main/README.md)
- [Releases](https://github.com/ExTV/Podroid/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/extv-podroid