devopsy.kinsta.cloud

Tag: infrastructure

GitHub Actions Gets Serious About Self-Hosted Runner Versions

GitHub is resuming enforcement of minimum version requirements for GitHub Actions self-hosted runners — and this time, the deadlines are firm.

After a rocky start that included multiple delays and a temporary pause earlier this year, GitHub has published a clear enforcement timeline for both GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency. If your team runs self-hosted runners and hasn’t upgraded them yet, now is the time to act.

Why This Is Happening

In early 2024, the GitHub Actions team began rearchitecting the backend services that power job execution and runner communication. That foundational rebuild now handles over 120 million jobs per day — more than three times the pre-migration volume — and lets enterprises start seven times more jobs per minute than before.

Version enforcement is the final step in completing that migration. Older runner versions that are incompatible with the updated infrastructure can no longer be supported as all runners move to the new platform.

Two Requirements to Stay Compatible

GitHub has simplified the compliance picture down to two requirements.

First, to configure or re-register a runner, it must be on version 2.329.0 or later. This is the minimum version required for the new architecture to recognize the runner and allow it to connect.

Second — and this is where some teams may get caught off guard — registration alone isn’t enough. To continue executing workflow jobs, the runner must stay up to date by installing each new runner release within 30 days of its publication.

The practical implication: a runner pinned at 2.329.0 that never updates again will eventually stop picking up jobs.

Runners with auto-update enabled automatically meet the 30-day requirement, as long as they can reach the update service. Runners with auto-update disabled must be upgraded manually on a regular cadence. And GitHub has added another layer of urgency: when a critical security update is published, GitHub Actions will pause job queuing to the runner until the update has been applied.

The Shift in How Runners Need to Be Managed

Mitch Ashley, VP & Practice Lead, Software Lifecycle Engineering & AI-Native Software Engineering at The Futurum Group, says this enforcement marks a meaningful change in how teams need to think about runner infrastructure.

“Self-hosted CI infrastructure is moving from a set-and-forget asset to a continuously validated state,” said Ashley. “A runner now has to prove version currency to keep executing jobs, and pinning it once no longer keeps it in service. A runner that registers cleanly today becomes a silent pipeline outage in thirty days if it stops updating. Freshness is now an availability requirement, moving the control point to image pipelines, provisioning automation, and ephemeral runner strategy.”

That last point matters. Teams that have been treating runner maintenance as a one-time provisioning task will need to rethink their approach — and the earlier they do it, the less disruption they’ll face.

The Enforcement Timeline

GitHub is using a brownout strategy to give teams time to identify and fix outdated runners before hard enforcement kicks in.

Brownouts will start by intermittently blocking registration of unsupported runner versions, then expand to also intermittently blocking job execution on unsupported runners. All brownout windows run from 11:00 AM to 3:00 PM ET on the listed dates.

For GitHub Enterprise Cloud with Data Residency, the brownout schedule starts June 29 and runs through late July, with full enforcement beginning July 31, 2026.

For GitHub Enterprise Cloud, brownouts begin August 24 and ramp up through mid-September, with full enforcement beginning September 25, 2026.

GitHub Enterprise Server is not impacted at this time.

What Happens If You Don’t Upgrade

The consequences are straightforward. After each enforcement date, self-hosted runners with versions below the minimum required for registration won’t be able to register or re-register. Existing runners below the minimum version required to execute workflow jobs will stop running workflow jobs, even if they were previously registered. Workflows targeting unsupported runners may remain queued or fail.

That’s a potential full stop on CI/CD pipelines — not a warning message.

How to Find and Fix Affected Runners

GitHub has added tooling to help teams audit their runner inventory. Enterprise owners can audit which runner versions are currently registering by querying the audit log for runner registration events, each of which includes the runner version. GitHub also recently added runner version data to the REST API.

The fix itself is straightforward: upgrade all self-hosted runners to the latest supported version, update installation scripts, VM images, container images, and deployment automation, and recreate runners built from older cached images or templates.

The Bottom Line

This isn’t a new requirement. GitHub has been communicating the need to keep self-hosted runners up to date for some time. What’s changed is that enforcement is no longer optional or easily deferred. Teams that treat runner maintenance as a low-priority task are about to feel that friction directly in their pipelines.

