Ephemeral PhoneOpen console

Documentation

Build a phone that is not tied to one device.

Join the founding deployment, understand the trust boundaries, or deploy the control plane and connect your own Android runtime. Early use cases help shape the requirements and operating model.

Overview

Ephemeral Phone is a working control plane for running a persistent Android handset on infrastructure you control and reaching it through temporary clients. The current reference deployment uses Cuttlefish on owner hardware, a protected control plane, GitHub authentication, and WebRTC streaming.

Early access with clear boundaries. Founding participants can validate real deployments and directly shape requirements. Do not treat the current release as an anonymity service, a certified hardened mobile device, or a guarantee against a determined adversary. The default mock runtime provides no Android isolation.

Choose your starting point

Join the founding deploymentSign in with an approved GitHub account, manage a handset, download a server installer, and help shape the requirements.Install your own serverTechnician instructions for the Windows and Ubuntu packages available inside the signed-in console.Watch the real flowSee the live console open a Cuttlefish Android handset over WebRTC.Integrate the APIUse the bearer-authenticated lifecycle API from your own client or automation.

Architecture at a glance

Control plane

ephemerald owns lifecycle state, provider selection, audit events, and short-lived connection tickets. The hosted web gateway exposes only an allowlist of those operations.

Runtime node

ephemeral-agent runs beside the Android runtime. The production demonstration uses Cuttlefish; command and remote adapters make the control plane independent of one runtime.

Replaceable client

The PWA and Android WebView shell are thin clients. They are designed not to retain Android application data after a session, although browsers and operating systems may still retain normal metadata such as history, cookies, screenshots, or network records.

Documentation map

  • Appliances and images — hardware tiers, capacity acceptance, Android image compatibility, client branding, and ordering.
  • Installers and deployment — supported artifacts, source builds, Docker, and runtime requirements.
  • Control API — authentication, endpoints, and an example request.
  • Privacy zones — optional airport and sensitive-area locking, including its limits.
  • Security and trust — what the system protects, what it does not, and how to report a problem.
  • Roadmap — completed, experimental, and planned work.