Skip to content
Notis
Giving an AI Assistant a Real Computer: How Notis Runs on Vercel

Giving an AI Assistant a Real Computer: How Notis Runs on Vercel

Why Notis puts the Portal on Vercel and builds its Cloud Computer on Vercel Sandbox — snapshots, deadlines, shared caches and the egress problem nobody warns you about.

Most AI assistants can talk about a spreadsheet. Very few can open one, run a script against it, and hand you the result.

That gap is the whole reason Notis has a Cloud Computer. And the reason the Cloud Computer exists at all is Vercel — specifically Vercel Sandbox, which gives every Notis user a real Linux machine the assistant can drive on their behalf.

Here is how that actually fits together, and what I learned wiring it up.

Giving an AI Assistant a Real Computer: How Notis Runs on Vercel — figure 1

Two different jobs, two different pieces of Vercel

People hear "we're on Vercel" and assume the whole product is a Next.js app. Ours is not. Notis has a Python/FastAPI backend that owns the business logic, the agent loop, the channels, and the tool dispatch. That part does not run on Vercel.

What does run on Vercel is the Portal — the Next.js web app people log into at app.notis.ai. It's the surface where you review documents, manage automations, connect integrations, and watch an agent work. It's a good fit for Vercel's deployment model: preview builds on every branch, instant rollbacks, no server to babysit.

The second piece is the interesting one. Vercel Sandbox is a separate product that spins up short-lived Linux environments over an API. We use it as the execution substrate for what users see as the Cloud Computer.

What "Cloud Computer" means in practice

When someone asks Notis to scrape a set of pages into a spreadsheet, convert a folder of PDFs, run a one-off Python script, or hand a coding task to Claude Code, the assistant does not simulate any of that. It provisions a sandbox and does the work in it.

Our bridge to Vercel Sandbox covers the operations you'd expect from a machine you actually own:

  • create and resume a session
  • execute commands and stream their output back into the conversation
  • read, write and move files
  • take and restore snapshots
  • attach a domain so a dev server is reachable in a browser
  • stop and delete the environment

The snapshot part is what makes it feel like your computer rather than a disposable container. A base snapshot is built ahead of time with the runtimes and CLIs we expect people to need, so a session doesn't spend its first two minutes installing Node. We garbage-collect old snapshots on a schedule, because snapshot sprawl is a real cost and nobody notices it until the bill arrives.

The parts nobody warns you about

Three things ate more of my time than the happy path.

Deadlines. A sandbox command has a provider deadline. An agent's command does not. If a user asks for something that takes eleven minutes and the segment timeout is shorter, you don't get a clean error — you get a half-finished job and a confused assistant. We ended up modelling segment timeouts explicitly, so the agent knows how much runway a command has before it starts, and can split work instead of dying mid-flight.

Shared caches across sessions. Package caches are the difference between a two-second start and a two-minute one. But if a maintenance pass deletes a cache while another command is mid-download, you get corruption that looks like a network bug. We put a bounded flock around it: ordinary commands queue behind an exclusive maintenance pass, and if they wait too long they run unlocked instead of burning the provider deadline. Worst case, a command re-downloads a cache. That's a fine worst case.

Egress IPs. This one surprised me. Several of the services Notis talks to — OpenAI and Composio among them — allowlist outbound IPs. Sandboxes don't have stable ones. So sandbox traffic that needs an allowlisted address dials out through a small relay we host elsewhere, with an explicit allowlist of destination hosts. Everything else goes direct. It's the kind of plumbing that is invisible when it works and completely mystifying when it doesn't.

Giving an AI Assistant a Real Computer: How Notis Runs on Vercel — figure 2

Why a sandbox instead of a container we run ourselves

I've built the "just run Docker somewhere" version before. It's not hard to start. It's hard to keep.

You end up owning image builds, warm pools, per-user isolation, disk pressure, zombie cleanup, and a scheduler. None of that is Notis. None of it is why anyone pays us. Vercel Sandbox gives us an API where the isolation boundary is the vendor's problem and our problem is the agent's behaviour inside it.

The honest trade-off: you inherit the vendor's limits. Deadlines, resource ceilings, and edge firewall behaviour are theirs, not yours. We spend real effort detecting those cases and turning them into something an agent can reason about rather than a stack trace a user has to read. That's the tax. I'd pay it again.

What this unlocks for the person messaging the assistant

Here's the part that matters outside engineering.

Because the Cloud Computer is a real machine, Notis can hand a task to a coding agent and let it work for twenty minutes while you go do something else. It can install a CLI it needs mid-task. It can start a dev server, get a public URL, open it in a browser, take a screenshot, and tell you whether the change actually worked. It can keep a working directory between messages, so "keep going on that" means something.

That's a different product from an assistant that can only compose text. And it's only possible because someone else runs the machines.

If you're building something similar

A few things I'd tell my past self:

  1. Decide early what is stateless and what is not. Our Portal is happily stateless on Vercel. The sandbox is deliberately stateful. Mixing those assumptions causes pain.
  2. Model the deadline in your agent, not just your client. An agent that knows it has four minutes behaves differently from one that finds out after the fact.
  3. Snapshot your base environment, then garbage-collect it. Both halves. The second half is the one people skip.
  4. Assume your sandbox has no stable identity on the internet. Plan for allowlists before a provider rejects you in production.

Notis is a founder-led product. We're still expanding from voice-to-Notion capture into connected-tool workflows, and the Cloud Computer is the piece that turned "assistant that writes things down" into "assistant that finishes things." Vercel runs the machines underneath it.

If you want to see what that feels like, try Notis and ask it to build you something.

is the founder of Mind the Flo, an Agentic Studio specialized into messaging and voice agents.

Related posts