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:
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.
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.
Top comments (0)