Built by an outside developer
Ocean Drive Racing
A synthwave racer that plays right inside a Reddit post. New street race every day, climb the ranks.
We build games on our own stack. We are not the only ones.
Every feature in ButterStack was built because one of these games needed it. They run on the same pipeline we sell: real version control, real CI, real asset approvals, real store deploys. Three of them are ours, still being built in the open. One was built by a developer outside the company, and you can go play it right now.
Four games, one pipeline.
Three we build in-house. One a developer outside the company built and shipped on the same stack.
Built in-house
Pilot Light
A SNES-style vertical shmup written and playtested by AI agents, one commit and one approval at a time.
Feature yours
Your Game Here
Built something on ButterStack? We would love to feature it on this page.
Tools we open sourced along the way
Building the games meant building the tooling. Most of it is not ButterStack, and you can use it without us.
perforce-docker
A production-ready Perforce server for game dev in about 30 seconds. Docker Compose, depot and protections defaults that suit a game team, and a nightly checkpoint, so a small studio gets real version control for large binary files without first hiring someone who knows Helix Core.
Game dev agents
Field-tested Claude Code agents for Perforce, Unreal, Unity, Lore, Godot, and Jenkins. Each one carries the tool-specific knowledge a general-purpose assistant guesses at: workspace and changelist semantics, engine build flags, and what a CI failure log is actually telling you.
ButterStack CLI
Manage tasks, builds, assets, and approvals from your own terminal. The same commands work in a build step as at your prompt, so you can approve an asset from CI, start a build off a Perforce trigger, or find out what broke without opening a browser.
MCP server
Connect Claude, Cursor, or any MCP client straight to your pipeline. Your assistant reads the real build history, the real approval queue, and the real changelists, so it answers "why did last night's build fail" from your data instead of from a log you pasted in.
ButterStack Connector
Reach a Perforce, TeamCity, Jenkins, GitHub Enterprise, or Horde server that lives inside your studio, without opening a single inbound port. A daemon on your own hardware makes one outbound connection out to us, runs only a typed allowlist of read commands, and keeps every credential on your side of the firewall.
ButterStack Ready
Reference AWS deployments for Perforce, Jenkins, Jira, and Lore, so a studio can stand the whole stack up in its own account instead of assembling it service by service. We run our own studio on these; publishing them is what comes next.
How these were built
Every one of these runs the same loop. Work lands in version control, CI builds it, and ButterStack watches the whole thing as one timeline instead of four dashboards. A Perforce changelist and a GitHub commit arrive through different integrations and come out the other side as the same kind of event.
When a build fails, the AI reads the logs, names the change that broke it, and posts what it found. When an asset needs a human, it goes into an approval queue that can be cleared from a phone. Neither of those is a demo path. They are the same integrations any account gets on day one.
That is the whole pitch, and it is why this page exists instead of a feature list. We could describe the pipeline, or we could show you four games that came out of it and let you go play one.
Build yours on it.
The pipeline these games run on is the product. Connect your version control, your CI, and your tracker, and see your own game the way we see ours.