DEV Community: Aroua KABOUBI

Kubernetes expertise: how to choose a consulting partner in 2026

Aroua KABOUBI — Tue, 18 Aug 2026 14:02:09 +0000

Key takeaways

Five delivery models all answer “yes” to “do you do Kubernetes?”. They are not selling the same thing, and three of them will be wrong for your problem.
The deciding criterion is neither day rate nor firm size. It is who actually writes the code on your cluster, and whether that is the person you met in pre-sales.
One question reveals incentive alignment: “what happens if we take operations back in two years?”

The market is not short of Kubernetes providers. It is short of ways to tell them apart, because five different businesses present themselves under the same phrase — “Kubernetes expertise” — and none will volunteer which one they actually are.

This guide sets out those five models, what each is really selling, and the questions that separate a pitch from a capability. It names no companies: the model is the right level of analysis, because two firms sharing a delivery model resemble each other far more than two firms sharing a headcount.
Disclosure :Edixos is a specialist cloud-native consultancy — model 3 — and also sells managed cloud operations. So we sit in two of the five models, including the one whose conflict of interest we flag. Put the same questions to us as to anyone else; we answer them at the end.

The five Kubernetes delivery models

1. The large systems integrator

The large technology consultancies, from several hundred to several thousand people, covering cloud, data, security and mobile, with framework agreements at most large enterprises.

What you are buying: capacity and contractual coverage. If you need forty people staffed next quarter, or procurement only permits pre-approved suppliers, this is the only workable model.

The trade-off : pyramid staffing. The architect who convinces you in pre-sales is not the person who writes your controllers — the margin comes precisely from that gap. On work where depth beats volume, the gap is paid in months of drift.

2. The cloud-native managed provider

Firms that build the platform and then run it, with 24/7 on-call and sometimes their own sovereign cloud.

What you are buying: the problem going away. No platform team to hire, no rotation to staff, no upgrade window to plan. For many organisations this is the right call, and it deserves saying plainly: if Kubernetes is not a strategic asset for you, operating it yourself is a cost with no return.

The trade-off: incentive alignment. A provider whose recurring revenue depends on running your platform has no economic reason to make you self-sufficient. Not bad faith — the structure of the model, and it can be contracted around. Ask directly: “contractually and technically, what happens if we want to take over operations in two years?“

3. The specialist cloud-native consultancy

Small to mid-sized firms where Kubernetes and platform engineering are the business, not one line in a catalogue of thirty expertises.

What you are buying : depth, and a handover. These teams write controllers, publish code, and work on CRDs, Crossplane, multi-tenancy and bare metal — where generalists stop. The normal deliverable is a platform your team then operates.

The trade-off: capacity. Ten people will not staff forty roles, will not clear procurement demanding three years of minimum revenue, and will not cover your security workstream in parallel. If your binding constraint is volume or process, this model wastes your time.

4. The freelancer

An independent expert, often excellent, with no overhead.

What you are buying: one precise skill, immediately. For an audit, an unblocking, or reinforcement on a team that already exists, this is frequently the best value in the market.

The trade-off: bus factor. No continuity, nobody to review the work. A control plane designed by one person without review becomes an asset you can neither evolve nor hand on. The risk is not competence — that is usually present.

5. Vendor-managed Kubernetes

GKE Autopilot, EKS, AKS, OVHcloud Managed Kubernetes, Scaleway Kapsule, with vendor support.

What you are buying: the control plane, operated by the vendor, at a cost nowhere near a human engagement. Many organisations need nothing else, and paying a consultancy for what a managed service already does is a classic procurement mistake.

The trade-off: support stops at the edge of the product. It will not design your golden path, will not write your abstractions, and will not say no to a team deploying whatever it likes. Everything that decides whether a platform gets adopted stays with you.

The decision table

	Large SI	Managed Provider	Specialist Consultancy	Freelancer	Vendor-managed
Who writes the code	Supervised juniors	Their engineers	The people you met	One person	Nobody (product)
Seniority guaranteed in contract	Rarely	Often	By construction	N/A	N/A
Scale to 40 people	✅	⚠️ Limited	❌	❌	N/A
Depth (CRDs, Crossplane, bare metal)	⚠️ Varies	✅	✅	✅ Narrow	❌
Your team inherits the platform	⚠️ Varies	❌ Rarely the goal	✅	⚠️ Unreviewed	N/A
24/7 on-call	⚠️ Optional	✅	⚠️ Varies	❌	✅ Product scope
Fits enterprise procurement	✅	⚠️ Varies	⚠️ Often not	❌	✅
Contract rewards finishing	❌ Billed by time	⚠️ Recurring revenue	✅ Defined deliverable	❌ Billed by time	N/A
Bus factor	Low	Low	Medium	High	Low

