AI has fundamentally changed software development.

Developers are writing more code than ever. AI coding assistants can generate features, tests, documentation, and infrastructure configurations in minutes. Engineering organizations are seeing meaningful productivity gains as AI becomes embedded throughout the software development lifecycle.

But there is a catch.

Security teams now face a difficult reality: application security was already struggling to keep pace with software delivery before AI arrived.

Now the gap is widening.

During a recent discussion on AI SAST, Rennye Shen, Senior Director of Product Marketing at Harness, summarized the challenge clearly:

"If you were struggling before with the pace of software development, you're probably going to break once your development organization adopts these tools en masse."

The problem isn't that AI created new security challenges.

The problem is that AI amplified existing ones.

Why Traditional SAST Is Struggling to Keep Up

Most organizations already run some combination of static application security testing (SAST), software composition analysis (SCA), and additional application security tools.

Yet many security leaders face the same outcomes:

• Thousands of findings
• Growing vulnerability backlogs
• Low remediation rates
• Frustrated developers
• Limited pipeline coverage

The issue isn't visibility.

The issue is action.

Security teams can find vulnerabilities. What they struggle with is helping developers resolve them quickly enough to keep pace with delivery demands.

As AI accelerates development velocity, this challenge becomes harder.

More code means more opportunities for vulnerabilities. Larger commits, faster release cycles, and increased deployment frequency create pressure on security workflows that were already stretched thin.

The Four Reasons SAST Programs Fail

1. Developers Don't Trust Findings

False positives remain one of the biggest obstacles to effective application security. When developers repeatedly investigate findings that turn out to be non-issues, trust erodes quickly. Security teams may view a 30% false-positive rate as acceptable. Developers do not. Once trust is lost, remediation rates decline.

2. Vulnerabilities Don't Get Fixed

Finding vulnerabilities is not the same as fixing them. Most developers are measured on shipping software, not performing security analysis. Without clear remediation guidance, security findings often become another item in an already overloaded backlog.

3. Business Logic Vulnerabilities Are Missed

Traditional SAST solutions excel at pattern matching. They identify known coding mistakes, insecure functions, and common weaknesses. But modern applications increasingly fail in more subtle ways. Business logic vulnerabilities, authorization flaws, and complex data flow issues often evade traditional scanning approaches because they require deeper contextual understanding.

4. Security Cannot Match Development Velocity

Many organizations only scan a fraction of their repositories and pipelines. The reason is simple. Traditional security tooling requires tuning, maintenance, and integration effort. As application portfolios grow, coverage often declines. The result is security visibility that scales more slowly than software delivery itself.

AI SAST Is Not One Technology

One of the most important lessons for buyers is that AI SAST is not a single category. There are two fundamentally different approaches emerging.

LLM-Native Security Testing

This approach uses large language models directly to analyze source code.

Its strengths include:

• Deep reasoning capabilities
• Better understanding of business logic
• Ability to discover novel vulnerabilities
• Rich contextual analysis

However, there are tradeoffs.

LLMs are probabilistic systems.

The same code may produce different results across scans. Hallucinations can occur. Findings may be harder to validate and explain.

AI-Assisted SAST

This model starts with a traditional deterministic scanning engine and applies AI to improve results.

Benefits include:

• Consistent findings
• Repeatable scans
• Easier workflow integration
• Greater auditability

The downside is that many implementations provide incremental improvements rather than fundamentally new detection capabilities.

This creates an important tension:

Reasoning versus reliability.

Three Myths About AI SAST

Myth #1: AI Eliminates False Positives

No security technology eliminates false positives completely. AI can reduce noise significantly. But uncertainty does not disappear. Instead, uncertainty changes form. Traditional scanners may generate false positives. LLM-based systems may introduce hallucinations. Security leaders should be skeptical of any claim that promises perfect accuracy.

Myth #2: AI Will Replace Traditional SAST

The future is unlikely to be either-or. Deterministic scanning remains valuable for CI/CD pipelines, compliance requirements, and auditability. LLM reasoning is valuable for code generation workflows and deeper vulnerability analysis. Most organizations will benefit from combining both approaches.

Myth #3: AI Is Always Correct

AI systems often sound confident. Confidence should never be confused with accuracy. Human validation remains essential, particularly when security decisions impact production systems. Trust and explainability will remain critical requirements for AI-driven security tools.

Five Questions Every Buyer Should Ask

When evaluating AI SAST platforms, focus on outcomes rather than marketing claims.

1. Can it secure AI-generated code?

The most important security shift may occur before code reaches a repository.

Can security testing happen directly within AI coding workflows?

2. Does it actually reduce noise?

Ask vendors for measurable evidence.

How much reduction in false positives do customers experience?

3. Can it detect business logic vulnerabilities?

Modern applications require contextual analysis.

Security tools must move beyond pattern matching.

4. Does it improve remediation?

Detection without remediation provides limited value.

Evaluate how effectively developers can fix identified issues.

5. Are findings explainable?

Security teams, developers, and auditors all need understandable evidence.

Trust requires transparency.

The Emerging Hybrid Security Model

The most practical future is neither fully deterministic nor fully probabilistic.

Instead, platform teams should expect hybrid architectures.

Deterministic engines provide repeatability and governance.

LLM-based systems provide reasoning and contextual understanding.

Together, they address different parts of the software delivery lifecycle.

This mirrors a broader trend across platform engineering.

The goal is not simply to find more problems.

The goal is to operationalize security at the speed of software delivery.

What Platform Teams Should Do Next

Three priorities stand out:

Shift Security Earlier

As AI-generated code becomes more common, security controls should move closer to code creation itself.

Optimize for Remediation

The best security finding is the one that gets fixed. Measure remediation effectiveness, not vulnerability volume.

Prioritize Developer Experience

Security programs succeed when developers trust and adopt them. Reducing friction matters as much as improving detection.

Conclusion

AI is not replacing application security.It is forcing application security to evolve.

Organizations that continue relying solely on traditional SAST approaches will find it increasingly difficult to keep pace with AI-driven software development. The winners will be teams that combine reliable security automation with intelligent AI-assisted workflows that developers actually use.

Ready to see how Harness helps platform teams secure software delivery while maintaining developer velocity? Explore Harness Security Testing Orchestration and AI-powered software delivery solutions.

FAQ

What is AI SAST?

AI SAST combines artificial intelligence with static application security testing to improve vulnerability detection, reduce noise, and accelerate remediation.

How is AI SAST different from traditional SAST?

Traditional SAST primarily relies on deterministic pattern matching. AI SAST adds reasoning, contextual analysis, and automated remediation capabilities.

Can AI SAST eliminate false positives?

No. AI can reduce false positives but cannot eliminate them entirely.

What is LLM-native application security testing?

LLM-native testing uses large language models directly to analyze source code and identify vulnerabilities.

Why is AI-generated code creating security challenges?

AI accelerates code production, increasing development velocity and creating more opportunities for vulnerabilities to enter software pipelines.

Can AI SAST detect business logic flaws?

Some AI-based approaches can analyze complex application behavior and identify business logic vulnerabilities that traditional tools may miss.

Will AI replace traditional application security testing?

Most experts expect hybrid approaches that combine deterministic scanning with AI-powered reasoning.

Everyone talks about moving faster with AI. But here's what nobody mentions: AI amplifies both good and bad practices alike.

You can build code 10x faster with AI agents. But if your testing, operational controls, and failure mode analysis aren't keeping up, you'll deploy bugs 10x faster too. Speed without guardrails is just a faster path to production incidents.

The uncomfortable truth is this: knowing you can use AI agents to build software and actually knowing how to do it safely and maintain operational control are two entirely different problems. Most organizations are optimizing for the first without solving for the second.

This is the defining challenge of the agentic era. How do you gain the speed that AI agents promise without compromising the quality and operational risk you're expected to deliver?

The Four Pillars of Agentic Engineering Excellence

After six months of redesigning their SDLC around AI-driven development, Harness identified four core pillars that enable both speed and safety. These aren't aspirational. They're now standard practice across their engineering organization.

1. Spec-Based Development: Make Context Explicit

Traditional product requirements documents live outside code. Specs exist in Confluence. Design docs languish in Google Drive. Tech specs might be on a wiki. The result is that context is fragmented, outdated, and inaccessible when you need it.

With agentic development, context is everything. AI agents need to understand product vision, technical constraints, design decisions, and test requirements. Scattered documentation defeats that purpose.

The solution is moving specs into code repositories. They should be versioned, searchable, and always in sync with implementation. This includes:

• Product specs: Domain knowledge, competitive landscape, roadmap, finished and in-progress features
• Tech specs: Design docs, resilience patterns, API contracts, scalability requirements
• UI specs: Mock implementations in code (using tools like Claude or Figma), shared styles, design system inheritance
• Test specs: Test cases, performance targets, SLA requirements, operational constraints

When specs live in code, AI agents can access them directly. More importantly, they stay current. Engineers reference them during implementation. Leaders can experiment with UI mockups in 30 minutes instead of weeks. Context becomes a core asset, not an afterthought.

2. Agent-Ready Architecture: Know When to Delegate

Not every problem needs an agent. The instinct to use agents everywhere will kill your ROI fast.

The right pattern is: use agents for open-ended, multi-step tasks that require dynamic decision-making and reasoning. Code review? Good candidate for an agent. Analyzing a Jira ticket to generate a full solution? Excellent. Routing a request to the right microservice? No. Use a traditional API.

At Harness, they found that roughly 15-20% of work is truly agent-driven (fully autonomous from Jira to PR), while 80% is AI-assisted (developers using agents as tools). Both are valuable.

The architecture looks like traditional microservices with agent endpoints (using Model Context Protocol). Services are still built for scalability, resilience, and multi-tenancy. But where there's ambiguity or complex reasoning, agents can operate on context and collaborate across systems.

The key is scope. Each agent has a specific role with bounded permissions. A code review agent doesn't implement changes. A testing agent doesn't modify production. A specification agent doesn't decide architecture. Granular, specialized agents are faster and cheaper than bloated omniscient agents trying to do everything.

3. Multi-Layer Verification: Test Everything Differently

Traditional testing doesn't work for agentic systems. You need six layers:

1. Front-end verification: Visual tests (Vitest, Playwright), UI correctness
2. Product and API testing: Unit, integration, and functional tests for services
3. Agent efficacy testing: Does the agent produce correct outputs? Baseline the agent's behavior against known-good examples
4. Data verification: Cross-check that training data and validation data are correct. This is critical for agents that hallucinate.
5. Continuous efficacy monitoring: The most crucial layer. Just like regression tests catch regressions in code, efficacy tests catch regressions in agent quality. If you change a prompt or context, your agent's output might degrade. Continuous monitoring catches this automatically.
6. Agentic feedback loops: Monitor agent behavior in production, not just in tests

‍

The difference is layer 5. With AI agents, quality isn't static. Change a system prompt slightly? The agent's outputs change. Update the context knowledge base? Efficacy drops. You need continuous verification that catches regressions in real time, just like you do with code tests.

4. Operational Excellence: Inspect Before Launch, Monitor Always

Most organizations surface operational concerns after development. That forces expensive rework and delays launches.

Operational Readiness Reviews (ORR) shift this left. During design review and test specification, teams ask: What about GDPR compliance? How do we ensure availability? What's the data residency strategy? What are our SLAs?

Instead of surprises at launch, ORR creates a checklist with documented evidence. Load tests prove you hit 200 TPS targets. Game days show incident response works. Security audits validate compliance. By launch, you don't wonder if you're ready. You know.

Then, post-launch, teams meet weekly for operational reviews. Dashboards show service health, customer issues, and RCAs from incidents. Engineering leadership meets separately for cross-calibration on operational excellence.

This discipline isn't just about preventing incidents. It's about continuously learning from operations and feeding that back into architecture and design.

The Results: Speed Without Sacrificing Safety

After six months of implementing these four pillars, Harness shipped 23% more features, reduced incidents by 44%, and achieved 45% AI ROI. More importantly, they now operate with predictable velocity and confidence in operational control.

That's not just faster. It's smarter.

Why This Matters

The agentic era doesn't have to be a choice between speed and safety. Teams that treat agentic development as a discipline (with specs, verification, architecture discipline, and operational rigor) gain speed and control.

Teams that just turn agents loose and hope for the best will gain speed and lose control. They'll ship faster. They'll also cause incidents faster. They'll accumulate technical debt faster. The cost of speed without structure compounds quickly.

The question isn't whether to use AI agents. You will. The question is whether you'll engineer for the agentic era with the same rigor you'd apply to critical systems. Agentic systems are critical systems now. They're making architectural decisions, generating code, and running production.

The organizations winning in the agentic era aren't the ones using the newest models or the most agents. They're the ones who slowed down just enough to build the guardrails, specs, and operational discipline that lets them move fast safely.

That's engineering excellence. That's the new baseline.

Ready to engineer for the agentic era safely? Learn how to implement spec-driven development, multi-layer verification, and operational excellence in your organization. The four pillars of agentic engineering aren't optional. They're table stakes.

Form Submission Thank You Message

Thank You Message Copy (Full Version):

"Thanks for downloading! You've just unlocked the framework that got Harness to 23% more features shipped with better quality. Check your email for the complete four-pillar implementation guide plus templates for spec-driven development, agent governance policies, and operational readiness reviews. See exactly how multi-layer verification catches AI regressions before they hit production. Your team can achieve the same results. Questions? Reach out anytime."

Thank You Message Copy (Short Version):

"Got it! Your guide is on the way. While you're reading, explore how Harness teams reduced incidents by 44% using operational readiness reviews and continuous efficacy monitoring for AI systems. Watch our live demo showing spec-driven development in action and how to chain agents safely. Or book a session with our engineering experts to design your agentic SDLC framework."

Modern software releases rarely consist of application code alone. A new feature might require additional database tables, modified columns, new indexes, updated constraints, or reference data changes. While many organizations have successfully automated application deployments, database schema migrations often remain disconnected from the rest of the software delivery process.

This separation creates deployment bottlenecks, increases operational overhead, and introduces unnecessary risk.

Application teams may deploy code through automated Continuous Delivery (CD) pipelines, while database changes are managed through separate processes, manual approvals, or standalone tooling. The result is a fragmented release workflow where application and database changes must be done manually. In this article, we'll explore how Harness Continuous Delivery (CD) and Harness Database DevOps (DBDevOps) enable teams to deploy database and application changes through a unified pipeline, improving release velocity, visibility, governance, and deployment safety.

Why Database Schema Migrations Should Be Part of Your CD Pipeline?

Applications and databases are now a days mostly tightly coupled and an application release may depend on:

• New tables
• Additional columns
• Updated indexes
• Modified constraints
• New database objects

When application deployments and database schema migrations happen independently, teams often encounter several challenges.

Manual Coordination

Application and database teams must coordinate release schedules and deployment windows.

Deployment Risk

Applications may be deployed before required database changes are available, resulting in runtime failures or broken functionality.

Limited Visibility

Teams often struggle to answer questions such as:

• Which database schema migrations have been deployed?
• Which environments are running the latest schema version?
• What changes were included in a release?

Complex Rollbacks

• Application rollbacks are generally straightforward.
• Database rollbacks can become significantly more complicated when deployments are managed through separate workflows.
• A unified deployment process helps eliminate these challenges by treating database schema migrations as a first-class part of software delivery.

What a Unified Deployment Pipeline Looks Like

Instead of managing application and database releases separately, teams can orchestrate both through a single deployment pipeline.

This approach ensures database and application changes remain synchronized throughout the deployment lifecycle.

Deploying Database Schema Migrations and Applications Together

Let's examine a practical example using Harness Database DevOps and Harness Continuous Delivery. The deployment stage consists of three primary phases:

1. Apply database schema migrations
2. Deploy the application
3. Verify deployment health and initiate rollback when necessary

Phase 1: Apply Database Schema Migrations

The deployment begins by applying database changes using the Harness Database DevOps schema deployment step.

- step:
    type: DBSchemaApply
    name: Apply Database Schema
    identifier: Apply_Database_Schema
    spec:
      connectorRef: account.harnessImage
      migrationType: Liquibase
      dbSchema: bookkeeper
      dbInstance: goodinstance
      tag: v1.0.0

