The Company
Draftbit started in 2018 as one of the first no-code platforms to let non-developers build mobile apps visually. The idea was to give designers, founders, and early-stage teams a way to build and ship real applications without needing a full engineering team behind them.
The product has evolved considerably since then. In late 2025, Draftbit launched an entirely new version, built around AI. Users can now invoke Claude Code, OpenAI Codex and Google’s Gemini models inside a protected cloud sandbox, with the full tooling stack pre-configured and running in the background. The output is React Native for mobile apps, or React for the web, with code generated in TypeScript or JavaScript. The platform is designed for people who aren’t full-scale developers but want to go further than a drag-and-drop tool allows: building first versions, testing ideas, moving through prototypes quickly.
Like the code it generates for users, Draftbit’s codebase is written almost entirely in a combination of JavaScript and TypeScript. The company has a larger professional services division, but the engineering team that built and runs the SaaS product comprises just six people, and none of them are infrastructure specialists. The product supports around 200,000 users who between them have built over 50,000 apps.
The Problem: Personalized Containers at Scale
When a user opens their app in Draftbit, a dedicated cloud container spins up for them. The container is a purpose-built environment with the right libraries, runtimes, and dependencies already configured. That container is where everything happens: it’s where the AI agents run, the live preview of the app renders, and all the communication back to Draftbit’s own infrastructure happens. When the session ends, the container winds down.
Draftbit's own front and back ends, along with supporting services like an API proxy, run as more traditional client-server infrastructure. Sandbox servers are a separate layer: when a user opens an app, Draftbit checks the Cycle API to see whether that app's sandbox is already running. If it is, the user drops straight in. If not, Draftbit spins one up, pulling the latest code from Git, bringing preview servers online, and connecting the builder UI once everything is ready.
Before adopting Cycle, Draftbit was first on Heroku, then Fly. “We had problems with those platforms around uptime,” notes Brian Luerssen, Draftbit’s co-founder and CEO. “We moved to Cycle around 2023, originally to help us with a scaling challenge in our V1 platform, and have uninterrupted deploys for our users when they’re building stuff.”
Draftbit was already happy with Cycle but as they started working on the new V2 platform, it became an even better fit. Spinning up individualized containers as Draftbit does is straightforward for individual users, but orchestration becomes complex when you have thousands of concurrent users and containers spinning up and down dynamically, without interrupting sessions already in progress. Cycle solved that problem.
The other approach would have been to run a Kubernetes cluster which, while technically viable, was unappealing for a team with no dedicated DevOps function. “I didn’t want to do that as I’d heard horror stories involving Kubernetes,” Luerssen says.
How a Small Team Can Run a Large Container Operation
The way Draftbit interacts with its infrastructure is deliberately narrow. The team uses GitHub Actions with a custom script to deploy into Cycle. Beyond that, operations are handled by just three API calls: start container, stop container, re-image container. “The complexity is hidden,” Luerssen says. “So for us, the API is very simple.”
Spin-up speed depends on whether an instance already exists. If a sandbox is already provisioned, even in a stopped state, Cycle can start it in around 10 seconds, with a further 20 seconds or so of Draftbit-side checks before the user is fully in. Building a sandbox from scratch takes longer, since it involves creating a new container and pulling everything down fresh.
To avoid disrupting active users when rolling out updates Draftbit uses re-imaging. Whenever Draftbit ships a new production build, it generates fresh images containing updates to preview servers, Claude Code, Codex, and other sandbox tooling, and pushes them into Cycle. Running sandboxes aren't interrupted: instead, the next time it's convenient (typically the next start), the sandbox is brought up to date. Draftbit treats the sandboxes themselves as ephemeral: the source of truth lives in Git and Draftbit's database, not on the container, so sandboxes for inactive apps can be deleted to save disk space and rebuilt on demand without any data loss.
Wind-down is driven by billing tier: free and lower-tier users' sandboxes are spun down aggressively (as fast as 10 minutes of inactivity), while team, pro, and enterprise users' sandboxes stay up much longer. That tiering is also what lets a handful of servers support a much larger population of users than are ever active at once. Draftbit typically runs hundreds of sandboxes currently, doubling or tripling during peak demand, and auto-scaling down overnight. Cycle also lets Draftbit assign different resource tiers, such as more CPU and memory, to higher-value customers. This is something Luerssen says has been a useful, if not yet fully exploited, capability.
The containers run on bare metal servers rented across multiple providers — Google Cloud, Vultr, and Cherry Servers — with geographic distribution handled by Cycle. Provider choice is mainly driven by cost: Draftbit looks for bare-metal hosts with high thread counts and memory (Luerssen cites servers with around 48 threads and 256GB of RAM) that let it pack in many lightweight sandbox instances, each provisioned for 4GB of memory and one vCPU, though actual usage is typically a small fraction of that. Geographic or data-residency-based placement isn't in use yet, but Luerssen says it's something they could support quickly if an enterprise customer required it, given Cycle's dedicated European control plane. The servers run in the cloud, without needing to be managed directly. “The team doesn’t have to think about them much,” Luerssen says.
The simplicity is by design. Cycle is an opinionated platform: it makes clear choices about how things should work. This means that Draftbit’s engineers can move quickly, without needing to develop their own strong opinions about infrastructure. The comparison Luerssen reaches for is familiar to anyone who has spent time deep in a hyperscale cloud console. “With the Amazons or Google Clouds of the world, you can figure it out. But it’s a sea of options — almost too much configuration for non-DevOps people.”
Cycle, he says, simplified a lot of that infrastructure while still giving access to the underlying Google Cloud environment beneath it.
If an unusual challenge arises, the Cycle team tends to have already solved it. “When we ask how to do something, they generally say, ‘We’ve already built that into the API — you just do this…’ Luerssen says.
Draftbit’s team has a shared Slack channel with Cycle and uses it the same way they use Slack internally, i.e. as a working channel, not a ticketing queue. For a team operating outside its area of expertise, the ability to talk directly to experts matters. “I don’t know enough to have good opinions in DevOps land,” Luerssen says. Cycle’s team fills the gap.
Inside each sandbox, Draftbit runs the equivalent of a personal dev server in the cloud, with the same agents (Claude Code, Codex) a developer might run locally, alongside preview servers and supporting tooling. There is also a lightweight management layer Draftbit uses to restart processes or intervene if an agent gets stuck.
Within a sandbox, agents have broad freedom to modify the app, clear caches, or restart previews, since each sandbox is scoped to a single app and isolated from every other user's environment. If something goes wrong, Draftbit can simply delete and rebuild it. Preview traffic reaches the sandbox through dedicated per-app subdomains, with the builder's live preview connecting directly to the running instance.
Noisy-neighbor issues, such as a runaway process or a loop do come up occasionally. Cycle's CPU and memory limits help contain the impact, though Draftbit's support team sometimes has to step in manually to restart or rebuild an affected sandbox. Luerssen notes this is rare enough that it hasn't demanded further tooling investment on Draftbit's side, though he's looking forward to the more granular per-instance monitoring Cycle has planned, which should reduce the need to SSH in to diagnose a runaway process.
Looking ahead, Draftbit is also working with Cycle on peer-to-peer communication between sandboxes to allow support for cases where a user's apps (say, a website, web app, and mobile app) need to talk to each other, or where a single agent needs to operate across multiple sandboxes at once.
The Results
Draftbit now orchestrates thousands of containers through Cycle on a regular basis, without a single dedicated infrastructure engineer on their team. The most direct measure of what that means financially is the hiring cost they have avoided.
“Without Cycle, it would be very hard for us to run this without at least a couple of DevOps engineers,” Luerssen says. “But we don’t need them.”
The combination of the platform itself and the support model around it has become load-bearing infrastructure for the business. “Even if I found a better or cheaper platform, it’s very rare to find a team that would help us at this level,” Luerssen says.
Draftbit demonstrates that scaling a sophisticated, AI-first platform doesn’t require a massive infrastructure footprint. By offloading orchestration complexity to Cycle, Draftbit has successfully decoupled operational scale from engineering headcount. This allows their six person engineering team to bypass the traditional burdens of DevOps and remain fiercely focused on what matters most: shipping features, refining their AI capabilities, and delivering a seamless product experience to their users.
Draftbit is an AI-first no-code app development platform that enables designers, founders, and early-stage teams to build, test, and ship mobile and web applications. The company serves customers through both a self-serve SaaS platform and a professional services team.