Manage Cloud Foundry resources the GitOps way — declarative, version-controlled, and reconciled continuously by Crossplane.
crossplane-provider-cloudfoundry lets you define Cloud Foundry resources (Orgs, Spaces, Services, Applications, and more) as Kubernetes custom resources. Crossplane takes care of the rest: provisioning, drift detection, and reconciliation — no scripts, no manual clicks.
We're building this in the open and we'd love your involvement — whether you're using the provider in production, experimenting with it, or just curious about how it works.
We hold a community call on the last Wednesday of every month at 4 pm CET.
- 👀 See what everyone's been working on
- 💡 Share ideas and feedback
- ❓ Ask questions — no question is too basic
- 🔬 Dive into technical details together
🔗 Join: : Click Here
🎬 Can't make it? Recordings are shared after each call.
Join us on Slack: #provider-sap-cloudfoundry — for questions, ideas, or just to say hi.
We have a growing backlog of features and improvements. You can follow along — and pick something up! — on our GitHub Issues and Discussions.
⚠️ Crossplane v2 is not yet supported but coming soon. Please use Crossplane v1 for now.
To install the provider into a Kubernetes cluster running Crossplane, apply the following resource — replacing <VERSION> with the latest release:
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-cloudfoundry
spec:
package: ghcr.io/sap/crossplane-provider-cloudfoundry/crossplane/provider-cloudfoundry:<VERSION>Crossplane will create a deployment for the provider. Once it's healthy, configure your credentials and start orchestrating. 🚀
The provider includes tooling to get you up and running locally quickly.
Prerequisites: kind and Docker must be installed.
# 1. Clone the repo
git clone https://github.com/SAP/crossplane-provider-cloudfoundry
# 2. Initialize the build submodule
make submodules
# 3. Spin up a local kind cluster with CRDs installed
make dev-debugThis leaves you with a local cluster and your KUBECONFIG pointed at it — ready for kubectl or k9s.
make runCompiles and runs the controller locally (outside the cluster), watching for resources via your KUBECONFIG.
make dev-cleanmake test-acceptanceSpins up a kind cluster, runs the provider as a container inside it, and fires kubectl commands to validate behavior end-to-end.
If you run tests multiple times, clean up the kind cluster first to avoid conflicts:
kind delete cluster <cluster-name>See the Upgrade Tests README for details.
| Variable | Description |
|---|---|
CF_CREDENTIALS |
CF admin user credentials as JSON: {"email": "...", "username": "...", "password": "..."} |
CF_ENVIRONMENT |
CF API URL, e.g. https://api.cf.eu12.hana.ondemand.com |
The provider ships an export CLI that generates managed resource definitions from an existing Cloud Foundry cluster's configuration.
→ See the User Guide for details.
Contributions are very welcome — from bug reports to new features to docs improvements. Here's how to get involved:
- 🐛 Found a bug? Open an issue
- 💡 Have an idea? Start a Discussion or drop by the community call
- 🛠️ Want to contribute code? Check out the CONTRIBUTING.md and DEVELOPER.md guides
Not sure where to start? Come chat on Slack — we're happy to help you find something.
If you discover a potential security vulnerability, please follow our security policy — do not open a public GitHub issue for security concerns.
We're committed to a welcoming, harassment-free community for everyone. By participating in this project, you agree to our Code of Conduct.
Copyright 2024 SAP SE or an SAP affiliate company and crossplane-provider-cloudfoundry contributors. See LICENSE for details. Third-party component licensing is available via the REUSE tool.