Per-user isolated container environments with persistent storage

[dnviti]

Problem / Motivation

Anyone who signs in gets a terminal and an agent that run directly on the machine hosting the app, with the same account, the same home directory, and the same installed tools as everyone else. On a multi-user installation that means people can see and change each other's files and credentials, one person's global package install changes the environment for everybody, and there is no way to tell from the host which running process belongs to which signed-in user.

There is also no personal, durable environment: whatever a user installs to make their own work possible either leaks into the shared host or has to be reinstalled from scratch.

Goal

Each signed-in user gets their own isolated workspace environment, created on demand at sign-in and clearly attributed to them by name, with storage that survives the environment being destroyed and recreated — so a user can install their own packages and tooling once and find them again next time.

Scope

• On sign-in, the user gets a personal environment of their own; if one already exists for them, it is reused rather than duplicated.
• The environment is named after the signing-in user, so anyone inspecting the host can immediately tell whose it is.
• The user's home directory and workspace are stored persistently and reattached whenever the environment is recreated, so installed packages, shell configuration, and agent credentials survive a restart, an upgrade, or an explicit teardown.
• Everything the user does through the app — terminal sessions, agent runs, the file browser and editor, uploads and attachments, git status — operates inside that user's environment, not on the host.
• Both Docker and Podman are supported as the engine behind this, chosen by configuration rather than requiring a different build.
• Administrators can configure what an environment starts from (which base image and preinstalled agents/tools) and what limits apply to it (CPU, memory, disk).
• Idle environments can be stopped to reclaim resources and restarted transparently the next time the user comes back, without losing their data.
• Operators can see which environments exist, who owns each one, and remove one when a user's access is revoked.
• Running this way is opt-in: an installation that does not enable it keeps working exactly as it does today, directly on the host.
• Documentation covers turning it on, the prerequisites for each engine, where user data lives, and how to back it up.

Non-goals

• Running each user's environment on a different machine, or any form of cluster/Kubernetes scheduling.
• Sharing one environment between multiple users, or letting users see each other's environments.
• Replacing the existing single-user, run-on-the-host mode.
• Letting users choose or customise their own base image from inside the app in this first iteration.

Security / Safety Considerations

• Isolation is the point of the feature: a user must not be able to reach another user's files, credentials, or processes, nor the host's own data, from inside their environment.
• The app's ability to create and destroy environments is a powerful capability; enabling it should be a deliberate administrator decision, and the mechanism should not become a way for a signed-in user to gain control of the host.
• Persistent storage holds agent credentials and API tokens, so it needs the same access restrictions as the rest of the user's data and should be removable when access is revoked.
• Naming environments after users makes attribution clear on the host; user-supplied names must not be able to collide with, or impersonate, another user's environment.
• Resource limits protect other users from one environment consuming the whole machine.

Acceptance Criteria

• With the feature enabled, a user signing in for the first time gets a personal environment created automatically, without any manual setup.
• The environment's name visibly contains that user's account name, and two different users always get two distinct environments.
• A user installing a package inside their terminal still has it after their environment is destroyed and recreated.
• Files a user creates are invisible to any other signed-in user, and the file browser, editor and uploads all show that user's own environment.
• The same behaviour is verified against both Docker and Podman.
• Signing in again reuses the existing environment instead of creating a second one, and reattaches the user's existing data.
• Configured CPU/memory limits are enforced on each environment.
• An installation with the feature disabled behaves exactly as it does today.
• An operator can list environments with their owners and remove one, and the removed user's data is gone afterwards.
• Documentation describes prerequisites, how to enable it, and where user data is stored and backed up.

Suggested Phasing

1. Create, reuse and destroy a per-user environment named after the user, with persistent home storage, on a single engine.
2. Route every user-facing surface (terminal, agents, files, uploads, git) through that environment.
3. Support the second engine, resource limits, and configurable base images.
4. Idle stop/restart, operator visibility and cleanup, documentation.

Open Questions

• What should a user see while their environment is being prepared for the first time, and what happens if it fails to start — a clear error, or a fallback to the current host mode?
• Should the amount of persistent storage per user be capped, and what should happen when a user hits that cap?
• When an administrator changes the base environment, should existing users be migrated automatically on next sign-in or left on the old one until they opt in?