AI App Builder IP Allowlisting Compared (October 2026)

Quick answer, October 2026. Five of the eight builders we track document some way of restricting access by IP address, and they do not restrict the same thing. Base44 locks the workspace and every app inside it behind an allowlist. v0, through Vercel, locks the deployed site behind Trusted IPs and separately offers IP blocking as a deny list. Softr says it can limit app access by IP. Lovable has IP allowlisting, but it applies to platform API keys and to connector egress, not to who can open your app. Bolt.new, Bubble, Replit and Webflow publish no comparable control. If you are buying this feature, the question is not whether a builder has it, but which of three different doors it closes.

What is actually being restricted

"IP allowlisting" sounds like one feature. Across these eight products it names at least three different objects, and getting the wrong one is an expensive mistake.

Object one, the builder workspace. Who can sign in to the place where the app is built and edited. This is the control a security team usually means when it asks for IP restriction during a review.

Object two, the deployed app. Which visitors can load the thing you shipped. This is a public-traffic control and it lives at the edge.

Object three, the platform API key. Which addresses may use a token that calls the builder's own API. This protects automation credentials, not people.

There is also a fourth thing that shares the vocabulary and is the opposite direction: a published list of the IP ranges a builder's outbound traffic leaves from, so that you can allowlist them on a third-party service. That is a convenience for configuring someone else's firewall. It restricts nothing on your side.

The comparison

A note on how those last four were established, because an absence is easy to assert and hard to earn. For Bolt.new, Bubble and Replit we swept each vendor's full documentation index for thirteen terms covering allowlists, blocklists, trusted IPs, CIDR notation, firewalls, VPNs and network access, and found nothing, then read their security pages directly. For Webflow we read the complete security and enterprise pages, roughly 37,000 characters between them, and found zero occurrences of any of those terms. Softr is the reason we do not stop at the index: its documentation index is currently an empty file, so an index-only sweep would have scored it a zero, and the capability is on its security page.

Finding one: Base44 is the only one that covers the editor as well

Base44's allowlist sits in workspace settings under Governance, and the documentation is unusually explicit about scope.

Base44, verbatim: "Set up an IP allowlist from Governance in your workspace settings so only people on approved networks or VPNs can sign in to your workspace and all of its apps."

It then names both halves. Base44, verbatim: "When IP allowlist is enabled, all apps in the workspace are protected by the allowlist." And the blocked surface is listed as published apps, meaning people using the app, and Base44, verbatim: "Apps open in the app editor" for development and editing.

That second half is the one nobody else offers. Vercel's Trusted IPs protect the deployment. Softr limits app access. Neither restricts where a developer can be sitting when they open the builder. If your security review asks "can a contractor edit this from an unmanaged home network", Base44 is the only product here with a documented answer.

Rejected requests get a specific status. Base44, verbatim: "Requests from IP addresses that are not in the allowlist receive a 403 Forbidden response." Supported entry formats are single IPv4, CIDR, hyphenated ranges, IPv6 and IPv6 CIDR.

Two caveats worth reading before you treat it as a perimeter. Base44 states plainly that this is a layer and not a replacement: Base44, verbatim: "IP allowlist adds a network-level restriction on top of your existing" authentication. And there is a documented bypass. Base44, verbatim: "Authorized Base44 support staff may bypass the IP allowlist as part of support operations." That is honest disclosure rather than a defect, but it belongs in a threat model.

Finding two: Vercel ships both polarities, and they are different products

v0 inherits Vercel's platform controls, and Vercel has two separate features that both operate on IP addresses in opposite directions.

Trusted IPs is the allowlist. Vercel, verbatim: "only visitors from an allowed IP address can access your" deployment, configured as IPv4 addresses and CIDR ranges at project level. The documented use case is narrow and practical: Vercel, verbatim: "you can limit preview deployment access to your VPN." It is gated, though. Vercel, verbatim: "Trusted IPs are available on Enterprise plans."

WAF IP Blocking is the deny list, and it is available far more widely. Vercel, verbatim: "block a specific IP address or multiple IP addresses by CIDR", with the documented use cases being known malicious addresses and scrapers.

These solve different problems and should not be confused in a purchase decision. An allowlist is a closed door with a guest list and it fails closed: anyone you forget to add is locked out. A blocklist is an open door with a bouncer and it fails open: anyone you have not thought of walks in. Most teams asking for "IP restriction" during a compliance review want the first, and the first is the one behind the Enterprise gate.

Finding three: Lovable's allowlist is real, and it is not about your app

Lovable genuinely has IP allowlisting, documented in detail, and it is attached to API keys rather than to app access. Lovable, verbatim, on what key management does: "restrict keys to approved IP addresses."

The implementation detail is unusually specific and tells you a lot about the shape of the feature. Entries are uploaded as a CSV, capped at Lovable, verbatim: "up to 3,000 entries and 1 MB". Ranges have a floor on breadth. Lovable, verbatim: "Lovable rejects ranges wider than /8 for IPv4 or /32 for IPv6." And there is a protocol constraint that will catch IPv6-only automation. Lovable, verbatim: "the Lovable API currently answers over IPv4 only", so every list must contain at least one IPv4 entry.

Separately, Lovable publishes its outbound ranges for connector traffic. Lovable, verbatim: "Requests from gateway-based connectors leave Lovable from a fixed set of IP ranges that you can allowlist." Read that direction carefully. It is a list you add to someone else's firewall so Lovable can reach them. It does not restrict who can reach you.

So a security questionnaire that asks "does the platform support IP allowlisting" gets a truthful yes from Lovable, and the yes answers a different question than the one most reviewers are asking.

Finding four: an absence of documentation is not proof of an absence, except where it is

Three of the four negatives in the table are stated as "no first-party documentation located" rather than "no". That wording is deliberate. Bolt.new, Bubble and Replit each have substantial documentation and none of it covers this; that is strong evidence and it is not the same as a vendor saying no.

Replit is a particular case worth separating. Its information security page describes a WAF, Replit, verbatim: "web application firewall prevents malicious traffic" and sophisticated attacks. That is infrastructure Replit runs on your behalf. It is not a control you configure, and you cannot put your office range into it.

Webflow is the one genuine negative. We read its complete security and enterprise pages and found no IP-based access restriction of any kind, not as an allowlist, a blocklist, or a firewall rule you control.

Softr sits at the other end of the evidence scale: the capability is claimed on its own security page, Softr, verbatim: "limit app access by IP address", but we could not locate a dedicated documentation article setting out formats, plan boundary or behaviour on rejection. Treat it as a vendor claim to verify in a trial rather than as a documented specification.

Verdict, October 2026

If the requirement is to keep the builder behind a corporate network, Base44 is the only product here that documents it, and it covers the published apps as well. If the requirement is to keep a deployed site private to an office or VPN, v0 through Vercel Trusted IPs is the cleanest fit, with the caveat that it is Enterprise-gated while the blocklist alternative is not. If the requirement is to stop a leaked automation token being used from anywhere on the internet, Lovable's per-key allowlist is the most detailed implementation of the three and the limits are published.

If you are shortlisting on this axis, write down which of the three objects you actually need before you read any vendor's feature list, because all three are sold under the same two words. And whichever you pick, Base44's own framing is the right one to keep: this is a network-level restriction layered on top of authentication, not a substitute for it. The adjacent questions are how the platform stores the credentials that automation uses, which we covered in our look at secrets management across AI app builders, and how cleanly a platform separates one customer's data from another's, which we covered in multi-tenancy.