Haven: an all in one remote access and mobile workspace for Android

What Haven is, and what it wants to be

Haven is a free, open-source remote access and mobile workspace for Android. The header line lists the protocols and features in one breath, SSH, Mosh, VNC, RDP, SFTP, SMB, email, cloud storage, a local Linux shell, mesh networking, and a consent-gated AI-agent endpoint.

The project's own framing of why it is one app rather than many is in a section called Why one app, and the argument is about composition rather than features. The list of parts is the parts, and the point is how they compose. Each is one flow inside Haven, with no second app and no curl piped into ssh incantation.

The examples are specific and worth reading, because they show what a design built around composition looks like. Tap a 4K MKV in Google Drive and FFmpeg transcodes it over HTTP, with the result landing back in the same Drive folder and never touching local disk. SSH to a box, forward its port, tap the VNC profile that targets localhost, and the desktop opens in the same app with the keyboard and clipboard shared. Cut a log directory from an S3 bucket, switch tabs, paste it onto an SFTP server, and rclone does the server-side copy when it can, otherwise Haven streams it through.

The vision document states the philosophy in one line. The phone is the thin client, Haven is the thin-client OS, and the cloud, your servers and your agents are the computer. Width is sufficient, composition is the point.

The app is on F-Droid as sh.haven.app, requires Android 8.0 or later, is written in Kotlin, and is licensed AGPL-3.0. The last push to the repository was on 2026-10-15.

The terminal, and the transports behind it

The terminal is the core of the app, and it supports three transports.

Mosh, Eternal Terminal and SSH, with the Eternal Terminal implementation living in the et-kotlin module in the repository and Mosh in the mosh-kotlin module, both of which are separate projects vendored in rather than called out to an external binary. The terminal also has tmux-aware session restore, so a session that was running on a remote tmux can be reattached rather than lost, and a configurable keyboard toolbar, which is the part that makes a terminal usable on a touchscreen.

The escape sequence integration is the detail that tells you this is aimed at people who use a terminal for work rather than occasionally. The feature list names OSC 7, 8, 9, 52, 133 and 777 support, which is the set of sequences that carry the working directory, hyperlinks, clipboard contents, prompt marking and other metadata between the shell and the terminal emulator. Getting those right is what allows a program running on the server to set the terminal title, offer a clickable link, or mark a prompt so a tool can find it.

The repository also carries a termlib module and a wayland-android module, and the terminal is the same terminal you get when the app draws its own desktop environment.

A screenshot link in the README points at a demonstration of terminal transparency over a live device wallpaper, which the release notes date to 5.60.4, and the header says that the terminal and every Haven screen are made translucent over the wallpaper.

Desktops: VNC, RDP and a compositor on the phone

The desktop features cover the three different ways you get a graphical session onto an Android phone.

VNC is implemented against RFB 3.8 with VeNCrypt, so it speaks the protocol modern VNC servers offer including the encrypted extension. RDP is built on IronRDP with EGFX, which is the graphics pipeline extension, and the implementation lives in the rdp-kotlin module, with a spice-kotlin module alongside it for the SPICE protocol.

The third option is the one that is unusual. Haven includes a GPU-accelerated native Wayland compositor, in the wayland-android module, plus a multi-distro local-desktop manager. That means the phone can run a Linux desktop of its own, rather than only displaying a remote one, and the earlier list of local Linux distributions makes that concrete: Alpine, Debian, Arch or Void, side by side, through PRoot.

The local Linux userland runs without root on any Android 8 or later device, and the build-proot directory is where that image is assembled.

So the desktops feature is really two features. One is remote display, with a keyboard and clipboard shared across protocols. The other is a local Linux environment, which is the prerequisite for running the agent CLIs and the tooling the project expects you to run on the device itself.

There is a related item in the feature list that deserves attention, USB forwarding, which brokers an attached USB device through Android and re-exposes it to the agent, into the Linux guest, or over USB/IP to a remote host. A phone-hosted YubiKey touched on the phone is the example given.

Files, cloud, mail and the agent endpoint

The files feature is a unified browser over SFTP and SCP, SMB and more than 60 cloud providers, with cross-filesystem copy and move, an editor and image tools, and on-device FFmpeg transcoding, HLS streaming and DLNA. The rclone-android module in the repository is the implementation, and the earlier example of a server-side copy between a bucket and an SFTP server is the point of having it.