The brownout schedule gives DevOps teams a reasonable runway to get compliant without scrambling at the last minute. But that runway is finite. Audit your runners now, enable auto-update where you can, and update your runner provisioning scripts before the first brownout dates hit.

The new GitHub Actions architecture is built for scale. The catch is that outdated runners aren’t invited to run on it.

June 16, 2026
The Validation Gap Is Costing You More Than You Think

Our latest State of Software Delivery report analyzed more than 28 million CI workflows and found a pattern that should give engineering leaders pause. Average throughput grew 59% year over year. Main branch activity for the median team declined 7%. Teams are generating more code than ever before. Less of it is reaching production.

The cost of poor validation used to show up mostly in developer hours: debugging, blocked deployments, context switching. That cost hasn’t gone away. But there is a second bill now. Every failed build means agent retries. Every slow pipeline is compute burning while an agent waits. Main branch success rates have fallen to a five-year low of 70.8% against a 90% benchmark, and the AI spend attached to every failed cycle is climbing alongside it.

The teams doing well are catching failures earlier and keeping their pipelines healthier. They are running the same tools as everyone else. What they have structured differently is where and when validation happens.

For most of our careers, the inner loop was something that was managed and optimized by the developer. Once AI generated code entered the picture, the inner loop as we knew it could not handle the volume. Today, the inner loop is agentic. It’s where the agent is actively working: writing, iterating, checking before anything is committed or pushed. The outer loop is CI: shared infrastructure, integration, the final gate before shipping. Most teams have invested heavily in the outer loop. Until recently, the inner loop didn’t need much attention. That has changed.

CI was designed around a human pace of development: one engineer, one branch, one push at a time. Agents generate changes in parallel, across multiple tasks, at a volume that makes the push-wait-fix cycle a serious drag on throughput. By the time CI returns feedback, the agent has moved on to the next task. Context is gone. Fixing the failure means starting a new cycle: reloading context, re-examining the change, potentially redoing work that was already completed.

Human review was always the backstop before code reached shared infrastructure. For most teams today, the volume of AI-generated change has simply outpaced what any reviewer can meaningfully assess before it hits CI. The code arrives faster than the review process was designed to handle. Most teams end up making a choice without fully realizing it: either throttle the agents to match available review capacity, or let the volume through and absorb the failures downstream.

Validation needs to happen earlier, while the agent is still working on the change. CI still matters. System-level validation, integration, packaging and deployment belong in the outer loop and always will. But by the time code reaches CI, it should have already passed basic scrutiny. The inner loop is where that confidence gets built, before anything touches shared infrastructure. Getting validation right at this stage is also how teams close the gap between a 70.8% success rate and the 90% benchmark the data points to.

The requirements for inner loop validation are specific to how agents work. Feedback has to arrive within the window the agent is still operating in. Tests need to be scoped to the relevant change, not the full suite. Failures should surface one at a time: an agent given a long list of problems fills its context window and stops being productive. These constraints are different from what CI was designed to satisfy, which is why existing tooling often doesn’t fit.

When the two loops share context, the picture changes. When the inner loop draws on what CI has historically flagged in a codebase, it runs smarter checks before anything is pushed. When CI sees changes that have already been validated locally, it can focus on what actually needs system-level verification. The two stages inform each other and the system gets better at catching the right things over time.

By the time CI returns a failure, is the agent that introduced it still working on that change?

This is where CircleCI has been focusing, building validation that spans both stages and learns from how a codebase actually builds. The infrastructure question is one teams will need to answer if they want to improve their throughput and success rates.

Every model release increases agent velocity and the volume of code flowing into delivery pipelines. Teams that have solved the validation gap absorb that increase and get faster. Teams that haven’t will find the gap between them and the top performers widening with every upgrade.

May 30, 2026
AI Is Changing How We Write Infrastructure, But It’s Not Solving How We Control It

Over the past year, AI has fundamentally changed how software is written. Infrastructure code is no exception. Tasks that once required deep familiarity with tools, syntax, and workflows can now be handled through natural language. Engineers are no longer starting from a blank file. In many cases, reviewing and modifying code generated for them has become the norm.

At a high level, this looks like progress, and in many ways, it is. Teams can move faster, the barrier to entry is lower, and experimentation is easier. But there is a growing gap that many organizations are only beginning to recognize: AI is accelerating how infrastructure is created, but it is not solving how infrastructure is understood, controlled, or governed.

The Shift from Writing to Generating

