< Infomaniak Network

Eco-design and technical debt: how we replaced horizontal scaling with a redesign that is 100x more efficient

Tuesday March 3rd, 2026
|In Case studies, All the news
|By Thomas Jacobsen

At Infomaniak, innovation is not only about creating new high-performance products, but also about making them more efficient, more sustainable and more responsible. In this article, our engineers Matthieu and Tristan explain how they redesigned Custom Brand, a kSuite feature that enables companies to use their online collaboration tools (instant messaging, Drive, Mail, Calendar, etc.) with their own domain and visual identity. Thanks to Go, Kubernetes and an eco-design approach, the service went from 2,855 pods to just 2 while becoming more reliable, more scalable and more sustainable.

By Tristan Smagghe (Software Engineer) and Matthieu Mabillard (Engineering Manager) at Infomaniak.

Why change?

Initially, this was a brand-new service, launched with very few users. The goal was to offer a simple means of customising kSuite applications with your own domain (ksuite.your-domain.com instead of ksuite.infomaniak.com).

The chosen architecture was deliberately simple: one customer = one Kubernetes pod, with an Apache server responsible for rewriting addresses and linking customer domains to kSuite applications.

This model worked well at first, but as more and more companies adopted this customisation option, its limitations became clear:

  • Thousands of pods to maintain
  • Huge amounts of reserved CPU and RAM resources left unused
  • Monitoring systems that were saturated and thus severely disrupted
  • The on-call team being woken up at night on a regular basis

In other words, what seemed robust at the beginning became an obstacle on a large scale.

The new approach: pool, simplify and modernise

The core idea behind the redesign was simple: pool what was duplicated. Instead of one Kubernetes pod per customer, a few pods are now enough to handle hundreds of customised instances.

To achieve this, we rewrote the system in Go, a language designed for performance and concurrency. Each pod now acts as an intelligent reverse proxy, capable of routing requests dynamically according to traffic and adjusting automatically to the load.

The infrastructure is no longer static: it self-adapts. During off-peak periods, a few pods are enough; during activity peaks, Kubernetes deploys more, then releases them. This elasticity means we use exactly the resources needed, at the exactly right time.

Another major change: SSL/TLS certificate configuration and management have been centralised. This simplifies administration, improves security and makes updates easier.

“We have moved from a rigid, costly system to an agile, scalable and lean model,” explains Matthieu Mabillard, Engineering Manager at Infomaniak.

The results speak for themselves

Beyond the impressive reduction in resources, the redesign has delivered a real operational gain. Even though requests are not processed any faster than before, we have enhanced performance in maintenance operations, deployments and our ability to evolve the service without risk.

Grafana monitoring of the number of pods required in real time after the migration

  • Kubernetes pods: from 2,855 to ~2 on average (-99.93%)
  • Reserved RAM: from 748 GB to ~2 GB (-99.73%)
  • Reserved CPUs: from 28.55 to ~0.2 (-99.30%)
  • Monitoring restored and stabilised
  • Multi-cluster compatibility and preparation for multi-data center deployment

These efficiency gains are not limited to performance. They allow us to reallocate resources to other strategic projects, while significantly reducing the overall carbon footprint of the infrastructure.

A direct impact on ecology and reliability

Fewer servers, less heat generated, less energy consumed. Beyond the figures, this is a genuine eco-design approach: thinking about consumption right from the service design stage.

Before the redesign, monitoring could no longer keep up. Today, we have a clear view of every request: how many resources are used, which components consume the most, and where to take action in order to keep improving.

This visibility enables us to fine-tune continuously and to anticipate needs without ever compromising stability.

A completely transparent migration

The migration was carried out gradually, starting with our own internal services. Thanks to a canary deployment approach, the switchover was transparent: no significant downtime and no loss of performance for end users.

Within a week, the entire service was running on the new architecture, with only one minor incident that was quickly fixed. The result: a redesign invisible to users, but spectacular for the technical teams.

5 tips for avoiding technical debt

Fewer servers, less heat generated, less energy consumed. Beyond the figures, this is a genuine eco-design approach: thinking about consumption right from the service design stage.

This redesign highlights several best practices:

1. Pool whatever can be pooled

horizontal scaling is not a problem in itself; it just needs to be designed intelligently. In the old architecture, each customer was isolated in their own pod. In the new version, horizontal scaling is still there, but customers now share resources, which allows for much more efficient scaling.

2. Avoid over-designing at launch

But plan a clear evolution path. Eco-design is often the logical outcome of a good architecture, not a separate effort.

3. Choose the right technology for the right use case

Apache/PHP made sense to get started quickly, but Go turned out to be far more efficient on a large scale in this context.

4. Centralise configuration and monitoring

To avoid flying blind. It is impossible to optimise without understanding what is really happening.

5. Favour progressive migrations

Canary deployments, feature flags and incremental roll-outs reduce risk and speed up learning.

A human journey and a cultural shift

This project also has a strong human dimension. It was entrusted to Tristan Smagghe, who was an trainee at the time. Guided by Matthieu and the teams, he led this redesign from end to end. Now working for the company full-time, he is working on our new hosting platform based on Node.js and Go, which will be the foundation for Infomaniak’s future optimised WordPress offering.

“This project shows that a well-supported trainee can have a real impact. At Infomaniak, we do not hand out mock-ups to test, but infrastructures to evolve,” says Matthieu Mabillard.

This transformation is also part of a broader cultural shift. Historically focused on Laravel/PHP and Angular, we now have the size and skills to use the right language for the right job: Go for the cloud, Node.js for real time and PHP, which remains a strategic, reliable and mature language.

This approach allows us to align our technical ambitions with our values: efficiency, sustainability and sovereignty.

Conclusion

Cutting the footprint of an infrastructure by a factor of one hundred without sacrificing performance is not a miracle: it is the result of a redesigned architecture, a committed team and a long-term vision. It is also proof that eco-design is not a trade-off, but a source of innovation.

This redesign enables us to pursue our mission: to build an ethical, high-performance and environmentally-friendly European cloud.

Find out more