Why Kuppit
The cloud is powerful. It shouldn't be your application interface.
Cloud infrastructure has tremendous capability. But deploying a relatively ordinary web application still tends to expose a developer to all of it at once:
- Build infrastructure
- Container registries
- Compute configuration
- IAM
- Networking
- DNS
- Logging
- Monitoring
- Billing primitives
Those things matter. Someone has to decide them, and getting them wrong is expensive. But most application developers do not need them to be the primary interface — the thing they open, learn and operate in order to put a service on the internet.
Kuppit puts an application model above them.
The model
- 01
Repository
What you already have.
- 02
Application
What you want to run.
- 03
Environment
Where it runs, and how it is configured.
- 04
Resources
What it needs around it.
- 05
Deployments
Each immutable release of it.
The provider-specific implementation stays underneath Kuppit, where it belongs. You work with the row above; Kuppit is what turns it into infrastructure.
Where this goes
One application model, not one provider's API.
Today, Kuppit Cloud manages the infrastructure behind this experience. The platform itself is being designed so that the application model does not have to belong to one infrastructure provider forever.
That's the direction, not a feature we offer today. Kuppit does not currently deploy into your own AWS or GCP account.