How Phaser Gives Every User a Game Studio in a Sandbox

Phaser is the open-source HTML5 game development framework created by Richard Davey in 2013, and actively developed for over 13 years. More than 100,000 developers have used Phaser to ship tens of thousands of games played by millions of players.

In July 2026, Phaser Studio launched the Phaser Game Agent. Users describe a game in one sentence, click through a few personalization options, and the agent handles the entire build of the game. Every game it makes is built with Phaser's game studio running in a Superserve sandbox. The game's design, code, art, and sound is crafted by the agent, and published from within the sandbox. The user gets back a link to the game, ready to play and to share with their community.

With Superserve, Phaser built and launched the Game Agent in under a month without having to build or maintain any new infrastructure.

A Game Engine for Non-Engineers

For thirteen years, using Phaser meant pulling it from npm, wiring it into a project, and reading the docs. That worked for developers. Most of the people arriving at Phaser today are not engineers.

"Seventy, maybe eighty percent of our users don't know how to code, and don't want to. They came to make a game, not to learn a terminal."

— Richard Davey, CTO and creator of Phaser

That one fact set the architecture. If your user has Claude Code or Cursor installed, the agent runs on their machine. If four out of five of your users have never opened a terminal, the agents must run on virtual machines you provision in the background.

If your agent is executing model-written code, installing packages, and driving a headless browser, on demand, for anyone who signs up - that cannot live on your application servers.

Phaser needed a stateful cloud computer for every agent with full control over its lifecycle, provisioned instantly, and configured programmatically at runtime.

Phaser's game studio in a Superserve sandbox

The sandboxes Phaser runs on Superserve are not generic Node boxes. Phaser's sandbox template turns each one into a full game studio:

• The engine: the Phaser team rebuilt their game engine specifically for agents to write against. The engine is baked into the sandbox image, and updatable in place when new engine versions ship.
• Build tooling: everything needed to validate the agent's code, like Node, Typescript, Linters, etc., is baked into the template.
• Playwright: the agent launches the game it just wrote, plays it, and screenshots itself doing so. Chrome's software renderer does the work, so the sandbox never needs a GPU.
• Skills files and agent memory: everything the agent needs to remember about the game it's making is persisted on the sandbox. Superserve sandboxes resume from that exact state next time.
• Locked scripts: custom scripts that hit Phaser's API directly. The agent can invoke them, but it can't read them.

That last detail matters more than it looks. The agent has no direct database access; every call routes through Phaser's gated MCP server, which checks credit balance and account status before it does anything.

"We hide quite a lot from the agent. Otherwise it starts doing things we really don't want it to do."

— Richard Davey

The sandbox is where that boundary gets enforced. Superserve isolation is what makes the boundary real.

Sandbox the agent, or its execution environment

The Game Agent has two paths in, and they converge on the same sandbox.

The hosted agent. A user types a prompt, stacks a couple of art styles, picks a model, and hits build. Phaser provisions a Superserve sandbox with its game studio template and runs a coding agent CLI on it headlessly. About twenty minutes later, an email arrives with a link to the finished game. Most users close the tab and go do something else.

Bring your own agent. Developers already living in Cursor or Claude Code connect to Phaser's MCP server instead. Their agent reads files, writes code, and runs builds, but nothing happens locally. Every operation goes through MCP into a Superserve sandbox and back.

"None of the files get created on their machine. It all gets built in the sandbox, because that's where our tooling is. That's how we know the code is correct."

— Richard Davey

Same environment, same validation, same guarantees, whether Phaser is running the agent or the user is.

The trick: stream files, don't generate them

When the agent needs a component (say, a character that fires a grappling hook with a rope), it doesn't write one. It searches Phaser's component database, and the file streams straight onto the sandbox filesystem, never passing through the agent's context.

"Otherwise the agent pays the input tokens and the output tokens to write something we already have. So we stream a lot of files onto the sandbox. An awful lot."

— Richard Davey

Traffic runs both ways: when a build finishes, logs, source, and generated assets stream out to Phaser's CDN. Games are served from there, not from the sandbox, which is what makes the last piece work.

Pause, resume, pause

The moment an MCP command finishes, the sandbox pauses.

The user plays their game the whole time, served as static files, with no sandbox in the loop. Then they decide the character should jump twice as high. The request lands, the sandbox resumes, the agent makes the change, the sandbox pauses, the result comes back. They play for five more minutes and change their mind again. Resume, edit, pause.

Compute burns only during the seconds an agent is actually working. Everything else is a static file and a paused VM. For a product where users iterate on a game for hours, that pause/resume cycle is essential for managing sandbox cost at scale.

Why Phaser chose Superserve over alternatives

The Phaser team tested four sandbox providers before landing on Superserve, putting real money down on each one, including offerings from Vercel, Sprites.dev, and Cloudflare. Most of them broke on the same requirements.

"We couldn't configure the templates the way we needed, and we couldn't hand a sandbox to an end user. That ruled out most of them straight away."

— Richard Davey

What Superserve got right:

• Templates that hold a real environment. A custom game engine, Playwright, a build chain, agent memory, and locked-down scripts, expressed as a template, versioned by Phaser, updatable without rebuilding the product around it.
• Sandboxes you can hand to an end user. Most platforms assume the sandbox belongs to the developer. Phaser provisions one per user, per game, on demand, for people who will never know it exists.
• Lifecycle control that belongs to you. Pause, resume, idle timeouts, persistence: set by Phaser, not dictated by the platform. Hosted builds run on a four-hour idle timeout; BYO-agent sandboxes pause the instant a command returns.
• A simple, fast API. Provision, configure, run, pause: sandboxes come up in milliseconds, as opposed to costing seconds on container-based solutions.
• Parallelism on tap. Batch jobs launch as many sandboxes as the work needs, at any hour.

"I wanted a simple API that spins up sandboxes fast, that we could configure, that we could build our own templates on. That's exactly what we got."

— Richard Davey

Could Phaser have built this themselves? Technically, yes. But the engineers who would have spent the next several months on provisioning, isolation, lifecycle management, and fleet monitoring are the same engineers who shipped the Game Agent instead. Phaser went from concept to live product in under a month, without worrying about managing infrastructure.

The hidden Build Farm

Here's the part that doesn't appear in the product UI. Every Game Agent run starts by searching a database of template games for something close to what the user described. That corpus (the games, the effects, the components) is built in Superserve sandboxes too.

The team queues a batch of games, fires it off, and goes to bed. The batch launches sandboxes in parallel, runs an agent headlessly on each, and by morning there's a pile of new games to review.

"We wanted these built overnight while we were asleep. We can run 24/7, and we can run in parallel, neither of which we can do on our own machines."

— Richard Davey

The same primitive that serves every user signing up is also the team's internal render farm. They never had to build either one.

Serious infra quietly powering the fun and learning

The games coming out of the Game Agent are personal: something for a Discord community, something for a website, something for a class. A lot of them are educational. Games that teach Korean. Games that teach English to kids in China. A teacher building a game about adverbs for their students.

"We're not here to take on Unity or Unreal. We're here to let people make things easily."

— Richard Davey

That ambition only works if the infrastructure disappears. A user typing "cute and fluffy, but Greek" into a text box should never need to learn what a microVM is.