Use Cases
Startups & Small Teams
The simplicity you came for, without the rebuild you were dreading when you outgrow it.
You are five to thirty people and you ship every day. You picked a PaaS because it got out of the way, and it did. The nagging part is what happens later: the day you need a network policy the dashboard does not expose, or an enterprise customer asks where the data physically sits.
Deploy on day one
Connect a repository, get a URL. Nobody on the team has to learn Kubernetes to ship a feature.
Nothing is hidden
Underneath it is Helm, PostgreSQL and Gateway API. When you need to look, there is something to look at.
Predictable bill
Pay for compute and storage, not per seat. Self-host the whole platform if the maths works out better.
The graduation tax
Migrating off a closed platform is rarely a migration. It is a rebuild. The deployment knowledge lives in a dashboard, the environment config lives in a proprietary format, the promotion workflow lives in someone's head, and none of it comes with you.
That is usually a quarter of engineering time that produces exactly zero customer value, paid at the worst possible moment: right when the thing that forced the move is already urgent.
Managed PaaS
Fast start, proprietary config
The wall
Networking, residency, cost, control
Rebuild on Kubernetes
A quarter of work, no new features
Lucity
Same click-to-deploy experience
The same wall
Now it is just configuration
Your own cluster, if you want
Eject, keep the charts, keep going
Grow into it, not out of it
You do not need to know Kubernetes on day one. That is the point of the dashboard. But when you do want to know, the answer is not "the platform handles that".
- 1
Start in the dashboard
Services, databases, variables and domains, all click-driven. The team ships features while you think about nothing.
- 2
Read the values
Every service is a Helm release with values you can inspect. The abstraction is thin enough to see through.
- 3
Take over the parts you care about
Set your own resources, health checks, start commands and scaling as your requirements sharpen.
- 4
Eject when it makes sense
One command hands you the charts and the guide. Moving to your own cluster stops being a project.
What your team learns along the way is Kubernetes and Helm, not the quirks of one vendor's control panel. Those skills follow them to the next company. That is a hiring argument as much as a technical one.
The cost conversation
Lucity Cloud bills for what you actually run: compute, storage, and the databases you provision. There is no per-seat pricing, so adding a designer to the workspace does not change the invoice.
If your burn rate is the thing keeping you up, the other option is genuinely available: Lucity is open source under AGPL-3.0, so you can run the whole platform on your own cluster and pay your infrastructure provider directly. Same product, different bill. Most teams start on the hosted version and never move, which is fine, but the exit stays open either way.