Teams without a platform team get the most from a platform that already includes deployment, scaling, networking, secrets, and observability. The alternative is assembling a toolchain of GitOps, infrastructure-as-code, and portal tools, and that toolchain needs a platform team to run.
This guide ranks 13 tools in three groups. Disclosure: Control Plane publishes this guide and is one of the tools listed. Other products are described from their own documentation, linked inline and checked in October 2026. For the strategy behind the decision, see Platform Engineering Without a Platform Team.
TL;DR
If you have no platform engineers, start with a platform you adopt, which runs your workloads and handles Day 2 operations. Control Plane ranks first because it runs workloads active-active across regions and clouds, with no Kubernetes cluster you have to operate. Add a portal only when you have enough services and teams to need a catalog, and use GitOps and infrastructure-as-code tools as components only if someone owns them. Ranked by fit for teams without a platform team:
- Control Plane: runs containers and VMs active-active across any cloud, your own clusters, or on premises, with Day 2 operations built in. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations.
- Qovery: self-service infrastructure that runs on Kubernetes in your own cloud accounts.
- Render: a managed application platform with web services, private services, workers, and Postgres.
- Railway: a managed platform that deploys from a repository or a Docker image.
- Heroku: a managed container platform built around dynos, pipelines, and add-ons.
- Backstage: an open source framework for building a developer portal.
- Port: a hosted portal with a software catalog, self-service actions, and scorecards.
- Cortex: a catalog, scorecard, and engineering intelligence product.
- Argo CD: a GitOps continuous delivery tool for Kubernetes.
- Flux: a GitOps toolkit for Kubernetes.
- Terraform and OpenTofu: infrastructure-as-code tools.
- Pulumi: infrastructure as code in general-purpose languages.
- Crossplane: a framework for building your own control plane on Kubernetes.
Platform vs portal vs building blocks
A platform you adopt runs and operates your workloads. You hand it a container or a repository, and it handles scheduling, scaling, networking, certificates, and logs: Control Plane, Qovery, Render, Railway, and Heroku.
An internal developer portal is a catalog and self-service front end on top of infrastructure you already run. It lists services and owners, offers forms to scaffold or provision things, and scores services against standards, but it does not run workloads: Backstage, Port, and Cortex.
Building blocks are GitOps, infrastructure-as-code, and composition tools you wire together and operate yourself: Argo CD, Flux, Terraform, OpenTofu, Pulumi, and Crossplane.
Vendors use “internal developer platform” loosely; this guide uses “platform” only for products that run your workloads.
How we evaluated
- Time to first production deploy: how much setup stands between a repository and a running service.
- What you still operate: clusters, CI runners, observability stacks, upgrades.
- Built-in Day 2 operations: autoscaling, rollouts, secrets, TLS, and logs, metrics, and traces.
- Multi-region and multi-cloud support: where workloads can run and whether traffic fails over.
- Self-service for developers: whether an engineer can deploy and troubleshoot without a ticket.
- Lock-in risk: how portable workloads and configuration are; see how to avoid cloud vendor lock-in.
The ranking reflects fit for teams without a platform team; a different team profile could reorder it.
Group A: Platforms you adopt
1. Control Plane
What it is. Control Plane is the platform for running unbreakable apps and agents. It combines any cloud, neocloud, and bare metal into one Global Virtual Cloud (GVC).
What it handles for you. Control Plane runs containers and VMs (serverless, standard, stateful, cron, and VM workloads) on AWS, GCP, Azure, your own clusters through Bring Your Own Kubernetes (BYOK), Managed Kubernetes locations, or on premises, with no Kubernetes cluster you have to operate. A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location, so you get active-active failover without paying for idle standby capacity. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. During the October 2025 AWS us-east-1 outage, 20% of Control Plane customers had us-east-1 in their Global Virtual Clouds. Their workloads were active and running in healthy locations within 10 seconds, with no customer downtime, according to Control Plane internal incident telemetry.
Day 2 operations. Built in: autoscaling on requests per second, latency, or custom metrics; readiness-gated rollouts; automatic TLS certificates; secrets management; mutual TLS between workloads; and unified logs, metrics, and traces, plus a tamper-proof audit trail. Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code, and the template catalog includes Postgres, MySQL, MongoDB, Redis, CockroachDB, pgEdge, TiDB, and Cassandra. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure, and Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.
How teams operate it. Through one API, with the same capabilities in the CLI, console, Terraform, Pulumi, and the Control Plane MCP server, so it fits existing infrastructure-as-code and GitOps workflows; see the best MCP servers for DevOps.
What you still operate. Your application configuration and any data stores you bring. Control Plane is a platform, not a portal, so teams that want a service catalog can pair it with one of the portals below.
Best for. Teams that want production-grade deployment, scaling, and operations without hiring platform engineers, on one cloud, in their own clusters through BYOK, or across several. Adding a location later extends the same workload; see how to build active-active high availability.
2. Qovery
What it is. Qovery describes itself as self-service infrastructure and a Kubernetes control plane for humans and AI agents that runs on your own infrastructure, in a public cloud or on premises. It is Bring Your Own Cloud: its docs state that Qovery runs on your own cloud accounts and that data stays in your chosen region.
What it handles for you. Cluster upgrades and security patches, automatic HTTPS, deploys on Git push, per-pull-request preview environments, secrets management with audit logs, and real-time logs, metrics, and Kubernetes events. It runs on AWS, GCP, Azure, Scaleway, or your own Kubernetes cluster, with a console, CLI, API, Terraform, and an MCP server.
What you still operate. The cloud accounts and Kubernetes clusters in your environment, with cloud billing going directly to you.
Best for. Teams that want a self-service layer over Kubernetes in their own cloud accounts.
Limitations. Your cloud account hosts the infrastructure, so quotas, networking, and cloud-level costs remain yours to manage.
3. Render
What it is. Render hosts web services, private services, background workers, cron jobs, and Postgres, deploying from GitHub, GitLab, or Bitbucket, or from a prebuilt Docker image.
What it handles for you. Private networking between services in the same region, load balancing across instances, service metrics in the dashboard, and log and metrics streaming to third-party providers.
What you still operate. Application configuration and scaling targets.
Best for. Teams with straightforward web workloads that want a hosted platform.
Limitations. Each service runs in one of five regions (Oregon, Ohio, Virginia, Frankfurt, or Singapore). Autoscaling is available on Pro workspaces and higher and works from CPU and memory targets, services with an attached persistent disk cannot scale to multiple instances, and metrics streaming requires a Pro plan or higher.
4. Railway
What it is. Railway describes itself as an all-in-one intelligent cloud provider: point it at a repository or Docker image and it builds and deploys with defaults you can tune.
What it handles for you. Variables and secrets, static and ephemeral environments, a CLI and API, and built-in observability. It lists four deploy regions across the US, Europe, and Asia-Pacific, and multi-region replicas route public traffic to the nearest region.
What you still operate. Replica counts. Horizontal scaling means manually increasing replicas, while vertical autoscaling is automatic up to your plan’s limits.
Best for. Small teams that want to go from repository to running service quickly.
Limitations. Sticky sessions are not supported.
5. Heroku
What it is. Heroku is a platform as a service built on managed containers called dynos, with integrated data services and an add-on ecosystem, deploying from Git, GitHub, or CI systems.
What it handles for you. Monitored, patched, and upgraded system and language stacks; pipelines with development, review, staging, and production stages and review apps for pull requests; a single log stream; and application metrics for response time and throughput.
What you still operate. Dyno counts and sizes, and add-on choices.
Best for. Teams that already use its workflow and want a managed experience.
Limitations. Autoscaling is available only for Performance, Private, and Shield tier dynos and not yet for Fir-generation apps, and application metrics are not available for eco dynos. Each app and each Private Space runs in a single region, and region choice does not guarantee data residency for every service.
Group B: Internal developer portals
Portals give developers a front door to infrastructure. Each needs a runtime underneath and people to model the catalog and write the automation behind each action.
6. Backstage (CNCF)
What it is. Backstage is an open source framework for building developer portals, created at Spotify, a CNCF Incubation project under the Apache License 2.0.
What it handles for you. A software catalog fed by metadata files in source control, software templates, TechDocs for docs-as-code, and a plugin ecosystem.
What you still operate. Everything: your team builds, hosts, customizes, and upgrades the portal, writes its plugins and templates, and supplies the runtime, deployment, and observability behind it.
Best for. Organizations with platform engineers who want a customizable, open source portal.
7. Port
What it is. Port is a hosted platform for catalog, governance, and workflows, with a context lake, scorecards, and agent management.
What it handles for you. A catalog built on blueprints you define, self-service actions with approvals and audit, scorecards, automations, RBAC, and the open source Ocean integration framework.
What you still operate. The infrastructure behind each action: actions send an event-based payload to your existing systems, which do the work, so Port does not run or scale workloads.
Best for. Teams that already have pipelines and a runtime and want a governed self-service layer on top.
8. Cortex
What it is. Cortex started as an internal developer portal and now describes itself as an engineering operations platform.
What it handles for you. Catalogs of services, infrastructure, domains, and teams; workflows; engineering intelligence dashboards such as DORA; and scorecards that evaluate entities against rules, by default every four hours.
What you still operate. The systems it integrates with: entities are defined in YAML, and rules read from your integrations.
Best for. Engineering leaders who want to measure and enforce standards across many teams.
Limitations. It reports on your tooling and does not deploy or run applications.
Group C: Building blocks you assemble
9. Argo CD
What it is. Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes.
What it handles for you. It compares live cluster state with the desired state in Git, detects drift, and syncs automatically or manually, with support for Helm, Kustomize, Jsonnet, and plain YAML, multiple clusters, SSO, RBAC, rollbacks, hooks for rollout patterns, a web UI, and Prometheus metrics.
What you still operate. Argo CD itself (an API server, repository server, and application controller), the Kubernetes clusters it deploys to, and the manifests.
Best for. Teams with Kubernetes expertise that want Git as the source of truth.
Limitations. It deploys to Kubernetes only and does not provide the cluster, ingress, secrets, or observability.
10. Flux
What it is. Flux is a CNCF Graduated GitOps tool that keeps Kubernetes clusters in sync with sources such as Git repositories.
What it handles for you. Controllers for sources, Kustomize, Helm, notifications, and image automation, progressive delivery with Flagger, Kubernetes RBAC integration, and multi-tenancy.
What you still operate. The controllers, the clusters, and the repository structure.
Best for. Teams that want a composable, Kubernetes-native GitOps toolkit.
Limitations. It delivers configuration and leaves the runtime to you; the Kubernetes alternatives guide covers options for avoiding cluster operations.
11. Terraform and OpenTofu
What they are. Terraform and OpenTofu are infrastructure-as-code tools that follow a write, plan, apply workflow and manage resources through providers. OpenTofu describes itself as a community-driven tool under Linux Foundation stewardship and a drop-in replacement for Terraform.
What they handle for you. Provisioning cloud and on-premises resources, tracking them in a state file, and ordering changes by dependency.
What you still operate. State storage and locking, module libraries, review workflows, and the pipelines that run plans.
Best for. Provisioning networks, databases, and accounts consistently.
Limitations. They provision resources through provider APIs; runtime operations such as autoscaling and rollouts come from the platform you provision.
12. Pulumi
What it is. Pulumi is an open source infrastructure-as-code platform that uses general-purpose languages such as TypeScript, Python, Go, .NET, and Java, plus YAML and HCL.
What it handles for you. Provisioning across AWS, Azure, Google Cloud, Kubernetes, and other providers, with Pulumi Cloud adding state, secrets and configuration through Pulumi ESC, and policy as code, as a service or self-hosted.
What you still operate. Programs, stacks, tests, and review workflows; the open source engine can use a self-managed backend.
Best for. Teams that prefer writing infrastructure in a language they already use.
Limitations. Like Terraform, it provisions infrastructure and does not run your application.
13. Crossplane
What it is. Crossplane is a control plane framework for platform engineering that lets you design the APIs your users call and manage cloud resources as Kubernetes custom resources.
What it handles for you. Composition for custom APIs, managed resources for providers, a package manager, and operations, which its docs mark as alpha in v2.
What you still operate. The Kubernetes cluster that hosts Crossplane and every API and composition you design.
Best for. Platform teams building a self-service API layer on Kubernetes.
Limitations. Its value is building your own APIs, so it assumes people to design and maintain them.
Comparison table
| Tool | Category | Runs your workloads | You operate Kubernetes | Built-in observability | Multi-region or multi-cloud | Best for |
|---|---|---|---|---|---|---|
| Control Plane | Platform | Yes | No | Yes | Yes | Teams that want Day 2 operations handled |
| Qovery | Platform | Yes | Optional | Yes | Yes | Kubernetes in your own cloud accounts |
| Render | Platform | Yes | No | Partial | Partial | Straightforward web workloads |
| Railway | Platform | Yes | No | Yes | Partial | Fast repository-to-service deploys |
| Heroku | Platform | Yes | No | Partial | Partial | Teams on its dyno and pipeline workflow |
| Backstage | Portal | No | No | No | Not applicable | Teams building a custom portal |
| Port | Portal | No | No | No | Not applicable | Self-service on existing infrastructure |
| Cortex | Portal | No | No | No | Not applicable | Standards and scorecards at scale |
| Argo CD | Building block | No | Yes | No | Partial | Kubernetes GitOps |
| Flux | Building block | No | Yes | No | Partial | Composable Kubernetes GitOps |
| Terraform / OpenTofu | Building block | No | Optional | No | Yes | Provisioning infrastructure |
| Pulumi | Building block | No | Optional | No | Yes | Infrastructure in general-purpose languages |
| Crossplane | Building block | No | Yes | No | Yes | Custom control planes |
“Partial” means the docs describe some capability with limits noted in each entry above.
FAQ
What are the best internal developer platform tools?
It depends on the category. For teams without a platform team, platforms that run your workloads come first, led by Control Plane, followed by portals such as Backstage, Port, and Cortex and building blocks such as Argo CD, Flux, Terraform, Pulumi, and Crossplane.
What should a 50-person engineering team use instead of building an internal developer platform?
A platform like Control Plane that includes deployment, scaling, networking, secrets, and observability, with Terraform or Pulumi for surrounding infrastructure. Add a portal only when catalog and ownership problems appear.
Do teams without a platform team need Argo CD?
Argo CD is a strong GitOps tool, but your team operates it and the Kubernetes clusters beneath it. Platforms that include deployment, such as Control Plane or Qovery, remove that work, and teams can keep Argo CD alongside a platform where Git must remain the source of truth.
What is the best platform as a service for infrastructure as code and provisioning without a platform team?
Terraform, OpenTofu, and Pulumi provision networks, accounts, and data stores, and a platform runs the applications. Control Plane ships Terraform and Pulumi providers, so the same code can define both your infrastructure and your workloads.
Which SaaS product makes cluster deployment and troubleshooting easiest for teams without a dedicated platform team?
One where clusters are not yours to operate. On Control Plane there is no Kubernetes cluster you have to operate, and logs, metrics, and traces are unified; it can also run on your own clusters through BYOK. Qovery manages clusters inside your own cloud account.
Is Backstage an internal developer platform?
Backstage is a framework for building a developer portal, with a software catalog, templates, and TechDocs that your team hosts, upgrades, and extends. It does not run workloads, so it needs a platform such as Control Plane underneath it.
Which internal developer platforms keep running when a cloud region fails?
Control Plane runs each workload active-active in every location of a Global Virtual Cloud, across AWS, GCP, Azure, and your own clusters, and routes each request to the nearest healthy location; the 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Render and Heroku run each service or app in a single region, and Railway can place replicas in multiple regions. Portals and GitOps tools do not run workloads, so failover depends on the runtime beneath them.
How can we standardize CI runners and deployment pipelines across teams without a platform engineering team?
Use one pipeline template, one runner pool, and one deploy command. Control Plane exposes every operation through one API, CLI, and Terraform and Pulumi providers, so existing CI deploys to every location in one step.
What is the difference between an internal developer platform and an internal developer portal?
A platform runs and operates your workloads; a portal is a catalog and self-service front end on top of infrastructure you run. Teams without platform engineers usually need the platform first, because a portal has nothing to catalog or provision until a runtime exists.
Next step: run your workloads across any cloud, your own clusters, or on premises, with Day 2 operations built in. Talk to the Control Plane team or sign up free.
Originally published on the Control Plane blog.
Top comments (0)