The DBSchemaApply step executes the database schema migration associated with the specified release version. By versioning database changes and deploying them through a pipeline, teams gain:

• Consistent database schema migration across environments
• Controlled promotion between development, staging, and production
• Deployment traceability
• Improved governance and auditability

Most importantly, database changes are deployed automatically as part of the release process rather than through a separate operational workflow.

Phase 2: Deploy the Kubernetes Application

After the database schema migration completes successfully, the pipeline proceeds with the application deployment.

- step:
    name: Deploy Application
    identifier: rolloutDeployment
    type: K8sRollingDeploy
    timeout: 10m
    spec:
      skipDryRun: true
      pruningEnabled: false

The K8sRollingDeploy step performs a rolling deployment to Kubernetes, gradually replacing existing application instances with the new version while maintaining service availability. Because the database schema migration has already been applied, the application can safely consume:

• Newly created tables
• Updated columns
• Additional indexes
• New constraints
• Modified database structures

This sequencing helps eliminate compatibility issues that commonly occur when application and database deployments are managed separately.

Automated Rollback for Safer Releases

One of the most valuable aspects of a unified deployment pipeline is coordinated rollback. If verification identifies an issue, the stage can automatically trigger rollback actions.

failureStrategies:
  - onFailure:
      errors:
        - AllErrors
      action:
        type: StageRollback

The rollback workflow executes the Kubernetes rollback step:

rollbackSteps:
  - step:
      type: K8sRollingRollback
      name: Rollback Rollout Deployment

This enables teams to quickly restore the previous application version and minimize production impact. Combined with database deployment visibility and rollback strategies, organizations can significantly reduce deployment risk and improve recovery times.

Benefits of Combining Continuous Delivery and Database DevOps

• Faster Release Velocity: Database and application changes move through a single automated workflow without waiting for separate deployment windows.
• Safer Database Schema Migrations: Version-controlled database schema migrations help ensure consistency across environments.
• Improved Visibility: Teams gain centralized insight into deployments, migration history, and release status.
• Better Governance: Approval workflows, policies, and compliance requirements can be enforced directly within deployment pipelines.
• Reduced Deployment Risk: Verification and rollback become built-in parts of every release.
• Stronger Collaboration: Developers, platform engineers, and database teams work from the same deployment process rather than maintaining separate release workflows.

Bringing Database Schema Migration into Modern Continuous Delivery

Database schema migration should not be treated as a separate operational activity. Modern software delivery requires application code and database changes to move together through a secure, automated, and governed deployment process. Harness Database DevOps enables teams to:

• Automate database schema migrations
• Integrate database deployments into CI/CD pipelines
• Manage version-controlled database changes
• Apply governance and compliance controls
• Support rollback and recovery workflows
• Deploy applications and databases together through a unified pipeline

By combining Harness Continuous Delivery and Harness Database DevOps, organizations can streamline releases while reducing deployment risk and improving operational efficiency.

Conclusion

Application releases and database schema migrations are two parts of the same deployment. Managing them separately creates unnecessary complexity, increases risk, and slows delivery.

By orchestrating database schema migrations, Kubernetes deployments, verification, and rollback within a single pipeline, teams can build a more reliable and efficient release process. Harness Database DevOps and Continuous Delivery provide the foundation for modern software delivery, enabling organizations to deploy applications and database changes together with greater confidence, visibility, and control. Explore how Harness Database DevOps can transform your delivery process today.

FAQs

1. What is a database schema migration?

A database schema migration is a version-controlled change to a database structure. Examples include creating tables, adding columns, modifying indexes, updating constraints, or introducing new database objects. Database schema migrations ensure that database changes can be tracked, reviewed, and deployed consistently across environments.

2. Why should database schema migrations be included in a Continuous Delivery pipeline?

Including database schema migrations in a CD pipeline ensures application and database changes are deployed together. This reduces deployment risk, improves consistency across environments, simplifies release management, and provides better visibility into the overall deployment process.

3. How does Harness Database DevOps support database schema migration?

Harness Database DevOps enables teams to automate database schema migrations through pipelines, manage version-controlled database changes, enforce governance policies, support rollback workflows, and orchestrate database deployments alongside application deployments within a unified release process.

‍

Why is Artifact Registry cleanup hard to get right

AI is changing artifact management in two ways at once. Every AI-generated pull request, dependency update, and automated build creates more container images, packages, and Helm charts than ever before. Registries are growing faster than engineering teams can manage them, driving up storage costs and leaving thousands of stale artifacts behind. At the same time, the cost of deleting the wrong artifact has never been higher. One mistaken cleanup policy can remove a production image that's still serving traffic or a package that hundreds of downstream applications still depend on.

One enterprise SaaS customer we spoke to run more than 270 microservices on a single Docker registry. A single age-based cleanup rule, set to delete artifacts older than 30 days, removed production images that were still serving traffic. The next deployment failed. An incident occurred. The rule was disabled. Cleanup never restarted. The registry kept growing at 2 to 3 TB per month.

That story is becoming increasingly common as release velocity accelerates. Across Docker registries, npm, Maven, Helm, and Python repositories, traditional cleanup strategies weren't designed for the volume and pace of AI software delivery.

• Age-based rules like "delete artifacts older than 30 days" remove production artifacts that haven't been redeployed but are still actively running.
• Count-based rules like "keep last 10 versions" silently drop deployed versions when rapid release cadence pushes them out of the keep window.
• Tag-based patterns fail when teams share tags across environments (the same release tag applied to both staging and production).

There's a fourth failure mode that's harder to see. Traditional lifecycle rules only look at the artifact itself: version count, age, and download activity. They have no awareness of the broader SDLC. The same artifact can be 60 days old, downloaded exactly once, and still be the exact image running live in a production pipeline. In a world where AI-generated pull requests are creating more builds than any team can manually track, that blind spot grows fast. Harness Artifact Registry's lifecycle rules are designed to 

close it. Rather than evaluating artifacts in isolation, they can tie in metadata across different stages of the SDLC, including CI/CD, so that an artifact currently deployed in a pipeline is automatically protected from deletion, no extra rule required. The registry doesn't just know what it's storing. It knows what's running.

Teams are left with an impossible choice: disable cleanup and let storage costs grow unchecked, or automate cleanup and risk deleting artifacts that production still depends on. In a world where most code is generated by AI, neither approach scales. Artifact lifecycle management has to become policy-driven, predictable, and safe by default.

Lifecycle Rules is built around fixing this exact problem. Two rule types. Three scope levels. Dry-run preview before any rule fires. Soft-delete with one-click recovery. An explicit attachment model that prevents the hidden cascading behavior most registries suffer from.

This guide walks through the feature as a narrative: one DevOps engineer's first day setting up cleanup rules across five package types and learning how the hierarchy works. The engineer is fictional; the registry behavior, screenshots, and execution data are real, captured from a working Harness Artifact Registry instance.

The feature is currently behind the HAR_ARTIFACT_LIFECYCLE_POLICY feature flag. Contact Harness Support to enable it on your account. Once on, you'll be looking at exactly what's shown below.

The mental model, in 60 seconds

Before the walkthrough, the building blocks:

Two rule types. Three scopes. Always reversible. That's the whole feature.

Day one. Maya opens the Lifecycle Rules tab.

Maya is a DevOps engineer on a fictional e-commerce platform. Her team has Docker, npm, Maven, Python, and Helm registries. Releases are tagged 1.0.0, 1.1.0, 1.2.0. Dev and PR builds use 0.9.0-dev, 1.3.0-pr-100, and similar. The registries have been growing for months. Today Maya gets the ticket: set up automated cleanup, but don't break anything.

Maya opens the Harness UI, navigates to Artifact Registry → Registries Settings → Lifecycle Rules, and clicks + New Lifecycle Rule.

She knows the rule of any cleanup operation: protect what matters before you delete anything. Her first rule won't delete a thing. It will mark her formal releases as untouchable.

Maya creates her first rule: a Retention rule

She fills in:

Retention rule with literal version chips. Each chip is one exact version. Predictable matching, no surprises.

She uses literal version strings, not 1.*. Maya knows that wildcards are greedy. 1.* would also match 1.3.0-dev, which would protect dev builds she actually wants cleaned up later. Exact strings are predictable.

She submits. The rule lands in the table. There's no schedule attached, because Retention rules don't run on cron. Instead they evaluate passively, every time a Cleanup rule tries to delete something. If the version matches, the deletion is blocked.

Retention always wins. If a Retention rule matches an artifact, no Cleanup rule, no manual delete, nothing within the lifecycle system can remove that artifact while the rule exists.

Now Maya goes after the dev builds

With her safety net in place, Maya is ready to actually delete something. She targets her npm registry first because the team's @shop/cart-sdk package has accumulated dev builds from months of feature branches.

She clicks + New Lifecycle Rule again, this time as a Cleanup rule:

NPM cleanup rule configured with strattest07 registry, NPM type, dev-version patterns, and Keep last 1.

Maya uses two patterns instead of one. She learned from experience that stacking narrow patterns is more reliable than reaching for one clever glob. 0.* catches versions like 0.9.0-dev and 0.9.1-dev. *dev* catches anything with "dev" in the name. Both together cover the dev-build space cleanly.

She submits. The rule is saved but hasn't run yet. Cleanup rules execute on schedule, but Maya isn't going to wait for tomorrow's cron. She's going to dry-run it right now.

The dry-run is where you build trust

This is the part Maya's old registry didn't have. From the rules table, she clicks the three-dot menu next to cleanup npm devs and selects Dry Run.

Within seconds, she lands on the execution detail:

Dry-run result. Stable 1.0.0 and 1.1.0 versions are PROTECTED by the Retention rule. Older dev versions are flagged as WOULD BE DELETED. No artifacts were actually touched.

Maya scans the result:

• 1.0.0 and 1.1.0: PROTECTED, because her Retention rule matched.
• The older dev versions: WOULD BE DELETED.
• At the top: an estimated storage reclaim number she can show her manager.

Nothing was actually deleted. This is the safety net. Maya can change her patterns, change the keep count, change the registry scope, and re-run the dry-run as many times as she wants. Each dry-run uses the same evaluation logic as a real execution. The only difference is the state mutation.

Maya stacks criteria for an even stronger safety net

For her Helm registry, Maya wants to be extra careful. Helm charts deploy production infrastructure. A wrong delete here means real downtime.

She creates a Cleanup rule with two criteria stacked:

• Keep last 1 version
• Delete artifacts older than 1 day

The two criteria combine with AND logic. An artifact must satisfy both conditions to be deleted.

She dry-runs it:

Helm dry-run with stacked AND criteria. No results found because every chart was pushed that morning. The age criterion blocked the deletion entirely.

No results found. Estimated savings: 0 bytes.

Why? Because Maya pushed all her Helm charts that same morning. Keep-last-1 alone would have flagged plenty for deletion, but the age criterion saw all the charts as less than 1 day old and blocked everything. Nothing gets deleted until every guard agrees.

This is exactly the conservative behavior she wants for Helm. She saves the rule confidently knowing it won't act until artifacts are genuinely old.

Rule of thumb. Use a single criterion when you want aggressive cleanup. Stack two or three with AND logic when you want a safety net.

Now her manager walks over

"Maya, the org admin team wants all releases tagged 1.0.0, 1.1.0, and 1.2.0 protected across every project. They don't want each team setting their own retention rules. Can we centralize that?"

Yes. This is what scoped rules are built for.

HAR has three scope levels for lifecycle rules:

1. Account level: for CISO, compliance, central governance.
2. Organization level: for platform teams, business unit governance.
3. Project level: for service teams, day-to-day operations.

But here's the key design choice from the docs:

"Rules are reusable policies that are explicitly attached to registries. A rule does nothing until attached. This explicit attachment model eliminates hidden cascading behavior."

In plain words: rules created at the org or account level don't automatically take effect in child scopes. The child scope admin sees the rule, decides to opt in, and explicitly attaches it. This means central governance doesn't surprise project teams, and project teams can't accidentally weaken what central governance has defined.

The org admin creates the rule at org scope

Maya's org admin switches to the organization scope using the top breadcrumb, then runs the same New Lifecycle Rule flow Maya used. Same form. Same fields. Only the breadcrumb above the form is different.

Org-scope rules tab. The breadcrumb shows Account / Organization, and the rules list contains the org-level Retention rule. From here, the rule is visible to all child projects but does not automatically protect anything.

The rule now lives at org scope. The next step is Maya's: she has to opt in.

Maya sees the org rule, but it isn't doing anything yet

Back in her project, Maya goes to the Lifecycle Rules tab and ticks the Show policies from parent scope box.

Project rules list with parent-scope visibility enabled. The org rule appears with the ORGANIZATION badge in the Created In column. There's no toggle on the right, only project-owned rules are toggleable from a child scope.

The org rule appears in her list with an ORGANIZATION badge in the Created In column. It's visible. But Maya wants to verify whether it's actually protecting anything yet.

She re-runs the dry-run on cleanup npm devs:

Dry run with the org rule visible but unattached. Every version, including the 1.0.0 and 1.1.0 releases, shows WOULD BE DELETED. The org rule is passive.

Every version shows WOULD BE DELETED. Including the 1.0.0 and 1.1.0 releases that should be protected by the org rule. The org rule is visible but passive. Maya hasn't attached it yet.

Maya attaches it

She clicks on the org rule row. An Edit form opens, but only one field is editable: which registries this rule attaches to in her project. Criteria, patterns, and schedule are all inherited from org scope and locked.

Attach form for the inherited org rule, opened from project scope. The project admin can add their registries to the attachment list. Criteria and patterns are inherited from the parent and cannot be changed here.

She adds her project's registries to the attachment list and saves.

Now she re-runs the dry-run on cleanup npm devs one more time. This time, 1.0.0 and 1.1.0 show PROTECTED. The protection is coming from the org-level rule, attached at the project scope.

Rules list after attachment. A chain icon next to the org rule name indicates it is actively attached to one or more registries in this scope.

The model in one sentence: authorship stays at the parent scope, attachment is opt-in by the child scope. Org admins define what counts as a release. Project admins decide which of their registries the definition applies to. Nobody can weaken anybody else's rule.

Maya schedules her rules to run overnight

The dry runs are passing. The hierarchy is in place. It's time to let the system run for real.

Maya edits each Cleanup rule and walks through to the Schedule step. She picks Daily, sets the timezone, and lets the cron expression auto-generate.

Schedule step. Timezone selector at the top, frequency tabs, and a generated cron expression. Custom mode lets you write any cron.

She schedules npm at 01:00 UTC, python at 01:15 UTC, maven at 01:30 UTC, spreading them out to keep the execution log clean. Helm and the generic bundles she leaves running with their safety-net criteria, knowing they'll keep returning "no results" until the artifacts are genuinely old enough.

Final state before overnight scheduled execution. Five Cleanup rules covering all package types, plus one attached Org Retention rule. Saved Storage starts at zero.

She closes her laptop.

The next morning

Maya opens the Lifecycle Rules tab and looks at the Saved Storage card at the top:

After overnight execution. 5.59 KB saved, 7 artifacts cleaned, 5 executions in the last 30 days. Real artifact cleanup, automated.

5.59 KB saved. 7 artifacts cleaned. 5 executions in the last 30 days. These are small numbers because this is a demo project. In production scale, with a registry growing at 2 to 3 TB monthly, those numbers add up fast.

She switches to the Lifecycle Rule Executions tab:

Executions tab with five SCHEDULED runs and several DRY RUN entries, all showing SUCCESS. Notice the rules that returned zero deletions (helm charts and bundles) still ran successfully. They just had nothing to delete, thanks to AND-logic safety.

Every execution is logged. Rule name, registry, type (Scheduled or Dry Run), status, registries affected, packages affected, versions deleted, storage reclaimed, timestamp. The execution log doubles as a complete compliance audit trail. Every deletion traceable to a specific rule run.

She drills into the python cleanup execution:

Drill-in view of the python execution. Two versions show SOFT DELETED, while 1.0.0 and 1.1.0 show PROTECTED by the Retention rule.

Two versions show SOFT DELETED. Two versions show PROTECTED. Exactly what Maya designed: dev builds cleaned, releases retained.

And then somebody asks for the deleted version back

"Maya, I was about to test a regression against 0.9.0.dev1. Can you get it back?"

