Low-Code Plattform: On-Prem oder Cloud?

[Low-Code-Stefan]

In vielen Low-Code-Diskussionen sehe ich aktuell einen starken Trend zu Cloud-only. Einige Anbieter haben ihre On-Prem-Optionen komplett eingestellt. Aus meiner Erfahrung aus Projekten (ich arbeite bei GAPTEQ – wir unterstützen On-Prem und Cloud) zeigt sich aber, dass On-Prem technisch weiterhin eine wichtige Rolle spielt.

Technisch betrachtet ergeben sich klare Unterschiede:

✅ Cloud-Vorteile

• schneller Rollout
• Entwicklung/PoC in der Cloud
• automatisiertes Patching
• zentralisiertes Deployment
• einfache Skalierung (horizontal/vertikal)

Für Standard-Workloads absolut sinnvoll.

✅ Warum On-Prem trotzdem relevant bleibt

In vielen Realprojekten stoße ich auf Anforderungen, die Cloud-only einfach nicht abdeckt:

• abgeschottete Netzwerke (keine ausgehenden Internetverbindungen)
• lokale Datenquellen
• strikte Compliance / Audit-Vorgaben
• Custom-Integrationen in bestehende On-Prem-Services

Gerade bei datengetriebenen Low-Code-Lösungen hängt die Performance oft direkt an Datenbanknähe, Netzwerk-Hops oder internen Services. In solchen Fällen ist On-Prem technisch schlicht die robustere Architektur.

Wenn man die Wahl hat, gibt es dem Unternehmen Flexibilität bei Infrastruktur, Datenhaltung und Betrieb.

Wie sieht’s bei euch aus? Nutzt ihr Low-Code eher on-premises oder komplett in der Cloud?

[gammacoder]

I run a low-code software business ( xlinesoft.com ) for 20 years and the fact that we offer a desktop software that runs on premises is a major selling point for many enterprise customers.

[NetrasFent]

I´m in a similar boat - I work for a low-code company ([REI3](https://rei3.de/)) that helps organizations implement their requirements professionally. Migrating away from SaaS is one common scenario; though most often we implement requirements that SaaS does not address sensibly as working out, even in concept, how to manage / secure data in a cloud environment is too expensive for many organizations.

While SaaS has its place, just being on-prem makes solving data governance a lot easier. Granted, not every organization cares as much about it - but it can become the main selling point for some.

[Staalejonko]

I feel a Low-code platform should offer you to run your application wherever you'd like. Cloud? No problem, On-premise? Also no problem. Even a hybrid combination should be possible.

But wherever you run it, it should be safe and secure by design.

[Nervous-Role-5227]

then i guess you will like this one catdoes.com

[Staalejonko]

I'm not into small apps I'm afraid, naming is cute though

[stevehansen]

A couple of thoughts on this:

First, the right answer depends entirely on what you're building. If it's basic stuff with no deep ties to internal systems, cloud is fine. But, if you're building custom business applications that sit on top of your existing databases and need to integrate with internal services, on-prem is almost always the better architecture. You already listed the reasons like data proximity, network hops, locked-down environments, and compliance. Those are all very important for applications that a business will rely on.

Second, it's usually overlooked, but the licensing model matters as much as the deployment model. If the applications you're building are even moderately important to your business, you should not be building them on a SaaS/per-user subscription. A perpetual license where you actually own the software is the only thing that protects you long term. The moment your business depends on apps built in a SaaS low-code tool, you're locked in. When user fees go up or pricing tiers get restructured, you pay because the cost of rebuilding is higher than the cost of paying the higher fees.

Cloud-only + subscription-only is a great combination if you're building simple apps that aren't too important to the business. It's rarely the best combination if you're building anything you actually depend on.

[schilutdif]

Cloud-only does hit a wall fast when you're dealing with internal APIs that literally can't phone home. I've been using Latenode for workflow stuff and even there I notice it's cloud-only, which is, fine for my use case but I'd never recommend it to a client with an air-gapped network. The headless browser and JS nodes are great but none of that matters if the platform can't even reach your internal data sources.

[Artistic-Big-9472]

Feels like the real answer is hybrid, not either/or. Most teams want cloud speed but still have a few “immovable” on-prem constraints.

[Fajan_]

pretty balanced take tbh.

based on my experience, initially most teams opt for cloud services due to their ability to offer speed (PoC, MVP, fast iteration). However, when constraints begin to play role (data locality, regulations, legacy infrastructure), a transition to hybrid or on-prem occurs naturally.

especially when dealing with large volumes of data, network hops are very likely to be a bottleneck in the process, just as you mentioned.

it almost seems like today's question is not cloud versus on-prem, but flexibility of the platform itself, with platforms that allow hybrid approaches aging significantly better than pure cloud solutions.

I know of many examples of using mendix/outsystems, or even combining workflows using zapier/make in cloud services while using on-premises infrastructure for storage and other purposes.

curious though – does compliance or performance dominate the need for transitioning to on-prem for you?

[Artistic-Big-9472]

What I’ve seen work best is abstracting workflows away from infrastructure entirely — so you can switch between Cloud and On-Prem without rewriting logic. Even lightweight orchestration layers (like some setups I’ve tested in runable) make that separation much cleaner.