tapflow: self-hosted browser access to iOS simulators and Android emulators

I built tapflow for teams that need to check mobile builds but do not want every tester to install Xcode or Android Studio. The topology is worth stating first: the relay can run on Linux or Docker, while the agent that drives the devices must run on a Mac. Apple only provides the iOS simulator on macOS. The Mac agent makes outbound WebSocket connections to the relay, so the agent side does not need an inbound firewall or NAT rule. The relay and the agent can therefore live on different machines on the same network: browser → Linux/Docker relay ← outbound WebSocket ← Mac agent → simulators/emulators The project is MIT licensed and currently v0.x. The point of running it yourself is that app builds, streams, and recordings stay on infrastructure you control. The relay brokers the traffic; it does not make a container into a simulator host. Docker relay The documented Docker path runs the relay only: services: relay: image: tapflow/tapflow:latest ports: - "4000:4000" volumes: - tapflow-data:/app/.tapflow/data environment: TAPFLOW_RELAY_URL: http://your-relay-host:4000 TAPFLOW_ADMIN_EMAIL: admin@example.com TAPFLOW_ADMIN_PASSWORD: change-this-password volumes: tapflow-data: The data volume matters because the relay stores its per-install sign-in secret there. TAPFLOW_RELAY_URL is used when generating invite links. The image is published for linux/amd64 and linux/arm64, with latest and version tags. After starting the relay, install tapflow on the Mac that owns the simulators and connect the agent to the relay. A container by itself has no simulator to stream. What it provides Once an agent is connected, a team member opens the dashboard in a browser and can interact with the selected simulator or emulator. The current path includes touch and keyboard input, device buttons, rotation, screenshots, recordings, build uploads, and session sharing. It is intended for QA and build review rather than replacing a physical-device lab. The Mac agent connects outward to the relay. That is useful when the relay is on a small Linux box or a NAS inside the same network: the device host does not need to expose an agent service to the network. Limits I want to be clear about • The iOS path requires macOS. The Android agent also runs on the Mac host in the documented setup. • These are simulators and emulators, so camera, biometrics, NFC, and other physical-device behavior are outside the model. • It is v0.x and still has rough edges. • A relay on a cloud VM is not the intended deployment. Keep it on the same Mac or on a machine in the network with the agent; sending the media path through a remote relay changes the data and latency properties. AI involvement The product includes an experimental, optional @tapflowio/mcp-server. It lets an LLM agent call tools such as tap, type, and screenshot. The normal product path is manual QA in the browser and does not require AI. During development, I use Claude Code as a coding assistant. I make the design decisions and review the changes myself. The code and self-hosting guide, including the Compose example, are in the MIT-licensed GitHub repository (https://github.com/jo-duchan/tapflow). The project website is https://www.tapflow.dev. If you run a self-hosted relay for device access, what does your deployment look like? I am especially interested in how you handle the Mac side when the relay lives on a Linux box.