This table describes models, never named companies. A single firm may sit in two models — Edixos included, which does both consulting and managed operations. When that is the case, ask which of the two carries the margin.

Seven questions to ask in pre-sales

1. “Who specifically will do the work, and can I speak to them before signing?” The one question whose answer cannot be rehearsed. A polite refusal, or “we’ll confirm staffing after signature”, is itself an answer.

2. “Show me public code.” Controllers, operators, Crossplane providers, CNCF contributions, maintained Helm charts. Real Kubernetes expertise leaves public traces; slide-deck expertise leaves none.

3. “Tell me about a production incident you caused.” An unfair question, deliberately. A team that has operated clusters has one, tells it precisely, and explains what they changed afterwards. A team without one has never been on call.

4. “What exactly is the deliverable, and what does the end of the engagement look like?” A platform engagement with no exit milestone quietly becomes open-ended staffing. Insist on the Git repository, documentation, runbooks, a handover session, and a date.

5. “What happens if we take operations back in two years?” The question that reveals alignment better than any reversibility clause.

6. “What are you not good at?” A provider claiming to cover everything has disqualified itself. Across a surface as wide as cloud-native, no admitted boundary means no actual specialism.

7. “What does the deliverable cost, not the day?” An isolated day rate informs nothing. A cheaper profile who takes three times as long costs more, and costs you a quarter on top. The full calculation is in what each model really costs.

Five red flags

A cloud partner tier presented as Kubernetes expertise . A partnership measures resale volume, not engineering capability.
The senior CV in the appendix, with no staffing commitment in the contract.
No public trace at all — no repository, no talk, no technical writing, no post-mortem. In an ecosystem as open as the CNCF, that is abnormal.
A proposal that opens with a tool — “we will deploy platform X” — before anyone has understood your golden path.
A quote with no discovery phase. Nobody prices a Kubernetes migration without looking at what exists. An instant number means a change request is already planned.

Running the selection in three steps

1- Qualify the model before the firms. Half a day internally: do we need capacity, operations, depth, reinforcement, or just a managed cluster? This eliminates two-thirds of the market and stops you comparing offers that were never comparable.

2- Buy an audit before you buy a project. Two to five days of architecture review from two firms in the same model costs a fraction of the project and shows how they reason. It is the only test drive available.

3- Contract the exit at the start. Repository on your side, documentation as a deliverable, a dated handover session. An aligned partner agrees without argument.

Edixos against its own checklist

We are model 3: a small, senior consultancy building Kubernetes control planes, golden-path internal platforms, reusable Crossplane APIs and SRE agents. Here are our answers to the seven questions, in order

Who will do the work? Named engineers, with their record and certifications published on the team page. From the first conversation you are talking to the person who will write the code — there is no bench behind us.
Public code? A Crossplane provider for OVHcloud that we maintain, 15,000+ downloads, running in production for French social ministries. Sveltos fleet work, contributions to the Tilt ecosystem.
A production incident? Our field notes on Talos and bare metal and on a stale eBPF network policy on GKE are published, causes and fixes included.
Production tenure? Kubernetes in production since version 1.2, in 2015 — before CRDs, before managed offerings existed.
Real systems? Over a thousand applications migrated for an automotive manufacturer, 150+ CRDs for a bespoke PaaS, self-service platforms in production.
A clean end of engagement? Repository, documentation and runbooks yours from day one, and a dated handover session written into the contract.
What are we not good at? Volume. We will not staff forty roles, will not clear heavyweight procurement, and for operations at very large scale on a provider’s own sovereign cloud another model will serve you better. We say so in the first meeting rather than cost you a quarter.

And to answer our own alignment question: we also sell managed operations , as Managed Cloud Operations. The conflict of interest described in model 2 therefore applies to us too. What you can verify in the contract rather than take on trust: it is contracted separately, never as the obligatory sequel to a build, and everything you need in order to do without us is yours from day one.

The lowest-risk next step is a two-to-five-day architecture review. You leave with an assessment you can act on even if you never work with us afterwards.

Frequently asked questions

What kind of Kubernetes consulting partner should I choose?
The one whose model matches your binding constraint. Need headcount: a large systems integrator. Need never to operate the platform: a managed provider. Need technical depth and autonomy afterwards: a specialist consultancy. Vendor size is not the criterion; the delivery model is.

