crossplane-provider-cloudfoundry

Crossplane Provider for Cloud Foundry

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.

🌍 Community

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.

📞 Monthly Community Call

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.

💬 Chat with us

Join us on Slack: #provider-sap-cloudfoundry — for questions, ideas, or just to say hi.

🗺️ Roadmap

We have a growing backlog of features and improvements. You can follow along — and pick something up! — on our GitHub Issues and Discussions.

📦 Installation

⚠️ 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. 🚀

🔬 Developing

Initial Setup

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-debug

This leaves you with a local cluster and your KUBECONFIG pointed at it — ready for kubectl or k9s.

Running the Controller

make run

Compiles and runs the controller locally (outside the cluster), watching for resources via your KUBECONFIG.

Cleaning Up

make dev-clean

E2E Tests

make test-acceptance

Spins 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>

Upgrade Tests

See the Upgrade Tests README for details.

Required Environment Variables

🛠️ Export CLI

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.

🤝 Contributing

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.

🔒 Security

If you discover a potential security vulnerability, please follow our security policy — do not open a public GitHub issue for security concerns.

🙆‍♀️ Code of Conduct

We're committed to a welcoming, harassment-free community for everyone. By participating in this project, you agree to our Code of Conduct.

📋 Licensing

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.