# atxserver2 Python Smartphone Management Server Review

> atxserver2 is a Python smartphone management server for Android and iOS, built with Tornado and RethinkDB. It is no longer developed according to the README, although the repository records a push on 2026-06-17.

**openatx/atxserver2** — Smart Phone Management. Reimplement of atx-server with Python

- Repository: https://github.com/openatx/atxserver2
- Stars: 1,441 · Forks: 451
- Language: HTML
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/openatx-atxserver2

## What atxserver2 manages, and who needs it

atxserver2 addresses the problem of seeing and controlling enrolled smartphones from a browser instead of attaching each phone to a workstation. Its target users are operators or teams that need a shared device inventory, remote operation, device assignment, and administrative controls. The README names Android and iOS as supported platforms, but the installation instructions describe an Android provider and only point to an iOS provider project. That distinction matters. The server is not presented as a generic Android debugging library or a phone emulator. It is a management layer with a web interface and device-related routes.

The interface is centered on a device list, authentication, and device ownership. The README says the first logged-in user becomes the administrator. Administrators can release a device being used by another person, occupy a device under another identity, retrieve source information, promote other users to administrators, and change the asset number. These features suggest a shared lab, test farm, QA pool, or support environment rather than a personal phone-management application. The documentation does not describe bulk enrollment policies, device metadata retention, audit logging, or a detailed permission matrix, so those capabilities should not be assumed.

There is also a private-device ownership feature. The Android provider accepts `--owner=xingxing` for a group or `--owner=panpan@gmail.com` for a person. The README says users can obtain a personal token and manage groups, while also noting that group-member management was not implemented at that point. The control model is therefore partly present, but its administrative surface is not fully described.

## Tornado, RethinkDB, and the device-provider data path

The documented architecture is a Tornado web application backed by RethinkDB. The repository layout places routes in `web/urls.py`, configuration in `web/settings.py`, database operations in `web/database.py`, and request-handler logic under `web/views/`. The README also says that much of the code uses `async`. That combination means the browser-facing server handles web requests asynchronously while retaining RethinkDB as the persistent state store.

The server is not itself the component that installs all phone-side control resources. For Android, the README directs users to `atxserver2-android-provider`. The provider is described as needing Python 3.6+ and NodeJS, and its Docker command sends `atx-uiautomator.apk`, `minicap`, `minitouch`, and `atx-agent` to the phone. Once that preparation is complete, the README says remote operation of a physical device is available. This creates a multi-process deployment: atxserver2 holds the web and management side, while the provider handles Android-side resource delivery and communicates with the server URL.

The default database connection is `localhost:28015`, with database name `atxserver2`. The Compose deployment names the database service `rethinkdb` and passes it through `RDB_HOST`. The application listens on port `4000` by default. Authentication is selected at startup with `--auth simple`, `--auth openid`, or `--auth github`. The README identifies GitHub authentication as requiring `client_id` and `client_secret` in `settings.py`, and it describes the default simple mode as accepting an email address. The documentation does not spell out the complete request or persistence flow for every route, so the database schema and provider protocol should be treated as implementation details to inspect before upgrading.

## Installing atxserver2 with Docker Compose

The README presents Docker Compose as the shortest deployment path. After cloning the repository and changing to its directory, the documented command starts both the web service and a RethinkDB container. The Compose file maps the web service to port `4000`, links it to the `rethinkdb` service, and stores database files in `./rethinkdb_data`. The reader should expect the web interface to become available at `http://localhost:4000` after the services start, subject to the container completing its database wait script.

The command is exactly as shown in the project documentation:

```bash
docker-compose up
```

The Compose file uses `rethinkdb:2.3.6`, while the Python project metadata pins `rethinkdb==2.4.2.post1` as the client dependency. The README does not explain that version split or provide a database migration procedure. It also does not document a reverse proxy configuration, TLS setup, backup command, or production secret-management procedure. The deployment is therefore a documented starting point, not a complete production operations guide.

The service is defined with an entrypoint that waits for the database and a command that starts `main.py` through `uv`. Because the Compose file has its restart policy commented out, the reader should not assume Docker will automatically recover a failed service. For a new deployment, the database volume and authentication settings need review before phones are attached.

## Manual installation and the first browser session

For manual deployment, the README requires a RethinkDB server and recommends Linux for that database. It then replaces the older `python main.py` startup instruction with `uv run main.py`. The project metadata requires Python `>=3.9,<3.10`, so the runtime should be checked before installation. The README does not give a separate database initialization or schema migration command.

Install `uv` and start the server with:

```bash
pip install uv
uv run main.py
```

The default listener is `4000`, and the default database address is `localhost:28015`. The documented environment variables are:

```bash
export RDB_HOST=localhost
export RDB_PORT=28015
export RDB_USER=admin
export RDB_PASSWD=
export RDB_DBNAME=atxserver2
```

After those values are in the shell, start the application again with `uv run main.py`. The server also accepts `--auth simple`, `--auth openid`, `--auth github`, and `--port 4000`. The README says X-Real-Ip and X-Forwarded-For support is enabled by default and can be disabled with `--no-xheaders`. It does not document the exact behavior of the email-only simple authentication beyond identifying it as a simple mode.

