New
What is in your internal developer platform, and what did developers actually adopt?
Golden paths, templates, portals, self-service environments. Which parts get used every day and which became shelfware?
Evaluation guide
How to evaluate DevOps and platform tools
This guide is for platform engineering, DevOps and engineering leaders building an internal developer platform, replacing a CI/CD system or standardising infrastructure as code. It assumes several teams ship software in different ways today and you want fewer, safer paths to production.
In short
Use this guide to compare CI/CD, infrastructure as code, internal developer portals and release tools on what decides the outcome: whether developers adopt them, pipeline and supply chain security, policy guardrails, fit with your existing toolchain, cost at your build volume and how easily pipelines move later. Then shortlist three to five companies on Techarda and trial them with one team.
What’s changing in DevOps & Platform Engineering
Before you compare anyone, it helps to know what has shifted in the market, because it changes which questions matter.
Platform engineering is now a team with customers
Many organisations have a team whose product is the internal platform and whose customers are developers. That changes how tools are judged: adoption and developer time count as much as features.
The software supply chain is a target
Attacks on build systems, dependencies and release pipelines have made provenance, signing and pipeline hardening part of the core brief. Frameworks such as SLSA give a shared way to describe what good looks like.
Licence terms have become a selection criterion
A licence change in a widely used infrastructure as code tool led to a community fork, and teams now weigh licence and project governance alongside features. Check the terms of the exact tool and version you would run.
AI assistants are entering pipelines
Vendors are adding assistants that explain failed builds, suggest fixes and write pipeline configuration. They help on routine failures, and you should check what code and logs they send, and where.
What to judge vendors on
Those shifts shape the criteria below. Each one says why it matters and what to ask, so you can take it straight into a vendor call.
| Criterion | Why it matters | What to ask vendors |
|---|---|---|
| 1Developer adoption | A platform developers avoid becomes shelfware while teams build their own paths around it. Adoption is the outcome to measure. | “How do developers start a new service on your platform, how long does that take in practice, and can we trial it with one of our product teams?” |
| 2Pipeline and supply chain security | Build systems hold secrets and can push code to production. A compromised pipeline is a compromised product. | “How are secrets stored and scoped, how are builds isolated from each other, and can you produce signed provenance for every artefact?” |
| 3Policy and guardrails | Guardrails let teams move quickly without each one rebuilding the same security and compliance checks. | “How do we define policies as code, enforce them on pipelines and infrastructure changes, and grant documented exceptions?” |
| 4Fit with your existing toolchain | Your source control, cloud accounts, ticketing and monitoring tools are staying. A platform that fights them creates more work than it saves. | “Which of our current tools do you integrate with natively, who maintains those integrations, and what would we have to replace?” |
| 5Cost at your build volume | Pricing per user, per build minute or per managed resource scales differently. A model that suits a small team can be expensive at full adoption. | “What would we pay at our current build minutes, users and managed resources, and at double that, and how are runners we host ourselves charged?” |
| 6Portability of pipelines and templates | Pipeline definitions and templates pile up quickly. Proprietary formats make the next migration much bigger. | “In what format are pipelines, templates and infrastructure definitions stored, and what tooling exists to move them to another system?” |
| 7Reliability of the platform itself | When the CI/CD system is down, nobody ships, including the fix for a production incident. | “How do you report your own availability, can we run critical pipelines on our own runners during an outage, and how are incidents communicated?” |
| 8Delivery measures | You will be asked whether the platform made delivery faster and safer. Measures such as deployment frequency, lead time and change failure rate are widely used for this. | “Can we report delivery measures across teams from your data, and export the raw events to our own analytics?” |
Trade-offs to settle early
No vendor does well on every criterion, and some pull against each other. Decide where you stand on these before the demos start, or the demos will decide for you.
Build an internal platform or buy one
Open-source portal frameworks let you build exactly what you need and need a team to keep them running. Commercial platforms deliver value sooner and shape your platform around their model.
All-in-one suite or a tool per stage
A suite covering source, CI, security and release gives one permission model and one bill. Specialist tools often go deeper at each stage, and you own the joins.
Golden paths or freedom
Standard templates make security and support easier. Make them too rigid and teams with real exceptions go around the platform, so decide where exceptions are allowed and who approves them.
Hosted runners or your own
Vendor-hosted runners remove maintenance. Your own runners keep builds and secrets inside your network and can cost less at volume, at the price of patching and capacity work.
Migrate everything or start with new work
Moving every pipeline at once gives a clean cut-over and a long, risky project. Starting new services on the platform is safer and leaves two systems running for longer.
Red flags
As the answers come back, watch for these. One on its own isn’t a deal breaker, but it deserves a follow-up question in writing.
- Demos built on a sample application that looks nothing like your services.
- Signed provenance and build isolation described as roadmap items.
- Pipeline definitions in a proprietary format with no export or migration tooling.
- Pricing that jumps once usage passes a tier, with no cap.
- Unclear licence terms for future versions of a tool you would depend on.
- References only from teams much smaller or much larger than yours.
Build your shortlist
Start with the developer experience you want, then use Techarda to narrow the field to three to five companies.
- Pick one path to production you want to improve, such as starting a new service or releasing a change, and write down how it works today.
- List the tools that are staying (source control, cloud, identity, monitoring) and keep only companies that integrate with them today.
- Compare like with like: CI/CD against CI/CD, infrastructure as code against infrastructure as code, portals against portals.
- Read recent stories on Techarda for licence changes, pricing changes and acquisitions.
- Bring the practitioner questions below into vendor calls, then trial the finalists with one real product team.
Companies to consider in DevOps & Platform Engineering
Listed by recent activity on Techarda (what people are reading, following and discussing). The order says nothing about quality, market share or fit for your needs.
Latest DevOps & Platform Engineering stories
Once you have names, recent news is where pricing changes, acquisitions and outages show up first. These are the five newest stories in this category.
What practitioners are asking
News tells you what vendors announced. These open questions show what teams are still trying to work out, with the least-answered first.
Where evidence is thin
A shortlist is only as good as the evidence behind it, and ours is still growing category by category. Here is what’s missing in DevOps & Platform Engineering right now.
20 of 20 companies have no published reviews
If you’ve run one of these in production, a short review helps the next team decide. Reviews are moderated before they appear.
1 question with no answers yet
An answer from someone who has made the same decision is often more useful than any guide. Share what worked, what didn’t and what you’d check next time.
Answer a DevOps & Platform Engineering questionFrequently asked questions
What should I ask DevOps & Platform Engineering vendors about developer adoption?
A platform developers avoid becomes shelfware while teams build their own paths around it. Adoption is the outcome to measure. Ask: How do developers start a new service on your platform, how long does that take in practice, and can we trial it with one of our product teams?
What should I ask DevOps & Platform Engineering vendors about pipeline and supply chain security?
Build systems hold secrets and can push code to production. A compromised pipeline is a compromised product. Ask: How are secrets stored and scoped, how are builds isolated from each other, and can you produce signed provenance for every artefact?
What should I ask DevOps & Platform Engineering vendors about cost at your build volume?
Pricing per user, per build minute or per managed resource scales differently. A model that suits a small team can be expensive at full adoption. Ask: What would we pay at our current build minutes, users and managed resources, and at double that, and how are runners we host ourselves charged?
What should I ask DevOps & Platform Engineering vendors about portability of pipelines and templates?
Pipeline definitions and templates pile up quickly. Proprietary formats make the next migration much bigger. Ask: In what format are pipelines, templates and infrastructure definitions stored, and what tooling exists to move them to another system?
New to some of the terms in this guide? The glossary explains CI/CD, DORA metrics, GitOps, Infrastructure as code (IaC), Internal developer portal and 1 more DevOps & Platform Engineering terms.
This guide is written by Techarda editors to our editorial standards. No vendor paid to appear in it or saw it before publication. See our methodology, the trust dashboard or go back to the DevOps & Platform Engineering hub.