How do I verify a partner's real Kubernetes expertise?
Ask for public code: controllers, Crossplane providers, CNCF contributions, published post-mortems. Then ask to speak to the engineer who will do the work, not the pre-sales architect. The gap between those two people is the most useful signal in the whole procurement.

What questions should I ask a Kubernetes provider before signing?
Who specifically will do the work, and can I speak to them? Where is your public code? Tell me about a production incident you caused. What exactly is the deliverable and what does the end of the engagement look like? What happens if we take operations back in two years?

Does a certified cloud partnership prove Kubernetes expertise?
No. A partner tier measures resale volume and commercial certification counts, not the ability to design a control plane or write a controller. It is a procurement signal, not an engineering one, and it is routinely presented as the second.

Specialist consultancy or vendor-managed Kubernetes?
If you need a reliable cluster and nothing more, vendor-managed is enough and costs far less than a human engagement. A consultancy earns its place when the value sits in the layer above: golden paths, abstractions, governance, and product-team autonomy.

Why Terraform Falls Short for Platform Engineering (and Kubernetes Wins)

Aroua KABOUBI — Tue, 11 Aug 2026 15:26:03 +0000

Key takeaways:

Terraform is not the problem — it’s the wrong tool for a self-service platform: manual apply per change, no native API, no continuous reconciliation.
Kubernetes + KRM + CRDs turn infrastructure into a self-service API: request a database, bucket, or cache with a single YAML — no tickets.
Even Kelsey Hightower has stated Terraform isn’t suited for building cloud-provider-style control planes . -Field-reported KPIs from teams that made the switch: +50% developer productivity, −36% lead time, +40% software quality (Puppet State of DevOps, Gartner).

Do you practice DevOps or Cloud today? Then you’ve lived this: you’re shipping a critical feature, but everything stops because you need a Jira ticket to provision a database, an S3 bucket, or any other cloud service. Welcome to TicketOps — a pattern that creates bottlenecks, silos, and quietly kills the agility your teams spent years building.

Let’s be blunt: the celebrated principle “you build it, you run it” too often becomes “you build it, someone else queues it, and maybe one day you get to run it.” The result is wasted time, frustrated developers, and stalled innovation.

Why Terraform is not suited for Platform Engineering

Terraform is popular and works well for provisioning resources occasionally — but it was never designed to be the engine of a self-service platform. Three structural gaps explain why:

Manual cycle — a terraform apply is required for every change. Not viable for dynamic, constantly evolving resources.
No native API — you can’t easily expose infrastructure as self-service through a simple API.
No continuous reconciliation — Terraform doesn’t automatically drive infrastructure back to its desired state when it drifts.

In short, for a genuine platform-as-a-service, Terraform hits its ceiling fast.

Kubernetes + KRM + CRDs: the new self-service model

Kubernetes is no longer just a container orchestrator — it’s a universal control plane for your entire infrastructure. The mechanism is the Kubernetes Resource Model (KRM) plus Custom Resource Definitions (CRDs), which let you manage anything declaratively.

Imagine this:

Need a database? Apply a YAML.
Need a Cloud Storage bucket? Another YAML.
Want a Redis cache? That same YAML pattern again.

This is pure self-service, with zero tickets, powered by Kubernetes and projects like Crossplane, AWS Controllers for Kubernetes (ACK), and Google Config Connector.

During his talk at Control Plane Day with Crossplane 2023, Kelsey Hightower — Developer Advocate at Google and a defining voice in the cloud-native community — put it plainly:

“Terraform is not suited for building control planes similar to those of major public cloud providers.”

Coming from an engineer whose talks and live demos have guided modern infrastructure practice for a decade, that carries real weight.

Level up: expose everything via REST, gRPC, and SDKs

The goal of this architecture is simple: give teams autonomy without losing control. Kubernetes acts as the central control plane on top of KRM, and product, DevOps, and development teams provision what they need through a single API — exposed over REST, gRPC, or even WebSocket.

This API isn’t a gadget — it becomes the standard entry point, usable from client libraries (Go, Python, JavaScript, Java), CLI tools, or an internal portal like Backstage. Teams stop waiting on tickets, and delivery cycles accelerate.

In the background, the platform continuously reconciles resources against your cloud providers and key tools (Google Cloud, GitLab, Kubernetes, Vault, Okta…). While teams self-serve, your Platform Engineering, SRE, and DevSecOps groups enforce company-wide security rules, reliability standards, and best practices. You industrialize the cloud at scale without friction: governance stays central, teams gain speed — the best of both worlds.

