Config Standardization
End config drift.
Once.
CI pipelines, YAML manifests, and CODEOWNERS files diverge quietly. Until a failed deploy or a compliance gap reveals what you didn't know was broken. Tidra standardizes them across your entire org, at once.
Add CODEOWNERS file to all repositories. Route /infra/ to @infra-team and /.github/ to @platform-eng and @security. Global ownership to @platform-eng.
The Problem
Config drift is a silent crisis
One team updates their GitHub Actions workflow. The rest don't hear about it for months. Security configs get added to new repos but never backfilled to existing ones. CODEOWNERS files are created once and never updated as teams change.
You don't know the drift is happening until something breaks: a failed deploy, a missed code review, a compliance audit that reveals 90 repos are running on an unsupported runner image. By then, you've accumulated a backlog that would take months to clear manually.
Without Tidra
- Config changes get applied to new repos only
- Drift grows silently over months
- Manual audits take weeks and go stale
- Compliance gaps discovered at the worst moment
- One-off fixes leave inconsistencies
With Tidra
- Changes propagate to all repos, not just new ones
- Drift caught and corrected in one initiative
- Automated audit runs in minutes
- Compliance state is provable and up to date
- Consistent standard enforced org-wide
Coverage
What you can standardize
Any file or configuration that should be consistent across repos. Tidra can enforce it at scale.
CI/CD pipelines
- Runner OS versions
- Workflow templates
- Job timeouts & permissions
Code ownership
- CODEOWNERS files
- Team routing rules
- Reviewer assignments
GitHub Actions
- Pin actions to versions
- Standardize action inputs
- Shared workflow calls
Observability configs
- Datadog agent tags
- OpenTelemetry settings
- Log level standards
Build configs
- .nvmrc and .node-version
- Lint & formatter configs
- Dependency lock strategies
Security configs
- SECURITY.md files
- Dependabot config
- Branch protection rules
Live Example
Runner versions & code ownership
Tidra applies the standard to every repo that needs it. Not just the ones you remember to update.
How It Works
Define once. Enforce everywhere.
01
Define the standard
Tell Tidra what the correct configuration looks like. Paste the target YAML, point to your golden repo, or describe the standard in plain language.
02
Tidra audits all repos
It scans your organization's repos to identify which ones are missing the standard or have diverged from it.
03
Changes generated at scale
Tidra generates the correct change for each repo, accounting for differences in structure, existing configs, and team conventions.
04
Review and merge
PRs open across all affected repos simultaneously. Track CI status and merge progress from a single dashboard.
From the library
Example standardization initiatives
Standardize CODEOWNERS
Add or update CODEOWNERS files across all repositories to enforce consistent review policies, ensuring every repo has clear ownership and required reviewers for critical paths.
Standardize GitHub Actions Workflows
Enforce consistent structure and patterns across all GitHub Actions workflows: action versions, checkout steps, caching, timeout settings, and naming conventions.
Standardize Dockerfile Base Images
Update all Dockerfiles to use approved base images from your organization's container registry, enforcing consistent and secure base layers across all services.
Frequently asked questions
What kinds of configuration can Tidra standardize?
CI/CD pipeline configs (GitHub Actions runner versions, action pinning, workflow templates), CODEOWNERS files, observability configs, linter and formatter configs, Dockerfile base images. Anything that lives in a file and follows a pattern across repos.
How does Tidra avoid overwriting intentional differences between repos?
You specify which repos to target when setting up the initiative. Every generated diff is visible before any PR gets created, so you can catch exceptions early. Teams can also push back in the normal PR review if something looks wrong for their repo.
Can Tidra enforce configuration standards on an ongoing basis?
The initial rollout is a one-time initiative. For ongoing enforcement, you run it again periodically. There is no automatic drift detection; you trigger it when you want to check.
How is this different from writing a script?
A script applies the same thing to every repo regardless of what is already there. Tidra reads each repo first and adapts the change to its existing structure. It also flags repos where the standard does not fit cleanly rather than forcing it. Every change goes through a normal PR review, so nothing happens outside your usual process.
Get started
Stop letting standards drift
Define the standard once. Tidra enforces it across every repo. Not just the ones you remember to update.
247 repos. One initiative.