Building vs. buying a guardrails engine

Engineering standards need to hold across the organization, including services that never adopted the golden path. Platform leaders need to know where those standards are being followed and enforce them where code is written, reviewed, and deployed.

CI templates and scripts remain useful parts of that system. The larger requirement is collecting reliable evidence across different workflows and evaluating standards without waiting for every team to adopt another template version.

That collection and enforcement system can be built internally or bought. The choice depends on what your platform already provides, how quickly you need broader coverage, and what your team can sustain as tools and requirements change.

What a guardrails engine needs to do

Whether you build or buy, the system should deliver the same outcomes:

• Know which services meet their standards, using current evidence of what ran, and identify where evidence is missing.
• Enforce new requirements promptly in developer and AI workflows, with the same standards for human- and AI-written code.
• Accommodate different workflows and tech stacks and apply controls appropriate to each service, without requiring every team to build and ship the same way.
• Retain evidence of what was checked, the result, and when it ran, so audit preparation does not become a separate investigation.
• Apply the standards only to the services that need them, and for this to be possible, classify the services accordingly.
• Instrument centrally so adoption does not require opt-ins or per-service setup.

Delivering those outcomes requires the following capabilities to work together:

Builds and tests stay in CI. A central collection and evaluation system observes what runs across pipelines, normalizes the evidence into a queryable view of each service, and checks it against the relevant standards. That view must include services outside the shared template.

This separates a policy change from a pipeline migration. Once the necessary evidence is available, a new standard can use the central evaluation and enforcement system without waiting for each team to upgrade its template. The build-versus-buy decision is who provides and maintains that capability.

Where existing tools leave work for your team

Extending the tools you already operate is a reasonable place to start. CI templates run checks, policy engines evaluate rules, and developer portals give teams a place to see results. Those investments can contribute to either an internal or a purchased solution.

The question is how those pieces work across services with different pipelines and tooling. Can they establish what actually ran, enforce the relevant standard, and support the next requirement without another round of team-by-team adoption? That is the work a build-versus-buy comparison needs to account for.

CI templates and scripts: a new control still needs to reach every service

Adding a check to a shared CI template doesn’t mean every service is running it. A service pinned to v37 will not inherit a new control in v40. Making the upgrade mandatory risks breaking custom workflows; leaving it optional lets teams postpone the control along with the upgrade. Services that never adopted the template remain outside its reach.

Customization creates another gap. A repo can invoke the approved template while running important steps inside hooks or overrides that the template does not inspect. Restricting those extensions can remove flexibility teams need. Allowing them means template adoption alone cannot establish whether the standard is being followed.

A postmortem follow-up can therefore turn into another pipeline migration: add the check to a new template version, help teams upgrade, and wait for adoption. Knowing where the requirement is enforced also requires evidence from actual pipeline execution.

That view needs to include every service in scope, including those that never reported a result, have stale evidence, or hold an approved exception. Otherwise, a green dashboard can describe only the services the check reached.

Standard build images and workflows can reduce the number of paths you need to support. A maintained default can also spare teams from solving the same problem repeatedly. But a golden path that applies the same controls to every service can get in the way of legitimate needs. Teams seek exemptions or build their own alternatives, duplicating infrastructure work and reopening gaps in standards enforcement. The goal is to enforce the standards that apply to each service while allowing teams flexibility in how they meet them.

Implementing a check as a shared CI script still leaves integration work. Custom build steps and changing tool outputs need collection logic your team maintains. Results must stay tied to the right service and change. Missing evidence and collection failures need explicit handling. Otherwise, each new check can bring another set of integrations and support work.

Templates can be enough for specific checks in a limited, controlled environment. Across a larger, mixed estate, the system also needs to observe and evaluate services independently of template adoption. Building that capability internally can preserve your CI investment; buying it can reduce the infrastructure your team has to operate.

OPA and Rego: collection is still yours to build

OPA can evaluate a rule correctly while your enforcement system misses every service that never supplied the data. Collecting and normalizing that data is the larger engineering problem. OPA’s external-data integrations provide ways to pass inputs to the engine; your team still has to produce those inputs.

For a test-coverage standard, that means finding the reports across shared and custom pipelines, reconciling different formats, and tying each result to the right service and commit. The system must detect missing or stale reports and keep working when teams change tools or workflows. Your team also has to connect OPA’s decisions to developer feedback or blocking checks. Writing the Rego rule leaves that collection and enforcement infrastructure to build and maintain.

Existing integrations give OPA a clearer starting point for infrastructure-as-code and Kubernetes admission checks, where Terraform plans or admission requests already provide structured inputs. They do not supply a common view of test runs, scanner results, and build activity across your engineering organization.

OPA plus DIY may be enough when your standards are confined to those supported infrastructure and deployment use cases, the integrations cover your services, and you have no plans to expand beyond that scope. If broader engineering governance is the goal, the build estimate needs to include the data collection system. Having a policy engine in place does not remove that work.

Developer portals: from a score to an enforced standard

A developer portal can surface a failing score and alert the service owner. That helps teams prioritize fixes, but the response still depends on someone acting on the finding.

The evidence behind the score matters too. Backstage’s providers and processors can bring in external data, but someone must maintain the integrations that establish what actually ran in CI and whether it met the standard.

An alert does not by itself prevent the next noncompliant change. That requires enforcement in the coding workflow, on the PR, or before deployment. Portals can connect to those controls, but the integration and ongoing operation still need an owner.