Better still, you can expose your services as a first-class API. From your CRDs you can auto-generate protobuf definitions, then expose REST or gRPC endpoints and ship SDKs for every language your developers use. They won’t even need to write YAML — they’ll call your platform API directly. The modern developer’s dream becomes real:

Zero tickets
Instant provisioning
Transparent GitOps integration

The numbers speak for themselves

Here are concrete KPIs reported by organizations that made the leap from TicketOps to self-service platforms:

🚀 +50% developer productivity
🕒 −36% lead time between commit and production
🧘 +40% improvement in software quality
📈 75% of large enterprises expected to adopt this model by end of 2025 (Gartner)

These figures come from the field — notably the Puppet State of DevOps report and Gartner analysis. Your mileage will vary, but the direction is consistent: less waiting, faster delivery, higher quality.

Goodbye TicketOps, hello self-service

The era of endless Jira tickets for simple provisioning is over. Adopt Kubernetes as the foundation of your Platform Engineering — with KRM and CRDs — and give your teams a genuinely self-service experience. Your infrastructure becomes agile, scalable, and API-first, and your developers will thank you (maybe even with cookies 🍪).

So — ready to leave Terraform behind for the parts it was never built for, and step into an API-first future with Kubernetes? You won’t regret it. 🚀

Conclusion: how Edixos can support you

At Edixos, we know a cloud platform is more than a stack of tools: it must be built to last, evolve, and fit each organization’s specific needs. Our expertise goes far beyond deploying Kubernetes clusters:

We write custom Kubernetes controllers that automate your business processes and specific needs.
We integrate powerful composition engines like Crossplane and Kro to turn Kubernetes into a true multi-cloud provisioning engine.
We work with existing controllers such as Config Connector (KCC), which natively expose major cloud providers’ services through Kubernetes CRDs.
We build complete, API-first platforms — exposing your services via REST, gRPC, and multi-language SDKs — to unify access and accelerate adoption.

What we offer is unique know-how to industrialize your cloud platforms: governance, security, and self-service at scale. This is exactly the kind of work behind our decade-long Kubernetes journey. If your ambition is a robust platform that aligns innovation, agility, and control, we have the building blocks and the experience to make it happen.

Let’s talk about your advanced Kubernetes challenges

Are you looking to automate operations, model your business processes, or industrialize deployments on Kubernetes? Let’s discuss your challenges and see how the API Machinery can bring you speed, reliability, and scalability.

Crossplane and OVHcloud: A provider-ovh Step-by-Step Guide

Aroua KABOUBI — Thu, 06 Aug 2026 13:46:11 +0000

Key takeaways:

Crossplane turns your Kubernetes cluster into a control plane that provisions cloud infrastructure through custom resources — no terraform apply, just YAML that a controller reconciles continuously.

provider-ovh is an open-source Crossplane provider built by Edixos, generated with Upjet on top of the official OVHcloud Terraform provider. It exposes 135+ OVHcloud resources as CRDs and is published on the Upbound Marketplace

This guide is end to end: a kind cluster, Crossplane, the provider, credential wiring, and a real managed Kubernetes cluster provisioned on OVHcloud.

Introduction

Most teams still provision OVHcloud the imperative way: a Terraform run here, a console click there, a script nobody wants to touch. It works until you need self-service, drift correction, and RBAC — the things a platform team actually has to deliver.

Crossplane flips the model. Your Kubernetes cluster becomes the control plane, and infrastructure becomes a set of custom resources that a controller keeps reconciled. At Edixos we built provider-ovh to bring that model to OVHcloud, and this article walks through it from an empty machine to a running managed Kubernetes cluster on OVH.

If you have used Crossplane with AWS or GCP, this will feel familiar. If you have not, you will have a working control plane in about fifteen minutes.

What is Crossplane?

Crossplane is a CNCF open-source control plane that extends Kubernetes so it can provision and manage external infrastructure. You install a provider, which registers Custom Resource Definitions (CRDs) for a cloud’s resources, and from then on you declare that infrastructure as Kubernetes objects. A controller reconciles each object against the provider’s API, correcting drift and cleaning up on delete.

The payoff is that infrastructure inherits everything Kubernetes already gives you: declarative YAML, RBAC, GitOps, admission control, and a single API surface across clouds. Instead of teams filing tickets, they apply a manifest — and the platform enforces the guardrails.

What is provider-ovh?

provider-ovh is the Crossplane provider for OVHcloud, built and maintained by Edixos. It exposes OVHcloud services — public cloud projects, managed Kubernetes, databases, private networks, IAM, object storage, and more — as Kubernetes managed resources. It is available on the Upbound Marketplace and the source lives on GitHub.

