CRDs Outside Kubernetes: Declarative Infrastructure Without the Cluster

  • Published

Kubernetes revolutionized infrastructure management with Custom Resource Definitions (CRDs), allowing platform teams to extend the Kubernetes API to model and manage anything, from databases to entire cloud environments.

But what if you want the same abstraction power without being tied to Kubernetes?

That’s exactly what Cloudomation enables with Custom Objects and Object Templates: a powerful, technology-agnostic way to model and manage infrastructure and platform services, independent of any runtime.

From CRDs to Custom Objects

In Kubernetes, CRDs let you define your own resource types (MyDatabase, CloudEnvironment, AccessRequest, …) and control their lifecycle with custom controllers. This pattern became so successful that projects like Crossplane extended CRDs to manage resources outside of Kubernetes — such as AWS RDS or GCP buckets — using the same Kubernetes-native API and reconciliation loop.

Cloudomation takes this idea one step further.

With Object Templates and Custom Objects, Cloudomation lets you define your own resource types, just like CRDs, but completely decoupled from Kubernetes.

Model Anything — Without Cluster Lock-in

Cloudomation’s object model is:

  • Technology-agnostic — no dependency on Kubernetes or any specific platform
  • Programmable — written in Python, no DSLs or YAML schemas to wrestle with
  • Composable — custom objects can relate to one another and trigger workflows
  • Integrated — interact with them via REST API or Webhooks

You can define custom object types for:

  • VMInstance on OpenStack
  • ProjectEnvironment across AWS and GCP
  • CI/CDPipeline in GitLab
  • AppConfig for application-level feature toggles
  • Anything else your platform manages

Each custom object comes with lifecycle hooks, automation points like before_create, on_create,on_update and on_delete, that can:

  • Trigger one-shot automation (e.g., provisioning a resource)
  • Maintain ongoing state synchronization (e.g., drift detection and reconciliation)
  • Drive event-based orchestration across tools

Why This Matters

Platform engineers spend a lot of time building abstraction layers: making infrastructure consumable via APIs, GUIs, or CLIs. CRDs were a breakthrough because they offered:

  • A standardized way to model resources
  • A declarative interface for developers
  • Hooks into a powerful reconciliation loop for state management

Cloudomation offers the same, without requiring a Kubernetes cluster, or even caring about the underlying platform.

Here’s why Cloudomation’s technology-agnostic custom objects are valuable:

  • Freedom from Kubernetes lock-in:
    Most modern platform automation solutions either require Kubernetes or are tightly coupled to it. Cloudomation lets you keep all the benefits of declarative resource modeling without forcing you to run or depend on a cluster.
  • Unified abstraction layer across all infrastructure:
    You can model VMs, cloud projects, SaaS accounts, CI pipelines, or any resource in the same consistent way. This massively simplifies building and maintaining platform services that span multiple technologies.
  • Full power of Python automation:
    Unlike CRDs with controllers often written in Go, Cloudomation lets you define lifecycle hooks and workflows in Python, a language many platform teams are comfortable with. This means faster iteration and easier customization.
  • Flexible integration & extensibility:
    The custom objects can trigger automation on events from Git, REST APIs, or other systems, fitting seamlessly into modern GitOps and event-driven platform architectures.
  • Avoid complexity creep:
    No Kubernetes means fewer moving parts to manage, troubleshoot, or upgrade, especially important in regulated or on-prem environments where introducing Kubernetes can be a big overhead.

Bottom line: It’s a powerful, practical, and future-proof approach to platform engineering automation that’s tailored for real-world complexity and diversity.

Crossplane Took CRDs Outside the Cluster. We Remove the Cluster Entirely.

Crossplane recognized how powerful CRDs are and extended them to manage external infrastructure from within Kubernetes. It gave platform teams a way to offer self-service infrastructure via familiar APIs.

Cloudomation builds on the same insight, but removes the Kubernetes dependency entirely. Our custom object model:

  • Works with Kubernetes if you want it to
  • Works without Kubernetes if you don’t
  • Provides the same abstraction layer, usable in on-prem, hybrid, or multi-cloud setups
  • Supports deep integration with tools like Git, Terraform, OpenStack, VMware, and more

Whether you’re managing Kubernetes clusters, VMware VMs, or third-party SaaS tools, you can define and automate their lifecycles in the same consistent way.

Real-World Use Cases

  • A team uses custom objects to model DevelopmentEnvironments across AWS and OpenStack. The same lifecycle hooks provision resources, configure access, and tear them down, regardless of where they run.
  • Another team defines PipelineTemplates as custom objects, allowing developers to register new projects in a Git-based catalog. Cloudomation automates scaffolding, CI/CD integration, and notification routing.
  • Custom objects represent ServiceAccounts, with automation managing creation in Azure, rotation schedules, and secret distribution.

API-Driven and Event-Driven

Custom objects in Cloudomation are first-class citizens in your automation landscape. They can be:

  • Queried and updated via REST API
  • Triggered via webhooks, e.g., on Git events
  • Managed via scripts, jobs, or long-running processes

They integrate easily into GitOps pipelines or event-based workflows, exactly as you would expect from a modern platform engineering tool.

Summary

Feature Kubernetes CRDs Crossplane Cloudomation Custom Objects
Infrastructure abstraction
Cloud resource automation
❌ (requires controllers)
Kubernetes required
GitOps-compatible
Technology-agnostic
❌ (Kubernetes-only)
Python-based logic

CRDs Without the Cluster

Custom Objects in Cloudomation give you the power of CRDs, without the Kubernetes baggage.

If you’re building an internal platform and want flexible, declarative, and technology-neutral resource modeling, you can do it with Cloudomation. No cluster required.

Now that you're here...

Cloudomation Engine is a platform orchestrator that enables you to provide self-service tools, automate complex tasks, and gain full visibility into your infrastructure.

Let’s talk about how Cloudomation
can make that happen for you.

Margot Mückstein

CEO & co-founder von Cloudomation