Harness is now available in the Claude Connectors Directory, giving teams real-time AI access to pipelines, deployments, approvals, and software delivery context.
June 1, 2026
Rohan Gupta
Chinmay Gaikwad
+ more
Time to Read
AI agents are only as good as the context they operate in. That's not a design philosophy. It's a practical constraint. An AI agent that doesn't understand how the underlying software delivery entities relate to each other, or what the data actually means, will get things wrong. In software delivery, wrong looks like a botched deployment, a misread failure, or an approval granted when it shouldn't have been, which directly affects your users.
Today, we're announcing that the Harness MCP Server is in the official Claude Connectors Directory, making Harness discoverable and connectable for every team using Claude. But the announcement isn't really about the directory listing. It's about what Harness + Claude can actually do in your delivery system.
What You Can Do with Claude and Harness
Claude can work across the full Harness delivery platform:
Capability
What Claude can do
Pipeline execution
Trigger and monitor builds across GitHub, GitLab, Bitbucket, or Harness Code
Deployment management
Promote services across environments with approval gate verification
Failure diagnosis
Pull structured execution context and surface root cause analysis
Approval workflows
Retrieve pending approvals and take governed delivery actions
Environment state
Query what's deployed where, in real time
Security posture
Review SBOMs, vulnerability scan results, and SSCA compliance status
Resilience testing
Initiate chaos experiments and retrieve structured results
Cost signals
Surface cloud cost anomalies tied to deployment activity
All of it is grounded in the Knowledge Graph, not raw API responses, but a structured model of your delivery system that Claude can reason over precisely.
The Problem With Giving AI Agents Raw API Access
MCP lets AI models call external tools by reading API descriptions and deciding which to invoke. That flexibility is useful. But when you're building an agent that needs to reason across an entire software delivery lifecycle, CI, CD, security scans, approvals, feature flags, cost signals, and environments, raw API access creates a deep reliability problem.
Consider a question a platform engineering lead might ask:
"Show me the pipelines with the highest failure rate over the last 30 days, and for each one, tell me which services they deploy and whether any of those services have open critical vulnerabilities."
That question spans four domains: pipeline execution history, service-to-pipeline relationships, environment state, and security scan results. An agent working off raw APIs has to discover which APIs exist across each domain, call them in the right order, paginate correctly, infer how field names correspond across systems, and synthesize the results without misinterpreting nested objects or guessing at relationships.
The result is 5+ sequential LLM calls, hundreds of thousands of input tokens, high latency, and an agent that had to guess at every join. Guessing is where hallucinations happen.
What the Harness + Claude Integration Changes
The Harness Software Delivery Knowledge Graph is a purpose-built model of everything that happens after code is written: builds, test runs, deployments, approvals, security scans, environment states, feature flags, infrastructure changes, cost signals, and rollbacks. Not as raw data but as a connected, typed, semantically annotated graph of entities and relationships.
Every field in the graph carries metadata that tells an agent exactly how to use it: whether a value is a number or a string, whether it can be aggregated or only filtered, what its unit is, and how it joins to related entities. Cross-module relationships, between a pipeline and the services it deploys, between a deployment and the security scan results for that artifact, between an environment change and the cost anomaly that followed, are explicitly declared, not inferred.
This is the difference between an agent that can access your delivery system and one that understands it.
When Claude connects to Harness via MCP, it doesn't receive a set of API endpoints. It's getting access to a structured model of your entire delivery organization, one where the relationships are known, the data types are enforced, and the agent can construct precise queries rather than guessing at field semantics.
The practical effect with Harness + Claude: that same cross-domain question above becomes 2–3 structured queries against a known schema. The agent selects the right entity types from the graph, generates queries with exact fields and declared relationships, and returns a deterministic answer. No guesswork. No hallucinated field names. No silent wrong answers.
What This Looks Like in Practice
Debugging a failed pipeline without context switching
A build has failed. Normally, you'd open the Harness UI, navigate to the execution, copy the relevant logs, paste them into a conversation, and wait for analysis. The AI reasons over whatever you managed to capture.
With the Harness MCP connection active in Claude, you ask what failed. Claude doesn't just pull logs; it queries the Knowledge Graph to understand the structure of that pipeline, which stage failed, what services were involved, whether similar failures have occurred before, and what changed since the last successful run. The answer it surfaces reflects the full delivery context, not just the stack trace you happened to copy.
Promoting a deployment through governed gates
Your team is ready to move a service from staging to production. Claude checks the current environment state, verifies that required approval gates have been satisfied, confirms the security scan passed for the artifact version you're promoting, and initiates the deployment — with every action running through your existing RBAC policies and logged for audit.
The agent isn't guessing about whether conditions are met. It's querying a graph where those conditions are modeled as typed relationships with known states. The answer is deterministic because the data is structured to make it so.
This Is Not AI Without Guardrails
The natural question when Claude can trigger pipelines and manage deployments: what stops it from doing something it shouldn't?
The same controls that govern everything else in Harness. Every action taken through the MCP server runs through your existing RBAC permissions, OPA policy enforcement, approval gates, and audit logging. Claude operates with exactly the permissions you have, nothing more. Every action is tracked. Nothing bypasses the governance layer.
The Knowledge Graph reinforces this: because Harness AI understands your delivery system structurally, it also understands the constraints within it. Approval gates aren't just optional steps the agent might skip; they're modeled as typed relationships with state. The agent can't promote past a gate that hasn't cleared because the graph reflects that clearly.
Speed and governance aren't a tradeoff. They coexist by design.
Why the Claude Connectors Directory Matters
The Claude Connectors Directory is a curated, reviewed set of integrations. Anthropic evaluates each server before listing it. Being approved is a signal of trust that carries weight for enterprise teams deciding which AI integrations to enable.
It also means discoverability at scale: engineering teams using Claude for DevOps workflows will find Harness natively. One-click OAuth connection, no API key management, no manual configuration.
This fits a broader pattern. The Google Cloud partnership brought Harness into Google's AI ecosystem through Vertex AI and Gemini CLI. The Cursor plugin brought it into the IDE. The Claude Connectors Directory brings it into conversational AI. In each case, the goal is the same: wherever developers are doing their best thinking and wherever AI is being asked to help with software delivery, Harness should be present with the right context for that AI to act reliably.
Getting Started
If you're already a Harness customer:
Open Claude and then the Connectors page
Search for Harness in the MCP directory
Authenticate with OAuth, no API keys, no manual configuration
Start asking Claude about your pipelines, deployments, and delivery workflows
If you're new to Harness, sign up for free and connect from day one. Detailed steps are listed in the documentation.
The Harness Connector gives Claude the ability to act in your delivery system. The Knowledge Graph gives it the understanding to act well. Together, that's what reliable AI in software delivery actually looks like.
Code entering your pipelines today is a collaborative effort. While developers focus on architecture and core logic, AI agents and coding assistants are amplifying code generation, opening PRs, and iterating at unprecedented volume and speed. Underlying repositories still expect every commit to come from a single human. The review process, on top of it, still assumes human speed. Fix the repository without fixing the review process, and you've got a faster way to generate code that no human can verify in time. Fix the review process without fixing the repository, and you're reviewing code faster, but on a repository that can’t handle it. Both must evolve to achieve fast, safe, and governed software delivery at an agent scale.
Today, we're introducing two capabilities built to close that gap: Agent-Ready HarnessCode Repository, a source code management (SCM) system designed to handle agent-generated code at scale, and AI Code Review, which reviews that code faster before it merges. These capabilities are now available as part of Harness' Software Delivery Agent, helping organizations deploy code changes to production in a governed way.
The Need for an Agent-Ready Code Repository
All pre-agent SCMs assume a predictable rhythm: a human writes code, opens a PR, and a few colleagues review it over the next few hours or days. That rhythm sets the pace for everything underneath it.
Agents don't keep to that rhythm. They can open dozens of PRs in an hour, each touching hundreds of files, at any time of day. Indexing and search start to lag. Diffs pile up faster than anyone can review them. Permissions built around a fixed set of human teammates don't have a clean answer for a non-human identity that might merge code on its own. None of these issues show up under a normal human workload. They begin to show up as the share of code committed by agents to your repository increases.
Over the last year, our own teams, like many organizations, have accelerated their use of agents for coding and, more recently, for software delivery. With this increased use, it's become obvious that a repository built for human developers and human reviewers doesn’t hold up when agents become the contributors.
Harness Code Repository: An Agent-Ready SCM
Harness Code Repository is what source control looks like when agents are part of the team. It is built to handle agentic workloads without degrading performance and to embrace AI workflows that accelerate human code reviews. Here’s what makes it agent-ready:
Throughput that doesn't assume human pacing
Indexing, diffing, and searching all have to keep up with a much higher volume of branches and PRs than when code was primarily written by humans. Harness Code Repository is scale tested to handle thousands of pull requests and commits per second.
Scoped permissions for non-human identities
With Harness, you can set up RBAC and OPA policies to precisely scope what an agent identity can access, merge, or deploy, similar to how team members operate.
Agents inherit permissions from the developers who trigger them. Developers can further define what an agent may access or merge, just as they would scope a new engineer, down to a specific repository, branch, or environment.
Discoverable and efficient for agents, seamless for humans
For developers who live in a terminal, Harness CLI enables agent-ready tooling for Harness Code Repository and AI Code Review. Harness CLI supports structured commands such as creating repositories, searching for PRs by author email, or pulling all open PRs into a single cross-repository inbox. Built-in commands for AI Code Review help prioritize diffs by risk levels, so that teams can move faster and with more confidence.
Harness CLI returns only the fields that the operation needs, rather than the full page or object graph a browser-driven flow or a generic API call would return. This keeps the token cost down per call. And because the commands are discoverable and self-describing, an agent can find the right operation and drive it on its own, without a human mapping out the workflow first.
Built-In AI Code Review
Once a pull request is opened, it must be reviewed. The standard line-by-line diff provides a limited signal once agents generate most of the PRs. AI Code Review looks at a pull request the way a tech lead would. It runs customizable AI checks against the change, groups the diff logically rather than by file, and writes feedback grounded in the risk associated with the introduced changes. That's what helps identify the pattern that took down production last quarter, aside from a simple single-line change.
Harness generates reviewer and label suggestions. You define what's important to your team, and the AI Code Review will ensure all new code meets your standards. All these round out the review experience so a PR shows up for review, not cold but already triaged.
Verification as a mandatory stage
Agent output quality varies PR to PR, so build, test, and secure can't depend on a human kicking them off. In Harness, storing, reviewing, building, testing, securing, and deploying the code follow a single sequence. AI Checks sit within that sequence as a gate that the code must pass before it can be merged. For example, each AI Check can be customized to team-specific conventions and required linting rules. AI Checks can be configured at the Account, Organization, and Project levels and have an inheritance model, allowing teams to configure certain checks at a broader level and ensure compliance at the lowest level. Checks that are required and fail can't be squashed and merged.
Groupings that prioritize what to review
Agents produce a lot of mechanical change: mass renames, dependency bumps, and generated boilerplate. None of this is risky on its own, but it buries the handful of files that actually changed behavior if the repository can't distinguish between the two. With the volume of code increasing, humans need to do more code reviews now, and it's important to give them the superpowers to succeed. With Diff Grouping by Risks, developers can see the riskiest changes first, allowing them to prioritize higher-risk reviews.
AI Code Review also works on GitHub repositories today. Here’s an example of how it works:
Our AI Code Review feature was built from our own lived experiences. Like many other organizations, we’ve embraced LLMs to generate large volumes of code and have encountered the same challenges many of you have: too many PRs, too much noise, and not enough context to tell what actually matters. The risk-based diff grouping and the context-grounded feedback in AI Code Review came out of fixing that for our own team first. It was built to make our own review process workable again, and we’re now opening it up to anyone using Harness Code Repository or GitHub.
Reviews Grounded in Your Delivery Context
Most code review tools stop at the diff. Harness AI Code Review will evaluate changes against your organization’s SDLC Knowledge Graph, including historical incidents, to surface risks the code alone can’t reveal.
When a PR modifies something that's caused problems before, AI Code Review flags it with the necessary information: the specific incident, what triggered it, how long it lasted, and the fix the RCA recommended. In the example below, AI Code Review caught a new index migration and flagged it as high-risk, surfacing a prior incident where an unindexed CREATE INDEX statement had locked a production table for 14 minutes, and reminding the author that the RCA called for CREATE INDEX CONCURRENTLY going forward. AI Code Review didn't just say "this could be risky" but it highlighted why, with the right context. This is only possible when the solution you use to review code has your organization’s software delivery context.
Built as one system
These features are both required in today’s software delivery environment. A repository that can absorb agent-scale volume without a review layer that can keep up just moves the bottleneck downstream. A review layer without the right context is, at best, guessing. Store, review, build, test, secure, and deploy remain a single continuous sequence in Harness, which is what makes both of these possible at the same time.
Most AI code review tools only see the diff in front of them, or at best, the repository they live in. In addition to the repository, Harness AI Code Review uses the context most reviewers never see, i.e., security and runtime policies, build and deployment architecture, and past production incidents specific to your organization. All of this is correlated inside the SDLC Knowledge Graph. That's the difference between a tool that tells you that the code is good with limited context, and a platform that tells you it's good for how your organization actually builds and deploys.
Code Repository and AI Code Review have become a part of the outer loop sequence that Harness Software Delivery Agent runs end-to-end, from commit to production, all under the same policy engine. Organizations like Gentera use Harness Code Repository to standardize DevOps across a regulated banking environment, reducing permission changes from weeks to minutes and improving delivery speed by 4x while halving the cognitive load of switching tools. The same governance that made that possible, fine-grained permissions and validation are moved earlier into the pipeline, and now extend to agent identities: scoped access before merge, verification gates that can't be skipped, and review grounded in the same system already running build, test, secure, and deploy.
See it in action
The clearest way to understand this is to watch a PR go through it. In the demo, you'll see the review land with reviewer and label suggestions already attached, the diff pre-grouped into logical changes, and a report summarizing what was checked and why. You'll also see what that PR looks like sitting in Harness Code Repository itself, scoped permissions, verification gates, and all.
Migration & getting started is easy
If you're moving to Harness Code Repository, getting your Git data in takes a few clicks. Import a single repository or an entire GitHub org, GitLab group, Bitbucket workspace, or Azure DevOps project directly from the UI. If you want your pull requests, labels, webhooks, and branch rules to come with you too, the Harness CLI migration commands handle the full migration, and they can run from your laptop, your self-hosted SCM server, or as a step in your CI/CD pipeline.
Harness Code includes generous storage out of the box: 50 GB per account on the Free tier, and 500 GB per account on paid plans (covering both Git and LFS storage), so teams can get started without worrying about hitting limits.
Built for what's coming
A repository and a review process built for one PR an hour looks different from one built for dozens. At Harness, we’ve reimagined both to hold up as that volume climbs, so teams do not need to rethink their workflows as the pace continues to change.
Our engineering team has been using Code Repository and AI Code Review on our own pipelines. With hundreds of developers contributing code, we’ve seen over 10,000 hours of savings over the last month by using AI Code Reviews. We’re excited to provide this benefit to other developers.
Developer self-service pipelines fail most often at the handoff between resource provisioning and production deployment. A service catalog might let developers scaffold a new microservice in seconds, but if they still need to file tickets to wire up CI/CD, provision environments, or update deployment configurations, the value proposition collapses. The friction reappears exactly where velocity matters most: the path from code commit to running production workload.
This article walks through how platform teams can connect internal developer portals to delivery pipelines in ways that preserve governance, maintain operational consistency, and genuinely accelerate deployment velocity. You will learn how to structure self-service workflows that trigger deployments, provision infrastructure, and manage promotion logic without sacrificing control or creating shadow pipelines that drift from organizational standards.
Why Self-Service Ends at the Pipeline Boundary
Most internal developer portals excel at initial service creation. Developers fill out a template, and the portal generates repositories, service definitions, and basic configurations. The problem surfaces when those outputs need to connect to existing CI/CD infrastructure.
Without integration, developers inherit manual wiring tasks: updating pipeline configurations, requesting environment access, configuring deployment targets, and aligning promotion policies with compliance requirements. Each step introduces latency, reduces reproducibility, and undermines the original promise of self-service velocity.
At scale, this pattern produces fragmentation. Teams build workarounds. Some write custom scripts that interact directly with pipeline APIs. Others maintain parallel tooling that duplicates functionality already present in the organization's CD platform. Eventually, platform teams lose visibility into what is actually running in production and how it got there.
The underlying issue is architectural. Portals that treat pipeline integration as an afterthought force developers to bridge the gap manually. Effective self-service deployment pipelines require the portal to function as a control plane that orchestrates pipeline execution, not just a UI that displays metadata.
Connecting Catalog Outputs to Pipeline Inputs
The simplest integration pattern involves passing service catalog outputs directly into pipeline execution contexts. When a developer provisions a new service through the portal, the workflow should automatically trigger pipeline creation or configuration with the necessary parameters already populated.
This requires three components working in concert:
Service metadata as structured data. The portal must expose service definitions in a machine-readable format that pipelines can consume. Ownership mappings, deployment targets, and compliance tags should live in the catalog, not hardcoded in pipeline configurations.
Pipeline templates aligned with golden paths. Platform teams define approved deployment patterns as reusable pipeline templates. When a developer creates a service of type "web application" or "batch job," the portal instantiates the corresponding pipeline template with service-specific values injected automatically.
Event-driven orchestration. Service creation events trigger pipeline provisioning through webhooks or API calls. Developers do not manually configure pipelines; the portal handles scaffolding based on service type and organizational policies.
This approach eliminates the context-switching problem. Developers interact with the portal, and the platform ensures that production delivery infrastructure materializes correctly without requiring deep pipeline domain knowledge.
Implementing Self-Service Promotion Logic
Production deployments rarely follow a single-step pattern. Services move through development, staging, and production environments with validation gates at each boundary. Self-service infrastructure provisioning becomes operationally viable only when promotion logic aligns with organizational risk tolerance.
Platform teams should encode promotion policies directly into portal workflows. When a developer requests a production deployment, the portal evaluates whether prerequisites are satisfied: required approvals obtained, test coverage thresholds met, security scans passed, and compliance checks completed.
The portal should not reimplement these checks. Instead, it queries existing systems: the CI platform for test results, the security scanner for vulnerability reports, and the approval system for sign-off records. The portal aggregates this information and either allows the promotion to proceed or surfaces specific blockers that require remediation.
This pattern keeps the portal lightweight while preserving governance. Developers gain visibility into why deployments are blocked and what actions will unblock them. Platform teams maintain centralized control over promotion criteria without forcing developers to navigate multiple disconnected systems.
Managing Environment Provisioning Through Portal Actions
Self-service deployment pipelines often require ephemeral environments for testing and validation. Developers need the ability to spin up isolated environments on demand without waiting for infrastructure teams to provision resources manually.
Effective implementations treat environment provisioning as a declarative workflow triggered through the portal. A developer selects "Create Preview Environment" from a service page, specifies configuration parameters like resource size and data fixtures, and the portal orchestrates environment creation through Infrastructure as Code tooling.
The key constraint: environments must remain tied to lifecycle policies. Preview environments should auto-expire after a defined period. Staging environments should align with branch protection rules. Production environments should require explicit approval workflows. The portal enforces these policies programmatically, preventing the accumulation of orphaned resources that increase cloud costs and create security exposure.
This requires the portal to maintain environment state and communicate it back to developers. A service overview page should display active environments, their expiration dates, and resource consumption metrics. Developers should be able to extend, delete, or reconfigure environments directly through the portal interface without filing tickets or running manual scripts.
Handling Pipeline Failures and Developer Feedback Loops
Deployment pipelines fail. Network timeouts occur, dependency versions conflict, and infrastructure quotas get exceeded. The difference between functional and dysfunctional self-service workflows lies in how failure information reaches developers.
Portal integrations should surface pipeline execution status in real time. When a deployment fails, the portal should display:
- Which stage failed and why.
- Relevant log excerpts filtered for actionable error messages.
- Links to full pipeline execution details in the underlying CI/CD platform.
- Suggestions for common remediation steps based on failure patterns.
This feedback loop must be fast. Developers should not need to leave the portal, navigate multiple tools, and correlate timestamps to understand why their deployment did not reach production. The portal aggregates execution data and presents it in context with the service they are trying to ship.
Platform teams benefit from this integration as well. By centralizing failure visibility, the portal becomes a diagnostic tool that reveals systemic issues: flaky tests that block promotions, infrastructure capacity constraints that throttle deployments, or configuration drift that causes environment-specific failures.
Common Pitfalls in Pipeline Integration
Treating the portal as a read-only dashboard. If developers can view pipeline status but not trigger deployments or modify configurations, the portal adds no operational value. Self-service requires write capabilities, not just observability.
Hardcoding environment-specific logic in portal workflows. When portal templates embed assumptions about specific cloud providers, Kubernetes clusters, or deployment tools, they become brittle. Abstractions should describe intent (deploy to production), not implementation (run kubectl apply against cluster XYZ).
Bypassing existing governance mechanisms. Portals that allow developers to bypass approval workflows, skip security scans, or override compliance policies create audit gaps and operational risk. Integration should enforce guardrails, not circumvent them.
Failing to handle partial failures gracefully. Service creation might succeed while pipeline provisioning fails. The portal should track these inconsistencies, surface them clearly, and provide remediation paths rather than leaving services in ambiguous states.
Ignoring the cost of portal maintenance. Every integration point between the portal and downstream systems introduces ongoing maintenance burden. Platform teams must monitor API changes, handle deprecations, and update integration logic as delivery infrastructure evolves. This operational cost is real and should factor into portal adoption decisions.
How Harness IDP Enables Pipeline Integration
Harness IDP is designed to centralize platform standards and enable self-service workflows across engineering teams. It treats pipeline integration as a first-class concern rather than a bolt-on feature.
When a developer provisions a service through Harness IDP, the platform can automatically scaffold corresponding CI/CD pipelines using Harness templates. Service metadata from the catalog flows directly into pipeline configurations, eliminating manual parameter entry and reducing configuration drift.
The platform provides visibility into service health and dependencies, aggregating execution status from Harness Pipelines alongside metrics from other integrated systems. Developers see deployment state, active environments, and failure diagnostics within a unified interface.
Governance guardrails align with platform policies. Harness IDP enforces promotion requirements by evaluating policy checks before allowing production deployments. Approval workflows, security scans, and compliance validations integrate directly into the self-service experience without requiring developers to context-switch across multiple tools.
For platform teams building multi-module workflows, Harness IDP coordinates inputs and outputs across the Harness platform. A service created in the portal can trigger a Harness Pipeline, which provisions infrastructure and deploys workloads while maintaining traceability and audit logs throughout the delivery lifecycle.
Developer self-service pipelines succeed when portals treat delivery infrastructure as a core integration target, not an external system that developers interact with separately. By connecting service catalogs to CI/CD platforms, enforcing governance through automated policy checks, and surfacing deployment status in real time, platform teams enable developers to ship to production without sacrificing control or visibility.
The technical implementation requires deliberate design: structured service metadata, versioned pipeline templates, event-driven orchestration, and feedback loops that surface failures quickly. When these components work together, the portal becomes a control plane that coordinates delivery workflows rather than just a directory of available services.
For organizations running Harness Pipelines alongside other delivery tooling, Harness IDP provides native integration that reduces the engineering effort required to build these workflows manually. The platform handles pipeline scaffolding, promotion logic, and governance enforcement as built-in capabilities rather than custom scripts platform teams must maintain independently.
Start by identifying one high-frequency workflow where manual pipeline configuration creates friction. Build a self-service path through your portal that eliminates that handoff. Measure the reduction in time-to-first-deployment and developer toil. Then expand to additional service types and deployment patterns incrementally.
Guardrails enable speed at scale. Self-service deployment pipelines work when the easy path is also the compliant path.
Frequently Asked Questions
How do I prevent developers from bypassing pipeline governance through the portal?
The portal should integrate with existing approval systems rather than reimplement them. When a developer requests a production deployment, the portal queries the approval service, verifies required sign-offs exist, and blocks the action if prerequisites are unmet. This ensures governance policies remain centralized and enforceable.
What happens when a pipeline template changes after services are already provisioned?
Platform teams should version pipeline templates and communicate breaking changes through the portal. Services using older template versions should display deprecation warnings with migration instructions. Automatic migrations are risky; allow teams to upgrade pipelines during planned maintenance windows.
Can the portal trigger deployments across multiple environments simultaneously?
Yes, but this pattern often violates promotion policies. Most organizations require staged rollouts with validation between environments. The portal should support parallel deployments only when compliance and risk management practices explicitly allow it.
How do I handle pipeline integration when teams use different CI/CD tools?
The portal should abstract deployment intent from tool-specific implementation. Define a common interface for triggering deployments and querying execution status, then implement adapters for each underlying CI/CD platform. This keeps portal workflows consistent even when delivery tooling varies.
Should the portal manage secrets required by deployment pipelines?
No. Secrets management should remain the responsibility of dedicated secret stores. The portal can reference secret identifiers and pass them to pipelines, but it should never store or display sensitive credentials directly.
Your internal developer platform golden paths launched three months ago. Adoption sits at 11 percent. The service catalog has 247 entries, half of them outdated. Developers still Slack the platform team for every deployment. What happened?
You built a directory when you needed a decision engine.
The Service Catalog Trap
Most organisations treat their IDP service catalog as an inventory system. They catalogue everything: microservices, databases, Kafka topics, S3 buckets, Lambda functions. The catalog grows. Ownership metadata gets assigned. YAML files proliferate. Platform teams celebrate visibility.
Then adoption stalls.
The catalog answers "what exists" but not "what should I use" or "how do I start." Developers face analysis paralysis. They see 30 PostgreSQL instances and no guidance on which pattern fits their use case. They find a React template from 2019 alongside one from last quarter with no indication of which is current. The self-service promise collapses into a support ticket.
Catalogs document the past. Golden paths encode the future you want to build.
Why Golden Paths Succeed Where Catalogs Fail
Golden paths are opinionated, maintained workflows that represent your organisation's current best practices. They are not the only way to do something. They are the recommended way, backed by real operational learnings and actively maintained by the platform team.
A golden path for deploying a new API service might include:
- Standard observability instrumentation and error tracking.
- Database provisioning with backup policies already applied.
- Load balancer configuration aligned with your traffic patterns.
- Deployment guardrails that prevent common production mistakes.
The path embeds decisions developers would otherwise make inconsistently. It trades flexibility for speed and reliability at scale.
Platform Engineering Golden Paths vs. Unrestricted Self-Service
Unrestricted self-service sounds empowering until you scale past 50 services. Without guardrails, you get:
- Sixteen different logging formats that your observability stack cannot correlate.
- Drift across deployment strategies that break rollback assumptions.
- Database instances provisioned without backup schedules or retention policies.
- CI pipelines missing mandatory security scans because they were optional.
Developer self-service platform capabilities succeed when they channel creativity within proven boundaries. Golden paths provide those boundaries without feeling restrictive. Developers get speed. Platform teams get consistency. Security and reliability become byproducts of the workflow rather than afterthoughts.
Building Internal Developer Platform Golden Paths That Scale
Start With One Path, Not Six
The instinct is to build golden paths for every major workflow simultaneously. This guarantees none of them ship complete.
Pick the most frequently repeated workflow where variance causes the most operational pain. For many teams, this is deploying a stateless API service. Build one excellent path that handles 80 percent of cases. Ship it. Measure adoption. Iterate based on real feedback before expanding.
A complete golden path needs:
- A service template that generates working code, not just scaffolding.
- CI and CD pipeline definitions that handle build, test, and deployment.
- Observability defaults that provide useful dashboards immediately.
- Documentation that explains when to use this path and when to deviate.
Make the Path the Default, Not an Option
If your golden path lives alongside six other ways to accomplish the same task, developers will choose based on familiarity rather than best practice. The path must be the obvious starting point.
This means:
- New service requests default to the golden path template.
- Deviations require explicit justification, not permission.
- The path is prominently featured in your IDP service catalog.
- Onboarding documentation assumes developers will use it.
The goal is not rigidity. The goal is to make the right choice the easy choice.
Instrument Adoption and Iteration
An IDP implementation guide should treat golden paths as products with lifecycle management. That means measuring:
- Time from template instantiation to first successful deployment.
- Percentage of new services using the golden path versus custom approaches.
- Support ticket volume related to golden path services versus others.
- Frequency of path updates based on production learnings.
If adoption remains low after two months, the path is solving the wrong problem or introducing too much friction. Treat this as a signal to iterate, not to build more paths.
The IDP Paved Roads Maintenance Problem
Golden paths decay without active maintenance. A path built on Kubernetes 1.24 becomes a liability when your clusters upgrade to 1.28 and deprecate critical APIs. A CI template referencing a deprecated security scanner becomes a compliance risk.
Service catalog best practices require treating paths as living infrastructure:
- Assign clear ownership with on-call responsibilities.
- Run automated tests against paths in staging environments.
- Version paths and communicate breaking changes with migration guides.
- Sunset outdated paths explicitly rather than letting them linger.
Many organisations launch golden paths as projects and wonder why they fail as products. Products need roadmaps, support processes, and feedback loops. Paths need the same.
When Catalogs and Golden Paths Work Together
A mature developer experience platform uses both. The service catalog provides discovery and ownership context. Golden paths provide opinionated starting points and standardised workflows.
The catalog shows what exists. Paths show what to build next. Together, they create a self-reinforcing system where new services follow established patterns, making the catalog more useful and paths more validated.
This requires intentional integration:
- Golden path templates automatically register services in the catalog.
- Catalog entries link back to the path used for creation.
- Drift detection flags services that diverge from their originating path.
- Path usage metrics inform which catalog entries are actively maintained.
Harness IDP Perspective: Platform Engineering Best Practices at Scale
Harness IDP was designed to centralise platform standards and enable self-service workflows across engineering teams without forcing teams into rigid catalog-only thinking.
The platform treats golden paths as first-class constructs through software templates that combine scaffolding, infrastructure provisioning, and CI/CD pipeline generation. A developer instantiates a template, and the platform handles service registration, repository creation, pipeline setup, and initial deployment in a single workflow.
Key capabilities include:
- Service catalog and ownership mapping that tracks which golden path generated each service.
- Self-service templates and golden paths with versioning and rollback support.
- Standardised CI and CD scaffolding that embeds security scanning and compliance checks.
- Visibility into service health and dependencies through centralised dashboards.
- Governance guardrails aligned with platform policies that prevent drift.
- Integration with source control, pipelines, and infrastructure workflows.
The platform assumes paths will evolve. Template versioning allows gradual migration rather than forced upgrades. Rollback capabilities let teams revert if a path update introduces issues. This operational maturity prevents the common failure mode where golden paths become abandoned prototypes.
For teams scaling beyond basic self-service, Harness IDP provides patterns for multi-environment promotion, dependency management, and progressive rollout of path updates. These are not theoretical features. They solve the actual problems that appear when 20 teams try to adopt the same golden path simultaneously.
Conclusion
Service catalogs answer "what do we have." Golden paths answer "what should we build and how". The difference determines whether your internal developer platform becomes adopted infrastructure or abandoned overhead.
Start with one excellent path. Measure adoption ruthlessly. Maintain it like production infrastructure. Expand only when the first path proves valuable. Treat the path as a product with users who need support and a roadmap that evolves with operational learnings.
The goal is not to catalogue everything. The goal is to make the right patterns effortless and the wrong patterns obvious. That shift turns platforms from documentation systems into decision engines that scale engineering velocity without sacrificing reliability.
Why does achieving continuous delivery excellence feel like pushing water uphill when you already have CI/CD pipelines in place?
The problem is not the pipeline technology. It is the cognitive overhead surrounding it. Your developers spend more time navigating Slack threads about deployment permissions, hunting down environment configuration, and reverse-engineering service dependencies than actually shipping code. Meanwhile, your platform team fields the same integration questions every sprint, and your release velocity stalls because nobody trusts the golden path enough to use it consistently.
This is the reality of continuous delivery at scale. The tooling exists. The automation exists. What breaks down is the interface between platform capabilities and developer adoption. When deployment workflows remain tribal knowledge rather than encoded standards, continuous delivery becomes continuous friction.
The Gap Between Pipeline Capability and Delivery Velocity
Most organizations treat continuous delivery as a pipeline problem. They invest in sophisticated CI/CD orchestration, implement comprehensive testing frameworks, and automate infrastructure provisioning. Then they wonder why deployment frequency remains flat and lead time continues to drift upward.
The issue is abstraction mismatch. Your pipelines may be perfectly capable of handling complex deployment topologies, but if developers cannot discover how to trigger them, understand their prerequisites, or determine which pipeline applies to their service, that capability becomes effectively unavailable. You have built automation that requires manual intervention to use.
This manifests in predictable failure modes. Teams create shadow pipelines because the official ones are too opaque to configure. Service ownership becomes unclear because there is no single source of truth mapping teams to deployments. Environment promotion stalls because approval workflows exist in multiple systems without a unified state model. Each workaround adds technical debt that compounds deployment complexity.
Platform engineering teams recognize this pattern. They know that developer experience automation is not about building more features into the pipeline. It is about reducing the cognitive load required to use the pipeline correctly. The challenge is doing this without fragmenting standards or creating one-off solutions that do not scale.
Service Catalog Deployment as the Missing Integration Layer
An internal developer portal continuous delivery model treats the service catalog as the authoritative source of deployment context. Instead of requiring developers to maintain separate service definitions in multiple systems, the catalog becomes the integration point that connects service metadata to pipeline execution.
This changes the deployment contract. Rather than expecting developers to know which Jenkins job, GitHub Action, or deployment script applies to their service, the portal maps catalog entries directly to standardized deployment workflows. A service registered in the catalog automatically inherits the correct pipeline configuration, environment promotion logic, and governance guardrails based on its metadata.
The operational benefit is consistency. When every service follows the same registration and deployment pattern, platform teams can enforce policies at scale without manual review. Developers gain self-service deployment platform access without needing deep knowledge of the underlying pipeline infrastructure. The catalog becomes both the interface and the control plane for continuous delivery.
This approach also solves the ownership problem. Service catalog entries define not just what gets deployed, but who owns it, which team maintains it, and what dependencies exist. When a deployment fails, the on-call engineer does not need to hunt through Git history or Slack channels to determine responsibility. The catalog metadata makes ownership explicit and actionable.
IDP Workflow Orchestration Across the Delivery Lifecycle
Platform engineering CD pipelines become more than isolated automation scripts when orchestrated through a unified developer portal. The portal acts as the coordination layer that connects service definition, build execution, deployment triggering, and observability feedback into a coherent workflow.
Consider environment promotion. In traditional setups, developers manually trigger deployments to staging, wait for validation, then trigger production separately. Each step requires context switching between systems, manual verification of prerequisites, and tribal knowledge about approval requirements. The portal consolidates this into a single orchestrated flow where service metadata drives progression logic.
This does not mean embedding all pipeline logic into the portal. The portal remains the control plane while delegating execution to specialized tools. A developer initiates deployment through a standardized interface. The portal validates prerequisites based on service catalog metadata, triggers the appropriate pipeline in the underlying CI/CD system, tracks promotion state across environments, and surfaces deployment status alongside service health metrics.
The workflow orchestration extends beyond deployment execution. Pre-deployment checks verify that infrastructure dependencies exist, required secrets are configured, and governance policies are satisfied. Post-deployment validation confirms that health checks pass and observability signals match expected baselines. Rollback procedures become self-service actions tied directly to the deployment record rather than undocumented runbooks.
This orchestration model scales because it separates concerns correctly. Pipeline engineers focus on optimizing build and deployment mechanics. Platform engineers define golden paths and governance boundaries. Application developers interact with a consistent interface regardless of underlying complexity. Each layer operates independently while the portal maintains coordination state.
Continuous Delivery Best Practices Through Enforced Standards
Developer portal DevOps integration is not about exposing every configuration option. It is about encoding continuous delivery best practices into the default path. When developers create a new service through the portal, they automatically receive a deployment pipeline that implements your organization's standards for testing, security scanning, artifact management, and progressive delivery.
This opinionated approach reduces variability. Instead of every team making independent decisions about deployment strategy, the portal templates encode proven patterns. If your organization has determined that canary deployments with automated rollback are the safest approach for production releases, that becomes the default behavior for all services. Deviation requires explicit justification rather than accidental drift.
The enforcement mechanism is subtle but effective. Developers are not blocked from customization, but the path of least resistance is the standardized workflow. The portal makes it easier to follow best practices than to work around them. This shifts the burden of governance from reactive review to proactive design.
Documentation becomes embedded in the workflow itself. Rather than maintaining separate runbooks that describe how to deploy services, the portal surfaces contextual guidance at each decision point. Developers see inline explanations of why certain prerequisites exist, what each approval gate validates, and how to troubleshoot common deployment failures. The knowledge is distributed at the point of use rather than centralized in wikis that become stale.
Harness IDP: Connecting Service Catalogs to Continuous Delivery
Harness Internal Developer Portal addresses these integration challenges by treating the service catalog as the foundation for deployment orchestration. Instead of requiring developers to maintain service definitions separately from pipeline configuration, IDP provides a unified model where catalog entries drive deployment behavior.
When a service is registered in Harness IDP, it inherits standardized CI/CD scaffolding aligned with your platform policies. The catalog defines service ownership, dependencies, and deployment requirements as structured metadata. This metadata then controls which pipelines are available, what approval workflows apply, and how environment promotion progresses. Developers trigger deployments through self-service templates that validate prerequisites and enforce governance guardrails before execution.
The portal integrates directly with Harness Continuous Delivery pipelines, creating a closed-loop workflow from service definition to production deployment. A developer initiates deployment through the IDP interface. The portal validates that required infrastructure exists, secrets are configured, and policies are satisfied. It then triggers the appropriate Harness CD pipeline, tracks execution state across environments, and surfaces deployment status alongside service health metrics in a single view.
This integration extends to rollback and incident response. When a deployment fails or causes operational issues, the portal provides immediate access to rollback procedures tied to the specific deployment record. On-call engineers do not need to reconstruct deployment history or hunt through multiple systems to determine what changed. The service catalog maintains a complete audit trail of what was deployed, when, by whom, and what observability signals followed.
Platform teams configure golden paths once at the catalog level rather than reimplementing them for each service. A new microservice automatically receives the same deployment standards, security scanning, and progressive delivery patterns as existing services. Policy changes propagate consistently because they are defined in catalog templates rather than scattered across individual pipeline configurations.
For organizations running multi-module workflows, Harness IDP connects service catalog definitions to infrastructure provisioning and feature flag management. A service registered in the portal can declare its infrastructure dependencies, and those dependencies are validated before deployment proceeds. Feature flag state becomes queryable alongside deployment history, making it easier to reason about what is actually running in each environment.
Building Continuous Delivery Excellence Through Platform Standardization
Continuous delivery excellence is not achieved by optimizing individual pipeline steps. It emerges from reducing the cognitive load required to deploy reliably at scale. When deployment workflows are encoded as platform standards rather than tribal knowledge, developers spend less time navigating process and more time shipping features.
The service catalog becomes the integration point that connects all continuous delivery concerns: service ownership, deployment pipelines, environment state, observability feedback, and incident response. By treating the catalog as the authoritative source of deployment context, platform teams can enforce governance without creating friction. The golden path becomes the obvious path because it is embedded in the workflow itself.
Organizations that achieve continuous delivery excellence recognize that tooling alone is insufficient. The socio-technical system surrounding deployment determines whether automation accelerates or impedes velocity. A developer portal that unifies service definition, pipeline orchestration, and operational visibility reduces fragmentation and makes best practices the default behavior.
If your deployment velocity is constrained by process overhead rather than pipeline capability, the interface layer between platform standards and developer workflows is where you should focus. Explore how Harness IDP reduces deployment friction and accelerates continuous delivery by providing self-service access to standardized pipelines.
Your executive team wants to see measuring IDP success in numbers, but the moment you start tracking individual developer keystrokes, you've already lost the trust that makes the platform worth building. The real question isn't whether your portal reduces mean time to first commit by three minutes per developer—it's whether teams are choosing to use it when they have other options.
Platform engineering teams face a paradox. Leadership demands ROI metrics that justify continued investment. Developers demand autonomy and privacy. Most organizations respond by instrumenting everything, then wondering why adoption stalls despite perfect uptime and comprehensive feature sets. The tension isn't philosophical—it's operational. Surveillance-based metrics optimize for the wrong outcomes while eroding the psychological safety that enables genuine productivity gains.
Why Traditional Developer Productivity Metrics Fail at Scale
Individual activity tracking creates perverse incentives that platform teams cannot afford. When developers know their commit frequency, lines of code, or story point velocity are being measured, behavior shifts in predictable ways. They batch commits to game frequency metrics. They split meaningful changes into artificial increments to inflate velocity. They avoid experimental work that might reduce their apparent productivity.
These distortions compound at organizational scale. A platform that measures individual API endpoint usage will see developers route requests through proxies or shared accounts. One that tracks template adoption by team will see teams gaming ownership assignments. The metrics become unreliable precisely when they're treated as performance indicators rather than system health signals.
The second-order effects are worse. Developers stop asking questions in internal channels when those interactions might be logged as "blockers." They avoid trying new platform capabilities that could temporarily reduce their velocity. Platform teams lose the qualitative feedback loops that identify real friction points, leaving them optimizing vanity metrics while core workflows remain broken.
Outcome-Based IDP ROI Measurement That Respects Privacy
Effective developer portal metrics focus on system-level outcomes rather than individual behavior. Measuring IDP success means tracking the collective results of platform adoption, not the activities of individual engineers. These metrics align with business objectives while preserving developer autonomy.
Deployment frequency at the service or team level reveals whether the portal's scaffolding and CI/CD integrations actually reduce time to production. A well-designed IDP should flatten the learning curve for new services, making deployments more frequent across the organization without requiring individual tracking. If deployment frequency increases after introducing golden path templates, that's signal. If it doesn't, the templates aren't solving real problems.
Mean time to recovery (MTTR) indicates whether the portal's service catalog and ownership mapping accelerate incident response. When oncall engineers can quickly identify service dependencies, ownership contacts, and runbook locations through a centralized catalog, MTTR drops. This improvement is measurable at the organizational level without knowing which specific engineer used which feature during which incident.
Service standardization rates measure whether teams are adopting platform patterns. Track the percentage of services that conform to organizational standards for observability, security scanning, or infrastructure provisioning. These are platform engineering KPIs that demonstrate governance effectiveness without individual surveillance. If 40 percent of services lack standardized logging six months after introducing an IDP, that's a platform design problem, not a developer compliance issue.
Platform Success Indicators That Build Trust
Internal developer portal analytics should measure engagement patterns rather than individual actions. Track aggregate template usage—how many services were bootstrapped from the Python microservice template this quarter versus how many were created manually. This indicates whether the golden path is genuinely easier than the alternative.
Monitor self-service workflow completion rates at the system level. If 80 percent of infrastructure requests complete without manual intervention, the workflows are well-designed. If completion rates drop after a UI change, you've introduced friction. These developer experience measurement approaches identify problems without attributing blame.
Time to first deployment for new services reveals onboarding effectiveness. This IDP adoption metric measures the platform's ability to reduce cognitive load for teams starting new projects. Compare average time to first deployment before and after introducing service scaffolding, measured across all teams rather than by team. The goal is demonstrating that the platform removes repetitive setup work, not ranking team performance.
Documentation freshness across the service catalog indicates whether teams trust the portal enough to maintain their information there. If service ownership records are consistently updated within 48 hours of team changes, the portal has become operationally critical. If they drift for weeks, teams are maintaining a source of truth elsewhere, and your adoption is shallower than it appears.
Building Developer Portal Metrics That Scale
The distinction between surveillance and measurement lies in granularity and purpose. Aggregate metrics that inform platform improvements respect privacy. Individual metrics that influence performance reviews do not. This boundary must be explicit in your metrics strategy.
Consider API usage patterns. Tracking which teams call which platform APIs helps identify adoption gaps and integration opportunities. Tracking which individuals call which APIs at what frequency enables micro-management and breeds resentment. The platform team needs the former; the latter actively damages the cultural alignment required for platform success.
Similarly, measuring average time to complete a self-service workflow across all users identifies bottlenecks in the interface. Measuring completion time per user creates anxiety and optimizes for speed over thoughtful decision-making. Platform teams should optimize workflows based on P50 and P95 aggregate times, not individual outliers.
Error rates in platform interactions matter more than individual failures. If 15 percent of attempts to provision infrastructure through the portal result in errors, that's a reliability problem requiring immediate attention. If those errors are concentrated in one team's attempts, reach out to understand their specific context rather than treating their error rate as a performance metric.
How Harness IDP Enables Privacy-Respecting Success Measurement
Measuring IDP success requires tooling designed around outcome-based metrics rather than surveillance. Harness IDP provides analytics that respect developer privacy while giving platform teams the visibility they need to demonstrate ROI and guide improvements.
The platform tracks service catalog adoption through aggregate metrics—total services registered, percentage meeting organizational standards, average time to catalog a new service. These platform engineering KPIs inform whether the catalog is becoming the source of truth for service metadata without exposing individual contribution patterns.
Harness IDP's template usage analytics show which golden paths are genuinely reducing toil. Platform teams can see that 60 percent of new Python services use the standard template, indicating successful paved road adoption. They can identify that the Golang template has low usage despite many Golang services, suggesting the template doesn't match real workflows. This developer productivity measurement happens at the organizational level, preserving individual team autonomy.
Self-service workflow metrics in Harness IDP focus on completion rates and bottlenecks rather than individual performance. The platform identifies which approval steps cause the most abandonments, which integrations have the highest error rates, and which workflows take longer than expected. These insights drive platform improvements without requiring individual-level tracking.
Service health visibility through Harness IDP's integrations with deployment pipelines and monitoring tools provides context for measuring platform impact. Teams can correlate portal adoption with improved deployment frequency and MTTR at the organizational level. This IDP ROI measurement demonstrates business value without invasive developer monitoring.
The key is treating the portal as infrastructure that should be measured like any other infrastructure component—uptime, throughput, error rates, adoption patterns. Harness IDP's analytics follow this principle, providing internal developer portal analytics that inform platform strategy while respecting the privacy that builds developer trust.
Measuring What Actually Matters
The most reliable indicator of platform success is whether developers voluntarily choose it when alternatives exist. This isn't measured through surveillance—it's measured through adoption patterns that emerge when the platform genuinely reduces cognitive load and accelerates delivery.
Build your metrics strategy around system-level outcomes that align with business objectives. Track deployment frequency, MTTR, and standardization rates. Monitor template adoption and workflow completion rates. Measure time to first deployment for new services. These developer experience measurement approaches demonstrate ROI while building the trust that makes platforms successful.
The organizations that build effective internal developer platforms understand that measurement exists to inform platform improvements, not to rank developer performance. When your metrics strategy respects privacy, teams engage authentically with the platform. When it doesn't, they route around it, and your metrics become meaningless anyway.
Start with aggregate outcomes. Build feedback loops that identify friction without attribution. Treat platform adoption as the leading indicator it actually is. The numbers that matter emerge naturally when the platform solves real problems—and those numbers don't require tracking individual developers to be meaningful.
DevOps is a culture and set of practices that ship software. Platform engineering builds the self-service tooling that scales those practices.
45% of developers name context switching between tools as a top source of friction (Harness State of Engineering Excellence 2026) — exactly the toil an internal platform removes.
Adopt platform engineering when DevOps practices work but stop scaling: duplicated pipelines, slow onboarding, and platform teams running help desks.
AI shifts the delivery bottleneck downstream, making governed self-service and policy-as-code essential, not optional, at every gate.
What is the difference between DevOps and platform engineering?
DevOps is a culture and practice that gets development and operations teams to collaborate, automate, and ship software faster and more reliably. Platform engineering is the discipline that builds the internal tooling and self-service infrastructure that makes those DevOps practices repeatable at scale. Put simply: DevOps is the goal; platform engineering is one of the most effective ways to reach it across many teams.
DevOps answers "how do we work together to ship safely and often."
Platform engineering answers "how do we make that easy for every developer, without a ticket."
The software engineering platform is the product a platform team builds so developers get a supported path to production instead of raw infrastructure.
Quick facts: DevOps vs platform engineering
What is DevOps
A culture and set of practices that align dev and ops teams to ship software faster and more reliably, measured by DORA metrics.
What is platform engineering
Designing and running the internal developer platform, workflows, and golden paths developers use to self-serve safely.
Developer time lost to toil
81% of engineering leaders say code review time has risen since adopting AI, and 94% admit developer burnout and validation time are missing from their metrics (Harness State of Engineering Excellence 2026).
Onboarding time
Two months on average for a new developer to reach productivity, per published industry benchmarks.
Relationship
Complementary. Platform engineering scales DevOps into a repeatable system every team can use on demand.
Your developers are shipping code faster than ever. The pipeline that has to test, secure, and release it has not kept up. So the same question keeps landing on engineering leaders' desks: double down on DevOps, or stand up a platform engineering team?
The framing is wrong. DevOps and platform engineering solve different parts of the same problem, and the strongest teams treat them as one system, increasingly a single software engineering platform that runs both. Below, where each earns its keep, when to invest in platform engineering, and how AI changes the calculation.
What is DevOps? A quick refresher
DevOps is a culture and set of practices that get development and operations working off the same goals: automate the path to production, share ownership of what ships, and improve in tight loops instead of big releases. In practice that means CI/CD pipelines, infrastructure as code, monitoring, and a "you build it, you run it" mindset, all measured by flow. DORA's four key metrics answer the question: can a change get from commit to production quickly, safely, and often?
What DevOps does not prescribe is who builds the shared tooling, or how a 500-developer org keeps every team on the paved road. That gap is where platform engineering comes in.
What is platform engineering?
Platform engineering is the discipline of designing and running the internal tools, workflows, and self-service infrastructure developers rely on to ship software. The output is usually an internal developer platform (IDP): a self-service layer between developers and the infrastructure underneath.
The defining move is the product mindset. A platform team treats its platform as a product, with real users, a roadmap, and adoption metrics. Nobody is forced to use it. It has to be good enough that developers want to.
A platform usually bundles a few core pieces:
Golden paths: the supported way to spin up and ship a service, so nobody reinvents the setup.
A software catalog: one searchable place for services, owners, dependencies, and APIs.
Self-service workflows: provision an environment or onboard a repo without filing a ticket.
Scorecards: automated checks that hold each service to your security, reliability, and compliance bar.
The goal is not only speed. It is cutting the cognitive load on developers so they spend their time on product work, not on infrastructure plumbing they should not have to think about.
How do DevOps and platform engineering compare, side by side?
One is about how teams work. The other is about what you build so that work scales.
Dimension
DevOps
Platform engineering
Primary goal
Faster, more reliable delivery via collaboration
Less developer friction via governed self-service
What it is
A culture and set of practices
A discipline that builds an internal product
Audience
The whole dev and ops org
Developers, treated as platform customers
Main output
Pipelines, automation, shared ownership
An internal developer platform with golden paths
Mindset
Break down silos
Treat the platform as a product
Key metrics
DORA: deploy frequency, lead time, MTTR, change failure rate
Adoption, onboarding time, developer satisfaction
Fails when
Every team reinvents the toolchain
Nobody adopts a platform built in a vacuum
Platform engineering does not compete with DevOps. It is what you reach for when those practices work but do not scale, when every team keeps solving the same provisioning problems alone.
When should you invest in platform engineering?
Not at the start. With a handful of developers, a shared pipeline and good habits beat a dedicated platform team. Platform engineering earns its cost when the friction of not having a platform outweighs the cost of building one.
What signals indicate your team is ready?
A few concrete tells, not impressions:
Developers lose an hour or more a day to deployment, environment, or infrastructure work. Time that should go to product, not plumbing.
DevOps has quietly become a help desk, fielding the same provisioning tickets repeatedly.
New-service setup takes days. Onboarding a new developer drags toward the two-month industry average.
Every team runs its own snowflake pipeline.
How does the business case stack up?
It comes down to math. A platform team is a fixed investment that buys back time across every other team. For enterprise and regulated teams the upside compounds, because a standardized platform is where you enforce security and compliance by default, not by audit.
What can go wrong with a platform investment?
Three failure modes worth pressure-testing. First, building a platform nobody adopts because it was designed in isolation from the developers it serves. Second, treating the platform as a finished project rather than a product, so it stops evolving and developers route around it. Third, layering self-service on top of weak governance, which speeds up the wrong things and creates compliance risk faster than DevOps alone would have.
How does AI change the DevOps and platform engineering equation?
AI does not settle the DevOps-versus-platform-engineering question. It makes it urgent. When AI assistants help developers write code several times faster, the bottleneck moves downstream, to everything that tests, secures, and releases that code. More code only helps if delivery can absorb it.
Harness calls this the AI Velocity Paradox: faster code creation without faster delivery infrastructure shifts the same risk further down the line. The fix is not slower coding. It is stronger delivery.
The pressure lands on both sides. DevOps with AI reshapes the pipeline: AI-assisted code review, smarter test selection, and automated remediation that rolls back bad changes. For platform teams, it raises the bar on self-service. GitOps-based delivery keeps your desired state in version control, so every change is reviewed, auditable, and reversible. That is what lets AI-driven automation move fast without moving recklessly.
How Harness approaches DevOps and platform engineering
The "versus" framing breaks down because mature teams need both at once, on the same software engineering platform. Harness is built for that: the AI-native Software Delivery Platform that automates and governs the after-code lifecycle, serving DevOps automation and platform-engineering self-service from one place.
The challenge
DevOps teams want fast, automated CI/CD. Platform teams want self-service with standards baked in. Bolt those together from separate point tools and governance becomes an afterthought spread across both. The handoffs leak audit trails, dilute policy enforcement, and shift toil from developers to platform teams.
Teams reduce toil and ticket queues, onboard developers and services in a fraction of the time, and ship faster without giving up control. The versus debate dissolves, because both DevOps automation and governed self-service run on one foundation. Hundreds of engineering teams trust Harness to consolidate point tools and remove manual interventions.
How engineering teams pair DevOps and platform engineering at scale
Two patterns, two stacks, one outcome: the work that used to repeat across teams stops repeating.
United Airlines
United Airlines moved CI and CD onto Harness, giving developers self-service deployments with governance enforced through templates rather than tickets. The company reported a 75% acceleration in deployment time and migrated 80% of workloads to the cloud (United Airlines case study).
“By choosing Harness for CI and CD, we were able to give the governance policies to the developers and create the guardrails we needed. Harness gives us a platform rather than just a DevOps tool.”
Ratna Devarapalli, Director of IT, Architecture, Platform Engineering & DevOps, United Airlines
With Harness, all Terraform plans and applies run concurrently. Pushing upgrades to Kubernetes clusters is 4x faster than it used to take with Terraform Cloud.
John Maynard, Director of Platform Engineering, PlayQ
Stop choosing, start combining
The honest answer to "DevOps or platform engineering" is that it was never an either-or. DevOps gives you the culture and practices. Platform engineering turns them into a software engineering platform every team can use on demand. One is the goal; the other is how you reach it at scale.
Pick the foundation that lets DevOps automation and governed self-service run together, and let developers spend their time on the product instead of the plumbing. See how Harness brings both together as one AI-native platform.
Platform Engineering vs DevOps: How a Software Engineering Platform Unites Both
A DevOps automation platform connects build, test, deploy, security, and rollback in one workflow instead of a stack of disconnected scripts.
An automation tool automates one step; a platform is workflow-aware and connects every step with shared context, permissions, and audit trail.
DORA 2025: 90% of technology professionals now use AI at work, and that speed lifts delivery throughput but raises instability unless your automation can absorb the extra change safely.
An AI-native platform recommends which tests to run, diagnoses failures, and remediates issues rather than just executing the steps you scripted.
What is a DevOps automation platform?
A DevOps automation platform is an integrated system that automates the repetitive, error-prone work across the software delivery lifecycle, covering builds, tests, deployments, security checks, and rollbacks in one place. Instead of wiring scripts and point tools together by hand, you get one workflow-aware platform that moves code from commit to production with less manual handoff.
What it replaces: a patchwork of point tools, each automating one step and none aware of the others.
What it automates: CI pipelines, deployment automation, infrastructure provisioning, security scanning, and incident response.
What "AI-native" adds: test selection, failure diagnosis, anomaly detection, and auto-remediation.
Who it's for: platform, DevOps, and engineering teams losing time to toolchain handoffs.
Quick facts: DevOps automation platform
What it is
An integrated system that automates the after-code lifecycle: build, test, secure, deploy, operate
Tool vs platform
A tool automates one step; a platform connects every step with shared context, permissions, and audit trail
Tool sprawl
60% of teams run more than five tools for software development (GitLab 2025)
Platform Advantage
90% of organizations now run at least one internal platform, and platform quality correlates directly with turning AI speed into results (DORA 2025)
87% of codebases carry at least one open-source vulnerability (Black Duck OSSRA 2026)
Walk into most engineering orgs and you will find too much automation, not too little, scattered across a CI runner here, deploy scripts there, and a monitoring tool nobody fully owns. What eats the week is wiring those scripts together and chasing what broke in the gaps between them. A DevOps automation platform folds that sprawl into one workflow, so engineers ship software instead of babysitting the glue.
What is the difference between an automation tool and a DevOps automation platform?
The difference decides whether automation actually pays off.
An automation tool does one job. Ansible configures servers, a CI runner executes builds, and a Terraform file provisions infrastructure. Each is good at its slice but blind to what runs before or after it. So you wire the slices together yourself, and every handoff drops context or triggers a manual step at 2 a.m.
A DevOps automation platform is workflow-aware. A build feeds a test stage, which feeds a deployment, which feeds a rollback policy, all sharing one context, one set of permissions, and one audit trail. With 60% of teams running more than five tools (GitLab 2025), the integration tax across those stacks is the real cost, not the tools themselves. Point automation speeds up a step. Platform automation speeds up the system.
What does a DevOps automation platform automate?
Automation takes repeatable work off your engineers across four areas. The table below maps what a platform replaces and why it matters.
Manual today
Automation replaces it with
Benefit
Hand-run builds and test suites
CI pipelines with caching and test intelligence
Faster feedback, fewer flaky builds
Click-ops deploys and overnight windows
Deployment automation with canary and blue-green
Ship in daylight, no big-bang risk
Manual approvals and security reviews
Security scanning in the pipeline
Issues caught early, audit trail by default
Manual incident diagnosis and rollback
AI-assisted failure diagnosis and auto-rollback
Faster MTTR, fewer late-night pages
On security: with 84% of codebases carrying at least one open-source vulnerability (Synopsys OSSRA 2024), in-pipeline scanning via Application Security Testing stopped being optional a while ago. The question is whether the scan happens inside your pipeline with an audit trail, or outside it where developers route around it.
What is an AI-native DevOps automation platform?
Rule-based automation runs the steps you scripted, the same way every time. An AI-native platform adds a layer that reads the situation and decides.
The difference shows up the moment something goes sideways. A scripted pipeline runs all 4,000 tests on a one-line change, then pages a human when it breaks. An AI-native one runs only the 40 tests that touch the change, and when something breaks it reads the logs, names the likely cause, and can roll back on its own. Test selection, failure diagnosis, anomaly detection, auto-remediation: all of it comes from one shift. The automation weighs what is in front of it instead of blindly running the steps.
Among teams leaning hardest on AI coding tools, 22% of deployments end in a rollback, hotfix, or incident (Harness, 2026 State of Engineering Excellence). When change volume climbs, scripted automation cannot tell a safe change from a risky one. That judgment is what an AI-native platform, grounded in the Software Delivery Knowledge Graph, adds.
How should you evaluate a DevOps automation platform?
Not every platform automates the same breadth, and the gaps are where bottlenecks hide. Run any candidate through this checklist:
Automation coverage. Does it span the full software delivery lifecycle (CI, CD, security, infrastructure, cost, incident response), or just a slice?
AI capabilities. Does the AI act on the pipeline (selecting tests, diagnosing failures, remediating), or only report on it from the sidelines?
Pipeline authoring. Can teams build and reuse pipelines via a portal like the Internal Developer Portal without a dedicated scripting priesthood?
Multi-cloud support. Does it run across the clouds and clusters you actually use?
Governance and audit. Are RBAC, policy-as-code, and audit trails baked in, not bolted on?
One warning: a platform that automates only part of the workflow creates fresh bottlenecks at the handoffs it does not cover. Partial automation moves the wait; it does not remove it.
How Harness approaches automated DevOps at scale
The challenge
Most teams automate in fragments: a CI runner here, deploy scripts there, security tacked on at the end. The fragments do not share context, so every release still leans on manual judgment. That judgment is exactly what buckles when AI-assisted coding pushes change volume past what humans can review by hand.
The approach
Harness automates everything after code is written, on one platform. Continuous Integration speeds builds with test intelligence. Continuous Delivery and GitOps ships with progressive rollouts, automated rollback, and continuous verification. Infrastructure as Code Management provisions infrastructure through governed pipelines. Application Security Testing embeds scanning into the workflow. AI SRE reads logs and names the likely cause of failures. Cloud and AI Cost Management closes the loop on spend. The Software Delivery Knowledge Graph grounds every AI decision in your delivery data, while policy as code and RBAC keep the whole system governed. Developer-friendly guardrails.
The outcome
With the whole lifecycle automated, shipping stops being the risky part. Each change carries its own checks and a clean path back if it misbehaves, so the team spends fewer nights chasing incidents and more time on the decisions that genuinely need a person. Hundreds of engineering teams trust Harness to consolidate delivery and remove manual interventions.
What teams running automated DevOps report
Two teams, two stacks, one pattern: retiring glue code and manual steps returns engineering time to the work that actually needs it.
How did Citi move from build to production in under seven minutes?
Moving release onto Harness let Citi go from build to running in production in under seven minutes, with role-based controls over more than 20,000 people, most deploying several times a day, the bank reported.
“Harness CD let us release each change within minutes of a pull request being merged.”
Stefanos Piperoglou, Technical Program Manager, Citi
How did Meltwater scale to 1,200 pipeline executions a day?
After moving CI off Jenkins onto Harness, Meltwater now runs more than 1,200 pipeline executions a day, with CI adoption growing 3x to cover 50% of the engineering organisation, the company reported.
“Harness CI is extremely open and flexible. There's nothing holding you back from building and deploying the way you want. Jenkins was extremely rigid and wouldn't have allowed us to grow the way we have.”
Jim Sheldon, Principal Software Engineer, Meltwater
The gain traces to one move: retiring glue code and manual steps, not stacking on more tools.
One system beats a pile of tools
A pile of point tools only takes you so far. A DevOps automation platform takes repeatable work off your engineers, connects every stage of software delivery, from build to production, and turns that pile into one system you can actually improve against DORA's delivery metrics. Start with breadth of coverage, demand AI that acts on the pipeline, and treat governance as a guardrail, not a gate. Get it right and the handoffs that used to eat your week quietly disappear.
See how Harness brings the full software delivery lifecycle onto one AI-native platform.
DevOps Automation Platform Explained: How It Works and Why You Need One
A software delivery platform governs the full after-code lifecycle (CI, CD, security, insights) as one system, replacing a stack of point tools.
A CI/CD tool automates one slice of the pipeline. A platform governs the entire after-code lifecycle with shared policy, visibility, and rollback.
Must-have features: pipeline automation, progressive delivery, built-in security, audit trails, and AI-native rollback and test intelligence.
Evaluate platforms on scope coverage, integrations, AI capabilities, governance, and scalability, not on a feature checklist alone.
What is a software delivery platform?
A software delivery platform is an integrated system that manages every stage of moving software from a code commit to production: continuous integration, continuous delivery, security, and the feedback loops in between. It treats delivery as one governed lifecycle instead of a chain of disconnected steps.
It covers the full software delivery pipeline, not a single stage like build or deploy.
It replaces a stack of stitched-together software delivery tools with one system that shares policy, access control, and visibility.
It's often called an application delivery platform or a continuous delivery platform, though those terms usually emphasize the deploy side.
The full software delivery lifecycle (CI, CD, security, and feedback loops), well beyond build and deploy.
Delivery risk
For heavy AI-coding-tool users, 22% of deployments end in a rollback, hotfix, or incident (Harness, 2026 State of DevOps Modernization).
Tool sprawl
The average engineering org uses 5+ tools across delivery, security, and operations (GitLab Global DevSecOps Report 2024).
Why it matters
Standardizing on one platform replaces scripts and silos with shared policy, visibility, and rollback across every team.
A vendor tells your team it needs a software delivery platform. You already run a CI/CD pipeline that builds and ships code every day, so the pitch sounds like a fresh label on the tooling you have. Most of the time, it is not. A platform owns the parts your CI/CD tool never touched: security gates, cross-service release coordination, governed rollback, and proof that a release worked. The line between the two is where most of the value sits, and where most of the buying mistakes happen.
Software delivery platform vs. CI/CD tool: what is the difference?
A CI/CD tool automates one slice of the work: it builds your code, runs tests, and pushes an artifact toward an environment. Most teams start there. The trouble is that build-and-deploy is the middle of the story, not all of it. Security scanning, approvals, multi-service release coordination, rollback, and the data that tells you whether the release worked all live outside that slice, so they get bolted on as separate scripts and separate software delivery tools.
A software delivery platform manages the whole after-code lifecycle as one governed system. Same policy engine, same access control, same audit trail, same view of what is in flight across every pipeline.
The distinction matters most as you grow. One CI/CD tool is fine for one team. Fifty teams running fifty variations is how toil and risk compound, and why so many move to a unified DevOps automation platform.
CI/CD Tool vs. Software Delivery Platform
Dimension
CI/CD tool
Software delivery platform
Scope
Build, test, deploy
Full lifecycle: CI, CD, security, cost, delivery insights
Governance
Configured per pipeline, often manual
Policy-as-code applied across every pipeline
Rollback
Custom scripts you write and maintain
Built-in verification and automated rollback
Visibility
Per-job logs
Shared view of services, environments, and releases
Scaling
Copy-paste pipelines per team
Reusable templates and golden paths
AI capabilities
None or bolted-on chat assistant
AI-native pipeline authoring, verification, and remediation
What features should you look for in a software delivery platform?
Treat this as an evaluation checklist. A real platform covers the entire software delivery pipeline, so it should carry all of these, not a subset. The capabilities below separate a current platform from a relabeled CI/CD tool.
Feature
What it does
What to ask in a demo
Pipeline automation
Builds, tests, and deploys without hand-written glue between stages
Show me a pipeline generated from a plain-language description
Progressive delivery
Canary and blue-green strategies for promoting artifacts across environments
How does the platform handle a failed canary in production?
Built-in security
SAST, SCA, and artifact scanning as governed pipeline steps, not separate gates
Demonstrate a deploy blocked by a critical CVE policy
Audit trails and policy-as-code
Immutable change log with Open Policy Agent rules enforced automatically
Show me a policy violation traced back to the originating commit
Automated rollback
Continuous verification watches live signals and reverts bad deploys
What signals trigger rollback, and what is the false-positive guardrail?
Test intelligence
Runs only the tests a code change can affect, so feedback stays fast at scale
Show me a run where only impacted tests executed on a real repo
AI-assisted failure diagnosis
Reads a failed build and names the probable cause from your delivery data
Diagnose a real broken build in our environment, not a demo one
Check the first five capabilities but none of the AI-native ones (test intelligence, automated rollback, AI-assisted diagnosis), and you're evaluating yesterday's platform. The AI Velocity Paradox is real: faster code creation without faster, smarter delivery infrastructure just delivers risk faster.
How should you evaluate a software delivery platform?
Features tell you what a platform can do. Evaluation tells you whether it fits your team. Score every candidate on the same six dimensions:
Scope coverage. How much of your pipeline does it replace? Count the software delivery tools you would retire.
Integration. Does it meet your stack (Git provider, registries, clouds, observability), or force a rip-and-replace?
AI capabilities. Pipeline generation, verification, and rollback grounded in your delivery data, not generic suggestions.
Governance. Policy-as-code, RBAC, and audit trails built into the flow, not layered on after.
Scalability. Does it stay sane at fifty teams and thousands of pipelines, or does it sprawl?
Pricing model. Per-seat, per-deploy, or consumption, and how that tracks as you grow.
Then put real questions to the vendor: How does rollback work, and what signals trigger it? What is your multi-cloud and on-prem support? How are pipelines versioned and reused across teams? How is access controlled, and what shows up in the audit log? What does onboarding look like, and who supports the migration?
Two platforms can check the same boxes and deliver different results once implementation support, documentation, and community enter the picture. The platform your team can actually adopt beats the one with the longest spec sheet.
How do you evaluate a software delivery platform against Jenkins, GitHub Actions, and GitLab?
Few teams evaluate a platform in a vacuum. You almost certainly already run Jenkins, GitHub Actions, or GitLab, so the real question is what a platform adds on top of what you have, not whether it can replace it outright. Two of the three are CI/CD tools you would extend; one is the closest thing to a platform-category peer. Score each on how much of the after-code lifecycle it still leaves you to build and maintain by hand.
Incumbent
What it covers today
What to evaluate a platform to add on top
Jenkins
Self-hosted CI automation; build and test orchestration through plugins you maintain
Governed CD, progressive delivery, continuous verification, and automated rollback you would otherwise script and babysit yourself
GitHub Actions
Per-repository CI/CD workflows in YAML, tied to your GitHub source
Cross-service release coordination, policy as code applied across every repo, and delivery insights beyond a single workflow
GitLab
The closest single-vendor platform: source control, CI/CD, and security scanning in one product
Depth of after-code governance, AI-native verification and rollback, and a control plane over your existing estate without a rip-and-replace of source control
The questions to put to a vendor follow from that table: How much of what we run in Jenkins or GitHub Actions does this absorb? Where does it sit alongside our source control instead of replacing it? Run the same scoring on all three incumbents, tally what each still leaves to manual scripts and add-on tools, then measure how much of that gap a given platform actually closes. The bigger the share it takes over, the less custom plumbing your team is left maintaining.
How Harness approaches the software delivery platform
The challenge
Most teams already automated the middle of delivery with a CI/CD tool. The parts a platform owns (security, cross-service release coordination, verified rollback, and self-service for developers) stayed manual, stitched together by hand. That gap is expensive: for heavy AI-coding-tool users, 22% of deployments end in a rollback, hotfix, or incident (Harness, 2026 State of DevOps Modernization), and DORA research (State of DevOps 2024) shows throughput flat while stability slips.
The approach
Harness is the AI-native software delivery platform for everything that happens after code is written. Continuous Delivery and GitOps generates pipelines from natural language, layers a control plane over your existing Argo CD estate, and auto-rolls back bad deployments. Continuous Integration speeds builds with test intelligence. The Internal Developer Portal gives platform teams a golden-paths layer for developer self-service. Application Security Testing, Cloud and AI Cost Management, and AI DLC Insights run on the same governed control plane. Underneath, Harness AI grounds intelligence in the Software Delivery Knowledge Graph, while policy-as-code and RBAC keep self-service governed. Developer-friendly guardrails, not bolted-on automation.
The outcome
Teams retire the tangle of point tools for one system. A release turns into something you can verify and reverse, not a gamble. Hundreds of engineering teams trust Harness to consolidate delivery and remove manual interventions, with platform teams defining golden paths and developers self-serving safely.
How engineering teams consolidate on one software delivery platform
The clearest signal is what teams report after they replace point tools with one platform.
How did Raisin retire Jenkins and save $525,000 a year?
Raisin's six-person DevOps team had been spending 80% of its time keeping a fragile Jenkins setup running. After moving to Harness, that team spends 20% of its time administering software delivery, a 60% reduction in effort worth roughly $525,000 a year. Deployments climbed from 10 to 53 a month, and onboarding a new application dropped from two days to 30 minutes.
“We have drawn clear lines of ownership using Harness. My team owns workflows and templates, and each application team manages their own services, pipelines and triggers.”
Experian shifted from "big bang" releases twice a month to 100 risk-controlled deployments per month using feature flags and progressive delivery, a 50x release-velocity increase. Engineers experiment with real consumer data safely, and cross-functional teams across multiple time zones now release continuously instead of coordinating around end-of-day windows.
“Harness provides so much more than just a tool set change. It sounds simple, feature toggles, but it's transformative in nature. It's transformative in terms of the teams, in terms of the culture that we adopt.”
A CI/CD tool solves the middle of delivery. A software delivery platform solves the whole of it, which is why the market keeps consolidating. Start from your own pipeline: map every stage from commit to production, mark the manual handoffs, and count the software delivery tools one platform would retire. The platform that erases the most of those handoffs while keeping delivery governed is the one worth buying. Everything else just runs the same brittle scripts faster.
See how Harness brings the full after-code lifecycle onto one AI-native platform.
FAQs about software delivery platforms
What is the difference between a software delivery platform and a CI/CD tool?
A CI/CD tool automates build, test, and deploy for one pipeline. A software delivery platform governs the entire after-code lifecycle across every pipeline, with shared policy-as-code, RBAC, visibility, and automated rollback. The tool is a stage in the workflow; the platform is the system that runs the workflow end to end.
What is an application delivery platform?
It is another name for a software delivery platform, with more weight on the deploy-and-run side: getting an application into production and keeping it healthy. In practice the terms are used interchangeably, though application delivery platforms sometimes emphasize runtime concerns over earlier pipeline stages.
What is a continuous delivery platform?
A continuous delivery platform focuses on the CD half of the pipeline: promoting artifacts across environments, progressive rollout with canary or blue-green strategies, and automated rollback. A full software delivery platform wraps that with CI, security testing, and delivery insights on one governed control plane.
How do I build a software delivery pipeline?
Connect source control, build and test, an artifact registry, security scans, and a deployment strategy into one flow, then add approvals and rollback. A platform generates and versions that software delivery pipeline for you instead of leaving it to bespoke scripts, and applies policy-as-code at each stage.
What software delivery tools do enterprise teams use?
Many still stitch together separate CI servers, deployment scripts, scanners, and registries. The market is consolidating: enterprises are replacing those software delivery tools with one platform to cut toil, standardize governance, and give platform teams a single place to define and enforce golden paths.
What are the limits of a software delivery platform today?
Two worth knowing. ML-based verification needs baseline data, so new services run in a learning period before anomaly detection is reliable. And automated rollback for stateful services or database migrations needs careful configuration before it can be trusted, even on a strong platform.
How much does a software delivery platform cost?
Pricing usually follows one of three models: per developer seat, per deployment, or consumption based on usage. The number that matters isn't the sticker price but how the bill behaves as your team and pipeline count climb, and what the platform lets you retire. One platform that replaces several point tools can lower your total spend versus the stack it consolidates, so weigh it against the licenses, maintenance, and engineering toil you would drop, not in isolation.
Software Delivery Platform Explained: Key Features and How to Evaluate One
Quick question: can you envision how Terraform scalability issues you when your third team tries to apply changes at the same time, locks the state file, and someone's Friday evening turns into a debugging session? Maybe that hits a little too close to home. The first 500 resources feel manageable. The next 2,000 teach you what "workspace limitations" actually mean in production.
When infrastructure code grows past a certain threshold, the tools and workflows that worked for small teams stop working. State files balloon into multi-megabyte JSON blobs. Plan times stretch from seconds to minutes. What used to be a quick `terraform apply` becomes a risky operation requiring coordination across time zones. The infrastructure as code bottleneck isn't hypothetical. It's the moment your team starts avoiding changes because the process has become unpredictable.
Why Terraform Scalability Issues Emerge
Most scalability problems stem from decisions made when the codebase was small. A single monolithic state file works fine for 10 resources. For a thousand, it creates a serialization chokepoint. Every change requires locking the entire state, even if you're only modifying a security group in one region.
Remote state backends help, but they introduce their own failure modes. S3-backed state with DynamoDB locking works until someone's network hiccups mid-apply and leaves a stale lock. Cleaning up requires manual intervention and tribal knowledge about which lock IDs matter. At scale, these incidents compound. What was once an edge case becomes Tuesday.
Module sprawl accelerates the problem. Teams copy-paste working configurations, tweaking variables for each environment. Over time, you end up with dozens of nearly identical modules that diverged in subtle ways. When a breaking change hits a core provider, you're patching every fork individually. Version drift becomes a compliance risk.
State Management at Scale Breaks Assumptions
Terraform state management at scale exposes the implicit contract between your code and reality. State files aren't just metadata. They're the single source of truth about which resources exist, their current configuration, and the dependency graph connecting them. When that file grows past a certain size, read performance degrades. Plan operations slow down because Terraform has to parse and validate every resource, even if you're only touching one.
Splitting state helps, but it shifts complexity. You trade a monolith for a distributed system of loosely coupled state files. Now you need a mental model of which workspace controls which resources. Documentation becomes critical because the implicit coupling between workspaces isn't enforced by the tooling. A misconfigured variable in one workspace can cascade into another through shared data sources or implicit dependencies.
Remote backends introduce latency. If your state is in S3 and your CI runners are in another region, every read adds round-trip time. Multiply that by hundreds of resources and the cumulative effect is noticeable. Teams start optimizing for fewer plan runs, which ironically makes each run riskier because more changes accumulate between tests.
Collaboration Friction Increases with Team Size
When five engineers share a single workspace, coordination is informal. Someone shouts in Slack before running an apply. By the time you have fifteen people across three continents, informal processes collapse. The infrastructure code management problem becomes an access control and workflow problem simultaneously.
Without proper guardrails, junior engineers can accidentally destroy production resources. The blast radius of a bad apply is proportional to the size of the state file. In a monolithic setup, one mistake can ripple across hundreds of resources. Policy enforcement becomes necessary, but Terraform's native tooling offers limited help. You need something outside the core workflow to validate plans before they execute.
Terraform workspace limitations compound this. Workspaces were designed for environment separation, not collaborative workflows. They don't enforce approval gates, policy checks, or audit trails. If you need those capabilities, you're building them yourself or adopting a platform that provides them natively.
When Standard Tooling Stops Scaling
The breaking point varies by team, but the symptoms are consistent. Plan times stretch past acceptable thresholds. State lock contention increases. Engineers start working around the tooling instead of with it. Someone proposes splitting the monorepo into per-team repositories, which solves the immediate pain but fragments governance.
This is the moment teams evaluate Terraform alternatives or consider an OpenTofu migration. OpenTofu offers a community-governed fork with a stable open-source foundation, which matters if licensing uncertainty is a concern. But switching engines doesn't solve workflow problems. A poorly structured codebase remains poorly structured regardless of which binary executes it.
The real question isn't which IaC engine to use. It's whether you're managing infrastructure code or merely running it. If your workflow is `git clone,` `terraform init,` `terraform plan,` and `terraform apply` in a loop, you're missing the orchestration layer that enables teams to scale safely.
How an IaC Management Platform Addresses Scale
An IaC management platform like Harness IaCM treats infrastructure code as a first-class workflow problem, not just a tooling problem. It provides the orchestration, governance, and collaboration features that become non-negotiable past a certain scale.
Harness IaCM supports OpenTofu, Terraform, and Terragrunt, which means you're not locked into a single engine. The choice of execution runtime becomes an implementation detail. What matters is the management layer: default pipelines for plan and apply operations, workspace templates that enforce consistency, and variable sets that reduce configuration drift.
State management moves from a manual coordination problem to a platform-managed concern. Harness handles backend configuration, workspace isolation, and access control through policy. Drift detection runs continuously, flagging resources that diverged from code without requiring manual audits. When someone needs to troubleshoot, they're working from a unified interface with full audit history, not SSH'ing into CI runners and reading logs.
The Module and Provider Registry centralizes reusable components. Instead of maintaining dozens of forked modules, teams publish versioned modules to a shared registry. Consumers reference specific versions, which prevents breaking changes from propagating unexpectedly. Dependency management becomes explicit and trackable.
Policy enforcement integrates directly into the workflow. You can block applies that violate security policies, fail compliance checks, or exceed cost thresholds. These gates trigger before any changes reach production, which shifts risk left in the development cycle. Engineers get immediate feedback instead of discovering issues during post-deployment audits.
The Harness IaCM product page details the full feature set, and the IaCM documentation walks through real implementation patterns. If you're curious about where the platform is headed, the roadmap shows upcoming capabilities around enhanced governance and multi-cloud orchestration.
Moving Beyond the Bottleneck
The infrastructure as code bottleneck isn't about Terraform's limitations, but the gap between what basic tooling provides and what production-scale operations require. Small teams can manage with scripts and conventions. At scale, you need structured workflows, enforced policies, and visibility into who changed what and why.
Guardrails don't slow teams down. They enable speed by reducing the cognitive load of coordinating changes across distributed systems. When engineers trust that the platform will catch obvious mistakes before they reach production, they ship with confidence. The alternative is a culture of fear where every apply feels like defusing a bomb.
If your team is feeling the pain of Terraform scalability issues, the solution isn't to abandon infrastructure as code. It's to adopt tooling that matches the complexity of what you're building.
Start by auditing your current workflow: Where do engineers waste time? What manual steps could be automated? Which failure modes recur most often? The answers will point toward the specific capabilities that matter most for your context.
Modern IaC governance and compliance aren't optional at scale. They're the difference between infrastructure that evolves safely and infrastructure that becomes unmaintainable. The teams that figure this out early gain a compounding advantage. Those who wait pay an escalating tax on every change.
Terraform Scalability: When IaC Outgrows Your Setup
Most teams think infrastructure problems start during provisioning. They're wrong. Infrastructure breaks after deployment—in what the industry calls "day 2 operations."
You provision an EC2 instance. It works. Then someone makes a console change at 2 a.m. during an incident. Or configuration drifts between what Terraform declares and what's actually running. Or Ansible doesn't see the infrastructure dependencies it's trying to configure. And suddenly, your infrastructure is in an undocumented state that nobody fully understands.
The core problem is simple: most organizations run multiple tools—Terraform, Ansible, CI/CD platforms—each managing infrastructure in isolation. There's no single system thinking about correctness end-to-end. State is defined once but never reconciled. Control is assumed at every layer but enforced nowhere.
This is where infrastructure control planes become essential.
The Day 2 Operations Problem: When Infrastructure Diverges from Reality
Here's what happens in most organizations. Day one looks great: infrastructure gets provisioned, policies are in place, everything deploys successfully. Day two is where it falls apart.
First, console changes creep in. A firefighter needs to test something quickly or fix an incident at 3 a.m., so they click a change directly into AWS or GCP instead of going through the pipeline. That's the spark. But it's not the real problem.
The real problem is that nothing in your tool chain was watching for it in the first place. Your Terraform management tool has no idea what happened. Your CI/CD platform sees no change. Your Ansible configuration assumes a specific state that's no longer true. The systems operate in silos.
Then comes the second wave: incidents occur, you make changes to fix them, but you don't remediate those changes back into your Infrastructure as Code. So the same incident pops back up weeks later. Your infrastructure state file doesn't reflect reality. Cost balloons unexpectedly. Compliance checks fail because nobody knows what's actually deployed.
This is infrastructure drift, and it's the symptom of a broken control model.
The Broken Model: Control Assumed, Never Enforced
Think about the infrastructure lifecycle in most organizations:
Coding — You write Infrastructure as Code using Terraform, OpenTofu, or CloudFormation.
Provisioning — Terraform applies your code, but it's isolated. It has no awareness of what happens next.
Configuration — Ansible configures the infrastructure, but it has no awareness of infrastructure dependencies or what Terraform did.
Deployment — CI/CD deploys your application, often blind to the infrastructure configuration happening in parallel.
Governance — Policy tools like Open Policy Agent or Sentinel scan each step independently, but nothing ties policies across the entire workflow.
The pattern is consistent: state is defined but never enforced across the system end-to-end.
Most teams assume control exists at each layer. Security assumes policies are enforced. DevOps assumes CI/CD has visibility into infrastructure. Platform teams assume nothing will diverge from the declared state. But assumption is not enforcement. When things break—and they will—there's no unified system to catch it.
The Solution: A Control Plane That Continuously Reconciles State
A control plane sits across provisioning, configuration, and deployment. It does two critical things: it continuously reconciles desired state against actual state, and it enforces policy before anything is allowed to move to the next stage.
Concretely, this means:
Continuous Reconciliation — Drift is caught in hours or minutes, not at the next quarterly review. If someone changes an EC2 instance size in the console, your system detects it immediately and alerts you or automatically remediates it.
Policy Enforcement at Design Time — Policies aren't a side process security runs sporadically. They're baked into every stage. If someone tries to provision an oversized instance that violates cost policy, the system blocks it before Terraform plan even runs—like a linter catching a syntax error.
Unified Ownership and Context — When an infrastructure change moves through provisioning, configuration, and deployment, ownership and context are preserved. If you define RBAC at the provisioning stage, that same RBAC applies at the configuration and deployment stages. There's no handoff where context is lost.
Only Compliant Infrastructure Reaches Production — This is the line that resonates with security and compliance leaders. Non-compliant infrastructure literally cannot reach production. It's binary, enforceable, and auditable.
From Silos to Unified Automation: The Practical Impact
Here's what this looks like in practice. You're using Terraform to provision infrastructure, Ansible to configure it, and Jenkins or GitHub Actions to deploy applications. Normally, these tools never talk to each other. You manually coordinate changes across them.
With a unified infrastructure control plane, everything happens in one place. You provision with Terraform, configure with Ansible, and deploy with CI/CD—all in a single orchestrated pipeline. Policies run at every stage. Cost estimation happens before approval. Security scanning is mandatory. Drift is detected automatically.
The result: one platform team can realistically stand behind hundreds of policies and review every change in real time, instead of a handful of reviewers trying to catch everything that slips through.
Where AI Agents Accelerate the Model
This is where Harness AI becomes powerful. Harness brings together context across your code, infrastructure, configurations, deployments, policies, and the broader software delivery lifecycle giving AI a complete understanding of how your systems operate.
Harness AI already includes specialized platform agents and AI-powered capabilities like DevOps Agent and AppSec Agent that help teams reduce manual effort, make better decisions, and automate complex software delivery workflows. With more AI agents and capabilities coming, Harness is continuing to expand what teams can safely delegate to AI.
What makes Harness AI different for infrastructure is its deep, unified context. It does not operate from isolated prompts, schemas, or point-in-time tool queries. It understands the relationships between code, infrastructure, deployments, policies, dependencies, and organizational standards.
That context enables Harness AI to deliver results that are more reliable, explainable, and governed, helping engineering teams move faster and remediate infrastructure without sacrificing control.
The Path Forward: Treat Infrastructure Like Product
The north star most platform and engineering leaders are chasing is simple to state, hard to do: treat infrastructure as code like a product.
This means infrastructure goes through the same golden path pipeline as application code. Policy checks. Cost estimation. Approvals. Audit trails. Full visibility. Not a side process, but the same process.
When infrastructure follows this model, day 2 operations stop being a crisis. Drift is caught and remediated automatically. Costs are controlled before they spike. Compliance is enforced, not aspirational. And teams can move faster because the governance is built in, not bolted on.
The infrastructure that breaks after deployment isn't a technical problem—it's a control problem. Fix the control model, and everything else follows.
Ready to fix your infrastructure control model? The teams that treat infrastructure as a governed product, not a manual process, are the ones that scale safely. Learn how to unify Terraform, Ansible, and CI/CD governance in one control plane.
FORM SUBMISSION THANK YOU MESSAGE
Thank You Message Copy:
"Thanks for downloading! You've taken the first step toward infrastructure that's governed, not fragile. Check your email for the complete guide plus templates for building your own unified infrastructure pipeline. Bonus: See how AI agents can automate drift remediation and cost control while your team focuses on innovation. Questions? Our infrastructure experts are ready to help—reach out anytime."
Alternative (Shorter):
"Got it! Your guide is on the way. While you're reading, explore how a unified control plane catches infrastructure drift in minutes, not months. Watch our live demo showing policy enforcement, cost estimation, and automated remediation in action. Or schedule a walkthrough with our team to see how this works for your infrastructure."
Infrastructure Breaks After Deployment: Why Day 2 Operations Demand a Control Plane
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.
Unified Deployment workflow
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:
Apply database schema migrations
Deploy the application
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.
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
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.
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.
How to Deploy Application and Database Schema Migrations Together in a Single CD Pipeline
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:
Concept
What it does
Cleanup Rule
Soft-deletes artifact versions on a schedule based on age, version count, or download activity.
Retention Rule
Marks matching artifacts as exempt from deletion. Retention rules are always evaluated first.
Scope
Defines where a rule exists: Account, Organization, or Project.
Attachment
Determines which registries a rule applies to. Child scopes must opt in.
Dry Run
Previews exactly which artifacts would be deleted before any cleanup rule runs.
Soft Delete
Places deleted artifacts into a recovery window, allowing one-click restoration from the artifact's Deleted tab.
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:
Field
Value
Name
protect prod releases
Rule Type
Retention Rule
Registry Scope
All Registries
Version Patterns
1.0.0, 1.1.0, 1.2.0
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:
Field
Value
Name
cleanup npm devs
Rule Type
Cleanup Rule
Registry Scope
Specific Registry: strattest07
Package Type
NPM
Version Patterns
0.*, *dev*
Retention Criteria
Keep last 1 version
Schedule
Daily at 01:00 UTC
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:
Account level: for CISO, compliance, central governance.
Organization level: for platform teams, business unit governance.
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.
Field
Value
Name
org-protect-prod-releases
Type
Retention Rule
Scope
All Registries (in this organization)
Version Patterns
1.0.0, 1.1.0, 1.2.0
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:
Set up automated cleanup across five package types.
Protected her formal releases with a Retention rule, so the cleanup can't touch them.
Verified every rule with dry-runs before letting them fire.
Adopted the org admin's centralized protect rule without losing project autonomy.
Scheduled real overnight execution and watched it work.
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:
Identify your release version patterns (the artifacts you never want touched).
Create a Retention Rule with those literal version strings at your project scope.
Create a Cleanup Rule targeting dev or snapshot builds in one registry.
Run a Dry Run before saving a schedule.
Let it run for one week, then review the Executions tab to see what was cleaned up.
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.
How to automate artifact cleanup in Harness Artifact Registry without breaking production
.png)
.png)