Soft delete is the whole reason Maya can sleep through the night. Every deletion in lifecycle rules is reversible during the recovery window (configured at the account level).

She navigates to Registries → pinym → shop-reco-engine. The artifact view has two tabs: Available and Deleted. She clicks Deleted.

Artifact view, Deleted tab open. The three-dot menu reveals Restore and Delete options. One click brings the version back to Available.

She clicks the three-dot menu on 0.9.0.dev1. The dropdown shows Restore and Delete. She clicks Restore.

After restore. Confirmation toast reads 'Artifact version restored successfully' and the version is back in the Available state. The metadata, digest, and size are preserved.

"Artifact version restored successfully." The version is back. Same metadata, same digest, same size. As far as the downstream consumer is concerned, it never went away.

The safety promise. There is no hard-delete option in lifecycle rules. Even the most aggressive Cleanup rule can only soft-delete. Within the recovery window, every deleted version is one click away from restoration.

What Maya accomplished in one day

By the end of day one, Maya:

1. Set up automated cleanup across five package types.
2. Protected her formal releases with a Retention rule, so the cleanup can't touch them.
3. Verified every rule with dry-runs before letting them fire.
4. Adopted the org admin's centralized protect rule without losing project autonomy.
5. Scheduled real overnight execution and watched it work.
6. Demonstrated one-click recovery the moment somebody asked for an artifact back.

She didn't break production. She didn't delete the deployed image. She didn't have to manually triage which builds to keep. The system did what the docs promised, and her engineering org has a paper trail to show compliance if anyone asks.

The same machinery scales from a single demo project to a 270-service real customer registry. Same Retention rule pattern. Same Cleanup rule pattern. Same explicit-attachment hierarchy from project to organization to account scope.

As software delivery accelerates, artifact registries can no longer be passive storage systems. They need to actively govern what stays, what gets removed, and what is safe to promote. Lifecycle Rules are one part of a trusted software supply chain, working alongside provenance, vulnerability scanning, promotion policies, and artifact signing to ensure every artifact in your registry exists for a reason. By automatically retaining what matters, removing what doesn't, and enforcing policy before storage becomes operational risk, teams can deliver software faster without sacrificing security, reliability, or trust.

We invite you to sign up for a demo and see firsthand how Harness Artifact Registry delivers high-performance artifact distribution with built-in security and governance at scale.

Frequently asked questions

What's the difference between a Retention Rule and a Cleanup Rule?

A Cleanup Rule deletes artifact versions on a schedule based on age, version count, or download activity. A Retention Rule protects matching artifacts from any deletion. It's always evaluated first, and a match always wins over a deletion attempt. Use Retention for releases you never want touched, and Cleanup for dev, snapshot, and stale builds.

Does soft delete mean my artifact is gone forever?

No. Every artifact deleted by a Lifecycle Rule enters a recovery window. During that window, the artifact can be restored in one click from the Deleted tab of the artifact's detail view. There is no hard-delete option in Lifecycle Rules at all.

How do rules at the Organization or Account scope apply to my Project's registries?

They don't apply automatically. A rule created at any scope is visible to child scopes when you tick "Show policies from parent scope," but it only acts on registries it's explicitly attached to. The child-scope admin attaches the rule by selecting which of their registries it should apply to. Criteria and patterns inherited from the parent scope cannot be modified at the child scope.

Can I preview what a rule will delete before it actually runs?

Yes. Every Cleanup Rule has a Dry Run action in its three-dot menu. The dry run uses identical evaluation logic as the real run but mutates no data. It produces a per-version table showing PROTECTED versions and WOULD BE DELETED versions plus an estimated storage reclaim.

What happens if I stack multiple retention criteria on one Cleanup Rule?

Multiple criteria combine with AND logic. An artifact must satisfy every enabled condition to be deleted. This is conservative by design and is the main safety mechanism against accidental over-deletion. Use a single criterion when you want aggressive cleanup, and stack two or three when you want a safety net.

Which package types does this work with?

The feature works across all package types supported by Harness Artifact Registry: Docker, npm, Maven, Python, Helm, NuGet, RPM, Cargo, Go, Generic, and others. Filter fields adapt to the package type (Maven shows Group ID patterns, Docker shows tag patterns, etc.).

How do I get access to Lifecycle Rules?

Lifecycle Rules are currently behind the HAR_ARTIFACT_LIFECYCLE_POLICY feature flag. Contact Harness Support to enable it on your account.

Next steps

If your registry has been growing without a cleanup policy, the safest place to start is exactly where Maya did:

1. Identify your release version patterns (the artifacts you never want touched).
2. Create a Retention Rule with those literal version strings at your project scope.
3. Create a Cleanup Rule targeting dev or snapshot builds in one registry.
4. Run a Dry Run before saving a schedule.
5. Let it run for one week, then review the Executions tab to see what was cleaned up.

For full reference documentation, see the official Harness docs. The Harness CLI used to push artifacts in this guide is open source. 

If you set up Lifecycle Rules and something surprises you, the Harness team wants to hear about it. Reach out through the community Slack, the developer forum, or open an issue on GitHub.

Cloud cost visibility at scale usually works great… until it suddenly doesn’t.

At first, everything feels manageable. You can track spend by service. You know which team owns which resources. Reports are clean, and the numbers make sense.

Then one day, there’s a $47,000 spike spread across three AWS accounts that no one noticed for eleven days. Leadership wants answers. Engineering wants context. And your carefully designed tagging strategy? It turns out half the resources aren’t tagged correctly anymore.

This isn’t about carelessness. It’s about scale.

The systems and processes that work for one account, a few teams, and predictable workloads simply don’t hold up in a fast-growing, distributed, multi-cloud environment. What worked when you had 50 engineers doesn’t scale to 500. Tagging strategies that worked for ten microservices fall apart at a hundred. Manual reviews that felt reasonable in year one become overwhelming operational debt by year three.

Cloud cost management doesn’t fail because teams don’t care. It fails because the model never evolved.

Why Traditional Cloud Cost Visibility Breaks Down

Many organizations still treat cloud spending visibility the way they treated on-prem infrastructure: centralized reports, periodic reviews, and reconciliation after the invoice arrives.

But the cloud doesn’t behave like a static data center.

Infrastructure is provisioned with API calls. Workloads scale up and down automatically. Teams deploy multiple times a day. In that environment, monthly reporting isn’t just slow — it’s disconnected from reality.

1. Cloud Cost Allocation Challenges Multiply Fast

Cost allocation usually starts simple.

You tag an EC2 instance with a team name.
You assign an S3 bucket to a product line.
You map Kubernetes namespaces to cost centers.

Easy enough.

Then things get complicated.

Shared services support multiple teams. A single database might power ten applications. Load balancers route traffic across services owned by different squads. Now your allocation model depends on custom logic, judgment calls, and manual adjustments.

At scale, cloud cost allocation challenges aren’t just about missing tags. They’re about unclear ownership and constantly shifting boundaries.

Without strong FinOps governance and automated enforcement, tagging degrades over time. Trust in the numbers erodes. And once teams stop trusting the data, infrastructure cost transparency disappears.

2. Multi-Cloud Environments Create Fragmented Visibility

Multi-cloud cost governance sounds great in theory. In practice, it’s messy.

AWS, Azure, and GCP all have different pricing models, billing exports, and discount structures. Reserved Instances don’t map cleanly to Committed Use Discounts. Credits and savings plans behave differently. Even basic service naming varies.

Maintaining true cloud spending visibility across providers requires more than dashboards — it requires normalization and context.

Without a unified view, engineers working in AWS don’t see how their choices impact Azure costs. Data teams running BigQuery jobs aren’t aware of the downstream effect on shared networking or storage costs. Everyone optimizes within their silo, but total spend keeps growing.

Enterprise cloud cost optimization can’t happen in fragments. It requires shared visibility across environments.

3. Reactive Reporting Comes Too Late

By the time finance flags a cost spike, the root cause is buried.

The change that triggered it may be three sprints old. The engineer who made it might not even remember. The workload has already scaled, dependencies have grown, and what started as a small inefficiency is now baked into production.

Traditional cloud cost monitoring tools often operate at the billing layer. They tell you what changed — but not why.

Was the spike caused by a misconfigured NAT gateway? An inefficient query? A new feature launch? Increased traffic? The invoice doesn’t know.

Cloud cost visibility at scale requires linking cost signals to engineering context — deployments, configuration changes, usage patterns — before those signals turn into major overruns.

How to Restore Cloud Cost Visibility at Scale

The fix isn’t just better reports. It’s treating cost visibility as an engineering capability.

Cost needs to live inside workflows, not in a finance slide deck.

1. Automate and Deepen Cost Allocation

At scale, allocation can’t be a quarterly cleanup exercise.

You need automated rules that continuously map resources to teams, services, and business units. When something falls outside those rules, it should be flagged immediately — not discovered weeks later during reconciliation.

Strong FinOps governance means allocation is proactive, not reactive.

When teams see near real-time cost impact — through showback or chargeback — behavior changes. Engineers start asking better architectural questions. Optimization becomes part of daily decision-making, not an annual mandate.

2. Use Context-Aware Anomaly Detection

Not every spike is a problem.

A 200% increase during a product launch might be expected. A 200% increase on a quiet Tuesday afternoon probably isn’t.

Effective anomaly detection understands seasonality, traffic patterns, deployment schedules, and baseline behavior. It integrates with observability and CI/CD systems so that when costs change, teams can immediately see what else changed at the same time.

Cloud cost monitoring tools are most valuable when they connect cost signals directly to engineering activity.

3. Make Governance Proactive, Not Punitive

Waiting for an invoice to exceed budget doesn’t protect you.

Instead, set budget thresholds at the team and project level. Trigger approval workflows when provisioning exceeds expected spend. Automatically identify idle or non-compliant resources before they accumulate real cost.

Done right, governance doesn’t slow engineers down. It simply makes cost constraints visible early, when they’re still easy to manage.

How Harness Cloud Cost Management Supports Visibility at Scale

Harness Cloud Cost Management approaches cloud cost visibility at scale as a continuous engineering discipline, not a monthly accounting ritual.

It combines allocation, anomaly detection, and policy enforcement in a way that aligns with how modern teams actually work.

Unified Cost Visibility Across Clouds and Kubernetes

Harness brings AWS, Azure, GCP, and Kubernetes data into a single, consistent view. Engineers can analyze spend by team, namespace, workload, or service without switching dashboards or reconciling inconsistent billing exports.

This unified approach strengthens multi-cloud cost governance while improving infrastructure cost transparency across the organization.

Cost Allocation That Matches Real Ownership

Harness automates allocation using tags, labels, hierarchies, and usage data that reflect how teams structure their work. Shared services and multi-tenant infrastructure are distributed based on actual consumption — not static assumptions.

When allocation logic changes, it updates system-wide. No spreadsheets. No manual reconciliation.

Context-Driven Anomaly Detection

Harness correlates cost spikes with deployments, configuration changes, and infrastructure events. Instead of simply highlighting that spend increased, it surfaces the engineering activity likely responsible.

That’s what makes cloud cost monitoring tools actionable — not just informative.

Governance That Enables Speed

Harness supports budget policies, approval workflows, and automated lifecycle management that prevent overruns without introducing bottlenecks.

Teams keep their autonomy. Finance keeps predictability. Everyone shares visibility.

Learn more about how Harness approaches cost visibility and governance at:
https://www.harness.io/products/cloud-cost-management

Detailed implementation guidance is available at:
https://developer.harness.io/docs/cloud-cost-management

Visibility Creates a Cost-Aware Engineering Culture

Cloud cost visibility at scale isn’t really about dashboards.

It’s about alignment.

When engineers see cost impact in context, when allocation reflects real ownership, and when guardrails are proactive instead of reactive, cost awareness becomes part of the culture.

Without that, organizations fall into a cycle of surprise invoices, reactive firefighting, and growing tension between finance and engineering.

Visibility alone won’t solve cloud cost problems. But without it, enterprise cloud cost optimization is almost impossible.

If your current cloud cost management strategy still revolves around monthly reports and manual reconciliation, the real question isn’t whether you need better dashboards.

It’s whether your engineers have the cost signals they need at the exact moment they make decisions that drive spend.

Most teams know how to run a disaster recovery test. Few know how to run a DR program. The gap between the two is what separates organizations that survive incidents from those that scramble through them.

A single test gives you a snapshot. A program gives you a trajectory. It is proof that your resilience is improving over time, evidence for auditors, and the operational muscle to recover predictably when something goes wrong.

If you haven't read the earlier posts in this series, start with our introduction to disaster recovery testing for the fundamentals, and the step-by-step DR testing guide for the operational playbook. This post builds on both, focusing on best practices, automation, and metrics that show whether your program is actually working.

From Ad Hoc Testing to a Mature DR Program

Most DR programs evolve through four stages. In the ad hoc stage, tests happen reactively, usually after an incident or before an audit. In the scheduled stage, tests follow a calendar but still rely heavily on manual coordination. In the automated stage, recovery procedures are codified and validated through pipelines. In the continuous stage, resilience is measured constantly, and improvements compound.

Mature programs aren't just faster. They're cheaper, more auditable, and more reliable under pressure. They produce documented evidence on demand, surface configuration drift before it causes outages, and turn DR from a quarterly fire drill into a steady operational practice.

The rest of this blog walks through the practices and metrics that get you there.

Establish a Risk-Aligned Testing Schedule

Testing every system at the same frequency wastes resources and burns out teams. The most effective programs match testing depth and cadence to business risk.

Critical services

• Quarterly or semiannual operational tests that exercise the full recovery path
• Monthly automated validations to catch drift between major exercises
• Annual full-scale simulations that include cross-functional teams and external dependencies

Moderate tiers

• Semiannual tabletop exercises or simulations
• Quarterly restore tests in isolated environments to verify backup integrity
• Targeted failover drills for individual components or services

Lower tiers

• Periodic tabletop exercises focused on process and communication
• Component-level checks tied to deployment or configuration changes

Stagger tests across business units to avoid resource bottlenecks. If every team runs a full failover in the same week, no one gets meaningful results. The goal is consistent coverage across the year, not a flurry of activity right before an audit.

The principle underneath all of this is simple. Invest more testing rigor in systems where downtime hurts the most. A risk-aligned schedule keeps your highest-impact systems sharp without exhausting the teams that maintain them.

Continuously Incorporate Lessons Learned

Every test produces data. Mature programs turn that data into changes: runbook updates, dependency fixes, process improvements. Immature programs file the report and move on.

Three practices separate the two:

• Maintain a living knowledge base of incidents and test outcomes, including playbook revisions, updated dependency maps, and contact list changes
• Convert lessons into measurable action items with named owners and due dates. Vague "we should improve X" notes don't get resolved
• Use regression tests to confirm fixes hold and that environmental changes haven't reintroduced old issues

The discipline here matters. Tests that don't produce closed action items are theater. Tests that close items but don't verify the fixes worked are wishful thinking. The combination of capture, act, and verify is what builds genuine resilience over time.

Another underrated practice: share lessons across teams. A failure mode discovered in one service often exists in others. Building a culture where DR learnings circulate widely turns each test into organizational improvement, not just team improvement.

Leverage Automation and Modern Tooling

Automation is what makes the difference between a DR program you can sustain and one that quietly atrophies. Manual coordination doesn't scale, and tests that depend on hero effort eventually stop happening.

Modern programs build automation across four layers:

Recovery as Code

Codify your recovery procedures using infrastructure-as-code templates, configuration management tools, and CI/CD integration. When recovery steps live in version control, they're reviewable, repeatable, and resistant to drift. Treat your DR pipelines like any other production code, with tests, reviews, and change management.

Automated Backup Verification

Backups that haven't been restored are unverified. Automate routine restores into isolated sandboxes and run integrity checks on the restored data. The point isn't just to confirm files exist. It's to confirm the data is usable for recovery.

Chaos Engineering

Apply chaos engineering selectively to validate failure domains and surface hidden service-to-service couplings. Start with controlled experiments in non-production environments, then graduate to production once teams trust the process. The goal is to find weaknesses in your schedule, not in the attacker's or the cloud provider's.

Observability and Multicloud Orchestration

