Security Best Practices
Hrida Terminal gives AI real power to run commands and manage files. Here's how to make sure that power is used safely.
Use Docker
Always use Docker unless you specifically need direct access to your machine. Docker isolates Hrida Terminal in its own container: it has its own filesystem, its own processes, and can't access anything on your host computer unless you explicitly allow it.
docker run -d --name hrida-terminal -p 8000:8000 \
--memory 2g --cpus 2 \
-v hrida-terminal:/home/user \
-e HRIDA_TERMINAL_API_KEY=your-secret-key \
ghcr.io/hrida-ai/hrida-terminalThe --memory 2g and --cpus 2 flags prevent runaway processes from consuming all your machine's resources.
Without Docker (bare metal mode), the AI can run any command with your user's permissions — including deleting files, installing software, or accessing anything your account can access. Only use bare metal on your own personal machine for personal projects.
Always set a password
Without an API key, anyone who can reach the port has full access — they can run commands, read files, and control the terminal.
-e HRIDA_TERMINAL_API_KEY=a-strong-password-hereFor production, use a config file or Docker secrets instead of putting the key on the command line.
Use admin connections (not user connections)
When connecting to HridaAI, prefer the admin-configured approach:
| Admin-configured | User-configured | |
|---|---|---|
| API key visibility | Hidden on the server | Stored in the user's browser |
| Requests go through | HridaAI's backend | Directly from the browser |
| Terminal network access needed from | Just the HridaAI server | Every user's computer |
Admin-configured connections keep the API key out of users' browsers and let you control who has access.
Limit resources
Prevent a runaway script from consuming all available CPU and memory:
deploy:
resources:
limits:
memory: 2G
cpus: "2.0"If a process exceeds these limits, Docker throttles it (CPU) or kills it (memory). Your server stays healthy.
Network isolation
For the most secure setup, put Hrida Terminal on a private Docker network that only HridaAI can reach:
services:
hrida-ai:
image: ghcr.io/hrida-ai/hrida-ai-studio:latest
ports:
- "3000:8080"
networks:
- public
- internal
hrida-terminal:
image: ghcr.io/hrida-ai/hrida-terminal
# Notice: no ports exposed to the outside
networks:
- internal
networks:
public:
internal:
internal: true # No internet access from this networkThis means:
- HridaAI can reach Hrida Terminal at
http://hrida-terminal:8000 - Hrida Terminal is not accessible from the internet
- Hrida Terminal cannot make outbound internet requests
Egress filtering
If Hrida Terminal needs some internet access (to install packages, for example), you can restrict it to specific domains:
Only these domains will be reachable. Everything else is blocked. This prevents:
- Unauthorized data leaving the container
- Downloading unexpected software
- Accessing internal services you didn't intend
Docker socket warning
The Docker container can optionally access your host's Docker (to let the AI build images, run containers, etc.):
-v /var/run/docker.sock:/var/run/docker.sockMounting the Docker socket gives the container full control over your host's Docker. This is effectively root access on your machine. Anyone with terminal access could:
- Run containers that mount your entire filesystem
- Access your host's network
- Manage every container on your machine
Only do this if you fully trust everyone who has access to the terminal.
Security checklist
| ✅ | Recommendation |
|---|---|
| ☐ | Use Docker, not bare metal |
| ☐ | Set a strong API key |
| ☐ | Use admin-configured connections |
| ☐ | Set memory and CPU limits |
| ☐ | Use network isolation (internal Docker network) |
| ☐ | Enable egress filtering if internet access isn't needed |
| ☐ | Don't mount the Docker socket unless necessary |
| ☐ | Use slim or alpine images if you don't need runtime package installs |