Official Docker image / dockerized BrowserOS runtime for self-hosted automation

[agiancon]

Hi BrowserOS team,

I am integrating BrowserOS into a self-hosted automation/orchestration flow where each user session runs in an isolated container.

From the public repo, I can see the desktop distributions and the CLI/MCP setup, but I could not find an official Docker image or a supported containerized runtime for BrowserOS itself.

This is currently the main blocker for my use case.

What I need is a dockerized BrowserOS runtime that can be started per session, ideally with:

• an official image published on GHCR or Docker Hub
• stable version tags
• documented ports and environment variables
• a health endpoint
• support for headed and/or headless operation
• CDP / WebSocket connectivity
• optional persistent profile volumes
• guidance for GPU and non-GPU deployments
• at least x86_64 support first, with ARM as a future extension

My concrete use case is:

• one BrowserOS instance per automation session
• an orchestrator that starts and stops ephemeral containers
• predictable startup and packaging, without depending on desktop-only installation flows

So my questions are:

1. Is an official dockerized BrowserOS runtime on the roadmap?
2. If yes, is there an approximate timeline or an interim recommended approach?
3. If not, would you be open to contributions or to a reference Dockerfile for a supported self-hosted deployment?

If this is already available somewhere and I missed it, a pointer to the right repo or docs would be enough.

Happy to test early versions and provide feedback.

Thanks.
AlgoFin Team

[Nikhil (shadowfax92)]

Thanks for the detailed writeup — this is one of the clearest self-hosting asks we've gotten, and the spec (per-session containers, health endpoint, CDP, profile volumes) is exactly right.

Straight answers to your three:

1. Honestly, an official dockerized runtime isn't something we have plans to build right now. It's a real product surface — stable tags, health endpoint, supported headless mode — and with our current bandwidth I can't commit to it. I'd rather tell you that than leave you waiting on a maybe.
2. Interim: because BrowserOS is a Chromium fork, you can run the Linux x64 build headless in a container and drive it over CDP / --remote-debugging-port yourself today. It's unsupported and you'll own the packaging, fonts, and sandbox flags, but people run Chromium this way and the same applies here. (We only ship Linux x64 right now, which lines up with your "x86_64 first.")
3. Yes — we'd be glad to take a community reference Dockerfile. If you get a working setup, a PR or even just posting your Dockerfile here helps the next person, and it's the most likely path to this ever becoming supported.

One thing that'd genuinely help me understand the need: what are these sessions actually doing? Walk me through a single automation run end to end — what the orchestrator kicks off, what the browser does, what comes out. I ask because "one BrowserOS per session" is a strong pattern, and knowing the real job behind it tells me whether a container runtime is the right answer or whether something lighter (the MCP server, or plain headless Chromium) gets you there sooner.