When is self-hosted no-code actually required?

Four cases: regulated industries with on-premise mandates, sovereignty requirements (government, public sector), air-gapped networks, and extreme-volume cost sensitivity. Outside those, self-host is usually a procurement preference satisfied by SaaS-with-DPA arrangements.

Which no-code platforms can be self-hosted?

Open-source options include Baserow, NocoDB, Appsmith, Tooljet, and Budibase. SaaS-only platforms like Bubble and Glide cannot offer self-host without breaking their revenue model.

What does a buyer actually need that they think is 'self-host'?

Usually encryption at rest, a signed DPA, regional data residency, audit logging, and a breach response plan. Probe with: 'If we satisfy your security and residency requirements with a vendor-managed deployment, is that acceptable?'

What are the hidden costs of self-host?

Running the infrastructure (patches, backups, upgrades), lag on feature velocity vs SaaS, longer support loops because the vendor cannot SSH in, and total cost that is usually higher than SaaS for small-to-mid teams. Self-host beats SaaS only at scale or for compliance reasons.

Should a SaaS maker build a self-host SKU?

Only if a specific large customer will fund the engineering, which is a multi-quarter effort and a structurally different product. Most makers should refer self-host buyers to a self-host-native vendor and stay focused on the SaaS architecture.

Self-hosted no-code: when 'we run it ourselves' is the only acceptable answer

Baserow launched its no-code application builder in 2024-03 with a clear positioning shot: "Self-Hosted Airtable Alternative Launches No-Code Application Builder." The HN thread was short but the strategic move was loud. Bubble, Glide, Adalo, and the SaaS-only no-code incumbents cannot match a self-host pitch without killing their revenue model. Baserow and a small cohort of open-source no-code platforms own the lane.

This article is about which buyers actually need self-host, which ones think they do, and how to evaluate the options that exist.

The four real self-host cases

Self-host is genuinely required in four cases:

Regulated industries with on-premise mandates. Healthcare (some HIPAA buyers), defense, intelligence, certain financial services. Their compliance team has written "data must not leave our network" into policy and there is no SaaS escape hatch.
Sovereignty requirements. Government agencies, EU public sector, certain B2B contracts that specify the data plane runs under the customer's jurisdiction. Self-host is the cleanest way to meet this.
Air-gapped networks. Manufacturing floors, secure research, certain industrial environments where the cluster is not connected to the public internet at all.
Extreme cost sensitivity at scale. Some buyers run such high volumes that any SaaS per-seat or per-row pricing breaks. Self-hosting on commodity hardware is the only way the math works.

These are the cases where SaaS is structurally wrong, not a preference.

The fake-requirement cases

The procurement-theater versions:

"We always self-host." Sometimes true, often inherited from a 2010-era IT policy nobody has revisited. The same buyer happily uses GitHub Cloud, Slack, and Notion. Worth probing.
"We need to control the data." Almost always satisfied by encryption at rest under a vendor-managed key, plus a signed DPA. Self-host is overkill.
"Our security team requires it." Sometimes true. Often the security team has not been asked; the form-filler assumed.
"It's in the RFP." The RFP was copy-pasted from a 2018 template. Worth asking whether it is a hard requirement or a default.

The diagnostic question to ask the buyer: "If we satisfy your security and data-residency requirements with a vendor-managed deployment, is that acceptable, or is self-host itself the requirement?" The answer separates the real cases from the theater.

The viable self-host options (2026)

Open-source no-code platforms that you can actually self-host today:

Baserow — Airtable-shaped, no-code app builder added 2024. Docker-deployable, MIT license. Strong table primitive.
NocoDB — Airtable alternative, REST API generator from existing databases. Active community, easy deploy.
Appsmith — Internal-tools builder closer to Retool's shape. Docker, Helm chart, on-prem-friendly.
Tooljet — Similar to Appsmith. Strong recent momentum, good Postgres/REST integration.
Budibase — Smaller but maintained. Good for narrow internal tools.

Each one has trade-offs. Baserow is strongest for spreadsheet-like data. Appsmith and Tooljet are stronger for action-heavy internal tools. NocoDB is best when you are wrapping an existing database. The choice depends on which side of the data-vs-action axis your tool lives on.

The trade-offs the buyer needs to know

Self-host comes with costs that the procurement form does not list:

You run the infrastructure. Patches, scaling, backups, restore drills, upgrades. The vendor's SaaS team does this for you; the self-host buyer signs up to do it themselves.
Feature velocity lags. The vendor ships features to SaaS first, then backports to the on-prem release. Lag is typically 1-3 months, occasionally longer.
Support is structurally different. The vendor cannot SSH into your cluster. Diagnostic loops are longer; logs have to be shipped, not viewed.
Total cost is often higher. Internal SRE time, hardware, networking, the upgrade cadence. Self-host beats SaaS only at scale or for compliance reasons; for small teams it is usually more expensive.

Buyers who came to "self-host" through procurement theater often did not price this in. Show them the numbers honestly. Sometimes the conversation flips to "okay, we can accept a SaaS-with-strong-DPA arrangement" once the SRE cost is in front of them.

What this means for makers

If you are a maker shipping a SaaS product and a buyer asks "do you offer self-host?", the answer hierarchy is:

Probe whether the requirement is real. Use the diagnostic question above.
If theatrical: offer your strongest SaaS-with-DPA posture. Encryption at rest, signed DPA, audit logs, regional residency, breach plan. Most procurement teams accept this after the diagnostic conversation.
If real: be honest you do not offer it. Building a self-host SKU on top of a SaaS-only architecture is a multi-quarter engineering project, and you will lose money on every deployment for the first two years. Some buyers are worth this; most are not.
Refer to a self-host-native vendor. Baserow, Appsmith, NocoDB. The buyer gets what they need; you maintain the relationship without breaking your architecture.

What I would actually do

Have a written self-host posture. "We offer SaaS with [DPA / encryption / audit logging / regional residency]." Send it before the buyer fills the procurement form.
Have a referral list. Two or three self-host-native vendors you have evaluated and can recommend honestly when the buyer needs that path.
Do not build self-host on top of SaaS architecture unless you have a multi-million-dollar customer who will fund it. This is the trap; the engineering is huge and most SaaS-priced contracts will not cover it.

The honest framing: self-host is real for a subset of buyers and theater for the rest. Knowing which one you are looking at saves weeks of vendor selection on both sides.