The story behind it is worth telling, because it explains why the project exists at all. When we first looked, there was no official or community Crossplane provider for OVHcloud. We built the first one and offered to donate it — the response at the time was that community providers could not be considered official, and it would not be maintained internally. Facing other commitments, the project went dormant for nearly a year.

Then three engineers — Nicolas, Kevin, and Ferréol from Theseus — got in touch. They were already running the provider in production, powering a Database-as-a-Service offering for the French public sector. Shortly after, Fabien opened a pull request bumping the provider to Crossplane 2.0. That was the catalyst. The provider was reborn as v2.9.0, with Endre Karlson and Alegrowin joining as co-maintainers, and it is now an actively maintained community project covering 135+ OVH resources and 90%+ of the Terraform provider surface, on both Crossplane 1.x and 2.x.

The lesson we keep repeating: real users in production are what keep infrastructure projects alive.

How provider-ovh is built?

provider-ovh is generated, not hand-written. It uses Upjet, the Crossplane code-generation toolkit, on top of the official OVHcloud Terraform provider — pinned in this release to version 2.13.1. Upjet reads the Terraform provider’s schema and generates XRM-conformant managed resources: Go API types, deepcopy functions, controllers, and CRD manifests.

That approach is why coverage is so broad. Instead of implementing every OVH endpoint by hand, we regenerate the provider whenever OVHcloud ships a new Terraform version, and the new resources come along for free. The current release ships 281 CRD manifests — the 135+ resources appear in two flavors, cluster-scoped and namespaced, thanks to Crossplane v2 (more on that below). Bumping the underlying Terraform provider is a documented, four-command routine: update the Makefile and go.mod, run make generate, and commit the regenerated schema, types, and CRDs.

Prerequisites

Before you start, install the following tools locally. Everything runs on your machine except the OVHcloud API calls, which need a real account.

Docker (or another container runtime kind supports)
kind — to run a throwaway Kubernetes cluster
kubectl — to talk to the cluster
Helm — to install Crossplane
An OVHcloud account with API credentials (we generate them in Step 5)

Step 1: Create a local kind cluster

Crossplane is a lightweight control plane, so a single-node kind cluster is plenty for this walkthrough. Create one:

Confirm the cluster is up and kubectl points at it:

This cluster never runs your OVH workloads — it only hosts the Crossplane control plane that provisions them.

Step 2: Install Crossplane

Install Crossplane with its official Helm chart into a dedicated crossplane-system namespace. This deploys the core Crossplane controllers and the package manager that installs providers.

Wait for the pods to become ready, then verify the installation:

You should see the crossplane and crossplane-rbac-manager pods running. Crossplane has also registered its own core CRDs — providers, configurations, providerconfigs — which the next step builds on.

Step 3: Install provider-ovh

Installing a provider is itself a Kubernetes resource: you apply a Provider object pointing at the package image, and Crossplane’s package manager pulls it and registers its CRDs. Apply provider-ovh from the Upbound registry:

Pin an explicit version tag in production — check the Marketplace for the latest release rather than using :latest. Watch the provider become healthy:

Once the INSTALLED and HEALTHY columns both read True, the provider’s controllers are running and every OVH CRD is registered in your cluster.

Step 4: Discover the managed resources

Because the provider registers its resources as standard CRDs, you explore them with plain kubectl — no special tooling. This is one of the quiet advantages of the Crossplane model: your infrastructure catalog is queryable from the same API as everything else.

List the OVH resource types the provider added:

You will see resources grouped by service — kube.ovh.edixos.io, network.ovh.edixos.io, cloud.ovh.edixos.io, databases.ovh.edixos.io, iam.ovh.edixos.io, and more. To inspect the fields of any resource, use kubectl explain:

That prints the full spec for a managed OVHcloud Kubernetes cluster — every forProvider field you can set — straight from the CRD’s OpenAPI schema. The complete API reference is also published at doc.crds.dev.

Step 5: Configure OVHcloud credentials

The provider needs OVHcloud API credentials to reconcile anything real. You supply them through a Kubernetes Secret, then point a ProviderConfig at that Secret. First, generate an application key, application secret, and consumer key from the OVH API console, granting the API rights your resources require.

Create the Secret in the crossplane-system namespace:

Now create a ProviderConfig named default that tells the provider where to read those credentials:

Never commit real credentials to Git. In production, source the Secret from an external secret store — provider-ovh supports Crossplane’s external-secret-store integration for exactly this.

