Platform Engineering with Mercado Libre's Fury

With Julia Pedrosa, Juliano Martins and Marcelo Quadros

How do you transform a massive infrastructure into a platform product that teams actually want to use? In Kubicast #190, we open the black box of Fury, Mercado Libre's platform that was born almost 12 years ago and today centralizes more than 80% of the company's technology. In this conversation, we talk about deep DX (templates, SDKs, and Backstage), operating without "kubectl in production", pragmatic multicloud, governance, security, and the trade-offs that only appear when the scale is continental.

Why Fury exists

When Mercado Libre started migrating from VMs to a more cloud-native model, it was clear that it was impossible to scale by asking every team to build their own platform. Fury was born out of this pain point: to offer autonomy with guardrails, in an opinionated way, so that hundreds of squads can publish and operate services with the same baseline of security, observability, and reliability.

One of the data points that stood out the most in the episode: about 85% of Meli's stack runs on Fury. This number alone explains why Platform Engineering became a central discipline there.

DX as a product: templates, SDKs, and Backstage

No "platform framework" that forces the team to memorize YAML to get started. In Fury, the developer experience begins with templates: from Backstage, the team generates a service skeleton (React, Go, etc.), already with pipelines, tests, policies, and guardrails ready to use. From there, it's "git commit and move on".

More than just provisioning, the platform offers SDKs and CLIs that embed best practices (deployment, configuration, minimum observability, secrets with Vault, and so on). The goal is crystal clear: to reduce cognitive friction without hiding enough to hinder the teams' evolution.

Operating without "kubectl in production"

The platform fully takes on the role of operation orchestrator. Deployment and rollout workflows rely on pre-packaged strategies (blue/green, canary), and tools like Argo drastically reduce the "glue work" that everyone has had to do at some point. The result? Less manual touch, fewer tickets, fewer pings for silly things.

Multicloud (really) or "many clouds"?

The conversation de-romanticizes the term multicloud. The team is direct: multicloud only when there is clear value. Fury abstracts where it makes sense (resources that need to exist in both GCP and AWS, for instance), but avoids promising universal portability. The focus is reliability and speed for Meli's products, not "buzzword checkboxes".

Observability and security in practice

Scale without observability is a lottery. Fury provides default telemetry (logs, metrics, and tracing) and pre-built integrations so teams don't have to "learn PromQL at 3 in the morning". On the security axis, guardrails come in early (checks, coverage, secrets, policies), and the platform pulls responsibilities to the center where this saves global effort and reduces risk.

Clusters and criticality

Not every service is the same. The design takes into account criticality levels, isolation, and blast radiuses, choosing where it pays to separate clusters and when multitenancy is enough. This segmentation avoids paying a premium for "one-size-fits-all" standards and creates clear paths for teams with special demands.

Career tips from the guests

For anyone wanting to pursue Platform Engineering: start by understanding the teams' pain points; learn to say "no (not yet)" with good reasons; and don't underestimate product skills (discovery, metrics, feedback). The brilliance of a platform lies in how much it disappears from the devs' daily lives — and not in the number of new components it displays.

Enjoyed it? Subscribe to Kubicast, share it with your platform team, and tag us with your questions. And if your team is on this journey, let us know.

Listen also on Spotify.