I was wrong about agent sandboxes.
In my article I said pattern 1, where the agent runs on your infra and only calls a sandbox for tools, doesn't work at scale. I moved everything to pattern 2 and put the whole agent inside a VM.
At the time that made sense but today I'd pick pattern 1.
For your own personal agent, a coding agent, or a small project, isolating the whole agent in a VM is still a great default. I would keep doing it.
At real multi-tenant scale it falls apart.
There will be more agents than humans. Every human gets one computer. Giving every agent its own VM running 24/7 means billions of CPU-hungry machines, and we're already short on compute.
Most of what an agent does doesn't need a machine at all. It thinks, calls APIs, reads pages, and waits. Nobody needs a 4 CPU VM sitting idle so an agent can run a simple JS script once an hour.
What I'd build now:
> the agent loop runs on shared infra that scales
> it gets a sandbox only when it has to run untrusted code
> sandboxes spin up in seconds and die right after
> zero state on the machine, everything lives outside it
VMs are a tool the agent calls, but they shouldn't be where it lives.
Sandboxes shouldn't be temporary by design.
At Oblien, we built flexible sandboxes that you can turn into persistent workspaces with just one click.
Imagine your sandbox isn't just something you spin up temporarily, but something that can also run 24/7, be turned off whenever you want, or even converted into a fully serverless environment that wakes up on the first request.
All of this, with VM-to-VM networking, desktop support, internal APIs, and much more.
That's the power of Oblien, and it's the vision we started working towards a year ago. We're still building on it.
If you need battle-tested sandboxes, persistent workspaces for your AI agents, or environments to run your apps, Oblien is the way.
Day 3/30: macOS workspaces
Need a Mac to build an iOS app? Most cloud sandboxes stop at Linux.
On Oblien, pick macOS from the image list. Terminal, files and commands run inside macOS, through the same API as any workspace.
Your agent can have a Mac too.
Day 2: Sleep when idle
Your VM doesn't need to keep running when it's not being used. And you shouldn't have to miss a single request because of it.
Set a rule to automatically put your VM to sleep when idle. Oblien saves its memory to disk and releases the compute, so you stop paying for idle resources.
The moment a new request comes in, it wakes up and continues right where it left off. Whether it's your app, workload, or AI agent.
Day 2: Sleep when idle
Your VM doesn't need to keep running when it's not being used. And you shouldn't have to miss a single request because of it.
Set a rule to automatically put your VM to sleep when idle. Oblien saves its memory to disk and releases the compute, so you stop paying for idle resources.
The moment a new request comes in, it wakes up and continues right where it left off. Whether it's your app, workload, or AI agent.
Oblien lets you run any image, including standard Docker images, inside hardware-isolated MicroVMs instead of regular containers.
Each VM gets its own kernel and isolation boundary while remaining lightweight.
You get the best of both worlds: keep using your existing Docker images and workflows while benefiting from much stronger isolation.
This is what allows platforms like @openshipio to run their cloud infrastructure with each customer's workload isolated in its own VM, while still taking full advantage of the existing container ecosystem.
Oblien lets you run any image, including standard Docker images, inside hardware-isolated MicroVMs instead of regular containers.
Each VM gets its own kernel and isolation boundary while remaining lightweight.
You get the best of both worlds: keep using your existing Docker images and workflows while benefiting from much stronger isolation.
This is what allows platforms like @openshipio to run their cloud infrastructure with each customer's workload isolated in its own VM, while still taking full advantage of the existing container ecosystem.
We're starting a 30-day challenge. 30 days to show you what Oblien can do and just how flexible it is compared to other solutions.
Every day, we'll highlight a different feature and show you how it can make a difference in your workload.
We're starting a 30-day challenge. 30 days to show you what Oblien can do and just how flexible it is compared to other solutions.
Every day, we'll highlight a different feature and show you how it can make a difference in your workload.
We previously added MCP to OpenShip so you could control the platform from your coding agents.
But we started thinking: why should you have to leave OpenShip and go through all those connection steps just to use your own agents?
What if you could use your existing coding agent directly inside the OpenShip UI?
You could also let it work automatically based on triggers. For example, get a report when a service goes down or a deployment fails, and let your agent investigate what happened -> then send you message via your notification channel.
That's what we're working on: bringing your existing coding agents directly into OpenShip Desktop.
For example, if a deployment fails, your agent can investigate the issue and you can apply its fix with one click, without leaving OpenShip.
Oblien Sandboxes can communicate with each other over a private internal network.
Control which VMs can send requests to others directly from your dashboard or SDK.
Build interconnected, unstoppable networks of VMs that scale with your workloads.
MindWire helps you ship your next AI product idea.
Build custom AI bot apps in minutes, like your own GrokBot assistant, or deploy agents for almost any use case.
Give your bots everything they need:
- Remote control
- Notifications
- Scheduled tasks
- Custom logic and runtimes
- Custom tools and knowlage
- API integrations and more
Available with TypeScript and Go SDKs.
Free and Open Source from Oblien