Email is a separate feature and an unusual one for a terminal app. It covers ProtonMail through the bridge protocol and any IMAP or SMTP mailbox, with compose, reply and forward, multiple accounts and attachments, plus Mail Rules for inbound automation.

The AI chat feature is the one to read carefully. It supports self-hosted or API models, naming OpenAI-compatible endpoints, Ollama, Anthropic and Gemini, over per-profile tunnel routing, with image attachment for vision models, clipboard copy and paste in both directions, and opt-in encrypted saved transcripts.

The agent transport is an MCP server exposing around 130 consent-gated, audited tools, and the README says the agent can even see and operate Haven itself, which is what enables a self-hosting build, install and verify loop.

That last capability is the sharpest edge in the whole project. An agent that can operate the app that holds your SSH keys, your mail and your cloud sessions is a large authority to hand to a language model, and the project is upfront about it, with consent gating and auditing named as the mitigation.

The security feature list is short and specific: a biometric lock, no telemetry, and encrypted backup and restore using AES-256-GCM.

Networking: tunnels, proxies, mesh and the connection manager

The connections feature is where the project assembles the network plumbing, and it is a long list.

Port forwarding covers the familiar SSH forms, with -L for local, -R for remote, -D for dynamic and -J for jump hosts. There are SOCKS, HTTP and Tor proxies. There are per-app WireGuard and Tailscale tunnels, which is the interesting entry, since a per-app tunnel means the traffic of one application on the phone can be routed differently from the rest of it. There is port knocking and fwknop SPA, and there is SSH key management including FIDO2 and SK keys.

The Reticulum feature is the one that stands out from the rest. It offers an rnsh shell, file transfer and -L and -D port forwarding over the Reticulum mesh, implemented in pure Kotlin in the reticulum-kt and rnsh-kt modules. The README calls it the one transport that keeps working with no internet at all, which is a different kind of claim from the rest of the list: it is about reachability rather than about convenience.

The feature documentation is organised per area, with files in docs/features for terminal, desktops, files-and-cloud, connections, email, chat, local-linux, usb, reticulum and security, and a separate document for the MCP tools. A full index lives in docs/FEATURES.md, which is the place to start if you want the map rather than the marketing summary.

The one place where the app breaks the pattern of a remote access tool is the email and AI chat features, which have nothing to do with remote access and are there because the project is about a mobile workspace rather than a remote client.

The state of the project, and how it is built

Three things about the project itself are worth knowing before you rely on it.

The first is the release cadence. The recent versions are v5.89.35 and v5.89.34, both from 2026-10-15, and v5.89.33 from 2026-10-14. Version numbers in the high eighties with several releases in a day is not a project that ships a version per quarter, it is one that ships continuously, and the CHANGELOG.md and RELEASE.md files in the repository root are how the history is kept.

The second is the build layout, and it explains the scale. The repository has core, feature, app and metadata modules, a tools directory, an integration-tests directory, and a long list of vendored projects as separate modules: et-kotlin, mosh-kotlin, rdp-kotlin, spice-kotlin, reticulum-kt, rnsh-kt, termlib, wayland-android, rclone-android, plus build-ffmpeg and build-proot. The presence of a .gitmodules file means some of those are submodules. The FFmpeg and PRoot build directories in particular are the reason the build is not trivial, since they compile native components rather than downloading a prebuilt binary.

The third is the tone of the project, and it is worth naming because it affects how you read the rest. The README quotes a maintainer describing it as an interesting vibe coding experiment, and lets see what comes out of it. There is a CLAUDE.md file and a .claude directory in the repository. A project built that way can move fast and cover an enormous surface, and it can also produce documentation that reads like a feature list rather than a description of behaviour, so the per feature documents are the more reliable source.

The translation workflow is a nice touch in the other direction. Twelve languages are available, including Arabic with right to left support, and the UI follows the device language. Translation happens on a web page at the project site, with no cloning or setup, and the changes arrive as a GitHub pull request.

Editorial conclusion

Adopt Haven if you are a technical Android user who keeps several remote tools on the phone and wants the workflows that cross protocols to work in one place, because that composition is the stated point of the project. Do not adopt it as a general purpose remote desktop client for an organisation, because the AGPL licence and the breadth of credentials it handles make it a personal tool rather than an enterprise deployment. Before you connect anything, read the security documentation, since the app stores SSH keys including FIDO2 credentials and gives an agent endpoint access to the app itself.

Frequently asked questions

Official sources

1. GlassHaven/Haven on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases