Managing Infrastructure At Scale: How Denovo GmbH Runs 250+ Cloud Instances with Docker, Terraform, and Inner‑Sourced CI/CD

Why this session matters for engineering teams

In “Managing Infrastructure At Scale,” Speaker Lukas Korl (Director of Operations, Denovo GmbH) walked us through the operational backbone of a software company that grew from 4–5 to 25 people and now delivers and operates more than 35 projects a year. Crucially, Denovo doesn’t just ship features; they run the products in production for their customers—end to end.

This responsibility comes with hard numbers:

• 250+ cloud instances (virtual and bare metal) across multiple providers
• 5,000+ implemented user stories that make manual testing impractical
• 25 employees vs. 35 projects per year—no single person can know everything

That reality demands standardized, reproducible environments. As Lukas put it:

Denovo also refuses to split into rigid silos. The mantra is shared ownership:

And on maintenance and security, Korl reminds us:

In this DevJobs.at recap, we outline what Denovo actually built: containerization everywhere, Terraform for Infrastructure as Code, GitLab CI/CD with modular includes, a clean separation between build and deployment, and regular human-in-the-loop cloud audits. The goal is to extract the engineering patterns you can apply tomorrow.

The problem space: Many projects, mixed clouds, shared responsibility

Denovo builds customized software—mobile, web, even desktop—with a strong presence in the circular economy (recycling and waste), but not exclusively. Teams are split between Graz and Athens, collaborate across projects, and follow an Agile process modeled after Scrum. They also work with agile fixed-price contracts in some cases. Most importantly, they support customers from initial idea to running product—which means they own operations.

As the organization scaled, several operational imperatives emerged:

• No single point of knowledge: Everything must be modularized and reproducible.
• DRY configuration: Spinning up 35+ projects a year can’t rely on copy/paste.
• Reliable deployments: Any developer should be able to deploy and verify.
• Cost hygiene: “We learned the hard way” that idle instances add up.

From these needs, the team distilled three principles:

1) Make every setup reproducible

2) Support and collaboration over silos

3) Treat security as continuous maintenance

Below is how those principles translate into engineering practice.

Principle 1: Reproducibility—Containerize, describe, and separate

Containerize by default

Every project ships as a container (e.g., Docker). The motivation is straightforward: bundle all runtime dependencies into a portable artifact that is identical across dev, test, and production. This kills off the classic “works on my machine” drift.

• Same image across environments
• Versioned dependencies per service
• Deterministic builds and deployments

Lukas’ throughline is clear: standardization reduces surprises, increases speed, and shrinks the error surface.

Infrastructure as Code with Terraform

Beyond the application containers, Denovo codifies infrastructure declaratively. Terraform reads the intended target state and creates, changes, or deletes resources to reconcile reality with the description.

• Versioned, reviewable infrastructure changes
• Terraform plan/apply as a guardrail in the pipeline
• Portability via modules: swap Heroku for AWS with minimal config changes

Korl described a concrete pattern: a module defines an API backend—one variant targets Heroku, another AWS. Adding a database is just another module. This modularization brings DRY to the infrastructure layer and keeps project setups fast and consistent.

Separate build from deployment

A core design choice is to decouple the lifecycles of code and infrastructure. Denovo uses two repositories:

• Repo A: Infrastructure (Terraform)
• Repo B: Application code

Both flow through GitLab CI/CD. For infra: Terraform provisions the cloud resources (AWS or Heroku). For the app: tests run, a container is built, and pushed to a registry. A subsequent job deploys the image to the target environment (e.g., an EC2 instance).

This separation pays off in several ways:

• Reproducibility: Infrastructure is versioned and rollbacks are straightforward.
• Diagnosability: Build failures and infra drift are isolated.
• Flexibility: You can deploy an older application version into a fresh environment.

Cost hygiene and cleanup as standard practice

Korl was explicit: “We learned the hard way”—you can end up paying for instances you don’t need. IaC plus pipeline discipline makes cleanup part of the Definition of Done: ephemeral environments are automatically torn down, staging comes and goes, and aged resources can be pruned reliably. Reproducibility includes de-provisioning.

Principle 2: Support and collaboration—Dissolve silos, inner‑source your infra

Lukas avoids the DevOps/DevSecOps buzzword debate but is clear on the practice:

Bring operations in early, share ownership

Operations isn’t a release-end gate; they collaborate early so services are prepared for production. Conversely, developers are expected to initiate deployments and verify outcomes. This shared model lowers idle time and cuts handover risk because context stays with the people doing the work.

Inner-sourced infrastructure: Open-source process inside the company

Denovo treats infrastructure as an internal open-source project. Changes go through merge requests, get reviewed, and are validated by running Terraform against the PR to see the effect before applying. The benefits are tangible:

• Transparency: Every change is visible and attributable.
• Guardrails: Terraform plan previews what will happen in the cloud.
• Learning: Developers expand their infra skills by contributing and reviewing.

Modular CI/CD via includes

A concrete artifact of this inner-sourced approach is a modular pipeline configuration. Lukas described a pipeline file that assembles its behavior via includes. Teams compose what they need per project:

• Toggle environments: development, test, staging
• Choose target provider: Heroku vs. AWS by swapping includes

The result is a re-usable, composable CI/CD toolbox. Developers don’t need to know the internals to use it, but they can request features or open MRs to extend it. Operations and developers co-evolve the platform together.

Principle 3: Security is continuous—Tests, audits, and expert judgment

Security isn’t a launch milestone; it’s an operational loop. Korl’s framing is pragmatic and memorable:

Run tests in the cloud for confidence

Tests belong in CI, not only on local laptops. Their purpose is confidence, not blame:

Automated testing is the baseline for frequent, low-risk releases. It validates container builds as well as infra changes.

Regular cloud audits with a report

Some checks can’t be automated. Denovo performs regular cloud audits and provides a report to customers—a service-book analogy that clarifies whether systems are “up to date” or need action. This visibility supports prioritization and budgeting.

Human expertise for context-sensitive risk

Not every CVE flagged as critical is material to your system; conversely, a minor issue can be high-impact in your context. Denovo brings expert knowledge into the loop and mixes perspectives (developers plus other stakeholders) to assess real-world risk.

The process engine: Deming cycle (Plan–Do–Check–Act)

Denovo’s approach didn’t appear fully formed. Lukas describes an iterative progression through PDCA:

1) Start with containerization: Plan–Do–Check–Act. Was it enough? No.

2) Add Terraform: codify infrastructure. Enough? Not yet.

3) Add monitoring and auditing: raise operational maturity.

This is agility in action: not the toolset (e.g., Jira) but the behavior—experiment, measure, adapt.

Actionable takeaways for engineering leaders and teams

Drawing from “Managing Infrastructure At Scale” (Speaker: Lukas Korl, Denovo GmbH), here’s a distilled checklist:

• Default to containers: Standardize runtime environments to eliminate drift.
• Adopt IaC end-to-end: Version, review, and plan/apply infra changes.
• Separate build from deploy: Decouple app and infra lifecycles.
• Make teardown reproducible: Treat cleanup as a first-class operation.
• Break silos: Developers deploy; ops engages early. Share responsibility.
• Inner-source your platform: Treat infra as a product with MR-driven evolution.
• Build a module toolbox: Re-usable pipeline and infra modules by design.
• Test for confidence: Run tests in CI; keep the feedback loop tight.
• Schedule audits: Complement automation with periodic human reviews and reports.
• Use expert judgment: Evaluate vulnerabilities in context, not by headline.
• Practice PDCA: Improve iteratively instead of chasing a big-bang redesign.

The architecture, described

The operating model Lukas outlined is composed of a few well-defined parts:

• Application code is packaged into containers and pushed to a registry.
• Infrastructure is described in Terraform and applied via a separate pipeline.
• Deployments pull the tested image from the registry and roll it out to the target—e.g., EC2 on AWS or a Heroku app.
• Pipelines are modular. Projects enable the environments they need (development/test/staging) and select the target provider via includes.
• Teams collaborate on both layers—code and infra—through merge requests with Terraform plans as a preview.
• Security is embedded (tests) and augmented (audits) to make risks visible and actionable.

This structure emphasizes portability and consistency, enabling Denovo to serve diverse customer environments while maintaining operational discipline.

Memorable lines worth bookmarking

A handful of statements from the talk serve as guiding principles:

• “A setup must be reproducible.” — Without reproducibility, scaling is luck.
• “Everybody gets their hands on everything.” — Shared ownership beats ticket ping-pong.
• “We learned the hard way.” — Cost hygiene is discipline, not an afterthought.
• “The tests shouldn’t be there for blaming somebody … they should be there to have confidence.” — Tests buy speed.
• “Software needs maintenance, exactly like a car.” — Operations starts after launch.

Conclusion: Scaling is about process discipline, not tool fetish

“Managing Infrastructure At Scale” shows that sustainable cloud operations aren’t about exotic tech; they’re about consistent principles executed well: containerization, IaC, modular pipelines, lifecycle separation, shared ownership, and continuous care. Denovo GmbH can run 250+ instances and onboard 35+ projects a year because these principles are encoded in their repos, pipelines, and team habits.

For teams facing similar growth, the path is clear: start with containers, codify the cloud with Terraform, separate build from deploy, modularize pipelines, break down silos, ritualize security, and iterate via the Deming cycle. That’s how you get systems that deploy reliably, audit cleanly, and keep costs under control—today and as you scale.

• 

  

  Mattias Rauter, Managing Partner von Denovo

  Managing Partner von Denovo Mattias Rauter gibt im Interview Einblicke in die Devteams, wie das Recruiting und Onboarding abläuft und mit welchen Technologien gearbeitet wird.

  Watch now

• 

  

  Maximilian Haider, Full Stack Developer bei Denovo

  Maximilian Haider von Denovo erzählt im Interview darüber, wie er zum Programmieren gekommen ist, was er aktuell als Full Stack Developer arbeitet und gibt Tipps für Anfänger.

  Watch now
• 

  

  Jacqueline Rinnhofer, Full Stack Developerin bei Denovo

  Jacqueline Rinnhofer von Denovo spricht im Interview über ihre späten Anfänge in der IT bis hin zur aktuellen Arbeit im Full Stack Development und gibt Tipps für Neueinsteiger.

  Watch now
• 

  

  Tobias Stangl, Mobile Developer bei Denovo

  Tobias Stangl von Denovo redet im Interview über seinen frühen Einstieg in die Software Entwicklung bis hin zum aktuellen Job als Mobile Developer und gibt Tipps für Anfänger

  Watch now
• 

  

  Michael Haar, Full Stack Developer bei Denovo

  Michael Haar von Denovo teilt im Interview seine Erfahrungen als Quereinsteiger ins Full Stack Development und was seiner Meinung nach wichtig für Anfänger ist.

  Watch now