Skip to main content

Setting Up Open Terminal for a Team

When multiple people on your team need terminal access through Open WebUI, you have two options.

Single ContainerPer-User Containers
HowOne container, separate accounts insideEach user gets their own container
IsolationFiles are separate, but they share the same systemFully isolated — separate everything
SetupOne extra settingAdditional orchestration service
Best forSmall teams you trustProduction, larger teams, untrusted users
Included inOpen Terminal (free)Terminals (enterprise)
Required for multi-user Open WebUI deployments

If your Open WebUI instance has more than one user account and the same terminal-server connection is shared across users, you must use one of the two isolation modes below. A single Open Terminal container without OPEN_TERMINAL_MULTI_USER=true (or without per-user containers via Terminals) places every user inside the same shell, the same filesystem, and the same network namespace — which means any user can read, modify, or replace any other user's files, run commands as the shared user, and bind shared ports. This is not a supported configuration for multi-user Open WebUI.

For deployments with untrusted users (open signup, public-facing portals, mixed-tenant setups), Option 1 is also insufficient on its own — file isolation does not extend to network namespace, so users can still reach each other through bound ports on the shared container. Use Option 2 (per-user containers via Terminals) for these deployments, or layer TERMINAL_PROXY_HEADERS on top of Option 1 to restrict what proxied responses can do in the user's browser.

Option 1: Built-in multi-user mode​

The simplest approach. Add one setting and each person automatically gets a separate workspace.

docker run -d --name open-terminal -p 8000:8000 \
  -v open-terminal:/home \
  -e OPEN_TERMINAL_MULTI_USER=true \
  -e OPEN_TERMINAL_API_KEY=your-secret-key \
  ghcr.io/open-webui/open-terminal

What happens​

When someone uses the terminal through Open WebUI, Open Terminal automatically:

  1. Creates a personal account for that user (based on their Open WebUI user ID)
  2. Sets up a private home folder at /home/{user-id}
  3. Runs all their commands under their own account
  4. Restricts their file access to their own folder

Each user sees only their own files in the file browser.

What's shared vs. separate​

Separate per userShared
Home folder and files✔
Running commands✔
System packages✔
CPU and memory✔
Network access✔
Good for small teams, not production

This mode gives everyone their own workspace, but they're all running inside the same container. Resource pressure (memory, CPU) is shared, and so is the network namespace — a user who binds a port (e.g. python -m http.server 8080) is reachable from any other user's terminal-server proxy URL on that port. Per-user file isolation does not extend to per-user network isolation in this mode.

Use this for small, trusted groups — not for wide-open deployments. For untrusted multi-user deployments, use Option 2 (per-user containers) below, or layer the TERMINAL_PROXY_HEADERS configuration on top to lock proxied responses into a sandbox CSP.

Option 2: Per-user containers with Terminals​

For larger deployments or when you need real isolation, Terminals gives each user their own container, completely separate from everyone else.

  • Full isolation — each user's container is independent with its own files, processes, and resources
  • On-demand provisioning — containers are created when users start a session and cleaned up when idle
  • Resource controls — set CPU, memory, and storage limits per user or per environment
  • Multiple environments — different setups for different teams (e.g., data science, development)
  • Kubernetes support — works with Docker, Kubernetes, and k3s

Two deployment backends are available:

  • Docker Backend — runs on a single Docker host. Best for small-to-medium teams or environments without Kubernetes.
  • Kubernetes Operator — production-grade deployment using a CRD-based operator. Deploys alongside Open WebUI via the Helm chart.
Enterprise license required

Terminals requires an Open WebUI Enterprise License. See the Terminals repository for license details.

This content is for informational purposes only and does not constitute a warranty, guarantee, or contractual commitment. Open WebUI is provided "as is." See your license for applicable terms.