Bolt.new Clone Features: Complete Platform Breakdown
Twenty-two LLM providers behind one picker, generated code that runs in the browser rather than on your servers, credit metering priced per model per plan, and an admin console that changes what any tier can use without a deploy. Here is every capability by role, benchmarked against Bolt.new itself and against building the same thing yourself.
Request a Live Demo →See PricingFeature Set by Role
The platform is three products sharing one database: what a builder does, what a paying team gets, and what the operator controls. Tiers are free, pro, enterprise and admin.
Builder
The core loop: describe an app, watch it generate, run it without leaving the tab.
- Plain-language prompt to complete, runnable multi-file projects
- WebContainers give every user a full Node.js environment client-side
- Live preview with hot reload, no remote sandbox and no cold start
- CodeMirror editor with a real terminal beside it
- Generate, edit, preview, deploy and export in one workspace
- Template library maintained by the operator
Pro & Enterprise
What paying tiers unlock, and how their consumption is accounted for.
- Access to operator-selected models per plan
- Central provider keys injected server-side by the auth proxy
- Credit balances backed by an append-only transaction ledger
- Input and output rates set individually per model
- Six deploy targets: Vercel, Netlify, GitHub, GitLab, Cloudflare Pages and ZIP export
- Framework auto-detection across ten frameworks
Operator & Admin
Everything configurable at runtime, without a code change or redeploy.
- Enable, disable and key any of the 22 providers
- Per-plan model access control
- Credit pricing per model, per tier
- 45+ feature flags
- User administration and environment variables
- Template library curation
The separation that matters commercially: the operator sets which models a tier may reach and what each token costs that tier, so plan economics are a configuration decision rather than an engineering one.
Bolt.new vs Miracuves Clone vs Building From Scratch
Where the readymade platform matches the original, where it deliberately differs, and what the same capability costs you in months if you build it yourself.
| Capability | Original Bolt.new | Miracuves Clone | Custom Build from Scratch |
|---|---|---|---|
| Code execution | In-browser via WebContainers | In-browser via WebContainers | Usually a server-side sandbox to build and pay for |
| Model choice | Vendor-selected | 22 providers, operator-configurable | One provider wired in, more added later |
| Additional models | n/a | 365+ more via OpenRouter | Per-provider integration work |
| Hosting model | Vendor SaaS | Self-hosted, code stays in your infrastructure | Yours, once built |
| Provider keys | Vendor-held | Operator-held, injected server-side by the auth proxy | Your own key handling to design |
| Usage accounting | Vendor plans | Credits per model per plan, append-only ledger | Metering is its own project |
| Deployment targets | Limited | Six, with framework auto-detection across ten frameworks | One to start |
| Runtime configuration | Not exposed | 45+ feature flags, pricing and plan access without a deploy | Code change per adjustment |
| Mobile app | None - browser product | None, matching the original | Not applicable |
| Time to live | n/a | 6 days | 3-9+ months typical |
Pricing is deliberately not on this page. The cost breakdown, including what a from-scratch build runs by complexity tier, lives on the development cost page.
The Technology Behind the Features
Remix and React 18 on the front end, PostgreSQL underneath, and an Express auth proxy running on a Cloudflare workerd runtime. WebContainers are what make the browser-native execution model work: every user gets a full Node.js environment client-side, so generated code runs, previews and hot-reloads without a remote sandbox, a cold start or a per-preview infrastructure bill. The auth proxy is where operator-managed provider keys are injected into requests server-side, which is why a paid-tier user can consume a model without the key ever reaching their browser.
How It Works, End to End
The unusual thing about this product is where the work happens. Code executes in the user's browser, not on your servers - which changes your cost model, your security surface and your scaling story all at once.
Signup and provisioning
A user registers and the platform provisions their account, tier and starting balance before they touch the workbench. Credits exist from the first session, so metering is never retrofitted onto an already-active user.
Choosing a starting point
They pick a template or start blank. The template seeds the browser runtime with a complete, working project rather than an empty folder, which is the difference between a first session that produces something and one that does not.
Prompt and generation
They describe what they want. The request is routed, keyed, metered and dispatched to the selected model. Every one of those four verbs is a place where an unmetered platform loses money.
Execution and live preview
The action commands execute inside the browser. Nothing runs on your servers, and the preview updates as the files land - so your infrastructure cost does not scale with how much code your users run.
Iteration and metering
They refine through follow-up prompts or direct edits, and the platform accounts for what was actually consumed rather than what was estimated. This is where the margin on shared provider keys is either protected or lost.
Deployment and export
They ship it - to a hosting platform, a git remote, or straight to disk. A user who cannot get their work out does not come back, which is why export is a first-class step rather than an afterthought.
Every Feature Earns Its Place
A feature list tells you what exists. This tells you what each one is worth to an operator, and what it costs you not to have it.
| Capability | What it actually does | Why it matters commercially |
|---|---|---|
| Browser-side execution | Action commands run in the user's browser, not on your infrastructure | Your server cost does not scale with how much code users run. This is the single largest structural cost advantage in the product |
| Per-model credit pricing | Input and output credit rates set per provider, per model, per plan | A cheap open model and an expensive frontier one can sit on the same plan at different rates. Without this, one is subsidising the other |
| Metering on actual consumption | The platform accounts for what was consumed rather than estimated | The margin on shared provider keys lives entirely in the gap between estimate and actual. Estimating loses it |
| Shared key architecture | You buy provider capacity wholesale and meter it out in credits | The spread between your API cost and your credit price is your primary revenue line, not a side effect |
| Templates that seed a working project | A complete runnable project rather than an empty folder | First-session success rate is the whole retention story on a generative tool. An empty workbench converts badly |
| Tiered provider access | Plans gate which providers and models a user can reach | Gives Pro and Enterprise a reason to exist that is about capability rather than just a bigger number of credits |
| Transaction ledger on credits | Every grant, spend and bonus written with a reason | Credit disputes are common on metered products, and the ledger is what settles them without a refund |
| Admin credit grants | Blocks issued for trials, onboarding or retention, each recorded | Your retention lever. Being able to grant credits without a deploy is what lets support save an account in the moment |
| Export to host, git or disk | Three exit paths from the workbench | Trust. Users commit more work to a tool they know they can leave, which is exactly why they end up not leaving |
What Is Not Included in the Base Package
The workbench, the metering engine and the admin layer are complete. The list below separates three different things: parity with the original, deployment configuration that happens on your server, and genuine add-on modules.
- Mobile app - parity, not a gapThe original has no mobile app and neither does this. It is a browser workbench by design. If you specifically want native iOS or Android builds for project monitoring and review, that is custom development.
- Deployment hardening - configured on your serverContent-Security-Policy, HSTS, strict CORS and encryption at rest are set during deployment onto your infrastructure rather than shipped as defaults, because the correct values depend on your domains and your hosting. We configure them at rollout.
- Payment processingThe platform meters and prices usage but does not process payments. Stripe or another provider is wired in at deployment with your own merchant account, including the webhook path.
- Single sign-on and two-factorSAML or OIDC single sign-on and TOTP two-factor are additive. Neither ships enabled, and the documentation lists two-factor as a planned item rather than a shipped one.
- Audit logging and retentionA dedicated audit datastore for admin actions, plus retention, export and deletion automation, are documented recommendations rather than shipped modules.
- Distributed rate limitingRate limiting runs on an in-memory map that resets on restart, which is fine on one instance. A Redis-backed limiter and cache is the step for multi-instance deployments.
- Team collaborationReal-time collaborative editing, shared team workspaces and project version history are roadmap items available as custom scope rather than part of the base build.
- Provider capacityYou bring your own provider accounts and buy the capacity you meter out. The platform prices and tracks it; it does not supply it.
See how Miracuves compares to agencies and freelancers
Cost, timeline, source-code ownership and support, side by side - plus the questions worth asking any provider before you sign.
Frequently Asked Questions
Which LLM providers are supported out of the box?
Where does generated code actually run?
How are provider API keys handled?
Can plan pricing and model access change after launch?
Is there a mobile app?
Where does the generated code actually run?
Explore the Bolt.new Clone
See exactly what you are getting - before you commit
Open the builder workspace, generate an app from a prompt, then sign in as the operator and change what any tier is allowed to use.
