Shopify attracts people who love to tinker. Building has never been the bottleneck here. People are always making things: prototypes, dashboards, little tools for their teams. The hard part was getting those things in front of anyone else.
Our solution to this was Quick: an internal platform where you drop in a folder of HTML and assets and get back a secure URL that only Shopify employees can see. No frameworks, deploy pipelines, or config files. You just upload a folder and your site is live. If you need a database, AI, file storage, or websockets, those are just an API call away.
We launched Quick in July 2025, and the timing turned out to be perfect. AI had just gotten good enough that people across every discipline, not just us engineers, could generate a working website from a prompt. Quick gave them somewhere to put it. AI wasn't why we built it, but it's a big part of why it took off.
Today, Quick hosts more than 50,000 sites across Shopify. Over half the company has created at least one. Everything from dashboards that teams rely on daily to a multiplayer mountain-climbing game that nobody asked for but everybody plays.
This is how we got here.
Architecture
Quick started with the idea of finding the simplest way to put HTML files somewhere and serve them. And what's simpler than every "site" being just a folder of assets in a Google Cloud Storage bucket?
To serve them, we put a lightweight NGINX server in front, with a wildcard config so that mysite.quick.shopify.io maps straight to the mysite folder. But we didn't want NGINX to know anything about querying buckets. This is where gcsfuse came in: it mounts the bucket as if it were part of the local filesystem, so NGINX thinks it's just serving local files.
Authentication is just as simple. The whole server sits behind Identity-Aware Proxy (IAP), so every request is already a verified Shopify employee before it ever reaches a site.
The `quick deploy` command is nothing more than a small wrapper around gcloud’s rsync. It grabs the files from your local directory and pushes it up directly to the bucket. Feels like the good old days of FTP.
The next step: APIs
In this configuration, Quick could already accommodate many use cases. But what if your prototype or site needed just a little bit of functionality from a backend? Maybe it’s to store a bit of data, or upload a file, or call out to AI. Now suddenly you’re left having to spin up databases and infrastructure, which feels like overkill in many cases.
That’s when we thought to ourselves, “what if we had a single server that all sites on Quick could access and could provide basic backend services?” Give it a nice little client-side API and you’re all set.
Want your Quick site to save a blog post?
const posts = quick.db.collection('posts');
const created = await posts.create({
title: 'Hello Quick DB',
status: 'draft',
created_at: new Date().toISOString()
});
Need realtime updates when something changes?
const unsubscribe = posts.subscribe({
onCreate: (doc) => console.log('New:', doc),
onUpdate: (doc) => console.log('Updated:', doc),
onDelete: (id) => console.log('Deleted:', id),
});
The original Firebase was a big inspiration for us. It let you easily spin up a key value store exposed to the internet that you could just read / write to. You didn’t need schemas, or migrations, or anything. And best of all, anything you saved in it magically synced across all connected clients.
We initially played around with the idea of each Quick site having its own sqlite database, but that didn't play as well as we hoped with gcsfuse. It was much easier to spin up a single CloudSQL database with a nodejs server in front of it.
AI was the next feature we added, so that any Quick site could make client-side calls to the LLM of their choosing without needing to provide any API keys. The API keys are stored on the server and passed along to our Shopify AI proxy.
// Make LLM calls right from your browser
const res = await quick.ai.chat([{ role: 'user', content: 'Summarize my tasks' }]);
// Can also call image gen and any other frontier models
Then we kept going through the list of things that sites might need. We added file uploads, data warehouse support so sites could pull in data from Big Query, and Websocket support to make it possible to build collaborative apps.
Since the sites are behind IAP, we have all the user information needed for any request, which we can provide to the client. That way sites can instantly know who is using it, and that becomes part of a nice little Identity API with things like name, title, team, Slack handle, etc.
By the end of it we landed on this core group of features:
- Database
- File uploads
- AI (LLM, image gen, etc...)
- Data warehouse
- Websockets
- Identity
It's amazing how just with these few building blocks it feels like we can recreate the entire Internet
Exposing any of these services to the public internet without authentication would make an ops team lose sleep. But since Quick sites are only accessible within the trusted walls of Shopify, we have the luxury of being able to provide a zero-config client side API. All keys are stored on the server.
Agents + Quick
While there are docs for all the Quick APIs, I’m not sure if anyone has ever actually read them. That’s because Quick comes out of the box with all the skills your agent needs to use them. All you have to do is type `quick init`, launch your favourite agent, and you’re off to the races.
“Make me a site where my team can vote on lunch spots in real time.”
"Make me a site where we can run a live poll during the all-hands."
In less than a minute you have a site up and running, ready to be shared and used by all.
"Can I see multiplayer cursors for everyone on the site?”
Thanks to the websocket API, you sure can!
Adoption
Quick launched internally in July 2025. Those of us who were already vibe-coding HTML artifacts finally had somewhere secure to host them. Those struggling with app deployment complexity now had an easy path. And for everyone else, they didn't see what the big deal was….yet.
For the first bit, it felt just like Geocities. People were making personal homepages.
Out of pure nostalgia, someone made a webring and even a birthday site with a guestbook.
These days, if someone puts an open guestbook or comment field on the open web, it’s sure to get hacked or filled with spam. But in the Shopify trust bubble, that’s not a concern. We were reliving the joys of the early 2000’s web without any of the downsides. The big difference is that anyone could now author HTML thanks to AI.
Then in December 2025 things really popped off.
It’s now being used for everything from prototypes, dashboards, dev tools, and presentations.
Designers will just create custom tools for their teams to use. Like Artifact, an internal tool for sharing work.
It’s become second nature to reach for it. Want to share an idea for how themes are shown in the admin? Don’t share an image, share a Quick site.
Need a tool for customizing the interactive background on the latest Remix landing page? Build a Quick site.
Google Meet had a small outage last year, and within 15 minutes someone vibecoded a replacement that used WebRTC for communication.
It’s completely changed the culture of how we build and share. And while we are using it mostly for “serious” use cases, there’s still that underlying Geocities feel that invites people to tinker with weird and delightful things.
There’s a good amount of games that people are building, especially since the websocket API makes it so easy to add multiplayer functionality. Over 140 games were submitted at a recent game jam.
If you wanted to add a leaderboard to a public game on the internet, your first thought would be how to prevent hackers. Once again, Quick being internal removes all that. It takes “should we add a leaderboard” from a “maybe” to a “hell yes!” It’s a creative paradise.
An emergent ecosystem
One thing we didn’t anticipate when building Quick is how people would start embedding sites within other sites. Because it's just the web, one site can import code straight from another. So we noticed people started publishing shared JS libraries, and even making landing pages for them.
Quick is growing into its own internal ecosystem. You can find libraries for adding Figma-style comments to your site, for adding voice, analytics, achievements, and so much more.
The Quick philosophy: Keep it simple + embrace the constraints
You might be wondering how we implemented permissions, or how people manage their sites. Turns out there’s none of that. All Quick sites are open to all employees. There’s not even a concept of a “site owner.” Want to update your site? Overwrite it with new files. Want to take over a subdomain? Overwrite it!
It’s amazing how the complexities of the open web just disappear when something is an internal tool.
Every day we get new feature requests. Can we get custom backends? Can you add cron jobs? We've gotten really good at saying no, which is especially hard in an AI climate where you can vibecode a new feature in minutes. But the constraints are the whole point.
A small, fixed set of capabilities is what keeps Quick simple to use and maintain, and it's what makes people more creative, not less. When someone comes to us with feature request X, more often than not we can show them it's already possible. They just have to approach it differently, and they leave a little surprised at what the existing pieces can do.
Maintenance
As of now over 50,000 Quick sites have been created. More than 50% of Shopify employees have created at least one site. And all of this is running on a single VM that costs $200 a month to run.
Since so much of it is client side, the server is only in charge of serving assets and processing API requests. As for scale, we know how many employees we have so there’s never a danger of somehow 1,000x more people starting to use the platform all of a sudden.
That’s not to say there haven’t been hiccups along the way. We’ll sometimes find someone trying to do a batch process job on a loop and store massive amounts of data in the database. That’s led us to implement some rate limiting practices.
We’ve also over time migrated away from node to using Go, which helps a lot with memory management and parallelism.
A place to tinker
We started Quick because sharing things at Shopify was harder than building them. The fix turned out to be almost comically simple: a folder of files, a URL, and the trust that comes with everything being internal.
Because everything on Quick is visible to every teammate, each site teaches the next person what's possible. Tobi has a word for this kind of environment: Lehrwerkstatt, a learning workshop where knowledge spreads through proximity. We just gave it a domain name.