Use observability platforms to capture metrics, logs, and traces during tests. This is your evidence trail for audits and your debugging trail for after-action reviews. For hybrid and multicloud environments, adopt orchestration tools that coordinate failovers across clusters, regions, and providers. The operational complexity is too high to manage by hand.

How Harness Brings This Together

Building each of these capabilities separately is expensive and slow. Harness Resilience Testing consolidates chaos testing, load testing, and disaster recovery testing into a single platform that plugs into your existing pipelines.

Instead of stitching together separate tools for chaos experiments, load generation, and failover validation, teams orchestrate the full resilience workflow in one place. Recovery steps run as pipeline stages. Chaos experiments and load tests share the same environment, evidence trail, and reporting. The Harness Resilience Testing documentation walks through how to set this up end-to-end, including integration with existing CI/CD workflows.

The result is a DR program that fits naturally into how engineering teams already work. That is the single biggest predictor of whether a program gets sustained over time.

Align with Security, Compliance, and Legal

DR testing isn't just an engineering concern. It intersects with security policies, compliance frameworks, and legal obligations, and mature programs treat those teams as partners, not afterthoughts.

Map your test evidence to the control frameworks that apply to your business. ISO 22301, NIST SP 800-34, HIPAA, and PCI DSS all have specific requirements for documented testing, evidence retention, and remediation tracking. Aligning your evidence capture with these requirements up front saves enormous time at audit.

Ensure data handling in test environments complies with privacy and retention policies. Production data in non-production systems is a common audit finding, even when used for legitimate recovery validation. Use synthetic or properly masked data when possible.

Coordinate with legal and communications teams for customer-facing test scenarios and any required external notifications. If a test could trigger customer-visible behavior or contractual obligations, the conversation needs to happen before the test, not after.

Finally, don't forget SaaS and managed services. Many critical workloads depend on third-party providers whose recovery capabilities you can't directly control. Validate that contractual recovery promises actually hold by testing them. Verify contact paths, escalation procedures, and any vendor-side failover commitments.

Track Metrics That Actually Matter

If you can't measure your DR program, you can't improve it. The right metrics turn DR from a series of one-off exercises into a function with clear performance signals.

Track these across every test cycle:

Recovery Time Performance

Time to initiate recovery and time to restore services, measured against your RTO targets. Trend these over time. A program is improving if the gap between the target and the actual closes. Persistent gaps point to runbook problems, automation gaps, or unrealistic targets that need revisiting.

Data Loss vs. RPO

Measure actual data loss against your RPO and check for any integrity discrepancies in restored data. RPO is often treated as theoretical, just a metric on a slide deck. Real testing turns it into an operational number you can defend.

Automation Coverage

Track the number of manual interventions per test and the trend in that count. Manual steps are where tests slow down and where they break under stress. A healthy program steadily replaces manual coordination with automated workflows.

Remediation Health

Defect recurrence rates and closure times for action items tell you whether your lessons-learned process is actually working. If the same issues keep surfacing across tests, the after-action discipline isn't yet in place. If items take months to close, ownership and prioritization need attention.

Customer Impact Indicators

During tests, capture error rates, latency, and any degradation in user experience. Even in controlled exercises, these indicators reveal blind spots in your recovery design. They show you places where the system technically recovers, but the customer experience suffers.

Review these metrics regularly. Quarterly is typical for most teams. Dashboards help, but the discussion matters more than the visualization. Trends matter more than snapshots. And every metric should connect to a specific improvement initiative. Tracking numbers nobody acts on is just noise.

Resilience Is a Compounding Discipline

A mature DR program isn't built in a single quarter. It's built through small improvements that compound over time: sharper runbooks, more automation, faster recovery times, cleaner audit evidence. Each cycle should make the next one easier and more revealing.

The best programs treat resilience as a competitive advantage, not compliance overhead. They recover faster than their competitors. They demonstrate trust to customers, regulators, and insurers with documented evidence. They give engineering teams the confidence to ship faster because the safety net is real.

If you're just starting out, return to the basics with our introduction to disaster recovery testing, or work through the operational playbook in the step-by-step DR testing guide. And whenever you're ready to consolidate chaos testing, load testing, and DR testing into a single platform, Harness Resilience Testing is built to make that consolidation straightforward.

Harness shipped 71 features in July, about one every 10 hours. That's more than June's 62, and the surge lines up with what AI is doing to the rest of the SDLC: coding agents are writing more of the code, test agents are now generating and running more of the tests by default, and every stage downstream: deployment, security, cost, and resilience has to absorb that pace without falling over.

This month's list runs from a canary strategy for Kubernetes to a test execution engine that's agentic by default to an AI bill of materials tracking components nobody was cataloging six months ago, and on top of all of it, Harness extended the entire platform to cover how agents themselves get built and shipped. Here's everything we shipped.

This month's biggest ships

Harness Agent DLC: We extended our platform to cover the full agent lifecycle, build, test, store, deploy, operate, and govern, so teams ship AI agents through the same pipelines, policies, and audit trails they already use for every other service.

One command line for humans and agents: Harness CLI is a single binary, with one command grammar and one auth flow across pipelines, CD, Harness Code, Artifact Registry, Infrastructure as Code Management, feature flags, governance, and audit. It's now in public beta, and it's built to be driven by an AI agent as reliably as by a person typing at a terminal.

AI DLC Insights starts tying AI spend to outcomes: New session-level insights, PR and work-item attribution, and multi-layer developer identity resolution let engineering leaders see which developer, which AI agent, and which token spend produced which shipped work, with Cursor now joining Claude Code and GitHub Copilot as a supported source.

‍

Here are the details:

Agent DLC brings the SDLC to AI agents

Agents don't behave like regular software: the same input can produce a different output twice, because the model underneath is deciding how to complete the task instead of running fixed code. That breaks the build-test-deploy playbook that took a decade to get right for applications. Harness Agent DLC extends the same platform used for services today to build, test, store, deploy, operate, and govern AI agents too, so a team doesn't need a separate toolchain just because the thing they're shipping is an agent instead of a service. Agents get built the same way services do, through Harness Continuous Integration, but testing needed new tools: Harness AI Evals scores agent output for correctness, performance, and safety and can gate a CD pipeline on the result, while AI Test Automation validates an agent through its actual chat interface using plain-English assertions instead of API hooks.

Everything downstream got the same treatment. Harness Artifact Registry now tracks the definitions, prompts, skills, MCP servers, models, and policies an agent is built from, with full version history. Agent Deployments extends Continuous Delivery's canary releases and approval gates to managed runtimes like Amazon Bedrock AgentCore and Google's Agent Runtime, governed by the same OPA policies as any other deployment. Cloud and AI Cost Management now attributes spend to individual agents and models, and a new AI Configs capability lets teams change prompts and models at runtime through the same feature flag infrastructure, with instant rollback. On governance, a new AI Asset Catalog auto-discovers and assigns owners to every agent, skill, and plugin, and security runs through the whole lifecycle: Primitive Scanning and an extended AI Bill of Materials catch risk before an agent ships, Harness AI Testing probes for adversarial behavior across the OWASP Top 10 for LLMs, and Agent Discovery, Posture Management, and a new AI Firewall watch agents once they're live. A new AgentTrace layer captures execution at the run and session level across all of it, and Harness is open-sourcing its foundational SDKs, harness-sdk and harness-evals, so teams can use the same tracing and eval primitives outside Harness. Learn more about Harness Agent DLC.

One CLI for humans and agents

Harness CLI 3.0 is now in public beta, and it replaces every per-module CLI Harness has shipped with one binary, one command grammar, and one auth flow. Every command follows the same shape, a verb, a noun, and an identifier, across pipelines, CD, Harness Code, Artifact Registry, Infrastructure as Code Management, feature flags, governance, and audit, so learning one command teaches you all of them. That consistency matters as much for AI agents as for people: the CLI exposes a closed, enumerable grammar and structured output in table, JSON, CSV, and several other formats, so an agent can predict what a command will return and chain it into a workflow instead of guessing at the shape of the output. It's fully open source under Apache 2.0. Learn more about the Harness CLI.

Worker Agents get scoped tokens, a graded marketplace, and more context

We launched Autonomous Worker Agents last month. Worker Agents running in step groups and stages now get scoped tokens instead of a broad session credential. You declare exactly which resources and verbs a stage needs, and Harness mints a token bound to that scope for the run, then discards it. Learn more about scoped tokens for Worker Agents.

Harness now offers managed LLM connectors for Anthropic and OpenAI, running on Harness Cloud through AWS Bedrock. There's no separate API key to provision or rotate: Worker Agents reach the models through the Harness LLM Gateway, and access is controlled the same way any other platform permission is.

The Worker Agent Marketplace picked up a real taxonomy. Agents now show up as Managed, Verified, or Community, so a team browsing the catalog knows whether they're installing something Harness built and supports, something a trusted partner built that's been reviewed, or something the community contributed that hasn't gone through review yet.

Harness AI Chat can now reach third-party MCP connectors directly. Attach a connector for GitHub, GitLab, Jira, or any custom MCP server, and the assistant pulls context from those systems inside the same conversation instead of you copying data back and forth between tools.

AI-SRE's root cause analysis can now factor in Worker Agent and pipeline outputs alongside its built-in investigation logic, so teams can extend what the AI Investigator reasons over with their own data sources and domain-specific logic, without waiting on a Harness release.

AI takes on more of the SDLC and starts grading its own work

AI Test Automation now runs every test through a new agentic execution engine by default. The "Create Test with AI" workflow got a matching overhaul, so generating a test and running it both go through the same agent-driven path instead of two disconnected steps.

AI DLC Insights added Cursor as a supported source, joining Claude Code and GitHub Copilot. Whichever AI coding tool a team standardizes on, or however many they mix, the same instrumentation now covers it. A new AI Session Insights view gives engineering managers session-level detail on how their developers actually use AI tools, not just adoption counts, so managers can coach specific habits instead of guessing from an aggregate percentage. PR and work-item level attribution now connects individual AI token spend to the pull request and work item it produced, and multi-layer developer identity resolution ties usage back to the right person across whichever AI coding agent they used. Together, that's the difference between knowing an org spent money on AI and knowing which developer, which agent, and which PR that money turned into.

Deployments that flex without a rewrite

Kubernetes deployments now support a dedicated canary strategy that rolls a new version out in percentage-based phases, 25%, then 50%, then 100%, while Harness holds the total pod count to a fixed budget by shifting replicas between two Deployments. Verification or approval gates sit between each phase, so a bad rollout gets caught at 25% instead of 100%. Learn more about Canary Deployments for Kubernetes.

Post-production rollback now works in bulk. From the service dashboard, you can select multiple infrastructures where a service is deployed, choose the target execution for each one, and roll them all back together instead of walking through each infrastructure one at a time.

AWS Auto Scaling Group deployments got smarter about what they touch. Redeployments now compare lifecycle hooks, scaling policies, scheduled actions, load balancers, and target groups against your configuration and update only what changed, instead of deleting and recreating the group and losing in-flight instances in the process. ASG deployments also now support MixedInstancesPolicy, letting AWS pull from multiple instance types automatically, including spot instances with automatic fallback when capacity runs short, while Harness keeps the launch template version in that policy current across deployments.

A handful of other delivery upgrades this month: the Shell Script step can now declare named identities and get an independent OIDC ID token injected for each one at runtime, so a script authenticates as the workload itself instead of through a connector; the Kubernetes cluster connector supports the client credentials OIDC grant type for machine-to-machine access, useful for clusters fronted by Microsoft Entra ID; AWS CDK steps can now run on ECS-based delegates instead of requiring a Kubernetes delegate runtime; Google Cloud Run and GKE deployments support pause and rollout control, so you can deploy without traffic, shift a percentage, validate, and gate the rest behind manual approval; monitored service configurations can now live in Git through the new Git Experience; and Kubernetes Blue Green rollbacks now automatically scale the previous stable deployment back up so traffic actually has active pods to route to.

Security and supply chain for a world of AI-generated code

Harness Supply Chain Security can now generate an AI Bill of Materials, cataloging the models, datasets, agents, frameworks, and libraries embedded in a repository the same way an SBOM catalogs open-source packages. Traditional SBOMs miss all of this. As AI components spread through codebases faster than most security teams can inventory them by hand, that gap is becoming the more urgent one. Learn more about AI Bill of Materials support.

Security Testing Orchestration now supports bulk exemption requests. Teams managing findings at scale can request exemptions for multiple vulnerabilities in a single action instead of filing one at a time. Learn more about bulk exemption requests.

Supply Chain Security now runs inside GitLab CI pipelines directly, with reusable templates for generating SBOMs, creating SLSA provenance, signing artifacts, verifying attestations, and enforcing security policies, all without leaving GitLab. Learn more about GitLab CI support for SBOM, SLSA, and artifact signing.

API Security Testing picked up three upgrades this month. The Traceable MCP Server now supports AI Security assets and issues, so teams running an AI Security proof of concept can generate a full AI Security posture report straight from a customer environment using Claude Desktop or any other MCP-compatible client. Scans also gained plugin-level visibility into execution, coverage, and performance for every API tested, and a new alerting framework lays the foundation for flexible, granular alert conditions across the platform. Learn more about generating AI Security Value Reports with the Traceable MCP Server.

The developer portal gets sharper eyes and fewer clicks

The Internal Developer Portal overview now shows each user a view tailored to their role. Developers, platform engineers, and engineering leaders see different cards by default, and platform admins configure the layout per view and assign it to the right user groups instead of shipping one generic dashboard to everyone.

OPA policy enforcement now covers every catalog entity, not just environments. Platform engineers can write Rego policies that block or warn on non-compliant entities at save time, enforcing naming conventions, ownership requirements, and lifecycle standards across the whole catalog instead of one corner of it.

Teams migrating off Backstage can now import catalog-info.yaml files directly from GitHub and Bitbucket, and the integration converts those entity definitions into the Harness IDP format automatically. No manual re-entry of everything Backstage already knew about your services.

Smaller catalog upgrades round out the month: the Kubernetes integration now supports a persistent agent mode for near real-time resource updates alongside the existing cron mode, with a new Kubernetes tab on entity detail pages showing workloads, pods, nodes, and containers; the portal now parses OpenAPI specs automatically and surfaces individual endpoints as structured metadata that external tools can enrich with risk scores or ownership tags through the Catalog Custom Properties API; the Discovered tab can bulk-select and import every service recommended for merge or registration in one click instead of one at a time; and accounts with outbound network restrictions can now route sync traffic through their own vanity URL instead of the default Harness endpoint. Learn more about routing sync traffic through your vanity URL.

Infrastructure as code adds real guardrails

Infrastructure as Code Management now includes native Ansible configuration management, bringing provisioning and configuration into one governed workflow instead of handing configuration off to a separate tool once the infrastructure exists. Learn more about native Ansible configuration management.

AWS CDK provisioning, in beta, picked up Drift and Destroy steps, a dedicated approval step, and expanded language support, closing gaps between what CDK could do standalone and what it could do inside a governed Harness pipeline. Learn more about AWS CDK Phase.

Module Registry versions were previously all treated as equally supported, with no way to flag one as outdated. A new lifecycle rule, in beta, automatically classifies each module version as Supported, Update Required, or Deprecated based on how recent it is, configurable from the Lifecycle Management tab on any module.

Cloud and AI cost management gets more precise

AI Perspectives can now drill down by Principal into Provider, Sub Provider, Sub Account ID, Model, and Token Type, so teams can trace AI spend to the specific account and model generating it instead of stopping at a vendor-level total. Learn more in the Cloud and AI Cost Management release notes.

The Overview page can now be filtered by cost category, and most tiles respect the filter (optimization tiles are the exception). The Anomalies widget on that page picked up a time series chart and a count of stale anomalies, and the Budgets widget got a clearer read on status.

Commitment Orchestration now supports Database Savings Plan purchases for RDS across the Actions, Approvals, and Inventory views, so teams can track and approve those commitments the same way they already handle other savings plans.

A few smaller fixes rounded out the month: AI chat quick actions now match whichever cost experience you're in, offering "Create a View" in Cost Explorer or "Create a Perspective" in the classic experience instead of one generic label; Cluster Orchestrator schedules show a live status badge and countdown for each schedule; and Perspectives now display clearer badges for external data sources like Snowflake, so it's obvious at a glance which numbers came from where.