Traditionally, infrastructure as code assumed that the person writing the configuration understood what it would do. That assumption no longer holds.

Today, it is increasingly common for infrastructure definitions to be generated rather than authored. The learning curve for tools and languages has effectively collapsed. This opens the door for more engineers and even non-specialists to interact directly with infrastructure. That shift is powerful; however, it also introduces a new kind of risk.

It is possible to generate a correct-looking configuration without fully understanding its impact. In application development, this is often manageable. A faulty deployment can usually be rolled back with limited consequences. Infrastructure is different. A misconfigured resource, an unintended dependency, or an incorrect policy can have immediate and widespread impact. In some cases, it can affect the availability, security, or integrity of entire systems. Stated differently: you can restart the database, but probably not the data itself? Different problems.

The problem is not that AI makes mistakes. The problem is that it enables changes to be made faster than organizations can safely reason about them.

Let’s explore this.

The Growing Tension: Speed vs. Control

Platform teams are now operating under two opposing pressures. On one side, there is a clear expectation to move faster. AI has raised the baseline for productivity across engineering, and infrastructure teams are expected to keep pace.

On the other side, the requirements for infrastructure have not changed. Systems still need to be secure, compliant, and stable. In many industries, those requirements are becoming more stringent, not less.

This creates a tension that cannot be resolved by simply adding more automation. Moving faster without control increases risk. Enforcing control without adapting workflows slows teams down. Most organizations today are caught somewhere in between.

Why Existing Models Don’t Hold

Before AI became part of everyday workflows, infrastructure teams typically operated in one of two modes.

The first was informal and manual. Engineers would make changes directly in cloud consoles or through ad hoc scripts. This allowed for speed, but at the cost of visibility, consistency, and governance.

The second was highly structured. Infrastructure changes would go through a defined pipeline: code written, reviewed, validated, and deployed through policy checks. This improved control, but introduced friction.

Both models are still present today. Neither fits the current reality. AI makes it easier to bypass structured workflows, because generating a change is no longer the hard part. At the same time, the cost of mistakes remains high. What used to be a tradeoff between speed and control is now a mismatch between how quickly changes can be made and how slowly they can be validated.

The Real Gap: Understanding and Decision-Making

One of the less discussed effects of AI-assisted workflows is the loss of context. When engineers write infrastructure manually, they build an implicit understanding of dependencies, constraints, and failure modes. That understanding is part of the safety model.

When infrastructure is generated, that context is no longer guaranteed. You can ask for a system to be created in precise terms. The system may be created correctly. But if you cannot fully interpret the result, you are operating with partial understanding. In infrastructure, partial understanding is often not enough.

This is where many current approaches fall short. They focus on improving generation—better prompts, better models, faster execution. But generation is not the limiting factor anymore. The limiting factor is decision-making.

Guardrails, Not Just Automation

If AI is going to play a meaningful role in infrastructure, it needs to operate within clearly defined boundaries. These boundaries cannot rely on probabilistic systems alone. They need to be deterministic, enforceable, and transparent. In practice, this means shifting focus from how infrastructure is generated to how it is governed.

Policies, access controls, and approval workflows are not new concepts. What is changing is their role. They are no longer just safeguards around human actions. They are becoming the primary mechanism for controlling both human and AI-driven changes.

This is not fundamentally different from how organizations have managed risk in the past. Humans are also non-deterministic. We have always relied on guardrails to ensure consistency and safety. The same principle applies here.

Building Trust Incrementally

One of the more pragmatic approaches emerging in organizations today is incremental adoption. Rather than moving directly to full automation, teams start with visibility. They use AI to understand infrastructure state, identify issues, and suggest changes. Over time, as confidence grows, they allow more direct interaction with systems. This progression is important.

Trust in infrastructure systems is not built through capability alone. It is built through predictability. Teams need to understand not just what a system can do, but how it behaves under constraints. AI can accelerate workflows. It cannot replace the need for that trust.

A Shift in Operating Model

The broader implication is that infrastructure is entering a new operating model. More people will interact with it. Changes will happen faster. The distinction between writing and operating infrastructure will continue to blur.

In this environment, the differentiator will not be how quickly organizations can generate infrastructure. It will be how effectively they can control it.

AI is already changing how infrastructure is written. That part is inevitable. The harder and more important question is how we ensure it remains safe, predictable, and aligned with the needs of the business.

