StackBlitz Bolt vs Lovable (2026)

Eight built-in MCP connectors plus any remote MCP server, each action toggled separately, alongside first-party integrations across design, version control, hosting, payments, data, mobile publishing and authentication.

The catalog runs to roughly ninety individually documented integrations spanning CRM, data warehouses, ecommerce, payments, accounting, communications, HR, security scanning, analytics, storage and CMS, which is breadth across classes rather than depth in one. The design detail worth carrying is the three connection types. A connector can be attached as an app connector, a chat connector, or an app user connector where each end user of the published app connects their own account. That last one means a built app can act on behalf of its individual users rather than through one shared service credential, a materially better security posture than a single shared token. Not every connector supports every type, and each catalog page states which it supports. Beyond the catalog, an any-API route and a create-connector path cover anything unlisted, and custom MCP servers plus MCP registries make the tool surface open-ended.

A documented project lifecycle runs from prompt to published app across many files in an in-browser runtime, with Plan Mode as a separate planning phase, skills carrying reusable workflows and a Prompt Library.

Build mode, previously called Agent mode, takes ownership of execution end to end: it understands intent, explores the codebase for context, applies changes across files, and resolves issues that appear during development, with visible tasks showing progress. Paired with Plan mode for decisions, that is a two-phase multi-step system rather than single-shot generation. Subagents are documented as their own feature, so work delegates rather than running in one context, and cross-project referencing lets one project draw on another, so composition works between projects. Skills carry reusable instructions, and code mode and an editor expose the generated files for hand editing. Drafts and project history give the iteration loop somewhere to stand.

Work reaches Bolt through the chatbox, fed by prompts, files, designs, templates or a Lovable import, with real-time collaboration; no scheduled, webhook or event-driven trigger is documented.

Project monitoring has Lovable check a project on a schedule, daily or weekly at a chosen time and optionally only after a minimum number of edits, reviewing the app code for broken functionality and recent visitor errors, then alerting by email and surfacing findings to fix in the project chat. That is a scheduled wake of the builder agent. Other routes in are the web chat, a Slack app, mobile and desktop apps, a Telegram route, the Lovable API and the Lovable MCP server. Monitoring is in beta, on Pro, Business and Enterprise.

A design system generated from the customer's material is stored, managed and kept in sync as its sources change, alongside knowledge held at account, workspace and project scope.

Knowledge is persistent text instructions, not a document store. Workspace knowledge holds shared rules across every project such as coding standards, preferred libraries and naming conventions; project knowledge adds application purpose, database schema, architecture decisions and domain terminology. It is always included in context, which Lovable contrasts with Skills, which load on demand. Workspace knowledge is described as a text field. The limit is stated in Lovable's own FAQ: project and workspace knowledge plus the code and components are the primary context sources, and the reference material does not describe reading instruction files from the repository or external sources. There is no ingestion of customer documents and no retrieval over a corpus; this is closer to a durable system prompt than to grounding on a knowledge base. Design systems are a second structure but ground style rather than knowledge: any project can be designated a design system and others connect to inherit its components and styles, with immediate propagation and precedence ordering when several are connected, though Lovable notes they are not versioned.

Projects, backups, version history, project knowledge and design systems persist, but nothing the agent learns accumulates; skills and saved prompts stay as the customer wrote them.

Lovable's state plainly persists: projects are durable objects with their own history, drafts persist unfinished work, project chat persists, and a Knowledge feature holds configuration that outlives any single conversation. Cross-project referencing makes state addressable between projects. What holds it at Partial is that none of it accumulates. Build mode explores the codebase for context at the start of each task rather than carrying learning forward, and skills are authored by the customer and stay as written; nothing is documented as the agent updating its own instructions after a correction. Durable state, yes; memory that compounds, no.

Plan Mode is an optional review step and connector actions, team roles and repository access can be restricted, but Build Mode applies changes with no documented approval step.

Plan mode investigates the project and writes a plan the user reviews, edits and approves before any code is written, and Lovable states Plan mode never modifies code. It is one of three modes the user picks, and Build mode implements changes directly, so the approval sits in an optional mode rather than in the build path; project monitoring findings are fixed only when the user asks. Workspace admin controls, integration admin controls, groups and project visibility settings constrain who can do what.

SOC 2 Type 2 with a trust profile at trust.bolt.new, encryption, monitoring and annual penetration tests, plus team access management and provisioning on Teams and SSO and audit logs on Enterprise.

The controls documented here govern Lovable itself, not only the app it builds: a trust center, SAML single sign-on, SCIM provisioning, two-factor authentication, workspace identity with identity reuse across workspaces, groups and people-level access control, integration admin controls, and Enterprise audit logs. Enterprise materials describe centralized identity, granular access controls and workspace-wide security oversight as the point of the plan. A data opt-out is documented as a Business capability, which matters because the training-data question is the one enterprise buyers ask first about an AI code generator, and it is answered as a setting rather than a policy statement. Secrets and build secrets are handled separately so credentials do not sit in generated code. Security scanning of the generated application, through a security center, security insights, sensitive-data scanning, scheduled Deep scans and Aikido and Wiz integrations, secures the output and counts toward testing. SOC 2 and ISO 27001 are consistent with the published trust center, but the certificates themselves have not been read.

