Applications
Apu
experimentalA browser workspace for software projects on your own hosts, each project in its own dev container.
Apu is a workspace for working on software projects that live on your own machines. You sign in, add the hosts you work on over SSH, and open a project there as a session: the project's own dev container on that host. From the browser you can then read the project's Markdown and code, rendered, and open terminals into it.
It is a Phoenix LiveView application, shipped as a container image.
What it does today
- Hosts over SSH. Apu holds an Ed25519 key per user, with the private half encrypted at rest and never shown. Adding a host shows the
authorized_keysline to install. On first connection Apu shows the host key's fingerprint and trusts nothing until the user confirms it. A changed host key is refused until it is re-pinned. - Setting a host up. Apu inspects the host (CPU, C library, systemd, Docker or Podman and whether rootless use works), copies over a small host daemon, verifies its checksum and starts it. Nothing else is installed. Each host's health is shown as it changes: reachable, unreachable and why, or degraded (for example, no container runtime the account can use, or low disk).
- Sessions that survive stops. The daemon keeps each session's description on the host, written atomically so a power cut loses at most a moment. When it restarts it adopts the containers still running or recreates them. A session cut short by an unclean stop comes back marked interrupted rather than silently resumed.
- A viewer through the session. Tabs, a file tree, rendered files, search and live updates, all read on the host through the session. The daemon confines every path to the session's project, so Apu cannot read past it however it is driven.
- Terminals into a session's container, using ExTC's LiveView terminal. The shell is held by the daemon, so a terminal survives the page closing and reattaches with what it showed.
Sign-in is always required, on loopback too. Apu reaches your hosts, keys and shells, and any local process that can reach localhost could otherwise drive it. Accounts can be local or from an LDAP directory, and a TOTP second factor is required by default.
Where it is going
The specification describes Apu as a multi-user workspace for working on projects with Claude. Claude Code agents would run headless inside each session's container, on the user's own account, with roles, approvals for what an agent may do, and a record of every event kept on the host. The plan also covers chat and notes per session, saved steps to run, and a phone-friendly view. In time, ExSh would serve as the shell and the supervisor of agents inside each container. None of that is built yet.
How it is built
The boundary between Apu and the work is deliberate. The Apu server mounts none of your project files. Everything is read on the host, as the user's own Unix account, through a daemon that treats Apu's requests as confined to one project, and whatever runs in a session is confined by its container. The host daemon is built for Linux (x86-64 and ARM64) and macOS on ARM, and ships inside Apu's image with checksums.
The specification is kept aligned with tests and code using Surfex. Sections not yet built are marked as deferred.
Status
Experimental. Apu has not yet cut its first release (its version reads 0.1.0-dev). Hosts, sessions, the viewer and terminals work. The agent features that motivate the design are specified but not implemented.