Supervisor Services are a versioned way to extend VMware Cloud Foundation (VCF) by integrating your capability natively into the Supervisor—surfacing it in the Service Catalog, upgrade workflows, and management APIs.
You do not need a Supervisor Service merely to run a workload in VCF; this guide focuses on the use case of extending the Supervisor with a lifecycle-managed service. For broader context on VCF services, see the general VCF documentation.
If you are building Kubernetes-native software, turning it into a Supervisor Service provides:
kubectl or other client commands to keep the service running.The path from your code to a running service follows a structured pipeline across the VCF management plane.
| Phase | Developer Action | Platform Action |
|---|---|---|
| 1. Package | Bundle manifests, images, and metadata into a distributable unit. | — |
| 2. Publish | Ship two artifact types to separate destinations: (1) Service definition to a location administrators can access. (2) OCI bundle (manifests and images) to a container registry. |
— |
| 3. Register | — | A user with the SupervisorServices.Manage vCenter privilege downloads the service definition manifest and registers it with vCenter/VCF;the platform validates and makes it discoverable. |
| 4. Install | — | A user with the SupervisorServices.Install vCenter privilege selects Supervisor(s) and provides required configuration. |
| 5. Deploy | — | The platform installs the service on the Supervisor. |
| 6. Maintain | Ship new versions. | Manages upgrades and health. |
Supervisor Services follow Semantic Versioning. You can upgrade to a newer version via the UI or APIs; the platform does not support downgrades—the lifecycle is forward-only.
Packaging is the process of transforming your Kubernetes manifests, container images, and configurations into a distributable unit that VMware Cloud Foundation (VCF) can discover, validate, and deploy. The platform currently uses Carvel for packaging. For step-by-step Carvel authoring, see Authoring Supervisor Services.
Every Supervisor Service package consists of these core elements:
| Component | Purpose |
|---|---|
| Service Identity | The service metadata: identifier (a unique, fully qualified name), display name, and description that appear in the Service Catalog. |
| Versioned Installer | The version-specific manifest that references the payload, declares any compatibility constraints, and exposes the configuration schema that admins fill in at install time. |
| The Payload | An immutable bundle of Kubernetes manifests and locked container image digests. What you test is exactly what the customer deploys. |
Signing your bundle lets the Supervisor verify, before installation, that the artifact came from a trusted publisher and was not modified in transit or in the registry. Unsigned bundles still install but trigger a third-party software disclaimer in the UI, and certain high-privilege capabilities are reserved for bundles that the Supervisor can verify as trusted.
See Image Signing and Verification for the signing model, prerequisites, and the end-to-end workflow.