// What is microservices.sh?
microservices.sh is a contract-driven production layer around apps your coding agent builds on Cloudflare. It ships the dangerous 30% — auth, payments, webhooks, audit, tenant isolation — as source-visible, version-pinned modules your agent can inspect, check, and deploy safely.
The microservices.sh System Harness is a contract-driven production layer around AI-built Cloudflare apps. It is not a prompt-to-app builder and not a hosted black-box backend — it is the governed foundation that an app generated by a coding agent runs on.
Concretely, you scaffold a working Cloudflare Workers + D1 app from source-visible, version-pinned modules, each carrying a typed contract your agent reads before it composes. The harness adds the parts AI builders skip: module contracts, a lockfile, pre-deploy checks, and approval gates before risky actions.
AI builders are already good at producing a demo — about the first 70% of an app. The pain starts at the last 30% that breaks in production: authentication, billing, multi-tenant isolation, audit logs, migrations, webhooks, secrets, and deploy safety.
microservices.sh owns that last 30%. Instead of letting an agent invent risky auth or payment logic, you compose verified modules with contracts, run checks that catch dangerous changes before deploy, and gate provider actions, billing changes, and production deploys behind explicit approval.
A typical Cloudflare SaaS boilerplate or starter is a one-time copy: you clone it, and from then on you own and maintain every line, with no upgrade path. microservices.sh modules stay live — pinned in a lockfile, versioned, and upgradeable through a checked, reviewable plan.
Each module ships a machine-readable contract (typed hooks, events, permissions, risk policy) so your agent can inspect what a module does before accepting it, instead of pattern-matching across copied files. You still own the source; you just don't inherit an unmaintainable fork on day one.
Those tools generate apps and websites from a prompt — that is a different job, and microservices.sh does not try to replace it. Use Lovable, Bolt, Replit, v0, Cursor, Claude Code, Codex, or your terminal to build.
microservices.sh gives the generated app a production harness: contracts, lockfiles, checks, approval gates, and source-visible modules so the result is inspectable, governed, and deployable — not just a demo. It is the layer that makes AI-built apps safe to run a business on.
The primary users are AI-heavy technical founders, agencies, fractional CTOs, and Cloudflare-oriented developers — teams that repeatedly build client portals, booking systems, internal tools, admin apps, and SaaS MVPs.
Agencies get the clearest value: they rebuild the same production foundation across clients, so a reusable, governed Cloudflare foundation means faster delivery, less risk, and better margin. The shared pain is not 'generate UI faster' — it is 'trust and maintain what the agent generated'.
Yes. Every module is source-visible code in your repository, not a hosted dependency you rent. You can read it, extend it through typed hooks, override files, or fork entirely — the customization ladder is config → hooks → overlay → fork.
Composition is pinned in microservices.lock.json, so the same source builds the same way every time. Local generation does not require a microservices.sh account or a Cloudflare account.
The harness targets Cloudflare Workers and D1 so apps run at the edge without a separate database service to provision. You get a Cloudflare-native path without having to become a Cloudflare infrastructure expert.
Managed, approval-gated deploy commands handle remote state and resource ids, while wrangler.jsonc stays a local-dev config — or you bring your own Cloudflare account when you are ready to own production.
Try it
Local generation needs no account. Create a working Cloudflare SvelteKit booking app, inspect the module contracts, and run checks before you deploy.
pnpm create microservices-app@latest studio-booking --template booking-sveltekit