Cloud "agent" products keep showing up with a cute name and a monthly bill: you get a sandboxed browser, a queue of tasks, and a vendor holding your logins. invisible_dots is the self-hosted answer from Federico Elia's team: each Dot is a persistent AI agent with its own QEMU virtual machine, disk, Firefox-based browser identities, skills folder, and permission gates you control.
It is MIT licensed, alpha status, and aimed at people who want something in the spirit of OpenAI Dots or Claude Cowork without shipping prompts and session data to someone else's control plane. The README is blunt: there is no hosted service, no telemetry, and you build the stack on your hardware.
What you are actually running
invisible_dots is a control plane on your host plus one VM per Dot. The Dot gets a Linux desktop environment, shell, files, memory notes under /home/dot/memory, and skills it writes itself under /home/dot/skills. When idle, the VM powers off after a timeout (15 minutes in the sample config) and wakes for the next message, queued task, or scheduled automation.
You talk to Dots through a web UI (default http://127.0.0.2:3000), CLI, HTTP API with live events, Telegram, or optional WhatsApp. The model comes from OpenRouter with your API key; reasoning runs inside the Dot's VM, not on a mystery SaaS backend.
Browser work goes through invisible_playwright_mcp, a patched Firefox stack meant to behave like a normal desktop browser with per-identity cookies and fingerprints. That is why the tagline mentions anti-bot systems: the project targets automation on sites that reject obvious headless Chrome. The project's own disclaimer still applies: your Dot uses your accounts, from your IP, and you are responsible for site terms and robots.txt. We are not writing a guide to harass third-party platforms; we are describing software people already run for invoice downloads, fare tracking, and repeat internal chores on sites they legitimately access.
Why self-host instead of rent a Dot
Approvals stay on your network. Tools are grouped into allow, ask, or deny. "Ask" lands in an Inbox and survives server restarts. That is the right shape for semi-autonomous agents that can touch files and browsers.
Disk and identities persist. A Dot remembers where the invoices page was last month because its overlay disk and browser profiles survive reboots. Cloud demos reset; this does not.
MCP servers on the Dot's machine. Hook custom tools the same way you would in Claude Code, with secrets kept out of the shared config file.
Canadian hosting angle. If compliance asks where agent traffic and stored files live, "on our VPS in Quebec or Ontario, keys in our vault" is a cleaner answer than routing employee workflows through a US agent startup.
What it takes to run (read this before you pick a plan)
This is not a single Docker container and a prayer.
- Host OS: Linux or Windows on x86-64 with hardware virtualization. macOS is not supported.
- Stack: Node 24+, Go 1.25+, Git, QEMU 8.2+.
setup --allinstalls QEMU and enables KVM (Linux) or Windows Hypervisor Platform. - Disk: at least ~20 GiB for the data directory; each Dot can grow a copy-on-write disk up to its configured cap (40 GB in samples).
- RAM: sample config uses 4 GiB per running Dot, plus roughly 0.8 GiB per open browser tab (up to three by default). One Dot doing browser work can easily want 6+ GiB while awake.
- Status: alpha. CI passes end-to-end tests on Linux with KVM; Windows paths are more manual.
Quick path on Ubuntu 24.04 (from the README): clone, npm ci, build the CLI workspace, node apps/cli/dist/invisible-dots.mjs setup --all, then server, paste OpenRouter key in the UI, create a Dot.
Can you run this on a Canadian VPS?
Maybe, but check nested virtualization. Dots spawn QEMU VMs on the host. Many budget VPS plans expose a virtual CPU without KVM to guests, or forbid nested virt entirely. Without it, performance collapses or setup fails. Bare metal or a KVM-capable VPS (often called out explicitly in the provider docs) is the realistic choice for always-on Dots.
Also plan egress and secrets: the Dot browses from the server's IP. If that IP is a datacenter range, some consumer sites will still block or challenge it regardless of browser patching. For shop portals and B2B tools you control, that is usually fine. For mass public scraping, wrong tool and wrong ethics.
If you only need a lightweight chat agent without a full desktop VM per task, our write-up on nanobot covers a thinner stack (invisible_dots even credits nanobot in its engine lineage). Pick invisible_dots when the workload genuinely needs a persistent computer and browser identities, not when a webhook and a script would do.
Security habits that matter
A Dot is only as safe as the permissions you grant. Start with deny-by-default on shell and file tools, use "ask" for anything that spends money or posts publicly, and segregate Dots (one VM each) so a compromise in a shopping automation does not share disk with payroll exports.
Keep the control plane off the public internet unless you put real auth and TLS in front. Telegram and WhatsApp channels are convenient; treat their tokens like production passwords.
Bottom line
invisible_dots is an ambitious self-hosted agent platform: real VMs, real browsers, real persistence, and a permission model that assumes you are an adult. It is alpha, heavy on RAM and KVM, and not a fit for tiny shared hosting. For the right team, though, it is one of the few open paths to "my own Dot" without renting someone else's computer.
Need a Canadian VPS or bare-metal box with nested virt and enough RAM for a Dot? Talk with Swift Host. Tell us how many Dots you want awake at once and we will size it honestly.