That is not a problem AI will solve on its own.

May 29, 2026
Why the Next Wave of Infrastructure Automation Requires a Different Kind of Intelligence

Every decade or so, something fundamental shifts in how we think about infrastructure. Not an upgrade, a rethinking.

Virtualization changed what infrastructure was. The cloud changed where it lived. Infrastructure as Code changed how it was defined. Each of those shifts felt incremental from the inside and transformative in hindsight. We’re at one of those moments again.

Automation has been the operating model of network infrastructure for the last decade. We scripted, we orchestrated, we built platforms to make repeatable things faster and more consistent. That work matters. It laid the foundation for everything that comes next.

But here’s what a decade of building automation for some of the world’s most complex networks makes clear: the hardest problems in infrastructure aren’t repeatable. They never were.

The Automation Gap Nobody Talks About

Walk into any network operations team that has invested heavily in automation and you’ll see the same dynamic. The well-understood tasks, provisioning, compliance checks, standard change management, are automated and running well. But the people who built those automations are still spending 60-70% of their time on everything else.

Incident response. Configuration drift that breaks in unexpected ways. Complex cross-domain changes that touch five teams. Day 2 operations that don’t fit the happy path.

These are the problems that consume the most labor, carry the most risk, and cause the most organizational friction. And they’re exactly the problems that traditional automation doesn’t solve well, because they require something automation can’t provide on its own: reasoning.

Traditional scripts and workflows are deterministic by design. If X, do Y. That rigidity is a feature when you know what X will look like. But real infrastructure doesn’t always fit the conditions we anticipate. Outages don’t follow a playbook. Brownfield environments don’t behave consistently. The operational context that determines the right course of action is distributed across systems, teams, and history that no single workflow can fully encode.

This is the gap. Not a gap in automation maturity, but a gap in what automation alone can do.

Reasoning Changes the Equation

AI reasoning agents introduce something qualitatively different. Not more automation, a different kind of intelligence.

Where automation executes, agentic AI reasons. It can interpret context, evaluate risk, weigh alternatives, and choose a path that aligns with business intent rather than just following a predefined sequence. That’s not a subtle difference. It’s the difference between a system that does what you told it to do and a system that understands what you’re trying to accomplish.

But reasoning without governance is just risk with better vocabulary. We’ve been here before. Every automation wave has required organizations to build trust before granting autonomy. You don’t hand over the keys to a system you can’t verify. You start read-only. You build confidence through evidence. You expand access incrementally, with governance at every layer.

Agentic AI should be no different, and the organizations that try to shortcut this will learn the same lessons the hard way.

The infrastructure industry is now mature enough to do this right. Automation platforms can serve as the governed execution layer. Standards like MCP give AI agents a structured, auditable interface to infrastructure. Domain-specific knowledge, built up over years of real-world deployments, can inform how agents reason about network-specific context. The foundation is there. What’s new is the intelligence layer on top of it.

What Agentic Orchestration Actually Looks Like

The term “agentic” is getting applied to everything right now, and like any category in early formation, that creates as much confusion as clarity.

Agentic orchestration is the combination of AI reasoning and deterministic automation in a governed architecture that can handle both well-understood tasks and complex, open-ended operations. The key insight is that these two types of work require different approaches, and conflating them is where most AI infrastructure initiatives go wrong.

For deterministic tasks, you don’t need an AI agent making decisions. You need a reliable, auditable workflow that executes consistently and can be trusted. Agentic AI applied to a task like standard VLAN provisioning is overhead, not value.

But for the complex, contextual problems, the ones that consume the most human effort, that’s where reasoning changes everything. An agent that can read the state of the network, pull relevant operational history, understand the change being requested, assess risk, and either recommend a path or execute within guardrails isn’t replacing automation. It’s handling the problems automation was never designed for.

The goal is a framework where those two worlds coexist and complement each other. Workflows that need to run consistently, run deterministically. Tasks that require judgment, reasoning, and context-awareness get the intelligence layer they need. The result isn’t just faster operations. It’s infrastructure that can actually keep pace with the rate of change the business is demanding.

The Question Every Infrastructure Leader Needs to Answer

Here’s what every network and infrastructure leader should ask right now: where are the problems in your environment that your automation can’t reach?

Not the tasks that are already running well. The ones where a human has to get involved every time, because the context is too variable, the risk is too hard to encode, or the coordination across teams is too complex to script. Those are the problems agentic orchestration is designed to solve.

The organizations that figure this out early will have a structural advantage. Not because they were aggressive about adopting AI, but because they were thoughtful about where reasoning belongs and where governance must hold.

That’s the inflection point we’re at. And having worked on the hard problems of network automation for over a decade, I don’t think it’s incremental. I think it changes the ceiling on what’s possible.

March 2, 2026
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

Our goal in these challenging economic times is to make it just that much easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role, it tends to create opportunities for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration.

Indeed.com

OpenAI
New York City
Client Platform Engineer
$255,000 to $325,000

Dice.com

Dell Technologies
Austin, TX
Principal Software Engineer
$170,000 to $220,000

LinkedIn

Jasper
Remote
DevOps Engineer
$170,000 to $200,000

The Job Network

CTG
Columbia, MD
DevOps Engineer
$120,000 to $226,000

SimplyHired.com

Viasat
Carlsbad, CA
DevOps Engineer
$111,500 to $208,000

October 20, 2025
Building Faster, Safer Pipelines Through Practical Automation

At swampUP 2025, Alan Shimel spoke with Hariharan Ragothaman, a technologist and repeat attendee who has taken his passion for DevOps automation to the next level. While not a JFrog employee, Ragothaman has been a frequent participant in the JFrog community, first attending swampUP 2023 and returning this year to present a framework he developed to optimize infrastructure deployments.

Ragothaman’s project focuses on improving accessibility, security and speed in the deployment process—three areas that often compete for attention in enterprise DevOps environments. Using JFrog’s platform as a foundation, he built a framework designed to dramatically reduce the time it takes to bring new services into production without compromising on compliance or control. The result, he explained, is a more efficient, secure, and transparent pipeline that helps teams move from code to deployment faster and with greater confidence.

What makes Ragothaman’s approach particularly compelling is its emphasis on practical, repeatable automation. By embedding quality checks and security policies directly into the framework, teams can accelerate delivery while maintaining strong governance. His work aligns closely with JFrog’s broader vision for end-to-end trust and automation across the software supply chain—a theme echoed throughout this year’s conference.

Beyond his technical presentation, Ragothaman reflected on the collaborative spirit of swampUP, describing it as a unique space where practitioners can share real-world solutions and learn from one another. For him, the event isn’t just about product announcements—it’s about community, experimentation, and the drive to keep improving how software gets delivered.

His takeaway: innovation in DevOps doesn’t just come from platforms; it also comes from practitioners who use those platforms to reimagine what’s possible.

October 6, 2025
Scaling DevOps: Tackling Infrastructure Automation

Spacelift CEO Pawel Hytry dives into the infrastructure automation challenges DevOps teams are facing following the picking up of an additional $51 million in financing.

Infrastructure-as‑code was supposed to make provisioning easy—copy some Terraform, hit “apply,” and move on. In practice, teams soon discover that version‑controlled snippets are only half the story. Once dozens of developers start spinning up resources, you still need collaboration, security reviews, cost oversight and a reliable audit trail. Hytry explains why his biggest customers hit a wall: what used to take a day to deploy now drags on for a week because manual approvals, rollbacks and duplicated code clog the pipeline. The tipping point usually arrives when an infrastructure lead realizes the team is hiring people just to babysit scripts.

Hytry argues that the answer isn’t to lock everything down; it’s to add “guard‑railed self‑service.” A central platform team defines reusable modules and policies, then lets application squads launch infrastructure inside those boundaries. That keeps velocity high while preventing surprise cloud bills or rogue ports. He frames the approach as a natural fit for the rise of platform engineering, where one group maintains the paved road so everyone else can drive fast without veering off a cliff.

AI enters as a helper, not a takeover artist. Hytry envisions agents that trace resource drift or predict cost spikes, with a human still approving changes—at least for now. The broader lesson, he says, is to replace brittle, ticket‑based processes with automated pipelines that scale as headcount and complexity grow. Teams that ignore the sprawl will keep paying in slow deploys, mounting cloud spend and tired engineers.

July 15, 2025
Report Shows Overinflated Opinion of Infrastructure Automation Excellence
Many infrastructure technology teams believe they have mastered infrastructure automation, but the data tells a different story. We commissioned a survey to explore the state of infrastructure automation, and this research uncovered a stark gap between perception and reality. While 45% of organizations believe they have achieved a high level of infrastructure automation, only 14% exhibit the behavior and technology patterns of infrastructure automation excellence.

This is one of the illuminating findings of our survey of 413 infrastructure tool purchase decision-makers and influencers, conducted by Panterra. Full results are detailed in “The State of Infrastructure Automation” report, available for download.

What I find most compelling about the survey revelations — and what the report addresses in detail — is the critical challenge facing technology decision-makers: balancing the need for speed with the necessity of control. In the pursuit of rapid deployment, many teams have sacrificed security, governance and operational stability. The most successful organizations—those we classify as “Leaders”—have found a way to break free from this “Speed-Control Paradox,” achieving both velocity and control. Their success offers a blueprint for others to follow.

What Infrastructure Automation Leaders Do That Others Don’t

The report uncovered clear patterns among the most automation-mature organizations — those who have mastered the Speed-Control Paradox:
1. Developer Self-Service with Guardrails: Leaders empower developers to deploy infrastructure independently while embedding safeguards. Leaders have built high-velocity environments where developers can focus on building rather than troubleshooting: 61% of Leaders have streamlined workflows and reduced friction, compared to 8% of companies who are classified as just getting started with Infrastructure Automation.
1. Platform Engineering for Consistency: Leaders are five times more likely to have implemented a platform engineering team than their less-advanced peers: 29% of Leaders have implemented platform teams compared to just 7% of total respondents. Leaders don’t rely on ad-hoc automation; they establish dedicated platform teams to create standardized workflows and reusable templates, ensuring consistency across environments.
1. Security as a Built-In Foundation: More than half (58%) of Leaders have cut security incidents, and 56% report fewer compliance violations versus 36% of total respondents. Leaders integrate automated security checks, policy enforcement, and drift detection into every stage of their automation pipeline. Security is not an afterthought; it is a continuous, proactive process.
1. Cost Optimization as a Priority: Leaders view cost efficiency as essential to business success: 51% of Leaders cite cost savings & ROI as a top business metric, compared to 41% of respondents overall. By leveraging automated cost estimation and policy enforcement to curb overprovisioning and prevent waste, 47% of Leaders have successfully reduced infrastructure costs, compared to 32% of all respondents.
1. Orchestration Over Automation: The most advanced teams go beyond tool adoption. They orchestrate the entire infrastructure lifecycle—provisioning, configuration, security, and governance — into a unified, automated pipeline. This end-to-end orchestration is what drives true automation maturity and results like these: Leading companies are twice as likely to get infrastructure deployments right on the first try, four times more likely to provision new resources in four hours or less, and five times more likely to deploy changes in production daily or multiple times a day. In contrast, over 50% of organizations take a week or more to deploy infrastructure changes in production, and 43% need to rerun their infrastructure deployments more than four times to get it right.
Is Your Organization an Automation Leader?

Where are you on the adoption continuum? Your organization may be an Experimenter, testing out some tools. Or perhaps you are an Adopter, implementing some automation but struggling with standardization and governance. More progressive companies will be Optimizers, having made significant progress with automated deployments and governance, and focusing now on addressing gaps in security, compliance and scalability. And bravo to you if your organization is a Leader, with automation, security, compliance and scalability built into every process.

Ask yourself these questions to help clarify your organization’s current standing:
- Are we automating for speed alone, or are we orchestrating security, compliance, and cost control alongside it?
- How much of our infrastructure is truly managed by Infrastructure as Code (IaC), and how are we managing drift?
- Are developers empowered with self-service tools, or are they still waiting on DevOps and platform teams to unlock progress?
- Is security embedded from the outset, or do we discover vulnerabilities after deployment?
- Do we measure success by deployment frequency alone, or do we also measure by efficiency, cost savings and risk reduction?
How to Achieve Infrastructure Automation Excellence

