The CAP M.O.
Let's dig into CAP's core ethos.
App-centric model
CAP thinks about applications like app devs. Applications are modeled as a collection of high-level resources, not as raw infra.
One platform spanning multiple clouds
GCP, AWS and Azure are already supported, with more on the way. App devs don't need to be experts in any of them.
Enterprise-class governance
All change is coerced through a single auditable path.
Multiple resource types
Databases, object storage buckets, caches, streaming topics and more.
Minimal cognitive load
CAP uses implicit contracts for access, workload identity and networking.
Opinionated externals, adaptable internals
While the platform interface is simple, CAP resource adapters can front a wide variety of infra technologies.
Safe for agents
By eliminating access to raw infra, CAP reduces context collapse and stops agentic mistakes (like deleting prod databases!)
The CAP Application Model
CAP's control plane splits applications into their constiuent resources. Each resource is backed by an abstract model that CAP adapts into specific underlying technologies.
Registry API
Create applications, manage teams, and authenticate with the platform.
Service API
Deploy and manage containerized backends, frontends, and more.
Database API
Provision and operate Postgres databases.
Bucket API
Provision and manage object storage buckets.
Topic API
Create and manage Kafka streaming topics.
Cache API
Provision and operate Redis caches.
Future APIs
The abstractions will continue until morale improves.
App Identity API
Cloud native identity and access management for resources across an application.
Open Source Roadmap
We want to build CAP with the community.
Now
- Registry API
- Source released under Apache 2.0 license
Early 2027
- Service API, App Identity API
- CAP UI, capctl
- Builds available in public registries
Late 2027
- Database API, Bucket API, Cache API, Topic API
- Development moves to the open source GitHub org
- Project governance established