Step 6: Provision your first OVHcloud resources

With credentials wired up, provisioning is now a kubectl apply. Let’s build a real stack: a private network, a subnet inside it, and a managed Kubernetes cluster attached to both. This is the same flow that I walk through in the Platform Engineering with Crossplane & OVHcloud talk. Each manifest references the default ProviderConfig from the previous step.

Start with a private network. Replace serviceName with your OVH public cloud project ID:

Add a subnet inside that network — this is where your cluster’s nodes get their IP addresses. It references the private network by name with networkIdRef, so Crossplane waits for the network and wires the ID in for you:

Now a managed Kubernetes cluster that references both the network and the subnet by name — Crossplane resolves each reference and injects the resulting IDs automatically:

Apply them and watch Crossplane reconcile against the OVHcloud API:

The kubectl get managed command lists every external resource Crossplane is tracking, with READY and SYNCED columns. When both read True, your cluster exists on OVHcloud — provisioned entirely through the Kubernetes API. Add a NodePool the same way, referencing the cluster with kubeIdRef, and you have a complete managed Kubernetes environment described as YAML.

Cluster-scoped vs namespaced resources

provider-ovh ships every resource in two variants because it targets Crossplane 2.x. Cluster-scoped resources use the classic network.ovh.edixos.io group; namespaced resources use the *.m.ovh.edixos.io groups (the m marks the modern, namespaced API). Namespaced resources let you scope OVH infrastructure to a Kubernetes namespace, which is the foundation for safe multi-tenancy — each team gets its own namespace, its own RBAC, and its own slice of infrastructure. That doubling is why the release contains 281 CRD manifests for roughly 135 logical resources.

Beyond raw resources: Compositions

Applying individual managed resources is powerful, but it is not yet a platform. The real leverage comes from Compositions: you define a Composite Resource Definition (an XRD) that presents a simple, opinionated API — say, EdixosCluster — and a Composition that expands it into the private network, subnet, cluster, and node pool underneath. Developers request one high-level resource; the platform assembles the details with your standards baked in.

The provider-ovh repository ships a complete Composition example that does exactly this. This is where Crossplane stops being a Terraform replacement and becomes a self-service platform — the pattern we build for clients at Edixos every week.

Troubleshooting

When a resource will not become ready, the reconcile loop tells you why. Describe the managed resource and read its conditions and events:

Most failures fall into three buckets: credential errors (the Secret JSON is malformed, or the OVH token lacks the required API rights), reference errors (a *Ref points at a resource that does not exist or is not yet ready), and quota or region errors returned straight from the OVHcloud API. For controller-level issues, install the provider with the --debug flag via a DeploymentRuntimeConfig and check the provider pod logs in crossplane-system.

Conclusion

You now have the full loop: a kind cluster running Crossplane, provider-ovh installed and healthy, credentials wired through a ProviderConfig, and real OVHcloud infrastructure provisioned as Kubernetes resources. The same manifests drop straight into a Git repository and a GitOps pipeline — which is the whole point.

provider-ovh started as a project OVHcloud declined to adopt and survived because engineers ran it in production and pushed it forward. It is open source, community-maintained, and built for teams who want OVHcloud to behave like every other cloud in a Crossplane control plane. Star it on GitHub, try it on your own project, and open an issue if something is missing — that feedback is exactly what keeps it moving.

Crossplane and provider-ovh are one piece of a larger platform-engineering practice. For the wider context, read why Kubernetes beats Terraform for platform engineering and our field-tested blueprint for building Kubernetes as a Service — both grounded in the decade of production Kubernetes behind this provider.

Let’s talk about your Crossplane platform

Do you want to expose OVHcloud — or any cloud — as self-service infrastructure your teams consume through the Kubernetes API? Let’s discuss your platform goals and see how a custom Crossplane control plane can bring you speed, governance, and scale.

Frequently asked questions:

What is provider-ovh?
provider-ovh is a Crossplane provider built by Edixos that exposes OVHcloud resources as Kubernetes custom resources. It is generated with Upjet on top of the official OVHcloud Terraform provider, covers 135+ resources, and is published on the Upbound Marketplace under edixos/provider-ovh for Crossplane 1.x and 2.x.

Do I need OVHcloud API credentials to use provider-ovh?
Yes. The provider authenticates to the OVHcloud API using an application key, application secret, and consumer key. You generate these tokens from the OVH API console, store them in a Kubernetes Secret, and reference that Secret from a ProviderConfig so Crossplane can reconcile your resources.