Here’s the best news that our study reveals: Any organization can achieve infrastructure automation excellence by adopting a deliberate, strategic approach. Endeavor to do these five things:
1. Benchmark Your Maturity: Begin with an honest assessment. Use available self-assessment tools to understand where you stand on the automation maturity curve. Recognizing gaps is the first step toward improvement.
1. Shift Left on Security & Compliance: Integrate security and compliance checks early in your infrastructure planning and lifecycle. Automated validation processes prevent issues from reaching production, reducing risk and minimizing downtime.
1. Balance Speed with Governance: Foster a culture where speed and security are not competing priorities but complementary goals. Empower developers through self-service while establishing clear policies and automated guardrails.
1. Standardize Through Platform Engineering: Centralize automation efforts under a platform team that aligns tools, workflows and best practices across the organization. This team should serve as an enabler, not a gatekeeper.
1. Measure What Matters: Move beyond deployment velocity as the sole metric. Track cost efficiency, security incidents, and infrastructure stability. A balanced scorecard approach fosters sustainable automation progress.
True infrastructure automation leadership is not about moving fast — it is about moving fast with certainty. To achieve this, Leaders invest in processes and team structures that ensure automation is both agile and secure.

From Experimentation to Excellence

Wherever you are on the automation continuum, you will inevitably encounter the Speed-Control Paradox along the way. The good news is that the blueprint for success is now clearer than ever. Leaders have shown that it is possible to deliver at the speed of innovation without sacrificing control.
June 25, 2025
Survey Surfaces IT Infrastructure Automation Shortfalls

A survey of 413 infrastructure decision-makers and influencers published today finds nearly half (45%) believe their organization has achieved a high level of infrastructure automation.

Conducted by the market research firm Panterra on behalf of Spacelift, a provider of an IT automation platform, the survey also finds that half of respondents (50%) are part of IT teams that require a week or more to deploy infrastructure changes in production, and 43% need to rerun their infrastructure deployments more than four times to get it right.

Overall, 45% of respondents claim to have streamlined workflows and reduced friction, with 32% having reduced infrastructure costs.

A total of 41% have also reduced security incidents, while 36% report incurring fewer compliance violations.

Spacelift CEO Pawel Hytry said that the survey makes it clear that while usage of infrastructure-as-code (IaC) is widespread, the level of automation being achieved by most organizations is limited.

In fact, only 14% of respondents have fully implemented infrastructure automation best practices, and only 7% have embraced platform engineering as a methodology for managing DevOps workflows at scale. Those organizations are four times more likely to provision new resources in four hours or less, and five times more likely to deploy changes in production daily or multiple times a day, according to the report.

In general, the survey shows that when it comes to IT automation there is a paradox between speed and control. While IaC tools enable organizations to provision IT infrastructure faster, an absence of best practices results in more mistakes being made that ultimately conspire to slow DevOps teams down, said Hytry.

The more complex the IT environment becomes the more problematic these issues become, he added. For example, 81% of the survey respondents work for organizations that are managing hybrid cloud computing environments.

Given the fact there is still plenty of room for IT infrastructure automation improvement, DevOps teams should revisit how IaC tools are being used. Many of the processes being employed by application developers are far more manual than they should be, which creates more opportunities for misconfigurations, said Hytry. As a result, application developers are spending time on a set of tasks that in addition to possibly introducing cybersecurity risks also takes time away from writing code, he noted.

Hopefully, advances in artificial intelligence (AI) will soon make it easier to discover these issues and surface suggestions for remediation. In the meantime, however, DevOps teams would be well advised to invest more in automation to ensure infrastructure is not only being provisioned faster but also more reliably, said Hytry.

Regardless of motivation, the pace at which code is now being developed in the age of AI has greatly accelerated. It’s only a matter of time before the number of times production environments will need to be provisioned and updated will exponentially increase. By the same token, DevOps teams that don’t fully automate those processes will continue to find themselves falling increasingly behind, as the amount of software being deployed inevitably overwhelms existing processes and workflows.

March 19, 2025
Scaling with Terraform: How to Manage Infrastructure at Scale

Managing large-scale infrastructure is a complex task that requires a strategic approach, especially when using infrastructure-as-code (IaC) tools such as Terraform. As organizations expand, their infrastructure must scale accordingly; however, it often becomes more intricate and challenging to manage. Terraform provides a robust framework for defining, provisioning and managing infrastructure, but scaling these operations requires a deep understanding of both Terraform and best practices for large-scale infrastructure management.

In this article, we will delve into effective strategies and practices for managing Terraform infrastructure at scale.

Benefits of Using Terraform for Large-Scale Infrastructure