Database changes ship like code, and reach further

Database DevOps pipelines can now pin a database instance to a specific git SHA instead of always tracking the latest commit on a branch, useful for teams that need a migration to run against an exact, audited version of a schema.

Database DevOps now supports Google Cloud Bigtable, so teams can manage schema changes and migrations for Bigtable workloads through the same workflows they already use for other databases. Learn more in the Database DevOps release notes.

Two reliability fixes round out the month: custom Database DevOps pipelines can now configure reserved parameters without manual encoding, and long-running Google Cloud migrations now refresh their OIDC token automatically instead of risking an authentication failure partway through.

Artifact Registry grows into more of the deployment path

Harness Artifact Registry now supports three more package types: Puppet, Debian, and a new Helm HTTP registry type that hosts and serves Helm charts through the classic helm repo add and helm pull workflow. Unlike the existing Helm OCI registry, Helm HTTP speaks the protocol most Helm repositories still use, with upstream proxy pull-through for public repos. Learn more about the new Artifact Registry package types.

Continuous Delivery can now deploy Raw File artifacts from Artifact Registry directly to WinRM targets, so a .zip package or other file stored in a Raw File registry reaches a Windows target without a third-party artifact connector in between. Learn more in the Artifact Registry release notes.

Run steps inside a containerized Step Group can now pull images straight from Harness Artifact Registry, no Docker connector required. Set the registry type to Artifact Registry, pick the registry and image, and the step runs against it natively.

Resilience testing catches more before it becomes an incident

Resilience Testing shipped a prompt library that turns the entire chaos-testing lifecycle into copy-paste prompts for Cursor, Claude Desktop, Windsurf, or any MCP-compatible client, with a builder for filling in service names, environments, and tolerance thresholds. Learn more about the Resilience Testing prompt library.

Services can now onboard with their own custom chaos service agent instead of going through discovery-based onboarding only, giving teams a second path for services that don't fit the standard discovery flow. Learn more in the Chaos Engineering release notes.

Load testing picked up several upgrades this month: tests can now be linked to a service directly from the UI, image registry support spans the frontend, backend, and DDCR so runs can pull images from your own registry; JMeter load profiles now enforce consistent user counts, duration, and ramp-up across script, zip, and custom-image modes, and both the load step and composite load stage now run through templates instead of inline configuration.

Chaos dashboards now render natively instead of through an embedded view, and pipeline scans got dedicated list, detail, and scanned-risks pages so results are reviewable directly in the UI instead of buried in a run log.

A handful of smaller onboarding and API upgrades round out the month: infrastructure type selection during service onboarding associates a service with the right infrastructure from the start; probe tuning can now inherit inputs from a linked Chaos Service instead of requiring re-entry; the Enterprise ChaosHub added ready-made Datadog health-check probe templates; a new API lists every service associated with a given probe identity; experiment YAML can reference a specific service inside a probe reference; and a redundant validation check during network map and service creation was removed.

Smaller updates that still save time

Access management got a couple of real conveniences: Resource Groups and Access Control roles can now be cloned directly from the UI, so a new role or scope starts from an existing baseline instead of from scratch. Dynamic GCP Secrets Manager references also gained project ID support, so a JEXL expression can pull a secret from a different GCP project than the one the connector lives in. Learn more about GCP Secrets Manager project ID support.

Two smaller updates rounded out July: code comments in Harness Code Repository now support emoji reactions, and Feature Management & Experimentation added a bucketingKey column to Amazon S3 impression exports, making it easier to validate consistent treatment assignment and analyze account-level rollouts.

The pattern

Seventy-one features in 31 days, about one every 10 hours! The velocity story this month isn't just that Harness shipped more. It's what got shipped: an entire lifecycle framework for building and running AI agents themselves, attribution that ties AI token spend to the pull request it produced, and a scoped-token system for the Worker Agents already running in production pipelines. AI is doing more of the actual work this month, writing tests, running them, triaging security findings, and the platform underneath it is building the guardrails and the receipts to match. June put Worker Agents into the pipeline. July gave them a permission system, gave the entire agent lifecycle a home in the same platform as everything else, and gave engineering leaders a way to see exactly what all of it is producing.

‍

We'll be back in August with more of it!

‍

As organizations ship software faster than ever, runtime behavior changes are becoming just as frequent as code releases. Teams need a way to update application behavior without waiting for code deployments while maintaining visibility, governance, and control.

‍

Now available in beta, Config Management provides a governed runtime control plane that separates runtime configuration from application deployments, enabling organizations to deliver configuration changes instantly across environments.

With Config Management, teams can:

• Change runtime values without redeploying applications
• Manage configurations across development, staging, and production
• Deliver configuration changes instantly through Harness SDKs
• Govern every configuration change with enterprise controls

Why Runtime Configuration Matters Today

Runtime configuration separates application logic from the values that control application behavior. Instead of embedding operational values directly into source code:

const maxRetries = 3;
const timeout = 5000;

Applications retrieve those values dynamically at runtime:

const maxRetries = client.getConfig("maxRetries"); 
const timeout = client.getConfig("timeout");

Changing a retry limit, timeout threshold, or feature parameter no longer requires a pull request, application rebuild, or production deployment. Teams can update the configuration on the Configs page, and the application receives the latest value through the Harness FME Configs SDK.

This enables organizations to iterate on application behavior at the speed their business requires, rather than at the speed their deployment pipeline allows.

Manage runtime configurations from a single project

Available today in beta, Config Management provides a centralized place to create, organize, and govern runtime configurations across your applications. The Configs page in Harness FME allows teams to search existing configurations, filter them by traffic type or tags, and quickly identify ownership across engineering and product teams.

Rather than scattering runtime values across source code, configuration files, or environment variables, Config Management centralizes application behavior into a single governed inventory that teams can manage collaboratively.

Creating a new configuration is equally straightforward. Clicking Create config opens a guided workflow where you define the configuration's name, immutable identifier, traffic type, owners, and one or more initial variations.

Each configuration begins with a shared structure that can later be delivered differently across environments. By defining variations up front, teams can prepare multiple runtime behaviors for targeted rollout and experimentation without changing application code.

Runtime control across the software delivery lifecycle

Harness provides dedicated capabilities for managing runtime behavior throughout the software delivery lifecycle.

One platform, complementary capabilities

Each capability answers a different question:

Altogether, these capabilities provide a unified platform for progressively releasing features, managing runtime behavior, monitoring production health, and validating outcomes through experimentation and warehouse native analytics.

Enterprise-grade configuration management

Configuration changes can have just as much impact on customers as application releases. Adjusting a retry count, modifying a pricing threshold, or changing a production timeout can immediately affect reliability, performance, and customer experience.

Config Management applies enterprise governance directly to runtime configuration.

Teams can:

• Require approvals before production changes
• Track every configuration change through version history
• Audit who changed what and when
• Validate configuration schemas before deployment
• Monitor configuration impressions through runtime evaluation
• Deliver configuration updates instantly through the Harness Configs SDK

Organizations have the flexibility to configure at runtime without sacrificing governance or operational control. 

Common use cases for Config Management

Optimize application behavior

Control customer-facing behavior without modifying application code. Runtime configuration allows product teams to independently adjust purchase thresholds, UI messaging, onboarding flows, and checkout experiences.

For example, in a checkout experience:

{
  "type": "object",
  "properties": {
    "bannerMessage": {
      "type": "string"
    },
    "freeShippingThreshold": {
      "type": "number"
    },
    "discountPercent": {
      "type": "number"
    },
    "showCountdownTimer": {
      "type": "boolean"
    },
    "maxCartItems": {
      "type": "integer"
    }
  },
  "required": [
    "bannerMessage",
    "freeShippingThreshold",
    "discountPercent",
    "showCountdownTimer",
    "maxCartItems"
  ]
}

Default Variation

{
  "bannerMessage": "Free shipping on orders over $75",
  "freeShippingThreshold": 75,
  "discountPercent": 0,
  "showCountdownTimer": false,
  "maxCartItems": 50
}

Free Shipping Variation

{
  "bannerMessage": "Free shipping on orders over $50",
  "freeShippingThreshold": 50,
  "discountPercent": 0,
  "showCountdownTimer": false,
  "maxCartItems": 50
}

Holiday Sale Promotion Variation

{
  "bannerMessage": "🎉 Holiday Sale! Save 20% today only",
  "freeShippingThreshold": 35,
  "discountPercent": 20,
  "showCountdownTimer": true,
  "maxCartItems": 75
}

Without redeploying the application, teams can adjust purchase thresholds, customer messaging, and operational limits independently for each environment.

Improve operational performance

Tune operational parameters in production without redeploying applications. Runtime configuration enables engineering teams to respond quickly to production conditions by adjusting retry policies, timeout thresholds, cache durations, and resource limits.

For example, in API Runtime Settings:

{
  "type": "object",
  "properties": {
    "maxRetries": {
      "type": "integer"
    },
    "requestTimeoutMs": {
      "type": "integer"
    },
    "cacheTtlSeconds": {
      "type": "integer"
    },
    "circuitBreakerEnabled": {
      "type": "boolean"
    }
  }
}

Default Variation

{
  "maxRetries": 3,
  "requestTimeoutMs": 5000,
  "cacheTtlSeconds": 300,
  "circuitBreakerEnabled": true
}

High Load Variation

{
  "maxRetries": 2,
  "requestTimeoutMs": 3000,
  "cacheTtlSeconds": 120,
  "circuitBreakerEnabled": true
}

Maintenance Variation

{
  "maxRetries": 1,
  "requestTimeoutMs": 1500,
  "cacheTtlSeconds": 60,
  "circuitBreakerEnabled": false
}

Iterate through experimentation

Experiment with runtime behavior by serving different configuration values to different audiences. Combined with Feature Management and Cloud Experimentation, Config Management enables teams to compare experiences without changing application code.

For example, in an onboarding experience:

{
  "type": "object",
  "properties": {
    "welcomeHeadline": {
      "type": "string"
    },
    "showTutorial": {
      "type": "boolean"
    },
    "requiredSteps": {
      "type": "integer"
    }
  }
}

Control Variation

{
  "welcomeHeadline": "Welcome!",
  "showTutorial": false,
  "requiredSteps": 5
}

Guided Onboarding Variation

{
  "welcomeHeadline": "Let's get you started.",
  "showTutorial": true,
  "requiredSteps": 3
}

Express Onboarding Variation

{
  "welcomeHeadline": "You're ready to go!",
  "showTutorial": false,
  "requiredSteps": 2
}

Target different configuration values to specific users or environments to compare onboarding experiences, pricing thresholds, UI copy, or application workflows.

Prepare for AI-powered applications

Treat prompts, model selection, and inference parameters as runtime configuration rather than hardcoded application logic. Teams can iterate on AI behavior, roll back prompt changes, and experiment with different models without redeploying applications.

For example, in an AI assistant configuration:

{
  "type": "object",
  "properties": {
    "systemPrompt": {
      "type": "string"
    },
    "model": {
      "type": "string"
    },
    "temperature": {
      "type": "number"
    },
    "maxTokens": {
      "type": "integer"
    }
  }
}

Default Variation

{
  "systemPrompt": "You are a helpful customer support assistant.",
  "model": "gpt-4.1",
  "temperature": 0.4,
  "maxTokens": 1000
}

Creative Variation

{
  "systemPrompt": "You are an enthusiastic product expert.",
  "model": "gpt-4.1",
  "temperature": 0.9,
  "maxTokens": 1500
}

Cost Optimized Variation

{
  "systemPrompt": "You are a concise support assistant.",
  "model": "gpt-4.1-mini",
  "temperature": 0.2,
  "maxTokens": 500
}

The foundation of AI Config Management

As Config Management continues to evolve beyond its beta release, it also provides the foundation for AI Config Management. As AI-powered applications become increasingly dynamic, teams need the same runtime control over AI behavior that they already require for traditional software. 

Config Management provides the foundation for managing AI-specific configurations, including prompts, model selection, inference parameters, and agent behavior. 

Rather than embedding these decisions directly into application code, teams can govern, target, and evolve AI behavior through the same runtime configuration platform. 

Get started with Config Management today

Whether you’re tuning application behavior, optimizing operational performance, or preparing for AI-powered workloads, Config Management enables teams to safely evolve production behavior without waiting for code deployments.

To get started, create a config in Harness FME, define its JSON schema and variations, initialize environment-specific values and targeting rules, promote validated configurations across environments, and integrate a Configs SDK to retrieve runtime values from your application. 

As your application begins serving configurations, you can monitor evaluations in real time with Live Tail to verify targeting behavior and troubleshoot runtime configuration issues. For more information, see the Config Management beta documentation. If you’re new to Harness, sign up for a free trial today.

Modern applications do not just depend on schema changes. They also depend on data that powers the application itself.

Things like dropdown values, feature flags, country codes, user roles, pricing tiers, workflow statuses, or internal configurations are often stored inside database tables. This is called reference data. Even though this data may look small, it is critical to the application. A wrong value can break workflows, show incorrect information to users, or create production issues.

In this blog, we will look at a clean and safe way to manage reference data updates using Harness Database DevOps with Liquibase OSS compatible changelogs. We will also see how to safely roll back data changes when something goes wrong.

Why Reference Data Needs Version Control

Many teams still update reference data manually.

Someone runs an SQL update in production. Another person edits rows directly from a database UI. Sometimes CSV imports happen without tracking.

This creates several problems:

• Nobody knows who changed the data.
• There is no rollback process.
• Different environments become inconsistent.
• Testing becomes difficult.
• Deployments become risky.

Over time, this also creates environment drift between development, staging, and production databases.

Database DevOps solves this by treating reference data like application code. Where the data lives in Git and the changes are reviewed through pull requests. Database deployments take place through pipelines and rollback workflows become predictable.

This gives teams consistency, governance, and traceability across every environment.

A Better Pattern for Managing Reference Data

One of the safest patterns for updating reference data is:

1. Store reference data inside versioned CSV files
2. Commit those files to Git
3. Use the loadUpdateData change type
4. During deployment, apply the new CSV version
5. During rollback, deploy the previous CSV version

This approach works especially well for database CI/CD and database deployment automation workflows. It also aligns nicely with GitOps-style database management where every change is versioned and auditable.

For example, the Harness community maintains a Terraform onboarding template that helps teams provision and onboard Harness Database DevOps resources directly from CSV files.

Real-World Examples of Reference Data

Teams commonly use this pattern for:

• Product pricing tiers
• Feature flags
• Internal application settings
• Country and currency mappings
• Approval workflow statuses
• Lookup tables used by frontend applications

These datasets are often tightly connected to application behavior, which makes safe deployments and rollback strategies extremely important.

Example Scenario

Imagine your application has a table called subscription_tiers. The application reads values from this table to display pricing plans inside the UI.

Your current data looks like this:

Now your product team wants to add a new Enterprise tier with help of subscription_tiers-v2.csv. Instead of manually inserting rows into production, we can version this data properly.

Step 1: Store Data in Versioned CSV Files

Inside your repository, create a folder for reference data.

reference-data/
├── subscription_tiers-v1.csv
├── subscription_tiers-v2.csv

The version suffix is important, this makes deployments predictable and makes rollback much easier and teams can quickly identify which dataset version was deployed to each environment.

Step 2: Use loadUpdateData

Now create a Liquibase OSS compatible changelog YAML file.

databaseChangeLog:
  - changeSet:
      id: subscription-tier-v2
      author: animesh
      changes:
        - loadUpdateData:
            file: reference-data/subscription_tiers-v2.csv
            tableName: subscription_tiers
            primaryKey: id
            separator: ","
            quotchar: "\""
      rollback:
        - loadUpdateData:
            file: reference-data/subscription_tiers-v1.csv
            tableName: subscription_tiers
            primaryKey: id
            separator: ","
            quotchar: "\""

This is the important part:

• During deployment, Harness Database DevOps executes the changelog and loads subscription_tiers-v2.csv.
• During rollback, the pipeline reloads subscription_tiers-v1.csv.

This creates a rollback-ready deployment workflow without requiring manual SQL fixes during incidents.

How This Fits into Database DevOps?

In a modern Database DevOps workflow, every database change should move through the same CI/CD process.

That includes:

• Schema changes
• Stored procedures
• Reference data
• Permissions
• Seed data

Reference data should not bypass governance. When reference data lives in Git, teams gain much better operational control:

• Developers can review changes before deployment.
• QA teams can validate updates in staging environments.
• DBAs keep database deployment automation in environments consistent.
• Rollback steps are already prepared before production deployment begins.

And this significantly reduces operational risk for the team.

Using Harness Database DevOps for Reference Data Deployments

While many teams have adopted CI/CD for application deployments, database updates often remain tied to manual workflows, increasing risk particularly with reference data.

Harness Database DevOps bridges this gap by enabling automated reference data management. By utilizing Liquibase OSS compatible changelogs and storing CSV files in Git as deployment artifacts, teams can bring database changes into their standard delivery pipelines.

This approach provides several key benefits:

• Full traceability through Git commits, pull requests, and pipeline history.
• Environmental consistency by moving the same reference data from development through production without manual intervention.
• Coordinated delivery by integrating database updates directly into existing application release pipelines.
• Enhanced governance via automated policy checks, audit logs, and approval gates.

Git-driven workflows are particularly advantageous for large-scale operations. To support this, the Harness community offers Terraform onboarding templates that facilitate CSV-driven resource provisioning, helping organizations standardize database operations.

This workflow ensures that rollbacks are integrated from the start. If an update causes an issue, teams can rapidly redeploy the previous CSV version using pre-defined rollback steps in the changelog. This result is a more predictable and secure delivery process for both operations and development teams.

But The Rollbacks Are the Real Advantage

Most teams focus mainly on deployments. But mature Database DevOps practices depend heavily on reliable rollback strategies. Reference data changes can fail for many reasons. The application may still expect an older value. Unexpected data changes can break the UI. 

A feature flag might get enabled too early. Without rollback automation, production recovery becomes stressful and slow. Using versioned CSV files with loadUpdateData keeps the rollback process simple. Since the previous working version already exists, recovery becomes much faster. That simplicity becomes extremely valuable during production incidents.

Conclusion

This streamlined lifecycle leverages automated pipelines to manage updates and rapid recoveries. Standardizing reference data management aligns database deployments with modern CI/CD best practices. Explore how Harness Database DevOps can transform your delivery process today.

FAQs

How does Harness Database DevOps fit into this workflow?

Harness Database DevOps automates Liquibase OSS compatible changelogs through governed pipelines with Git traceability and rollback support.

Can Harness Database DevOps handle both schema and data deployments?

Yes. Harness Database DevOps supports schema changes, reference data updates, stored procedures, and rollbacks in one workflow.

What is the safest way to rollback reference data changes?

Use versioned CSV files with loadUpdateData. Deploy the new CSV during apply and reload the older CSV during rollback.

Is Liquibase OSS better than Flyway Community for reference data updates?

Liquibase OSS supports rollback logic and loadUpdateData, making reference data versioning easier than Flyway Community.

A year ago, most of my customer conversations were about cloud cost attribution, commitment coverage, and rightsizing. Classic FinOps stuff. The occasional surprise bill, sure, but nothing that kept anyone up at night. I stopped asking “what was that ‘oh $*#@’ moment when you saw a bill and knew something had gone seriously wrong?” because no one had one of those moments anymore.

Somewhere in the last 12 months, the tables turned and our customers were asking me a serious question: why did my AI bill just do that, and how do I stop it from happening again?

Clearly, something changed. So we ran a study to figure out why.

We surveyed 700 engineering leaders and practitioners across five countries this spring to ask about their organization's FinOps practices. All respondents are at organizations with at least 1,000 employees and real, recurring AI spend, not startups experimenting on a credit card. What we found in the 2026 State of AI in FinOps survey report reads less like a new problem and more like an old one wearing a different jacket.

The pattern I keep seeing

I spent years in FinOps for cloud before AI spend was a line item anyone thought about. But the patterns in the AI billing data – the ownership confusion, the governance gaps, the invoice showing up before anyone understood why – are the same ones we saw in cloud 10-plus years ago. Now, however, the patterns are compressed into a much shorter timeframe and coming at an accelerated pace, if you can believe it.

67% of organizations now spend more than $250,000 a month on AI. 20% have already crossed $1 million a month. At that scale, AI isn't a tool cost anymore, it's a capital decision, which deserves the same governance and attribution discipline it took the industry a decade to build for cloud. We don't have a decade this time.

Ownership is the root, not the symptom

If you ask five people in a typical enterprise who owns AI costs, you'll get five different answers. 52% of respondents told us there's no clear, dedicated AI cost owner in their organization. And the deeper issue isn't that nobody's watching, it's that four different functions are each contributing to the bill. Platform and DevOps teams carry 30% of the accountability, with FinOps 27%, finance 23%, and engineering 19%. No single function comes close to a majority and that is one of the top problems enterprises are facing at the very start.

Meanwhile, engineering and platform teams hold the most influence over spending decisions, more than any function's share of accountability. The disconnect between decision-making and accountability is where a single cost overrun escalates into a full-blown P&L problem. 

When the bill doubles overnight

72% of organizations have hit an unexpected AI cost spike or surprise bill in the past year. 1 in 3 have been caught off guard more than once. That alone wouldn't worry me as much if diagnosis were fast. It isn't. 79% report needing a full day or longer to trace a spike back to its source; and roughly a third need a full week. Meanwhile, the bill keeps running.

In the cloud, knowing a spike happened is only the first indication of a problem. Understanding the cause in real-time is where most organizations still fall short, and in today's AI-driven world, the stakes are higher because the spend curve is steeper.

The waste number that should get a CFO's attention

Across the dataset, organizations estimate that 26% of all AI spend is wasted — consistently, across infrastructure, software, models, and services alike. For a company spending $1 million a month, that's $260,000 a month with no measurable return. Just imagine what any enterprise could achieve with that amount of wasted money turned into investments?

Unlike waste in a traditional cloud landscape (are we really, already, calling cloud “traditional” or “legacy”?), this isn't an idle instance somebody forgot to shut down. It's embedded in usage patterns — prompt design, model selection, retry logic — none of which currently carries a cost signal. 56% of engineering leaders told us their teams don't have cost in mind when building AI features, and only 45% of engineers, on average, understand what their builds actually cost.

That's not a motivation problem. In our FinOps in Focus Report 2025, 62% of developers said they wanted more control over cloud costs, and there's no reason to think AI is any different. The problem is a lack of visibility, not a misalignment of intent. The data simply isn't in front of people when the decisions get made.

Policy on paper, not in practice

The instincts are right; the operational muscle isn't there yet. 73% of organizations say they have an AI cost policy. Only 47% fully enforce it. That's a 26-point gap between what's written down and what actually happens day to day. Policies that don't show up in the tools engineers actually use tend to get ignored, because the incentive to move fast usually wins.

Only 21% describe their AI cost management as fully mature company-wide, and only 26% have a robust way of measuring the business value of their AI spend at all. Four in five organizations simply aren't there yet.

‍Building an AI ROI Culture

What I keep coming back to is that the hardest part of this isn't technical. It's cultural and organizational. The tooling is catching up. The harder work is getting engineering teams to build with cost in mind from the start, not as a constraint, but as a design principle.

The organizations in our data that did reach maturity didn't try to fix everything at once. They followed a fairly consistent sequence: 

• name an owner before buying a tool, 
• build a unified cost view before optimizing, 
• embed cost data into engineering workflows before writing policy, 
• and establish unit economics tied to real business outcomes before chasing ROI.

Use this report to find out where your organization stacks up against others in the industry and how mature enterprises are getting ahead of AI cost blindspots..

Download and learn more about the 2026 State of AI in FinOps.

Key takeaways: 

• The Harness Cursor Plugin now works inside Cursor's new iOS app, with the same natural-language access to pipelines, security, and deployments as desktop.
• Reading works the same on iOS as on desktop. Write actions, like triggering a pipeline, are denied by default unless they pass confirm:true and the right RBAC role.
• Setup: connect the plugin's Cloud environment on desktop and enable Cloud Agents on your GitHub or GitLab repos.

---

The Harness Cursor Plugin now works on Cursor for iOS. Check pipeline status, security posture, and deployment health from your phone.

In April, Harness announced the Harness Cursor Plugin, a native integration that lets developers manage CI/CD pipelines, deployments, and security posture using natural language inside Cursor, governed by the same RBAC, OPA policies, and audit trails already enforced across the Harness platform. That experience has, until now, lived entirely at a desk.

If a pipeline failed, a security scan flagged something, or an approval needed clearing while a developer was away from a laptop, checking in meant waiting to get back to one. An on-call engineer paged about a failing deployment, for example, could do little more than acknowledge the alert until reaching a desk.

What This Unlocks 

Cursor for iOS isn't about replacing the desktop experience. It's about removing unnecessary waiting. Whether you're reviewing the health of a deployment before boarding a flight, checking why a pipeline failed between meetings, or pulling security scan results before a release window closes, you no longer lose visibility simply because you aren't sitting in front of your laptop.

Introducing Harness on Cursor for iOS

Cursor's iOS app lets developers launch and track coding agents, review completed work, and merge pull requests from their phone. The Harness Cursor Plugin now works inside it too, using the same natural-language interface already available on desktop.

Here's how it works:

1. On the desktop, open the Harness plugin's configuration and connect its Cloud environment, separate from the Local one already in use. Then enable Cloud Agents on the GitHub or GitLab repositories you want to reach from your phone.

2. Open Cursor for iOS and ask Harness what you'd ask on the desktop: pipeline status, deployment health, security posture. Read requests are answered live from the Software Delivery Knowledge Graph, the same source the desktop plugin uses.
3. To take an action, like triggering a pipeline or promoting a deployment, confirm intent explicitly. Cursor's desktop app shows an on-screen prompt before running actions like these; iOS doesn't yet. So, without that prompt, Harness denies write requests by default unless you pass an explicit confirm:true parameter, and even then, the request only executes if the user's RBAC role permits that specific action.

The Paradox Doesn't Stay at the Desk

Harness's governance covers every surface a developer works from, not just the desktop. RBAC, approval gates, and audit trails are enforced at the pipeline and policy layer, no matter where the request comes from.

That consistency matters because of what Harness calls the AI Velocity Paradox: teams ship faster with AI, but the systems meant to catch problems before release haven't kept up. 63% of organizations now ship code to production faster since adopting AI. Only 41% are confident their governance processes can catch issues before release, and 72% have already had a production incident caused by AI-generated code.

Coding is already becoming untethered from any one device, and that pace isn't slowing down. If governance stayed deskbound while coding didn't, the paradox would only get worse. That's why Harness on Cursor for iOS keeps RBAC, approval gates, and audit trails traveling with the same pipeline, no matter where the request originates.

Getting Started

To use Harness inside Cursor for iOS:

1. If you haven't already, install the Harness Cursor Plugin from the Cursor Marketplace and authenticate with OAuth.
2. On the desktop, open the plugin's configuration and connect to the Cloud environment.
3. Enable Cloud Agents on the GitHub or GitLab repositories you want to access from your phone.
4. Download Cursor for iOS from the App Store.
5. Ask Cursor any questions specific to your Harness delivery pipelines.  

AI has already changed how software gets built. Now it's changing how software gets delivered. Extending Harness to Cursor for iOS isn't just about supporting another device. It's about making governed software delivery available wherever developers work, without compromising the security, policy enforcement, or visibility platform teams depend on.

For more on the underlying integration, see the Harness Cursor Plugin documentation or read the original launch announcement.

FAQ

Does the Harness Cursor Plugin work on Cursor for iOS? Yes. The Harness Cursor Plugin works inside Cursor's iOS app, giving developers the same natural-language access to pipeline status, security posture, and deployment health they already have on desktop, pulled live from the Software Delivery Knowledge Graph.

How do I set up Harness on Cursor for iOS? On desktop, open the Harness plugin's configuration, connect its Cloud environment (separate from the Local one already in use), and enable Cloud Agents on the GitHub or GitLab repositories you want to access. Then download Cursor for iOS from the App Store.

‍

When you install Terraform without considering security and scale from the start, you build technical debt that manifests as state corruption, credential leaks, and configuration drift across teams. A proper Terraform installation guide addresses these operational realities before the first `terraform apply` runs.

This article walks through how to install Terraform with security hardening and scalability built into the foundation. You'll learn platform-specific installation steps, configuration best practices that prevent common pitfalls, and setup patterns that support team workflows without creating bottlenecks. By the end, you'll have a production-ready Terraform configuration management approach that scales with your infrastructure needs.

Understanding Terraform Installation Requirements

Before you install Terraform, understand what changes when you move from local experimentation to production automation. The binary itself is stateless, but the workflows it enables are anything but. Production Terraform deployments require state management, secret handling, version control, and team coordination.

Naive Terraform setup best practices focus on getting the CLI working. Real infrastructure as code security starts with recognizing that Terraform manages privileged access to your infrastructure. Every installation decision affects how credentials are stored, how state is accessed, and how teams collaborate without stepping on each other's changes.

At scale, the installation becomes less about the binary and more about the surrounding toolchain: where state lives, how modules are versioned, how plans are reviewed, and how drift gets detected. The baseline installation must anticipate these concerns, not retrofit them later.

How to Install Terraform Across Platforms

The installation process varies by platform, but the security and scalability considerations remain consistent.

Linux Installation

For Linux systems, install Terraform using the package manager to ensure automatic updates and signature verification:

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

This approach ensures signature verification on every package update. Manual binary downloads bypass this verification, introducing supply chain risk that becomes significant at scale.

macOS Installation

On macOS, use Homebrew for managed updates and version control:

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Homebrew maintains the formula and handles dependency resolution. For teams managing multiple IaC tool versions, consider using `tfenv` to switch between Terraform versions without breaking existing workflows.

Windows Installation

For Windows environments, use Chocolatey for automated infrastructure provisioning:

choco install terraform

Alternatively, download the binary and add it to your system PATH. For enterprise environments, package the binary in your internal software distribution system to control which versions reach production workstations.

Version Management

After installation, verify the version and establish a version pinning strategy:

terraform version

Lock your Terraform version in version control using a `.terraform-version` file or required_version constraint in your configuration. This prevents the "works on my machine" problem that emerges when different team members run different CLI versions.

Secure Infrastructure Automation Configuration

Once Terraform is installed, configure it for secure operations. The default configuration works for learning, but production deployments require explicit security boundaries.

State Backend Configuration

Never store Terraform state locally in production. Configure a remote backend before applying any infrastructure changes:

