DamDevOps

Crossplane: the perfect tool to build your own PaaS ?

,

Too Good to Be True!

What if I told you there’s a tool « almost magical » that lets you manage your platform as a product? Sounds like a dream, right? You might not believe it… but you’d be wrong. Because this tool has been around for a few years now, and its name is Crossplane.

Why Build Your Own PaaS?

Let’s be honest developers want to ship features, not mess around with cloud dashboards or wrestle with Terraform modules. Meanwhile, platform and infra teams are focused on cost, security, consistency, and automation.

So how do you give devs the speed and simplicity they want, without compromising on governance or standards?

That’s where an internal PaaS (Platform as a Service) comes in. Something that gives devs a Heroku-like experience but entirely within your own infrastructure, with your policies, your limits, and your tooling.

Sounds complex? It can be unless you use the right tool. And that tool is Crossplane.

What Is Crossplane?

Crossplane is an open-source CNCF project that turns your Kubernetes cluster into a control plane for managing cloud infrastructure.

Think Terraform, but Kubernetes-native, fully declarative, and way more composable. Instead of pushing .tf files, you’re applying YAMLs to the cluster. But more than that you can define your own infrastructure abstractions, set policies, and expose simplified interfaces to developers.

How It Works (Quick Overview)

Here’s the key concepts:

High-level architecture of a Crossplane-based Internal PaaS
  • Providers: Plugins that let Crossplane talk to AWS, GCP, Azure, and more
  • Compositions: Infra templates you create (e.g. “standard Postgres setup”)
  • Claims: What developers request (e.g. “give me a DB”)

Crossplane turns your Kubernetes cluster into an infra platform API. Developers interact with it using clean, simplified YAMLs and everything else is handled behind the scenes.

A Real-World Example: Provisioning a PostgreSQL database

Let’s say a dev team needs a new postgresql database.

The traditional way:

  • They open a Jira ticket
  • Someone provisions the DB manually (or via Terraform)
  • Credentials are shared manually
  • You cross your fingers it’s tagged properly and eventually cleaned up

The Crossplane way:

  • The dev applies a YAML with a claim for a databaseAccess
  • Crossplane provisions it automatically via the cloud provider

Here an example of database claim have I use few days ago:

apiVersion: damdevops.com/v1alpha1
kind: DatabaseAccess
metadata:
    name: damdevops-db
spec:
    instanceRef: damdevops-dbi
    dbName: damdevops-db
    schemas:
        - blog
        - networks
    user:
        username: blog-user
        ownerOf:
            - blog
        readerOf:
            - public
    user:
        username: networks-user
        ownerOf:
            - networks
    writeConnectionSecretToRef:
        name: damdevops-db-creds

What this manifest made ?!
1 – It create the database « damdevops-db » on the instance « damdevops-dbi »
2 – It create two schemas (blog, networks) on the database
3 – It create two users (blog-user, networks-user) and grant them privileges (owner or reader) on specified schemas and on their objects (tables, views…)
4 – It stored credentials who have been created in a Kubernetes secret.

No tickets. No back-and-forth. Just clean automation and full control for the platform team.

Why Crossplane Is Great for Internal PaaS

  • Abstract complexity: Devs don’t need to know if it’s RDS, Cloud SQL, or something else. You define the backend, they get the service.
  • Declarative & GitOps-friendly: Works great with ArgoCD, Flux, and your existing Git workflows.
  • Multi-cloud ready: Support AWS, GCP, Azure, or even on-prem using the same API.
  • RBAC built-in: Control access per team, per namespace, per resource type.
  • Composability: Build complex infra products (e.g. DB + S3 bucket + IAM roles) as a single claim.

In short: Crossplane lets you build infrastructure the same way devs build APIs. That’s the essence of a true internal PaaS.

Drawbacks & Challenges

Let’s be real: Crossplane isn’t magic. It comes with its own learning curve.

  • Learning curve: Compositions and claims take a little time to master.
  • Debugging: Troubleshooting provider-level errors can be tricky at first.
  • Initial investment: You’ll need to spend time upfront designing good abstractions.

But once you’re through that, the return is massive especially as your team grows and you scale platform offerings.

Tips to Build a Solid Internal PaaS with Crossplane

  • Start small expose a simple resource (like an S3 bucket or PostgreSQL DB).
  • Work closely with devs build abstractions around their real needs.
  • Version your compositions treat them like internal APIs.
  • Add GitOps early plug it into ArgoCD or Flux from day one.
  • Build lightweight docs or a CLI/portal help devs discover available infra products.

Remember: you’re building a platform. Treat it like a product.

Final Thoughts

Crossplane won’t build your PaaS for you but it gives you the perfect foundation to build one that actually works.

If your org is already on Kubernetes and heading toward GitOps, Crossplane fits right in. It helps you shift from “infrastructure as code” to infrastructure as a service managed by your platform team, consumed by your devs.

Is it perfect? Maybe not. But is it the best thing out there today to build your own internal PaaS?

Very possibly.

Further Resources