Once the process starts, browse to `http://localhost:4000` and complete authentication. The README shows the device list as initially empty. That is expected because no Android or iOS provider has been registered yet.

## Enrolling an Android phone through atxserver2-android-provider

Android enrollment is a separate operation, not a command executed by atxserver2 itself. The README links the companion project `atxserver2-android-provider`, recommends Docker on Linux, and gives this deployment example. `SERVER_URL` must be changed to the address where atxserver2 is reachable from the provider.

```bash
SERVER_URL="http://10.0.0.1:4000"
IMAGE="codeskyblue/atxserver2-android-provider"
docker pull $IMAGE
docker run --rm --privileged -v /dev/bus/usb:/dev/bus/usb --net host \
    ${IMAGE} python main.py --server ${SERVER_URL}
```

The command grants the container privileged access, mounts the USB bus, uses host networking, and points the provider at the server URL. The README says the image sends the required Android resources to the phone, including `atx-uiautomator.apk`, `minicap`, `minitouch`, and `atx-agent`. It does not document USB debugging authorization, device serial selection, recovery from a failed push, or what happens when multiple phones are connected. Those omissions make host permissions and device preparation part of the operator's responsibility.

The README's mouse mapping is simple: right-click performs BACK and middle-click performs HOME. It does not document keyboard mappings, multi-device gestures, browser session behavior, or the exact remote-control screen. For iOS, the README only refers readers to `atxserver2-ios-provider` and does not provide an installation command.

## Maintenance, licensing, and the limits of the documented platform

The README explicitly says the project is no longer under development and recommends choosing another platform. The repository is not archived, and its last push was on 2026-06-17. That means the repository is not marked archived, but the project's own maintenance statement is more important than the absence of an archive flag for adoption decisions. The most recent listed release is `v0.2.0`, dated 2019-04-16. The README also contains a later installation update mentioning `uv run main.py`, but it does not publish a new release for that change.

The upgrade cost is therefore higher than a normal dependency update. An adopter may need to inspect `pyproject.toml`, `uv.lock`, the `Dockerfile`, the `docker-compose.yml` database image, and any provider deployment. The Python requirement is narrow, and the project depends on `rethinkdb==2.4.2.post1` and Tornado. The repository does not document a migration guide for changing RethinkDB versions or for upgrading provider and server components together.

The project uses the MIT license. That permits use and modification under the license terms, but it does not remove operational costs. Someone adopting the server still has to secure the web interface, manage database credentials, review reverse-proxy settings, and keep the Android or iOS provider available. The README's “first user becomes administrator” rule also deserves review before exposing the service beyond a trusted network.

A named alternative is the original atx-server. atxserver2 describes itself as a Python reimplementation of atx-server, while the project documentation gives concrete implementation details for atxserver2: Tornado, async request handling, RethinkDB, a browser interface, and separate device providers. It does not document the original project's current architecture, releases, maintenance state, or setup, so the comparison can only establish the stated reimplementation relationship, not claim that either project has a particular feature advantage. The README also credits scrcpy, but it does not describe scrcpy as a drop-in server replacement or explain its integration.

## Conclusion

Adopt atxserver2 only if you can maintain a Python 3.9 application, operate RethinkDB, and provision separate Android or iOS providers. Do not choose it for a new long-lived deployment without checking its stopped-development status, dependency compatibility, and provider maintenance first. The first verification should be whether the documented `uv run main.py` path still starts with the selected database and whether the device-provider project is still suitable for the phones you need.

## FAQ

### How do I install and run atxserver2?

The README offers Docker Compose with `docker-compose up` or manual startup with `pip install uv` followed by `uv run main.py`. Manual deployment requires a RethinkDB server, and the default web port is `4000`.

### How does atxserver2 connect an Android phone?

Android onboarding requires the separate `atxserver2-android-provider` project. The documented Docker command passes the atxserver2 URL to the provider, which pushes `atx-uiautomator.apk`, `minicap`, `minitouch`, and `atx-agent` to the phone.

### Is atxserver2 still actively developed?

No. The README explicitly states that the project is no longer being developed and recommends choosing another platform. The repository is not archived, and its last push was on 2026-06-17.

### Which authentication modes does atxserver2 support?

The documented startup choices are `--auth simple`, `--auth openid`, and `--auth github`. The README describes simple mode as a simple email-based mode and says GitHub configuration uses `client_id` and `client_secret` in `settings.py`.

### Does atxserver2 include iOS setup instructions?

The README says atxserver2 supports Android and iOS, but the instructions only link to `atxserver2-ios-provider` for iOS. No iOS installation command or provider configuration example is included.

## Sources

- [Issues](https://github.com/openatx/atxserver2/issues)
- [License: MIT](https://github.com/openatx/atxserver2/blob/master/LICENSE)
- [openatx/atxserver2 on GitHub](https://github.com/openatx/atxserver2)
- [README](https://github.com/openatx/atxserver2/blob/master/README.md)
- [Releases](https://github.com/openatx/atxserver2/releases)

---

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