Version history, GitHub commit sync, hosting analytics and database logs record the project, but no agent run trace or tool-call record is documented and no organization audit log appears in the documentation.

Lovable audit-logs the platform itself, recording actions taken by workspace members. A change shipped on 24 August 2026 added client attribution, so each entry records whether an action came from Web, Desktop, iOS or Android, and the log filters by client or by member; entries before that date read as Unknown. That sits alongside project monitoring, logs, project usage and analytics, and security insights, so both the platform and the built app are observable. Audit logs are an Enterprise capability. What is still absent is a trace of the agent's own reasoning within a build: visible tasks show progress but not why a choice was made.

BYOK deployment runs Bolt inside the customer's own AWS or Azure tenant with full infrastructure isolation, development executes client-side in the browser, and published apps can sit on Bolt Cloud, Netlify, Expo or anywhere through GitHub export.

This is real residency, not disclosure. A default hosting region is chosen from Americas, Europe or Asia Pacific; on Business and Enterprise workspaces an admin can set a required region for every new project, and members then cannot choose otherwise, which is the enforcement half; and country-specific regions including Germany, Japan and United States East are available on Enterprise by request. Enterprise materials describe this as regional code hosting. One operational detail will catch people: the setting applies only to new projects, and existing projects keep the region they were created in, so a workspace that adopts a residency policy late does not relocate what it has already built. Beyond region choice the output is unconstrained: Lovable Cloud hosts with custom, verified and transferable domains, two-way GitHub sync gives the customer the codebase, and external deployment and hosting-ownership guidance covers taking the app elsewhere entirely.

A vendor Templates catalog of named, previewable working templates opens in Bolt with one click, alongside team templates, built-in prompts and skills.

Design templates are documented as a Business capability, alongside a managed registry, a remix path for forking an existing project as a starting point, a prompting library, skills carrying reusable instructions, and design systems supplying the customer's own components. What Lovable ships ready-made is a set of design templates and a registry; the substantial reusable assets are ones the customer or the community builds. Remix is the closest to adopting a packaged asset, since forking a working project is adopting rather than assembling, but it depends on there being projects to fork.

Bolt Forge lets the customer pick among open-source models from several makers on individual Pro plans, in research preview to 14 October 2026, while the Standard and Max agents choose models behind the scenes.

Lovable exposes no model selection anywhere in a documentation inventory of roughly two hundred pages, and an inventory that complete makes the silence meaningful. The near-misses do not count. Fireworks, Replicate, Perplexity and Gemini Enterprise appear as integrations, and an AI feature page sits among the Cloud backend pages; those give the application being built access to models, which is the opposite of what this axis measures. This is a product position rather than an oversight: Lovable is opinionated about the builder and open about what the built app can reach. A buyer with a model-approval policy will care.

GitHub sync with full codebase export, outbound MCP connectors and the open-source bolt.diy fork, but no API, SDK or first-party MCP server for driving Bolt itself is documented.

Both directions are documented. Outbound, Lovable itself is callable from outside through a documented Lovable API and a Lovable MCP server. A third route is unusual: agent integrations turn the customer's published app into an MCP server for ChatGPT, Claude and other assistants, with configurable tools, sign-in and permissions. Lovable's framing is clear: people use an app by clicking buttons and moving through screens, an assistant cannot click, so it needs a list of actions instead. That extends the output rather than the platform, so it supports rather than carries the grade. Also documented: custom MCP servers, MCP registries, a create-connector path, an any-API route, and two-way GitHub and GitLab sync so the codebase leaves without lock-in.

A project security check finds and fixes security problems, with live preview, backups, branches and troubleshooting guides, but no test generation, regression suite or scoring of one build against another.

Browser testing has the platform interact with the customer's application in a real browser running in a virtual environment, clicking buttons, filling forms, navigating pages and verifying behavior with screenshots across different screen sizes. It returns a verdict: a Details view shows the steps taken and summarizes what worked and what did not, and the documented pattern is reproduce, fix, then verify. Where test and live environments are enabled it runs against the project preview in the test environment, so the evaluation happens before the change reaches anyone. A criterion applied by Lovable's mechanism to the customer's artifact ahead of release is Full.

Builds run in an in-browser Node runtime and the live preview shows the agent's own app; no operation of third-party software through its interface is documented.

Browser testing is not computer use. Exercising the application just generated inside a browser to check that it works is verification of Lovable's own output; this axis counts only an agent operating third-party software that offers no programmatic interface. The preview toolbar and preview pages are the same thing viewed by a person. The Firecrawl and Apify integrations retrieve web content over HTTP, which is scraping rather than computer use. Everything Lovable's agent touches externally, it touches through a documented connector, an API or an MCP server. Nothing in a two-hundred-page documentation inventory describes navigating or operating an external application.