The portal’s existing integrations determine how much work remains. If they already provide reliable evidence and enforcement across the required services, extending them may be the smaller investment. Where those connections are missing, a separate engine can supply collection and enforcement while the portal remains the place teams see results.

Adoption effort and the cost of waiting

The time between deciding on a requirement and enforcing it across the affected services matters. A strategy that depends on template upgrades also depends on service owners finding time for those upgrades. Coordination and follow-up belong in the estimate.

During a runtime migration, incomplete enforcement can mean manually checking releases while unsupported versions remain in use. Your support and incident history can help estimate that work and exposure. Procurement or integration delays can prolong the same gap when buying.

Maintenance is hard to estimate in advance. Support tickets and integration fixes for comparable internal tools offer a starting point. During a pilot, measure the effort to support a second workflow, investigate incorrect results, and handle missing evidence.

Separate recurring support from changes such as tool upgrades or new workflows. A low and high estimate over the same period as the subscription quote makes uncertainty visible. State which changes each estimate assumes.

Compare the same services, requirements, and enforcement deadline. Include the platform work an internal build postpones, and the subscription, integration, policy tuning, and operating effort a purchase retains.

When building makes sense

Building or extending an internal engine can be the right choice when your requirements are tightly scoped, evidence sources are stable, and affected workflows are under your control.

An established platform may already collect the evidence, evaluate policies, and block changes where needed. A new runtime check could then be a small extension of a system your team knows how to operate.

If those capabilities are missing, your team has to build them while delivering the first check.

You need to store results against the right services and changes, test policies, expire exceptions, and roll out enforcement safely. Collection must keep working when tools change their output. Service ownership and support contacts must stay current.

Separate collection from evaluation early. Updating the approved runtime list should not require rewriting every collector. Supporting another build system should not require duplicating every policy.

Assign the support work too. Who responds when missing evidence blocks a release? Who investigates incorrect findings? Who maintains integrations when the original authors move on?

Include those responsibilities in the build proposal, alongside the platform work you would postpone.

When buying makes sense

Buying earns its place when it delivers broader adherence sooner without giving your team another infrastructure product to build and maintain. The purchase should remove enough collection, adoption, and operating work to justify its cost.

An evaluation using your own services can show how much work the product would remove. A custom pipeline or legacy workflow is especially useful: it exposes which evidence arrives automatically, where custom collection is still needed, and how findings reach developer feedback and blocking gates.

A purchase needs to improve coverage or free enough platform capacity to justify its cost, after accounting for infrastructure you already operate.

Buying also introduces dependencies. Access requirements, policy extensibility, evidence retention and export, and the vendor’s response to integration changes can all affect fit. Less infrastructure to maintain comes with less control over its implementation.

Your team still sets the standards, approves exceptions, and decides when blocking is appropriate.

Test the difficult paths before committing

For either option, test the whole process: collect evidence, evaluate the standard, and return feedback or block the change.

Start with one important standard and representative services. For the runtime migration, include a service using the shared workflow and one with custom build steps. Include a monorepo if it introduces service or release boundaries your system must understand.

If teams must opt in, compare expected adoption with your last rollout: what share of services adopted the check, how long did it take, and how much follow-up was needed? Central instrumentation removes that per-service opt-in dependency.

Then test the cases a successful demonstration can miss:

• A repository declares an approved version, but the release artifact contains an unsupported one.
• Evidence exists for a previous change but is missing for the current change.
• A collector fails or stops reporting.
• An approved exception expires.
• A service bypasses the expected workflow.
• Low adoption of the check.

Distinguish a pass from a failure, an approved exception, or an unknown result. Decide what happens when evidence is missing: warn, block, or allow an approved temporary fallback. Missing evidence should never silently become a pass.

Start with reporting so you can find missed services and incorrect results. Enable blocking once collection is reliable, developers can understand the feedback, and the exception process is clear.

Then test the next standard. After the runtime migration, add a release safeguard or a postmortem follow-up. Measure which collectors, service mappings, feedback, and rollout controls you can reuse, and what new work is needed. New evidence may require a collector; it should not require rebuilding the entire enforcement system. Count the incremental cost of each check, including any new collection and adoption work.

An engine that supports the first check but needs another service-by-service adoption campaign for the next one leaves a large part of the original workload in place.

What you’re buying with Lunar

Earthly Lunar provides central instrumentation and enforcement across your existing repositories and CI/CD. It normalizes observed activity into structured posture data and evaluates standards independently of template adoption. Builds and tests stay in your pipelines, and the same standards apply to human- and AI-written code. Custom collectors and policies extend that foundation for organization-specific requirements.

Your team still decides which standards apply, approves exceptions, and determines when blocking is appropriate.

The value depends on how much collection, rollout, and maintenance work Lunar removes from your particular environment, including the custom work that remains.

Choosing what your team will own

A useful evaluation should show which services meet the requirement, how violations are handled, and how quickly a new standard reaches both shared and custom workflows. The evidence should also make it possible to explain each result.

That gives you a concrete outcome to weigh against the engineering, adoption, and operating effort each option requires.

Building is a sound choice when your platform and team can deliver that coverage and sustain it alongside their other commitments. Buying is worth the investment when the coverage or capacity it adds outweighs the subscription, integration work, and vendor dependence.

If you’re weighing building versus buying a guardrails engine, we’d love to help you assess where Lunar could fill the gaps in your current setup. Book a demo to walk through your standards and workflows.