Coolify is the application control plane, not the server provider.
It should stay behind the server detail experience where the user already has enough infrastructure context.
Coolify owns
- Applications and services
- Databases
- Deployments
- Runtime environment variables
- Resource domains
- Certificates for Coolify-managed resources
- Application-level backups where configured
UI placement
Coolify surfaces should live inside a server detail page, not the top-level VPS inventory.
Recommended sections:
| Section | Purpose |
|---|---|
| Applications | View active apps and service roles tied to the server |
| Deployments | Show release history and active deployment status |
| Domains and TLS | Surface mapped domains and certificate state |
| Databases | Show attached databases and operational status |
| Backups | Explain which backups are Coolify-managed versus external |
UX rule
The docs and dashboard should make one thing obvious: Coolify manages workloads on a server, while provider APIs manage the machine itself.
That split keeps the control plane understandable and prevents unsupported server actions from appearing in app-level screens.