terraform {
  backend "s3" {
    bucket         = "prod-terraform-state"
    key            = "infrastructure/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Remote backends provide state locking, preventing concurrent modifications that corrupt infrastructure state. Encryption at rest protects sensitive values stored in state. State locking using DynamoDB prevents race conditions when multiple pipelines run simultaneously.

Credential Management

Configure Terraform to retrieve credentials from external systems, not from configuration files:

export AWS_PROFILE=prod-automation
export ARM_CLIENT_ID="${AZURE_CLIENT_ID}"
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"

Avoid hardcoding credentials in provider blocks. Use environment variables, credential files outside the repository, or integrate with secret management systems like HashiCorp Vault. Each credential leak represents infrastructure-wide exposure, not just a single service compromise.

Provider Configuration

Pin provider versions explicitly to prevent breaking changes from automatic updates:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

The `~>` constraint allows patch updates while preventing major version changes that introduce breaking API modifications. Test provider updates in non-production environments before promoting to production workflows.

## Scalable IaC Deployment Setup

When teams grow beyond a few engineers, installation alone doesn't solve workflow problems. Scalability requires workspace organization, module management, and drift detection.

### Workspace Structure

Organize workspaces by environment and team ownership:

terraform workspace new prod-networking
terraform workspace new prod-compute
terraform workspace new staging-networking

Workspaces isolate state, but they share backend configuration. For stronger isolation, use separate backend configurations per environment. This prevents accidental production modifications when someone forgets to switch workspaces.

Module Registry Access

Configure access to private module registries if you're standardizing infrastructure patterns:

module "vpc" {
  source  = "app.terraform.io/org-name/vpc/aws"
  version = "2.1.0"
}

Private registries enforce versioning and provide a central distribution point for validated infrastructure patterns. Without this, teams copy-paste configurations and diverge over time.

CI/CD Pipeline Integration

Integrate Terraform into your deployment pipelines rather than running it manually:

terraform-plan:
  script:
    - terraform init
    - terraform plan -out=tfplan
  artifacts:
    paths:

Automated pipelines provide audit trails, prevent manual errors, and enforce approval workflows. The plan artifact becomes a reviewable object, not just terminal output that disappears.

Common Installation and Configuration Pitfalls

Even with proper installation, several failure modes appear at scale.

State File Mismanagement

Teams often start with local state and migrate to remote backends later. This migration is error-prone. State files contain the complete infrastructure mapping, and any corruption during migration creates reconciliation problems. Always initialize with remote backends, even in development environments, to avoid migration complexity.

Version Drift

Without version constraints, different team members run different Terraform versions. A feature that works in 1.6 might fail in 1.5, or worse, succeed with different behavior. Version drift causes "flaky" infrastructure that works sometimes and fails others, depending on who ran the command.

Credential Exposure

Storing credentials in Terraform configuration files or state exposes them in version control and state storage. Even encrypted backends store credentials if you hardcode them in provider blocks. Use dynamic credential retrieval from external systems, not static credentials embedded in code.

Concurrent Modifications

Without state locking, two people running `terraform apply` simultaneously corrupt state. The second run overwrites partial changes from the first, leaving infrastructure in an undefined state that doesn't match reality or the code. Always configure state locking before any team uses Terraform.

How Harness IaCM Extends Terraform Enterprise Installation

Installing and configuring Terraform solves the technical problem, but operational scale requires governance layers that prevent drift, enforce policies, and provide visibility across teams.

Harness Infrastructure as Code Management handles the surrounding operational concerns while treating the IaC engine choice as an implementation detail. It supports OpenTofu, Terraform, and Terragrunt, allowing teams to work with their existing tooling while gaining centralized governance.

The platform provides a module registry that acts as a single source of truth for validated infrastructure patterns. Instead of teams copy-pasting configurations or maintaining dozens of module repositories, they pull from a central registry with versioning and access controls. This solves the "how do we standardize without blocking teams" problem that manual installation approaches leave unaddressed.

Variable sets and workspace templates eliminate repetitive configuration. Define backend settings, provider configurations, and common variables once, then apply them across environments. This prevents the credential leaks and version drift that emerge when each team member configures Terraform independently.

Default pipelines automate the plan-review-apply workflow without requiring custom CI/CD setup. Every infrastructure change follows the same approval process, creating audit trails and preventing manual `terraform apply` commands that bypass governance. The pipeline becomes the interface, not the CLI.

Drift detection runs continuously, comparing actual infrastructure state against the declared configuration. When someone makes a manual change outside Terraform, drift detection flags it before it cascades into broader problems. This visibility prevents the "infrastructure doesn't match code" problem that invalidates Infrastructure as Code benefits.

Policy enforcement using Open Policy Agent blocks non-compliant configurations before they reach production. Instead of discovering security violations after deployment, policies fail the plan stage. This shifts compliance left without requiring manual review of every Terraform plan output.

For installation workflows, this means you set up Terraform once, configure it to work with Harness, and let the platform handle the operational complexity. Teams still write Terraform code, but they don't manage state backends, configure pipelines, or build custom drift detection. The installation becomes simpler because the surrounding automation is handled centrally.

Learn more about [Harness Infrastructure as Code Management] or explore the [documentation] for configuration details.

Frequently Asked Questions

What is the difference between installing Terraform locally versus in a CI/CD pipeline?

Local installation is for testing and development. CI/CD pipeline installation automates the deployment workflow, enforces consistency, provides audit trails, and prevents manual errors that bypass governance controls.

How do I manage multiple Terraform versions across projects?

Use version management tools like `tfenv` or `asdf` to switch between versions per project. Pin the required version in your Terraform configuration using the `required_version` constraint to prevent version drift.

Can I install Terraform without internet access in air-gapped environments?

Yes. Download the binary from HashiCorp's release page, verify the SHA256 checksum, and distribute it through your internal software management system. Configure private module registries and provider mirrors for dependency management.

What happens if I forget to configure state locking?

Concurrent Terraform runs will corrupt your state file, leaving infrastructure in an undefined state that doesn't match your code or reality. Always configure state locking using DynamoDB, Azure Blob Storage lease, or Google Cloud Storage consistency tokens.

How do I migrate from local state to a remote backend?

Run `terraform init -migrate-state` after configuring the backend block. Terraform will copy the local state to the remote backend and delete the local file. Back up your local state before migration in case the process fails.

Conclusion

Installing Terraform is straightforward, but setting it up for secure infrastructure automation and scalable IaC deployment requires planning beyond the binary download. Remote state backends, credential management, version pinning, and workspace organization prevent the operational failures that emerge when teams scale Infrastructure as Code beyond individual contributors.

The installation provides the foundation, but production reliability comes from the surrounding governance: how state is managed, how credentials are secured, how changes are approved, and how drift is detected. These concerns don't disappear with better tooling, but platforms like Harness IaCM centralize them, allowing teams to focus on infrastructure logic rather than operational mechanics.

Start with a secure Terraform installation guide that addresses backend configuration, credential management, and version control. Build workflows that enforce these patterns across teams. When operational complexity grows beyond manual coordination, evaluate platforms that automate the governance layer while preserving your existing Terraform workflows.

Your cloud cost optimization strategy just flagged a $47,000 anomaly in last month's Kubernetes spend. Finance wants answers. Engineering claims everything is running normally. Platform teams are scrambling through logs. Three hours later, you discover the spike came from a staging environment that someone forgot to tear down after a load test two weeks ago. The tooling caught the symptom. Your approach missed the disease.

This scenario repeats across organizations daily. Teams invest in sophisticated monitoring, deploy dashboards, set up alerts, then watch their cloud bills climb anyway. The problem is not the tooling. It is the assumption that visibility alone drives accountability.

Why Traditional Cloud Cost Optimization Approaches Fail

Most cloud cost optimization challenges stem from treating cost management as a periodic cleanup exercise rather than an operational discipline. Organizations implement dashboards, generate monthly reports, and schedule quarterly reviews. Then they wonder why engineers ignore the recommendations and spend continues growing.

The gap lies in the feedback loop. When cost data arrives weeks after the spending decision, engineers cannot connect their architectural choices to financial outcomes. A developer deploys a new microservice with default resource requests. Three weeks later, someone in finance notices the overprovisioning. By then, the service is in production, and rightsizing it requires another deployment cycle that nobody prioritizes.

This delayed accountability creates a culture where cost optimization becomes someone else's problem. Engineering builds features. Finance tracks spending. Platform teams inherit the reconciliation work. Nobody owns the relationship between technical decisions and their financial consequences.

The Reactive Cycle That Perpetuates Cloud Cost Optimization Challenges

Reactive cloud cost management approaches follow a predictable pattern. Teams deploy infrastructure, operate services, receive bills, analyze spending, identify waste, create tickets, prioritize work, and finally implement fixes. By the time optimization happens, new inefficiencies have already accumulated.

Consider how teams handle idle resources. Someone notices an underutilized EC2 instance during the monthly cost review. They create a ticket to investigate. Engineering confirms it is no longer needed. The ticket goes into the backlog. Two sprints later, someone finally terminates the instance. Meanwhile, that resource consumed another $600 in unnecessary spend.

This reactive model fails at scale because cloud environments change faster than monthly review cycles can track. Teams launch experiments, provision temporary infrastructure for testing, scale services to handle traffic spikes, then forget to scale back down. Each decision makes sense in isolation. Collectively, they create persistent waste that compounds month over month.

The FinOps strategy required to break this cycle involves embedding cost accountability into the workflows where spending decisions actually happen, not bolting it on afterward through reporting.

Building a Cloud Cost Governance Framework That Scales

Effective cloud spend optimization requires governance mechanisms that operate in real time, not historical analysis. Teams need to understand the cost implications of their architectural choices before those choices reach production, not weeks later when bills arrive.

This means establishing cost guardrails at the infrastructure provisioning layer. When an engineer requests resources, they should see projected spend alongside technical specifications. When a team deploys a new service, cost allocation should happen automatically based on tagging policies. When usage patterns change, teams should receive immediate feedback about the financial impact.

The cloud cost governance framework must also address ownership boundaries. Which team owns the cost of shared infrastructure? How do you allocate spending for platform services consumed by multiple applications? Who decides when optimization work takes priority over feature development?

Organizations that answer these questions clearly create sustainable cloud cost optimization best practices. Those that leave ownership ambiguous end up with fragmented accountability where nobody feels responsible for the overall spend.

Implementing a Sustainable Cloud Cost Management Approach

A functioning cloud cost management approach requires three operational components: real-time visibility into spending patterns, automated allocation to responsible teams, and integration with existing development workflows.

Real-time visibility means engineers see cost data during development, not during retrospectives. When someone modifies resource requests in a Kubernetes manifest, they should understand the monthly cost difference immediately. When a team considers using a managed service versus self-hosting, cost implications should inform the architectural discussion.

Automated allocation eliminates the manual reconciliation work that consumes platform team capacity. Tags applied during resource provisioning should automatically map spending to teams, services, and environments. Cost data should flow into the same systems teams already use for capacity planning and incident management.

Workflow integration ensures cost optimization does not become isolated work. Rightsizing recommendations should appear in pull requests. Anomaly alerts should route to the same channels as performance alerts. Budget tracking should connect to the same approval workflows used for infrastructure changes.

This integration transforms cost optimization from something teams do occasionally to something embedded in how they operate continuously.

How Harness Cloud Cost Management Enables Governance at Scale

Harness Cloud & AI Cost Management addresses these operational requirements by treating cost visibility as infrastructure, not reporting. The platform provides real-time cost tracking across AWS, Azure, and GCP, with automatic allocation based on Kubernetes labels, cloud tags, and organizational structure.

Teams get cost breakdowns by service, environment, and business unit without manual tagging reconciliation. Budget tracking operates continuously with anomaly detection that routes alerts to the teams responsible for the spending. Optimization recommendations appear in context where engineers already work, not in separate dashboards they need to remember to check.

The governance capabilities extend beyond visibility. Harness CCM enables policy-based cost controls that prevent wasteful configurations before they reach production. Teams can set budget guardrails, enforce tagging policies, and establish approval workflows for high-cost resources.

This approach shifts cost accountability left in the development process. Engineers see the financial impact of their decisions during design and implementation, when changes are cheap to make. Platform teams get automated allocation that eliminates manual reconciliation. Finance gets accurate forecasting based on actual resource usage patterns.

Because Harness CCM integrates with broader platform and delivery workflows, cost optimization becomes part of the deployment process rather than separate cleanup work. Rightsizing recommendations flow into the same pipelines teams use for continuous delivery. Cost trends inform capacity planning alongside performance metrics.

For organizations implementing FinOps practices at scale, this integration matters. Cost management cannot operate in isolation from the technical workflows that generate spending. Tools that treat cost as an afterthought create friction that engineering teams route around. Platforms that embed cost visibility into existing processes enable the shared ownership required for sustainable optimization.

The platform documentation provides implementation patterns for teams moving from reactive cost management to proactive governance. The product roadmap shows ongoing investment in capabilities that strengthen cost accountability across the software delivery lifecycle.

Establishing Sustainable Cloud Cost Optimization Best Practices

Sustainable optimization requires treating cost as an operational concern, not a financial reporting problem. Teams that build cost awareness into their development practices avoid the accumulation of waste that reactive approaches never fully eliminate.

This cultural shift begins with transparency. When every team sees their spending in real time, cost becomes a shared responsibility. When budgets connect to technical decisions, engineers understand the financial consequences of architectural choices. When optimization recommendations appear during code review, addressing inefficiency becomes part of normal development work.

Organizations implementing this approach report sustained reductions in cloud spend without sacrificing delivery velocity. Engineering teams make better trade-offs because they understand cost implications alongside technical considerations. Platform teams spend less time on manual reconciliation and more time on automation that prevents waste. Finance gets predictable spending patterns because budgets connect to the workflows that generate costs.

The key is embedding cost accountability where spending decisions happen, then providing the guardrails and visibility required to act on that accountability continuously.

---

Your staging environment is still running. The difference is that now you know about it immediately, the responsible team gets an automatic alert, and your governance policies prevent similar waste from accumulating next time. That is not better reporting. That is a better approach.

Ever wonder why your FinOps savings optimization efforts feel like playing whack-a-mole with service quotas while your CFO still asks why cloud spend keeps climbing? You're not alone. Most teams approach cost management as a quarterly fire drill—identify overruns, kill underutilized resources, negotiate better rates, then repeat the cycle three months later.

In recent years a more accurate framing has emerged—and it’s reshaping how leading enterprises approach cloud economics:

You’re not overspending. You’re under-saving.

That shift isn’t just a catchy line. It’s the difference between reacting to cloud bills and systematically capturing savings before waste ever becomes spend. And once you see cloud cost through this lens, it becomes clear why so many cloud programs plateau: they’re trying to optimize after the fact.

The problem isn't that teams are spending recklessly. It's that they're systematically missing the largest pool of potential savings: the costs they never should have incurred in the first place.

The Real FinOps Paradigm Shift: From Cost Control to Value Creation

The traditional cloud cost savings strategy treats spend as a problem to solve after deployment. Teams spin up infrastructure, run workloads for weeks or months, then scramble when finance flags the variance. By then, architectural decisions are locked in. Instance families are chosen. Data transfer patterns are established.

The opportunity to prevent those costs expired the moment the first commit hit production.

The real FinOps paradigm shift isn’t better dashboards or faster anomaly alerts. It’s moving from cost control (looking backward) to value creation (looking forward). When we focus on overspending, we’re asking: What went wrong? When we focus on under-saving vs overspending, we’re asking: What could have been optimized?

Because here’s the uncomfortable truth:
Every unsaved dollar is a lost opportunity — and those opportunities can compound quickly.

Why Traditional FinOps Cost Optimization Frameworks Miss the Target

Standard FinOps cost optimization frameworks focus on three levers: rightsizing, commitment-based discounts, and resource lifecycle management. These tactics work. They're also insufficient at scale because they treat the symptom, not the cause.

• Rightsizing saves 15-20% on compute that shouldn’t be running at that scale in the first place.
• Reserved instances lock in discounts on workloads that might disappear next quarter.
• Automated shutdowns prevent idle waste but don’t question why the resource exists.

And most importantly: traditional FinOps often assumes you already have attribution solved.

But most organizations don’t.

At the last FinOpsX conference, one stat stood out because it explains why cost programs stall:

Only 37% of enterprise companies can achieve 80% or greater tagging accuracy for showback purposes.

Meaning: most enterprises are “flying blind” on a meaningful chunk of their spend. Not because they lack dashboards—but because they can’t reliably connect costs to owners, services, or outcomes.

The Foundation: You Can’t Optimize What You Can’t Attribute

The path to meaningful cloud optimization starts with a simple truth:

You can’t optimize what you can’t attribute.

Yet most organizations struggle with basic cost attribution, leaving 40–60% of their spend unallocated across:

• Shared resources with no clear ownership split
• Legacy systems with unknown owners
• Cross-functional services used by multiple teams
• Infrastructure components that span business units

This isn’t just a reporting problem. It’s an optimization blocker.

Because if teams can’t see their real costs, they can’t make informed decisions about architecture, service ownership, or operational tradeoffs. They default to safe-but-expensive patterns: overprovisioning, indefinite retention, and “just in case” redundancy.

That’s not overspending. That’s under-saving.

Proactive Cloud Cost Management Starts Before Deployment (Not After the Invoice)

Shifting to proactive cloud cost management requires embedding cost awareness into engineering workflows, not appending it afterward.

That means surfacing estimated spend during:

• Code review
• CI pipelines
• Infrastructure as Code changes
• deployment approvals

This isn’t about blocking deployments or adding bureaucratic gates. It’s about making cost a first-class design constraint, like latency or error rates.

The most innovative FinOps organizations are moving toward what is called a “zero drift” model: embedding cost optimization directly into the development and deployment pipeline so inefficiency never ships.

Instead of discovering optimization opportunities after resources are deployed, zero drift ensures that:

• Infrastructure is provisioned with optimal configurations from day one
• Tagging policies are enforced at deployment time
• Resource selections align with existing commitment purchases
• Guardrails prevent expensive mistakes before they happen

This is where the best cloud savings opportunities actually live: not in post-hoc cleanup, but in pre-production prevention.

Beyond Dashboards: Always-On Systems That Never Sleep

Real savings don’t come from dashboards. They come from systems that never sleep.

Traditional FinOps relies on periodic reviews and manual interventions. But modern cloud environments are too dynamic for that. Workloads shift daily. Teams deploy constantly. Kubernetes autoscaling changes cost behavior in real time. No human review process can keep up.

To maximize cloud cost efficiency, optimization has to be:

• Continuous
• Automated
• Anforced through governance
• Connected to engineering workflows

This is the difference between a FinOps program that “reports” and a FinOps program that actually saves.

Cloud Cost Governance Best Practices That Scale with Teams

Effective cloud cost governance best practices balance autonomy with accountability. Overly restrictive policies slow teams down and create shadow IT. Overly permissive policies lead to unchecked spend and architectural drift.

The solution is policy-driven guardrails that prevent obvious waste without requiring centralized approval for every resource change.

Examples include:

• Enforcing tagging standards for cost allocation
• Setting spend thresholds that trigger reviews
• Flagging resources that violate efficiency baselines
• Requiring approved instance families in production
• Blocking deployments when mandatory tags are missing

Tagging discipline remains the foundation. Without consistent tagging, showback and chargeback models collapse, and optimization becomes guesswork.

Engineering Economics: Making Optimization Everyone’s Job

One of the biggest blockers in traditional FinOps is the disconnect between:

• The teams who identify optimization opportunities (finance)
• And the teams who must implement them (engineering)

This is why cost optimization often feels like cost policing.

To fix it, organizations need to make cloud cost management an engineering discipline—supported by unit economics and workflow integration.

High-performing teams connect technical decisions to business outcomes using metrics like:

• Cost per transaction
• Cost per user
• Cost per deployment
• Cost per environment
• Cost per SKU

When engineers can see how their architectural choices translate to dollars, optimization becomes a natural part of delivery—not an external mandate.

How Harness Cloud Cost Management Enables Proactive FinOps Savings Optimization

Harness Cloud & AI Cost Management provides the visibility and control infrastructure needed to shift from reactive cost cuts to proactive savings.

Unlike platforms built primarily for post-invoice reporting, Harness integrates cost awareness directly into deployment workflows—surfacing spend data at the point where engineering decisions are made.

Harness CCM strengthens FinOps savings optimization through:

1) Intelligent rule-based retro-tagging
Most enterprises don’t reach consistent tagging accuracy manually. Harness CCM solves this with automated retro-tagging that classifies untagged resources using:

• resource groups
• naming conventions
• subscription metadata
• deployment pipeline data

This can help organizations achieve tagging accuracy up to 98%, unlocking reliable showback, chargeback, and accountability.

2) Shared cost allocation for real attribution
Harness CCM supports sophisticated shared cost allocation so organizations can distribute costs (like AWS support contracts) proportionally based on actual usage—not arbitrary splits.

