Breaking the release monolith: How OutSystems platform engineering restored trust in delivery

Releasing software at OutSystems used to feel more complex than building it. We had invested in a modern, cloud native architecture. OutSystems Developer Cloud was built around microservices and Kubernetes. Infrastructure was automated. Teams were writing code quickly.

But everything slowed down at the release stage.

At Chainguard Assemble 2026, we shared how we transformed our release process through platform engineering, built Pegasus CD platform, and achieved Elite DORA performance. This post captures that journey. You can watch the full session recording embedded below.

The irony of a modern architecture with a 1990s release process

OutSystems is an enterprise AI development platform trusted to run mission-critical applications. As we evolved, we built a new microservices-based product designed for agility and scale. Yet when it came to releases, we were still moving on a synchronized release train. To understand why, we need to go back in time, to what we call BC: Before Cloud.

In the old world, things looked very different for us at OutSystems. For nearly two decades, we shipped enterprise software the traditional way, and honestly, we lived a pretty comfortable life. Our platform was a monolith, and our deployment model fit our customers perfectly. Releases happened a few times a year at most. Customers would download the software, install it, and run it in their own environments. Stability and predictability mattered far more than speed. And for a long time, that model worked extremely well.

Then the cloud arrived, and the rules changed completely.

We built a new cloud-native platform, OutSystems Developer Cloud (ODC). Architecturally, everything was modern: microservices everywhere, cloud infrastructure, and the promise of continuous delivery. But when it came to releasing software, we were still operating in the old way.

Every team boarded the same synchronized release train. What was tested in staging had to be exactly what went to production. Our leadership team wanted safety and predictability. The result was a lack of trust in automated testing across services. We did not trust developers with the deploy button.

The consequences were predictable:

• Bake times were used as throttles rather than signals

• Infrastructure changes reset release timelines

• The software development lifecycle team became professional ticket operators

Lead time ranged from four days to four weeks. Developer experience surveys identified the release cycle as the number one pain point.

We had built an electric car and were insisting that horses drive it.

We had to do something about it, and the decision was clear: break the release train. Move from blockers to enablers. Enter platform engineering.

From release train to independent releases

The shift was deeper than decoupling services. We decoupled releases.

Pegasus became our cloud native continuous deployment platform, built by Platform Engineering and treated as a product. It was designed to be autonomous with guardrails.

Teams could release when they wanted. Security, compliance, and quality controls were enforced automatically via policy-as-code. There were no release calendars and no ticket ops queues. It became a motorway to production with embedded guardrails.

One of our guiding principles was simple:

Rules written in YAML are taken more seriously than rules written in Confluence.

This was a mindset shift. Development teams were customers of the platform. Feedback mattered more than mandates. Adoption mattered more than enforcement.

The first teams that adopted Pegasus became its strongest advocates. Standardization happened because it delivered value.

The results were immediate and measurable:

• Lead time dropped to under 24 hours (which was a 10x improvement)

• Teams moved from weekly releases to dozens per day

• We surpassed 1,000 deployments per month

• DORA performance reached Elite (top-of-the-line metrics in deployment frequency, lead time, change failure rate)

Platform Engineering stopped being a bottleneck and became a trusted partner.

We also learned an important lesson: faster without safety simply means breaking things sooner. Guardrails were foundational, not optional.

From automation to judgment

Once the releases stopped being painful, we asked a different question.

How do we make them boring?

Pegasus is evolving into an agentic platform. The goal is not to replace engineers. The goal is to reduce cognitive load and on-call fatigue.

We are introducing a set of focused agents:

• A Deployment Failure Agent that watches releases in real time and performs root cause analysis 

• A Promotion Advisor Agent that evaluates system health during bake periods using hard metrics rather than intuition

• An On Call Agent that detects incidents, attempts self-healing, and escalates with context to reduce MTTR

We are also adopting progressive delivery practices across regions and canaries, with promotion decisions driven by SLOs and observable evidence.

The platform is starting to assess risk before a human even presses the deploy button.

The shift is from automation to judgment, from pipelines that execute instructions to systems that evaluate conditions.

The mindset that made it possible

The technical implementation mattered. The cultural shift mattered more.

Three ideas changed everything:

1. You cannot automate your way out of a trust problem.

2. Platform Engineering works when it is treated as a product, not a gate.

3. The right way must be the easiest that brings the right value.

If developers must fight the platform to ship, they will work around it. If the secure, compliant path is also the fastest, they will embrace it.

Pegasus succeeded because it combined autonomy with guardrails. It gave teams ownership without sacrificing reliability.

Today, OutSystems deploys continuously, securely, and independently. Lead times are measured in hours. Deployment frequency reflects confidence rather than fear. Reliability metrics support speed rather than constrain it.

Breaking the release monolith was not about pipelines. It was about trust.

And once trust was encoded into the platform, everything accelerated.