Open source, Apache-2.0
Super Farm
Super Farm runs many Android instances as Docker containers on one Linux machine and controls them from a web panel, a command line (sf) and an HTTP API. Each Android has its own data volume, rendering mode and network path, and one selection syntax (all, running, tag:eu, 1-10) applies every operation to as many of them as you choose.
About the demo. It is the project’s real panel over a fake backend that runs in your browser. No Androids, VPNs or servers are connected, and your changes stay in this browser tab. How the demo works
The panel
Screenshots of the real panel on the test machine. The demo shows the same pages with invented data.
The dashboard: capacity estimate, fleet state and first-run checklist
Androids as cards with thumbnails, state and tags
The New Android dialog with per-Android options
The control wall with broadcast input
The approvals inbox with a change and a destructive request
The automation page with datasets and recording
What it does
| Feature | What it does |
|---|---|
| Rendering per Android | Each Android draws on the CPU (software), the integrated GPU (igpu) or a discrete GPU (dgpu). You can also pick by vendor (intel, amd, nvidia) or pin one render node. Intel and AMD cards are driven by Mesa inside Android. NVIDIA cards are reached through a Venus relay on the host, which you build once. See docs/GPU.md. |
| Android version per instance | Images are configured for Android 9 to 15 and a farm can mix them. Only Android 13 has been booted in testing. |
| Network per Android | direct, vpn (one OpenVPN or WireGuard tunnel per Android), gateway (one shared VPN gateway for many Androids), proxy or none. In vpn and gateway mode a kill switch drops everything that would leave outside the tunnel, and it is loaded before the tunnel starts. See docs/NETWORKING.md. |
| Any app | The app library takes APK, XAPK, APKS and APKM files. You install, update, launch, stop and uninstall across a selection, and a matrix shows which version is where. The code has no special case for any app. See docs/APPS.md. |
| Live view and broadcast control | The panel shows thumbnails of every Android and a live view of one. On the control wall, one tap, swipe or typed line goes to every selected Android. |
| Listen to one device | sf listen 3 plays that Android's sound on the host's speakers. |
| Virtual camera and microphone | A video file or a live RTMP stream becomes the camera picture and microphone sound of the Androids you select. This needs a kernel module and a camera HAL that you extract yourself. See docs/MEDIA.md. |
| Automation | You record a task a few times on the live view, training merges the recordings into one program by consensus, and the program replays on any selection. Flows are hand-written YAML scripts that run the same way. See docs/AUTOMATION.md. |
| AI assistant, AI Pilot and MCP | A built-in Assistant (sf ask) and any external MCP client (sf mcp) operate the farm through one set of 39 tools. Under the default policy, every action that changes the farm waits for your Yes or No in an approvals inbox. The Pilot lets a model operate an app once and turns the verified runs into a program that replays with no model. See docs/AI.md and docs/MCP.md. |
| Capacity estimate | sf host capacity and the dashboard say about how many Androids this machine can run and what runs out first. The estimate is advisory: by default a start over the estimate only warns. See docs/SCALING.md. |
| Backups | A backup is a tar archive of one Android's data with a checksum manifest. You restore it as a new Android or over an existing one. A safety backup is taken before a delete. See docs/BACKUP.md. |
| Host checks | sf doctor runs 46 read-only checks and prints the fix command for each problem it finds. |
What has been tested
Version 0.1.0. It has been tested on one machine with one Android version, and several parts have not been run for real. docs/VERIFICATION.md has the full table, with the test behind every line and how to run it again.
Verified live on the test machine (Ubuntu 26.04, kernel 7.0, Docker 29, an Intel integrated GPU and an NVIDIA card, Android 13):
- the lifecycle of an Android through the whole stack, in software, Intel and NVIDIA rendering
- VPN tunnels, the kill switch and shared gateways, against an OpenVPN server the test creates
- backup and restore, app installs, input, live view, automation, the API, the MCP server and the panel in headless Chrome
Not verified:
- anything that needs root or a real init system:
sf host applyfor real, the boot service,sf service install, kernel module signing - AMD GPUs, WireGuard tunnels, IPv6, Docker older than 29
- Android versions other than 13
- the virtual camera picture end to end, and building the NVIDIA runtime from source with
native/venus/build.sh - browsers other than Chrome
- more than two real Androids at once through Super Farm itself
Where to go next
- Try the demoCreate pretend Androids, start them, tap their screens, run a flow. Nothing leaves your browser.
- Install itRequirements, the installer and host setup for a real machine.
- Quick startFrom a running daemon to a first Android with an app, a flow and a backup.
- What was verifiedWhat was tested, on what, and what was not.
- All documentationGuides, the reference and how it works.