Can I run Crossplane and provider-ovh on a local kind cluster?
Yes. Crossplane is a lightweight control plane and runs fine on a local kind cluster for learning and development. It only provisions real OVHcloud infrastructure once you supply valid API credentials through a ProviderConfig, so the control plane itself has no special hosting requirement.

How is provider-ovh different from the OVHcloud Terraform provider?
provider-ovh reuses the OVHcloud Terraform provider's schema under the hood but exposes it as Kubernetes CRDs reconciled continuously by Crossplane. Instead of running terraform apply, you declare resources as YAML and a controller keeps live infrastructure matching that declared state, with RBAC and GitOps built in.

Our Kubernetes Journey: 10 Years Building Cloud-Native Platforms

Aroua KABOUBI — Mon, 27 Jul 2026 18:21:28 +0000

Key takeaways:

Edixos ran Kubernetes 1.2 in production in 2015, using Third Party Resources — the predecessors of today’s CRDs — well before managed Kubernetes was mainstream.
Our edge is the platform layer: custom Go controllers, GitOps, and Crossplane that turn Kubernetes into an API-driven, self-service control plane.
Real production systems, not slideware: 1,000+ apps migrated for an automotive leader, 150+ custom CRDs for a bespoke PaaS, plus smart-city and utility platforms.

Introduction:

Some tools permanently change how you design infrastructure. For Edixos, that tool is Kubernetes — and our story with it started in 2015, when container orchestration was still in its infancy. A decade of trials, failures, and shipped production systems laid the foundation for the company we are today.

We are not another consulting firm renting out slides. We are practitioners who have run Kubernetes in production since version 1.2, written the controllers, and operated the clusters at 3 a.m. This article takes you behind the scenes: from our first master node to the platforms that now run thousands of applications.

How did Edixos start with Kubernetes?

It started in 2015 with kubeup.sh and Kubernetes 1.2 in production — a bold bet at a time when almost no one ran containers at scale. We used Third Party Resources (TPR), the ancestors of CRDs, installed clusters on AWS with kops, and migrated a SaaS platform onto this new architecture.

I still remember launching the kubeup.sh script and watching our first master node appear. It was more than a technical success — it was a defining moment.

To automate environment creation, we even wrote our own Kubernetes controller in Python. It was demanding, hand-crafted work, but incredibly formative. In 2016 I moved into Kubernetes consulting, helping major companies across France — from bare-metal setups to managed services. Every mission widened the expertise Edixos is built on.

What makes Edixos different?

We don’t just promise excellence — we build it daily, line by line, cluster by cluster. What sets us apart is turning complex problems into elegant, durable solutions: automating Kubernetes environments, designing custom controllers, and industrializing GitOps practices with a relentless focus on impact.

Working with Edixos means partnering with seasoned practitioners who are genuinely passionate about cloud-native best practices — engineers who write production code, not PowerPoints, and who level up your teams as they go.

Real projects, not PowerPoints :

At Edixos we write code, Kubernetes manifests, robust APIs, and custom controllers — not slides. Every mission is a real technical challenge and a complex business problem. Here are a few of the adventures that forged our reputation.

🚗Cloud transformation for a French automotive leader
For a major French car manufacturer, we orchestrated the migration of more than 1,000 applications to the public cloud. Kubernetes became the backbone, with a centralized control plane built on Crossplane and KRM and multi-tenant custom controllers written by our team. The result: teams now consume infrastructure as a service through CRDs — with traceability, RBAC, and governance built in, and zero friction.

🌐A Kubernetes-first Platform-as-a-Service
Inspired by KRM and GitOps, we designed a bespoke PaaS on Kubernetes for a client. Key features:

A self-service REST and gRPC API.
Over 150 custom CRDs.
In-house Go controllers automating the creation of clusters, workloads, and managed services.
Built-in automatic reporting, policy enforcement, and FinOps.

This is not an off-the-shelf product. It’s a living platform, engineered for scalability, control, and team autonomy.

🏙️Kubernetes serving smart cities
For a public-sector organization, we built a Kubernetes platform hosting critical components: web services, databases, Kafka brokers, and urban data collectors. Every microservice and every real-time pipeline is orchestrated resiliently. It was never just a “cluster” — it was a digital city operated continuously.

💧Innovation flowing like water
Using Kubernetes and Kafka, we built a real-time water-consumption monitoring solution for a local operator: leak detection, live dashboards, and optimized storage. Proof that cloud-native and sustainability can go hand in hand.