● Scalability: Terraform is designed to handle complex infrastructures with ease. Its modular architecture and state management capabilities allow you to scale your infrastructure efficiently.
● Consistency: By defining IaC, Terraform keeps your infrastructure consistent across different environments and reduces the risk of configuration drift and errors.
● Automation: Terraform is a great help when it comes to automating provisioning and management of infrastructure, enabling you to deploy resources quickly and reliably. This automation is crucial for large-scale environments where manual intervention is impractical.
● Collaboration: Terraform’s configuration files can be versioned and shared, promoting collaboration among teams. The collaborative approach ensures that everyone is on the same page and reduces the likelihood of conflicts.

Strategies for Managing Terraform at Scale

As you scale your infrastructure, the complexity of managing resources and ensuring stability increases exponentially. The strategies outlined below will help you scale effectively with Terraform.

Structuring Your Terraform Code

Modularization
A key strategy for managing Terraform at scale is modularization. Breaking down your Terraform configuration into reusable modules enhances readability, maintainability and reusability. Modules are self-contained packages of Terraform configurations that manage a specific set of resources. By utilizing modules, you can standardize configurations across different environments and projects, reducing redundancy and errors.

Organizing by Environment
Separate your configurations by environment (e.g., development, staging and production). This structure prevents accidental changes in production and allows for environment-specific customization.
Example Directory Structure:
├── environments
│ ├── dev
│ │ ├── main.tf
│ │ ├── outputs.tf
│ │ ├── provider.tf
│ │ ├── terraform.tf
│ │ ├── terraform.tfvars
│ │ └── variables.tf
│ └── prod
│ ├── main.tf
│ ├── outputs.tf
│ ├── provider.tf
│ ├── terraform.tf
│ ├── terraform.tfvars
│ └── variables.tf
└── modules
├── ec2
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
└── network
├── main.tf
├── outputs.tf
└── variables.tf

Terraform workspaces are used to manage multiple environments (e.g., development, staging and production) within the same configuration. The isolation ensures that changes in one environment do not impact others.

State Management

Proper state management is crucial when dealing with large-scale Terraform deployments. The Terraform state file contains mappings between your configuration and the deployed infrastructure. Using remote state storage, such as AWS S3 with DynamoDB for state locking, ensures consistency and prevents conflicts.

terraform {
backend “s3” {
bucket = “bucket-name”
key = “path/to/terraform.tfstate”
region = “us-east-1”
“encrypt” = true
dynamodb_table = “terraform-locks”
}
}

Optimizing Resource Configuration and Performance

Here are a few tips to achieve optimal performance in large-scale environments:

● Maintain Consistency in Naming Conventions: Follow a consistent naming convention for resources to make it easier to identify and manage them, especially in large deployments.
● Use Data Sources: Dynamically fetch information about existing resources to avoid hardcoding values.
● Minimize Resource Dependencies: Reduce dependencies between resources to enable parallel deployments and speed up provisioning.
● Apply Lifecycle Hooks: Control the order and conditions under which resources are created, updated or destroyed.
● Review and Update Regularly: Keep your Terraform configurations up to date with the latest features and practices.

Automated Workflows

Integrate with CI/CD Pipelines

Automate your Terraform workflows using CI/CD tools such as Jenkins, GitLab CI and GitHub Actions to minimize manual effort and ensure consistency across deployments.

CI/CD pipelines enable you to automate various stages of your Terraform workflows, including validation, planning and application of changes. This automation ensures that every change goes through a standardized process, reducing the risk of inconsistencies and errors. For example, when a developer submits a pull request with infrastructure changes, the pipeline can automatically trigger the validation and planning stages and notify the relevant team members for review. This process ensures that changes are peer-reviewed and meet the required standards before being merged and applied.

Advanced CI/CD Integration

Terraform Cloud, Terraform Enterprise or Spacelift offer additional features including remote runs, state management and policy as code. These services help manage Terraform at scale by providing a centralized platform for collaboration, governance and automation.

Policy Enforcement

As your infrastructure grows, enforcing policies becomes crucial to ensure compliance and security. Terraform provides Sentinel, a policy as code framework that allows you to define rules governing your infrastructure. By integrating Sentinel policies into your CI/CD pipelines, you can automatically enforce best practices and organizational standards. Alternatively, you can use Open Policy Agent (OPA) with Terraform to achieve these results.

Wrapping Up

Scaling infrastructure with Terraform requires a blend of strategic planning, best practices and the right tools. The key points above can help you effectively manage Terraform infrastructure at scale, ensuring your systems are resilient, scalable and compliant with organizational policies and industry standards.

July 8, 2024