# Run AI agents in Docker, on your own machine

An AI agent that does real work needs a computer: a browser, a terminal and somewhere to keep files. With Docker, that computer is a container on a machine you control. Nothing runs in someone else's cloud, and you don't need an account with a sandbox provider.

[SFCrew](https://sfcrewai.com/) is an open source app for AI teammates that do real work. You talk to each bot in chat, and each one gets its own computer with a desktop, browser, terminal and files that you can watch and take over. When you [host SFCrew yourself](https://sfcrewai.com/self-hosted-ai-agent/), Docker is the default: the same install that starts SFCrew also starts your bots' computers next to it.

Updated November 4, 2026.

## What is a Docker computer?

[Docker](https://www.docker.com) runs software in containers: isolated processes with their own files, network and limits, on the same machine as everything else. SFCrew uses it to give each bot computer its own container, built from a published Debian image that has a full desktop in it.

A small service called the supervisor creates, starts and removes those containers. It runs inside the SFCrew install, holds the Docker socket, and is never exposed outside it. The SFCrew API asks the supervisor for a computer; it never touches Docker directly.

This is SFCrew's own setup, not Docker's separate Docker Sandboxes product, and it isn't made or endorsed by Docker.

## What a bot can do on a Docker computer

Each computer is a small Linux desktop. The bot works on it the way a person would, and you see its screen in the chat.

- Browse the web in Chromium, sign in to sites and download files. You can watch the screen live and take over the mouse and keyboard at any time.
- Run commands in a terminal, install tools and write scripts.
- Keep its work. Each bot's home folder lives on your server's disk, so files are still there after the computer or the whole server restarts.
- Share a computer with its teammates. Bots in a workspace use one team computer by default, each with its own screen, and you can give a bot a private computer instead.
- Read folders you choose. An admin can mount host folders, such as a shared docs folder, into every computer, read-only unless they say otherwise.

## When to choose Docker

Choose Docker when you want everything on hardware you own, with no sandbox account and no bot computers in anyone else's cloud. It is the quickest way to try a self-hosted SFCrew, and it suits a person or a team on a machine they trust.

If you'd rather keep bots off your own server, a hosted sandbox puts their computers in someone else's cloud. [Boat](https://sfcrewai.com/sandboxes/boat/) is what SFCrew Cloud uses, and [E2B](https://sfcrewai.com/sandboxes/e2b/) pauses idle computers instead of deleting them. If you already run a cluster, [Kubernetes](https://sfcrewai.com/sandboxes/kubernetes/) gives you one pod per computer and lets you add gVisor or Kata for a stronger boundary. For a bot that needs your real apps and logins, see [your own computer](https://sfcrewai.com/sandboxes/your-computer/). The [sandbox comparison](https://sfcrewai.com/sandboxes/) puts every option side by side.

## Limits and security

Every computer container starts with all Linux capabilities dropped and `no-new-privileges` set, so nothing inside can gain root powers. By default each one is capped at 2 GB of memory, 2 CPUs and 2048 processes, and each bot gets its own network that only the supervisor and screen proxy join.

- A container shares your server's kernel. It is not a virtual machine, so a kernel bug could let a process escape it. If that matters to you, use a hosted provider or Kubernetes with gVisor or Kata.
- Restricted networking gives computers the public internet but blocks your LAN, the Docker host and cloud metadata addresses. It needs Linux Docker Engine with iptables and the host rules from `infra/compose/restrict-computer-egress.sh`. By default the stack checks for those rules and falls back to open networking without them, so a server without the rules lets bots reach your LAN. Set `SANDBOX_COMPUTER_EGRESS=restricted` to refuse to start computers instead. Docker Desktop for Mac or Windows, rootless Docker and nftables hosts can't use restricted networking. The [Docker computers guide](https://github.com/Isuhail29/sfcrew-ai/blob/main/docs/self-host-docker-computers.md) has the details.
- There is no per-domain allowlist. A bot can reach any public website.
- Anyone who controls the supervisor controls Docker on that machine, which is why it stays on the internal network behind its own token.

## How to set it up

These steps are for whoever runs a [self-hosted SFCrew](https://sfcrewai.com/self-hosted-ai-agent/). Docker computers come with the published install, so there's no extra provider to configure, and they are set by the server's environment, not in the app's Settings. If you'd rather not run a server, the [desktop app](https://sfcrewai.com/download/) can start the same install on your Mac or PC.

1. Install Docker Engine 26 or newer with the Compose plugin on the machine that will run SFCrew.
2. Run the installer from the [self-hosting guide](https://sfcrewai.com/docs/self-host/). It writes a `.env` with random secrets, including the `SANDBOX_SUPERVISOR_TOKEN` the supervisor needs, and starts SFCrew with `SANDBOX_PROVIDER=docker`.
3. On Linux Docker Engine, let the installer apply the restricted-networking rules when it asks for sudo, or run `sudo bash infra/compose/restrict-computer-egress.sh` later.
4. Optionally change the limits with `SFCREW_COMPUTER_MEMORY`, `SFCREW_COMPUTER_CPUS` and `SFCREW_COMPUTER_PIDS_LIMIT`, or share host folders with `SANDBOX_COMPUTER_MOUNTS`, as described in [Docker computers](https://sfcrewai.com/docs/self-host-docker-computers/).
5. Sign up, open a bot and open its computer to check that the desktop comes up.

## FAQ

### Is Docker safe enough for AI agents?

For a personal or team server you control, a locked-down container is a reasonable boundary. SFCrew drops every capability, blocks privilege escalation and caps memory, CPU and processes. A container still shares the host kernel, so for strangers' bots or a public instance, prefer a hosted sandbox or Kubernetes with gVisor or Kata.

### Can I run AI agents in Docker on a Mac?

Yes. The SFCrew desktop app's This computer option runs the whole install in Docker Desktop or OrbStack on your Mac. Restricted networking isn't applied there, so bots can reach your local network.

### Is this the same as Docker Sandboxes?

No. Docker Sandboxes is Docker's own microVM product. SFCrew runs its computers as ordinary containers through its own supervisor.

### Do I need a cloud account to run bots in Docker?

No sandbox account is needed. You still need a model, which can be a hosted API key or a model server you run yourself.

## More sandboxes for AI agents

- [Compare all sandboxes](https://sfcrewai.com/sandboxes/)
- [Boat](https://sfcrewai.com/sandboxes/boat/): Many bots with separate logins
- [E2B](https://sfcrewai.com/sandboxes/e2b/): Public or multi-user deployments
- [Daytona](https://sfcrewai.com/sandboxes/daytona/): Teams already on Daytona
- [Novita](https://sfcrewai.com/sandboxes/novita/): Bots that pick up where they left off
- [Railway](https://sfcrewai.com/sandboxes/railway/): Running everything in one Railway account
- [Wuying](https://sfcrewai.com/sandboxes/wuying/): Windows apps, Alibaba Cloud and mainland China
- [Kubernetes](https://sfcrewai.com/sandboxes/kubernetes/): Teams that already run Kubernetes
- [Your computer](https://sfcrewai.com/sandboxes/your-computer/): Bots that need your real apps and logins

## Sources

- [Docker](https://www.docker.com)
- [SFCrew, Docker computers](https://github.com/Isuhail29/sfcrew-ai/blob/main/docs/self-host-docker-computers.md)
- [SFCrew, self-hosting](https://github.com/Isuhail29/sfcrew-ai/blob/main/docs/self-host.md)
- [SFCrew, computer providers](https://github.com/Isuhail29/sfcrew-ai/blob/main/docs/self-host-sandbox-providers.md)
- [SFCrew, computer runtime and isolation](https://github.com/Isuhail29/sfcrew-ai/blob/main/docs/computer-runtime.md)