These projects show that at Edixos we build cloud-native platforms to engineering standards. If you’re looking for a partner who truly knows API Machinery, controllers, and GitOps — and speaks YAML and Go better than PowerPoint — you’re in the right place.

Conclusion:

Cloud-native is a field of execution, not theory. At Edixos we don’t sell promises; we ship architectures that run, pipelines that deploy, platforms that evolve, and APIs that simplify. What we build is designed to last, to scale, and to serve your teams.

And when the official documentation isn’t enough, that usually means we need to write it ourselves — in Go, with tests, and a solid controller-runtime. Whether you want to industrialize GitOps, create custom CRDs, stand up an enterprise PaaS, or adopt Crossplane for infrastructure as code, our engineers have already been there. And they still are.

Curious how these platforms actually work under the hood? Read why Terraform falls short for Platform Engineering and how Kubernetes + CRDs deliver true self-service.

Let’s talk about your advanced Kubernetes challenges:

Straight answers:

Frequently asked questions:

When did Edixos start working with Kubernetes?

Edixos' founder ran Kubernetes 1.2 in production in 2015, using Third Party Resources (the ancestors of CRDs) and installing clusters on AWS with kops. That decade of hands-on experience predates most managed Kubernetes offerings and shaped the company's platform-engineering practice.

What is a Kubernetes custom controller and why does it matter?

A custom controller is code that watches Custom Resources and continuously reconciles real infrastructure to match a declared state. It matters because it turns Kubernetes into an API-driven platform: teams request databases, clusters, or workloads through YAML instead of tickets, with RBAC and governance built in.

Does Edixos only deploy Kubernetes clusters, or build platforms on top?

Both, but the value is in the platform layer. Edixos writes custom controllers, integrates Crossplane and Config Connector, and exposes infrastructure as self-service APIs (REST, gRPC, SDKs) — so internal teams provision what they need without friction while SRE and security keep central governance.

What industries has Edixos built Kubernetes platforms for?

Edixos has delivered cloud-native platforms across automotive (migrating 1,000+ applications to public cloud), the public sector (smart-city services on Kubernetes), and utilities (real-time water-consumption monitoring with Kafka), among others — each a production system, not a proof of concept.

DEV Community: Aroua KABOUBI

Kubernetes expertise: how to choose a consulting partner in 2026

Key takeaways

The five Kubernetes delivery models

1. The large systems integrator

2. The cloud-native managed provider

3. The specialist cloud-native consultancy

4. The freelancer

5. Vendor-managed Kubernetes

The decision table

Seven questions to ask in pre-sales

Five red flags

Running the selection in three steps

Edixos against its own checklist

Frequently asked questions

Why Terraform Falls Short for Platform Engineering (and Kubernetes Wins)

Key takeaways:

Why Terraform is not suited for Platform Engineering

Kubernetes + KRM + CRDs: the new self-service model

“Terraform is not suited for building control planes similar to those of major public cloud providers.”

Level up: expose everything via REST, gRPC, and SDKs

The numbers speak for themselves

Goodbye TicketOps, hello self-service

Conclusion: how Edixos can support you

Let’s talk about your advanced Kubernetes challenges

Related reading

Frequently asked questions:

Is Terraform bad? Should we stop using it?

What is the Kubernetes Resource Model (KRM)?

How do Kubernetes and CRDs enable self-service infrastructure?

What is TicketOps and why is it a problem?

Can I expose Kubernetes infrastructure as a REST or gRPC API?

Crossplane and OVHcloud: A provider-ovh Step-by-Step Guide

Key takeaways:

Introduction

What is Crossplane?

What is provider-ovh?

How provider-ovh is built?

Prerequisites

Step 1: Create a local kind cluster

Step 2: Install Crossplane

Step 3: Install provider-ovh

Step 4: Discover the managed resources

Step 5: Configure OVHcloud credentials

Step 6: Provision your first OVHcloud resources

Cluster-scoped vs namespaced resources

Beyond raw resources: Compositions

Troubleshooting

Conclusion

Let’s talk about your Crossplane platform

Frequently asked questions:

Our Kubernetes Journey: 10 Years Building Cloud-Native Platforms

Key takeaways:

Introduction:

How did Edixos start with Kubernetes?

What makes Edixos different?

Real projects, not PowerPoints :

Conclusion:

Let’s talk about your advanced Kubernetes challenges:

Frequently asked questions:

When did Edixos start working with Kubernetes?

What is a Kubernetes custom controller and why does it matter?

Does Edixos only deploy Kubernetes clusters, or build platforms on top?

What industries has Edixos built Kubernetes platforms for?