Setting Up Hrida Terminal for a Team

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

	Built-in multi-user mode	Separate instances
How	One container, separate accounts inside	One Hrida Terminal container per user or team
Isolation	Files are separate, but they share the same system	Fully isolated — separate files, processes, and network
Setup	One extra setting	One connection per instance, restricted with access grants
Best for	Small teams you trust	Untrusted users, teams that need hard separation

Required for multi-user Hrida.ai deployments

If your Hrida.ai instance has more than one user account and the same terminal-server connection is shared across users, you must use one of the two options below. A single Hrida Terminal container without HRIDA_TERMINAL_MULTI_USER=true 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 Hrida.ai.

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 (separate instances) 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 hrida-terminal -p 8000:8000 \
  -v hrida-terminal:/home \
  -e HRIDA_TERMINAL_MULTI_USER=true \
  -e HRIDA_TERMINAL_API_KEY=your-secret-key \
  ghcr.io/hrida-ai/hrida-terminal

What happens

When someone uses the terminal through Hrida.ai, Hrida Terminal automatically:

1. Creates a personal account for that user (based on their Hrida.ai 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 user	Shared
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, run a separate Hrida Terminal instance per user or team, or layer the TERMINAL_PROXY_HEADERS configuration on top to lock proxied responses into a sandbox CSP.

---

Option 2: Separate instances per user or team

For hard isolation, run one Hrida Terminal container per user or team and give each its own admin-configured connection. Restrict each connection with access_grants so only the intended group can use it:

[
  {
    "id": "terminal-data-science",
    "url": "http://hrida-terminal-ds:8000",
    "key": "ds-api-key",
    "name": "Data Science Terminal",
    "auth_type": "bearer",
    "config": {
      "access_grants": [
        {"principal_type": "group", "principal_id": "<group-id>", "permission": "read"}
      ]
    }
  }
]

Set this in TERMINAL_SERVER_CONNECTIONS or add the connections under Admin Panel → Settings → Integrations → Manage Terminal. Each container has its own filesystem, processes, CPU/memory limits, and network namespace.

---

Related

• Security best practices →
• All configuration options →