3) Always-on optimization systems
Harness CCM replaces periodic reviews with continuous automation, including:

• AI-powered right-sizing based on real workload requirements
• commitment orchestration that executes optimization actions daily
• anomaly prediction that flags spikes before budgets are impacted
• policy-driven guardrails that prevent drift in new deployments

4) Shift-left “zero drift” enforcement
Harness integrates with CI/CD and IaC workflows so teams can enforce cost policies at deployment time, including mandatory tagging and approved resource patterns.

The Path Forward: From Cost Cutting to Systematic Under-Saving Recovery

The transition from reactive cost cutting to proactive savings optimization requires three shifts:

1. Fix attribution first (tagging + shared cost allocation)
2. Move optimization from periodic to always-on
3. Shift left to prevent waste from being deployed

These aren’t cultural aspirations. They’re engineering problems with technical solutions.

The organizations winning at cloud cost management aren’t the ones cutting budgets or negotiating better discounts. They’re the ones that stopped accepting architectural inefficiency as inevitable and started designing cost efficiency into every deployment.

The opportunity isn’t in finding waste after it accumulates.

It’s in building systems that prevent waste from ever becoming spend in the first place.

What To Go Deeper?

Watch our webinar, You’re Not Overspending, You’re Under-saving to learn more. 

For teams looking to implement a cloud cost savings strategy that goes beyond reactive cuts, Harness CCM provides the operational foundation for proactive cost management. Learn more at or explore technical implementation details.

Why does developer productivity feel like it's declining even as your team grows? You hire more engineers, yet features ship slower. Sprint velocity looks healthy on paper, but deployment frequency tells a different story. The standups get longer, the Slack channels multiply, and somehow everyone is busy but nothing feels finished.

This disconnect isn't about effort. It's about visibility. Most engineering leaders lack the instrumentation to distinguish between legitimate delivery constraints and workflow friction that scales linearly with headcount. They track story points and commit counts while the actual bottlenecks hide in handoff delays, review queues, and context switching that never shows up in a burndown chart.

The following eight questions cut through vanity metrics to expose what actually moves the needle on software engineering efficiency. They're not comfortable questions. Some will reveal problems you'd rather not acknowledge. But answering them honestly is the difference between scaling a team and scaling chaos.

What Does Developer Productivity Actually Mean for Your Team?

Before you can improve engineering productivity metrics, you need to define what productivity means in your context. A platform team optimizing infrastructure has different success signals than a feature squad shipping user-facing changes. Conflating these creates metrics theater where everyone reports green while delivery quality erodes.

Developer productivity breaks into three layers that often conflict. Individual throughput measures coding speed and task completion. Team velocity captures collaborative output including reviews, deployments, and knowledge transfer. Business impact tracks whether engineering work actually moves strategic objectives forward.

The mistake is optimizing one layer at the expense of others. A developer cranking out pull requests might be fragmenting the codebase. A team hitting sprint commitments might be ignoring technical debt that will crater velocity in six months. High deployment frequency means nothing if you're deploying the wrong features.

Define productivity through the lens of sustainable delivery. Can your team maintain current output six months from now without burning out? Are you building technical leverage or accumulating complexity tax? The answers shape which metrics matter.

Are You Measuring Activity or Outcomes?

Lines of code, commit frequency, and hours logged are activity metrics. They tell you what engineers are doing, not whether it matters. Activity metrics create perverse incentives where developers optimize for measurement rather than impact.

Developer workflow optimization requires outcome-based measurement. How long does it take to ship a customer-facing change from commit to production? What percentage of deployments require rollback? How many production incidents trace back to code merged in the last sprint? These questions connect engineering work to business consequences.

DORA metrics provide a framework grounded in delivery outcomes. Deployment frequency, lead time for changes, change failure rate, and time to restore service capture the feedback loops that separate high-performing teams from the rest. They're leading indicators of engineering health because they measure your ability to deliver value reliably.

The trap is collecting DORA metrics without understanding the workflows they represent. A team with high deployment frequency but terrible lead times might be shipping small cosmetic changes while complex features rot in long-lived branches. Context matters more than the numbers.

Where Are Your Team Productivity Measurement Blind Spots?

Most engineering organizations track what's easy to measure and ignore what actually constrains throughput. Pull request metrics are abundant. Build system performance data is scattered across Jenkins logs. Incident response times live in PagerDuty. Requirements churn never gets quantified at all.

Team productivity measurement fails when it doesn't capture the space between commits. How long do pull requests sit in review queues? What percentage of engineering time goes to unplanned work driven by production issues? How often do spec changes force rework after development starts? These invisible delays compound into delivery drag that conventional metrics miss entirely.

Workflow visibility requires stitching data across systems. Source control shows when code was written, not when it was ready for review. CI pipelines show build duration, not queue time. Issue trackers show ticket status, not the three days spent waiting for product clarification. Without integration, you're optimising local maxima while system-level bottlenecks persist.

The hardest blind spot is cultural. Are engineers afraid to flag blockers because leadership interprets them as excuses? Does your retrospective process surface genuine impediments or just generate action items that never get addressed? Measurement infrastructure means nothing if teams don't trust the data will be used constructively.

What Percentage of Your Engineering Capacity Goes to Unplanned Work?

Unplanned work is the silent killer of developer experience. Every production incident, urgent bug fix, and surprise escalation from sales interrupts flow state and fractures focus. A team that looks 80 percent utilized on sprint planning is actually 50 percent effective after accounting for firefighting.

Engineering velocity collapses under unplanned work load because context switching isn't free. Dropping a feature branch to fix a production issue costs more than the fix itself. You lose the mental model of what you were building, the architectural decisions that informed your approach, and the momentum toward completion. Regaining that context takes time measured in hours, not minutes.

Track interrupt ratio as a first-class metric. What percentage of story points delivered each sprint were unplanned? How many engineer-days per month go to incidents versus roadmap work? How often do critical path features miss deadlines because the team was pulled into emergency mode? These numbers reveal whether you're running an engineering organization or an operational fire brigade.

Reducing unplanned work requires investment in reliability, observability, and proactive incident prevention. It also requires saying no. Not every escalation is truly urgent. Not every bug justifies interrupting a sprint. Protecting engineering focus is a leadership decision, not a technical one.

How Long Does It Take to Get Feedback on Code Quality?

Developer productivity tools only matter if they shorten feedback loops. A test suite that takes four hours to run might catch bugs, but it trains developers to batch changes and avoid frequent commits. A pull request that sits for three days accumulates merge conflicts and bit rot. Delayed feedback is expensive feedback.

Fast feedback enables iterative improvement. Developers adjust their approach based on test results, review comments, and production behaviour. When that feedback arrives within minutes instead of days, quality improvements compound. Code reviews become conversations instead of asynchronous bottlenecks. Bugs get caught before they escape the developer's working memory.

The goal isn't just speed. It's actionability. A CI pipeline that fails instantly but produces cryptic error messages creates frustration, not productivity. A monitoring system that alerts on every minor blip trains teams to ignore signals. Feedback quality matters as much as feedback speed.

Measure feedback latency across the entire delivery pipeline. How long from commit to CI results? From pull request open to first review? From merge to production deploy? From deploy to user impact visibility? Each delay point represents an opportunity for improvement or a constraint that's being accepted as the cost of doing business.

Are Your Engineering Productivity Metrics Driving the Wrong Behavior?

Metrics shape behavior. Measure pull request volume and developers will split changes into trivially small commits. Measure story points completed and teams will game estimation. Measure individual output and collaboration suffers. The question isn't whether metrics influence behaviour but whether they're encouraging the behaviour you actually want.

Engineering productivity metrics should reinforce team health and sustainable delivery. DORA metrics work because they measure system-level outcomes that require collaboration to improve. You can't game deployment frequency without also improving your build and test infrastructure. You can't fake low change failure rates without investing in quality practices.

The danger is treating metrics as performance scorecards instead of diagnostic tools. When management uses productivity data to rank individuals or teams, trust evaporates. Engineers optimize for metrics instead of outcomes. The dashboards stay green while delivery quality degrades. Productivity measurement becomes counterproductive.

Use metrics to surface questions, not assign blame. Why did lead time spike last month? What's causing the increase in change failure rate? Where are the review bottlenecks that slow down this particular team? The goal is to identify improvable constraints, not to shame teams into working faster.

Do You Understand the Relationship Between Developer Experience and Business Outcomes?

Developer experience directly impacts business results through retention, velocity, and quality. Engineers who spend half their day fighting broken tooling deliver less value. Teams that can't deploy without manual approvals ship slower. Organisations that ignore developer frustration lose their best people to competitors with better engineering cultures.

Poor developer experience compounds. A slow build system adds minutes to every code change. A flaky test suite makes deployments risky. An overloaded review process creates merge conflicts. Each friction point individually seems minor. Together, they create an environment where shipping software feels like pushing a boulder uphill.

The business case for improving software engineering efficiency is straightforward. Faster feedback loops mean faster iteration. Lower change failure rates mean less time spent on incident response. Better tooling means engineers spend more time building and less time fighting infrastructure. These improvements show up in reduced time to market and higher team output.

Track developer experience through both quantitative and qualitative signals. Survey results capture sentiment. Turnover rates reveal whether frustration is driving attrition. Deployment frequency and lead time show whether workflow improvements translate to delivery acceleration. The combination paints a complete picture of engineering health.

How Does Harness SEI Answer These Questions?

Most engineering organizations already collect a lot of data. The problem isn’t a lack of metrics — it’s that the signals are scattered across different systems.

Code activity lives in source control. Build performance sits inside CI pipelines. Work tracking happens in ticketing systems. Incident response lives somewhere else entirely. Each tool tells part of the story, but none of them show how work actually flows through the delivery system.

Harness Software Engineering Insights (SEI) connects those signals so engineering leaders can understand what’s really happening across the development lifecycle.

Connecting the delivery data

SEI integrates with the tools engineering teams already use — including source control platforms and issue tracking systems — and consolidates that data into a unified view of engineering delivery.

Instead of looking at isolated reports from individual systems, teams can analyze how work moves from planning to development, through code review, and into deployment. This makes it easier to see where delays accumulate and how workflow patterns change over time.

Measuring delivery performance

SEI provides built-in engineering delivery metrics, including industry-standard indicators such as DORA metrics and pull request lifecycle analytics.

These metrics help answer questions like:

• How long does it take for a change to move from development to deployment?
  
• Where do pull requests spend the most time waiting?
  
• Are deployment and delivery patterns improving or slowing down?
  

Because these metrics track system-level outcomes rather than individual activity, they provide a more reliable view of engineering performance.

Visualizing workflow trends

SEI surfaces these signals through configurable Insights dashboards, where engineering leaders can explore delivery trends and drill into the underlying data.

These dashboards make it easier to identify patterns that aren’t obvious from individual tools — for example, whether review queues are slowing down merges, whether certain teams experience longer lead times, or whether workflow improvements are actually reducing delivery friction.

Instead of reacting to anecdotal feedback, teams can use these insights to investigate where bottlenecks might exist.

Adapting metrics to your organization

Developer productivity doesn’t look the same for every team. Platform teams, infrastructure teams, and product engineering groups often measure success differently.

SEI allows organizations to define custom metrics and measurement frameworks based on how their teams actually work. This flexibility helps engineering leaders evaluate delivery performance, workflow efficiency, or engineering investment without forcing every team into the same definition of productivity.

Understanding how engineering effort is spent

Beyond delivery speed, engineering leaders also need visibility into where engineering time goes.

SEI supports configurable profiles that help organizations analyze both delivery performance and engineering investment. Teams can examine how work is distributed across areas like feature development, maintenance, bugs, or technical debt — helping leaders understand whether engineering effort aligns with business priorities.

Turning visibility into better decisions

The goal of developer productivity measurement isn’t to monitor developers more closely. It’s to understand how the delivery system behaves.

By connecting engineering data, surfacing delivery metrics, and visualizing workflow trends, Harness SEI helps organizations move beyond guesswork and answer the kinds of questions that actually drive engineering improvement.

When teams can see where work slows down, where effort is being spent, and how delivery patterns evolve over time, they’re better equipped to remove friction and support sustainable developer productivity.

The Questions Lead to Better Answers

Developer productivity improvement starts with honest assessment of current state. The eight questions above force engineering leaders to confront uncomfortable truths about workflow inefficiencies, measurement gaps, and cultural barriers that prevent teams from performing at their potential.

The answers vary by organization, but the pattern is consistent. Teams improve when they have visibility into their delivery process, feedback loops that enable rapid iteration, and leadership that treats productivity metrics as diagnostic tools rather than performance scorecards. The technology enables visibility. The culture determines whether that visibility drives meaningful change.

Start by picking one question and answering it with data. Instrument the workflow. Track the metric. Review the trend. Use what you learn to inform the next improvement. Sustainable productivity gains compound through small, validated changes rather than large, disruptive transformations.

The goal isn't perfect measurement. It's sufficient visibility to make better decisions. You don't need to know everything about your engineering process. You need to know enough to identify the next constraint worth addressing. That's how high-performing teams stay high-performing even as they scale.

You can explore Harness SEI and review implementation details or explore the roadmap to learn how the platform continues evolving to address emerging engineering productivity challenges.