PLATFORM · OPINION · 2026-05-08 · Createrun Engineering · 7 min read

On-prem in 2026: when low-code makes sense

The narrative says everything is moving to SaaS. The reality, especially in regulated industries and emerging markets, is more complicated.

The lazy take

"Just use SaaS, save the ops cost." For a startup running a generic CRM, fair. For a manufacturer whose suppliers' financial data is in scope of three regulators, less fair. For a Turkish retailer whose KVKK obligations conflict with US-jurisdiction data centres, sometimes outright wrong.

We built Createrun on-prem-first not because we like data-centre photos. We did it because a substantial fraction of customers we want to serve cannot legally — or contractually — put their data in someone else's cloud. The platform that ignores them is leaving real value on the table.

When SaaS is fine

Most internal tools. Most customer-facing apps for B2C startups. Most non-regulated B2B SaaS. We're not arguing against SaaS — we ship a managed cloud option ourselves. The argument is narrower: low-code platforms thatonlyship SaaS exclude the customers who need on-prem.

When on-prem matters

Three categories drive most of the on-prem demand we see:

1. Data residency under sovereign rules

KVKK in Turkey, GDPR in the EU (with national variants like Schrems II implications), DPDP in India, financial-services regulations everywhere. Some of these are satisfied by EU-hosted SaaS; some require the data to physically reside on infrastructure under local control. The cost of getting this wrong — fines, contract clawbacks, brand damage — dwarfs the cost of running an on-prem deploy.

2. Supplier and audit data with multi-party contracts

When a nationwide grocery retailer audits a supplier, that data covers pricing, terms, defect rates, IP. The supplier signed an NDA with the retailer, not with whatever SaaS vendor the retailer happens to be using this quarter. Putting that data in someone else's cloud means re-papering hundreds of NDAs. On-prem skips the negotiation entirely.

3. Connectivity and air-gapping

Plant floors, military bases, remote field operations, hospitals with strict network policies. SaaS-only platforms can't run there. Low-code is exactly the right fit for these environments — fast to build internal tools without sending engineers to remote sites — but only if the platform deploys on-prem.

What "on-prem" actually requires

It's not just a Docker compose file. To be deploy-anywhere, the platform needs:

  • Self-contained installer.NativeAOT single-file CLI, Avalonia desktop wizard, no .NET runtime dependency on the target.
  • Crypto stack.ECDSA P-256 manifest signing, JWT activation, SPKI-pinned downloads, SHA-256 streaming verification, DPAPI / AES-GCM session encryption — all hardened, not "TODO" comments.
  • Air-gappable update path.Manifests can be downloaded once, signed offline, and installed on disconnected systems — with an offline test harness for validating the whole path.
  • No mandatory phone-home.Telemetry is opt-in. License verification falls back to grace mode when offline.
  • Source ownership.The customer's authored CRApps belong to the customer. Editor-authored or hand-coded — same answer.
  • Self-service multi-tenant.One on-prem deploy hosts many internal "tenants" without re-installation per tenant.

The on-prem + cloud hybrid

For customers who want both: dev / authoring on a managed cloud (faster iteration), production on-prem (regulatory alignment). The .crpck package format and dual-signature distribution make this feasible — sign once, deploy to either target, no per-environment build.

When low-code wins

The classic on-prem internal-tools story is "Java team builds custom apps for 18 months." Low-code shrinks that to weeksandmakes the resulting apps easier to maintain because the platform handles the boilerplate (auth, multi-tenant isolation, BPM, document storage, reports).

If your platform only deploys SaaS, you can't help these customers. If your platform only deploys on-prem, you miss the modern startup market. Our answer: ship both, with the same .crpck packages, the same CRApps, the same Marketplace.

The honest trade-off

On-prem deploys cost more to install and operate per customer than SaaS. But for the customer, the alternative is often a fully custom build — typically far more expensive and far slower to deliver. We make on-prem viable by making the installer good — see/securityand the Setup crypto stack.

If your situation calls for on-prem,talk to us. If it doesn't, the same platform runs on our managed cloud — same Marketplace, same AI agent, same source ownership. The choice is yours.

←Back to blog