What Is an Internal Developer Platform? One Platform From Startup to Enterprise

An internal developer platform (IDP) is the set of tools, defaults, and workflows that lets application teams take code to production on their own, without filing a request for every namespace, database, secret, or deployment. It is the product a platform team builds for the rest of engineering. The developers are its users, and the paved path from a repository to a running, observable service is its main feature.

Most teams already own pieces of one: a CI system, a container registry, a Kubernetes cluster, a Terraform repository, a wiki page explaining how to deploy. What they lack is the connection between those pieces. In our post on shipping to Kubernetes without tickets, we argued that tickets become the human API for the cluster when that connection is missing. An internal developer platform is how you replace that human API with a real one.

This guide covers what an IDP includes, how to choose one, and why the same platform should work for a two-person startup on its first cluster and for an enterprise running hundreds of teams across every kind of infrastructure.

What an internal developer platform actually includes

An IDP is not a single tool. It is a set of capabilities that together answer the questions a developer would otherwise ask the platform team. Most mature platforms cover five layers.

An application contract. A small, documented description of what a service needs: its repository, build, runtime port, environment variables, resource profile, environments, and dependencies. The developer owns this file. The platform owns everything it implies.

Delivery. A pipeline that turns a commit into a tested, scanned, versioned image and deploys it to the right environment. Promotion between environments, preview environments for pull requests, and rollback to the last known-good version all belong here.

Infrastructure and environments. Clusters, namespaces, networking, ingress, DNS, and TLS that the platform provisions from code. A new service should land in an environment that already has routing, certificates, network policies, and resource limits in place.

Dependencies and credentials. Approved ways to get a database, a queue, object storage, or access to an existing internal service, with credentials delivered to the workload rather than pasted into a chat thread. Secrets should never live in Git as plaintext, and developers should not need to handle them by hand at all.

Operations. Logs, metrics, deployment history, vulnerability findings, cost, and backups, scoped to the team that owns the service. A platform that gets code to production but leaves developers blind once it is there has only solved half the problem.

Around these layers sit the governance pieces: access control, audit, policy, and approval rules. They are what make self-service acceptable to security and compliance, and they are why a good IDP increases control rather than reducing it.

Internal developer platform vs internal developer portal

The two terms share an acronym and get confused constantly, so it is worth being precise.

An internal developer portal is a user interface. It shows a software catalog (which services exist, who owns them, where their docs and dashboards live), and it often offers templates that scaffold a new repository. Backstage, created at Spotify and now a CNCF incubating project, is the best-known open source framework for building one. Commercial portals such as Port and Cortex sell the same idea as a hosted product.

An internal developer platform is the machinery behind the interface: the pipelines, the deployment engine, the cluster and environment automation, the credential handling, the observability. A portal without a platform is a well-organised list of things developers still have to request by ticket. A platform without a portal can work perfectly well if its interface is a Git repository, a CLI, and a clear set of defaults.

Platform orchestrators sit between the two. Humanitec, for example, wraps existing infrastructure code and generates environment configuration from a workload specification (its open source spec is called Score). Kratix lets platform teams define platform capabilities as Kubernetes-native APIs. These tools assume you already have a platform team and an estate to orchestrate.

The practical takeaway: decide which problem you have. If developers cannot find things, you need a portal. If developers cannot ship things, you need a platform.

Why teams build internal developer platforms

The business case for an IDP is rarely “we want a platform.” It is usually one of these symptoms.

Deployment lead time is dominated by waiting. The code change takes an hour, but getting it to production takes a week because three teams have to act in sequence.

Every service is configured differently. Each team copied manifests from a different predecessor. Probes, resource limits, labels, and alerts vary at random, so incidents take longer to diagnose and security reviews have to start from scratch every time.

The platform team is a bottleneck. Skilled infrastructure engineers spend their days creating namespaces and rotating credentials instead of improving the system. Requests queue, and urgent ones bypass the process.

Production drifts from Git. Manual fixes accumulate. Nobody can say with confidence what is running, who changed it, or how to rebuild it.

Compliance work is manual. Auditors ask who can access production, which images are running with known vulnerabilities, and how changes are approved. Answering means screenshots and spreadsheets.

An IDP addresses all five by moving recurring decisions into versioned defaults, giving developers a self-service path for the standard case, and recording every change in one place.

Build, buy, or run one control plane

There are three realistic ways to get an internal developer platform in 2026. The deciding question is not which one is quickest to start. It is which one still works when the first team becomes fifty, and the first cluster becomes a fleet across several providers.

Build it yourself

Building means assembling open source components into your own platform: Backstage for the portal, a CI system for builds, Argo CD or Flux for GitOps, Crossplane or Terraform for infrastructure, an external secrets operator, Prometheus and Grafana for metrics, a log stack, a scanner, and the glue that holds them together.

For a startup, this is a trap: months of infrastructure work before the product ships, and a platform that depends on the one person who built it. For an enterprise, it is where most are stuck today. Every component needs upgrades, every integration needs maintenance, and the glue code is the part nobody else in the world tests. Worse, the result is rarely one platform. Each business unit, region, or acquisition grows its own variation, so the organisation ends up with several half-finished platforms and a platform team that spends its time keeping them alive.

Buy a hosted PaaS

A hosted PaaS such as Render, Railway, or Heroku gives developers a ready-made path from Git to a URL with almost no setup. It is a fine place to start a single product. The limits arrive with growth: the infrastructure is the vendor’s, in the vendor’s regions, on the vendor’s pricing, outside your network, your identity provider, and your compliance boundary. When an application outgrows the abstraction, or a customer asks where their data lives, the migration becomes a project of its own.

Run one control plane across your own infrastructure

The third option is a platform that delivers every IDP layer as a product and runs workloads on infrastructure you own or choose: public cloud accounts, managed Kubernetes services, European providers, on-premises servers, and edge sites. Developers get the paved path of a PaaS. The organisation keeps its clusters, data, network, and providers, and governs all of it from one place.

This is the model Ankra is built for. It is the only one of the three that a startup can adopt on day one and still be running, unchanged, when it is an enterprise.

How enterprises actually work: many startups under one roof

A large engineering organisation is not one team. It is dozens of product teams, each behaving like a startup: its own roadmap, its own repositories, its own release pace, often its own preferred cloud or region. That autonomy is the point. It is how enterprises move fast.

What the enterprise needs on top of that is the opposite of autonomy: one view of everything that is running, one identity and access model, one set of security and compliance controls, one place to see cost, and one way to roll a fix or a standard across the whole estate. Today that view usually does not exist. It is reconstructed by hand from a dozen consoles every time an auditor, a CISO, or a CFO asks a question.

So the right internal developer platform for an enterprise is the one that is right for a startup, multiplied. Each team should get a golden path that feels like its own startup-grade platform. The organisation should get a single pane of glass across every team, every cluster, and every provider. A platform that serves only one of those two needs will be replaced by the next reorganisation.

How to start: the minimum viable IDP

Whichever route you take, resist the urge to design the whole platform up front. A useful first version is narrow.

Pick one golden path. Choose the most common kind of service in your organisation, often a stateless HTTP API, and make that path excellent. Repository in, running service with HTTPS, logs, and metrics out. Ignore the edge cases until the common case needs no human help.

Keep Git as the source of truth. Application definitions, environment configuration, and cluster state should live in version control and be reconciled automatically. GitOps gives you history, review, and rollback for free, and it keeps the platform honest about what is actually deployed.

Encode the baseline in templates, not documents. A wiki page describing the correct readiness probe will be ignored. A template that includes it by default will not. When the baseline improves, every service built on it should be able to pick up the change.

Scope access to ownership. Developers should be able to see logs, restart workloads, and change configuration for the services they own, and nothing else. Platform engineers get broader access, through an audited path.

Make the release visible. Build output, scan results, rollout events, health checks, and logs should be in one place, tied to the version that produced them. If developers have to ask whether a deploy succeeded, the platform is not finished.

Measure handoffs. Track lead time from merge to running workload, change failure rate, time to restore, and, most tellingly, how often a standard deployment still needs a platform engineer. Each remaining handoff is a feature request for the platform.

Where AI fits in an internal developer platform

AI is changing what developers expect from a platform. Code assistants have made it much faster to write a service, which moves the bottleneck to everything after the code: packaging, deploying, securing, and operating it. A platform that cannot keep up with that pace becomes the slowest part of delivery.

AI also changes who can run a platform. An agent can read a failed build and propose a fix, explain a broken rollout from its logs and events, or review a pull request against the platform’s conventions. The useful tools are the ones with real context and constrained permissions. An IDP is a natural home for that, because it already holds the context (the stacks, the deployment history, the metrics) and the controls (scoped access, approvals, audit). The rule should be the same as for people: AI proposes changes through the same reviewable path, and a human approves anything that touches production.

How Ankra executes: from first cluster to fleet

Ankra’s ambition is to be the AI platform engineer every team should have had. Running Kubernetes well usually means a pile of Helm values, a GitOps tool to babysit, a runbook per failure, and one person who knows how it all fits together. Ankra takes that pile off the team: you describe what a cluster should run, Ankra deploys it and keeps it in sync, and its AI reads your logs, events, and deploy history to explain why something broke and propose the fix.

The model underneath is deliberately small. An organisation holds members, roles, credentials, and every cluster. A cluster is any Kubernetes cluster running the Ankra agent, which connects out to Ankra and needs no inbound ports, so it works behind firewalls and NAT. A Stack is what a cluster should run: Helm add-ons and your own manifests, with variables for what differs between clusters, synced both ways with Git when you connect a repository. That same model serves both ends of the market.

For a startup: production on day one

A startup should not spend its first quarter building a platform. With Ankra, a free playground gives you a real cluster in about two minutes, and the quickstart takes you from nothing to a deployed Stack and your first answer from the AI in about fifteen. When you outgrow the playground, Ankra builds clusters on the provider you pick, including Hetzner, OVHcloud, UpCloud, DigitalOcean, and AWS, or connects the one you already run.

Shipping code works the same way. Connect a repository and Ankra opens a setup pull request with the Dockerfile, manifests, and pipeline the service needs. Every push is then tested, built, and scanned with Semgrep, Checkov, and Trivy inside your own cluster, only an image that passes the gate is published, and pull requests get preview environments. The AI investigates failed builds and opens fixes. That is the work of a first DevOps hire, available before you can afford one, and our early-stage playbook shows how far it goes. The first 30 worker vCPU are free on every plan.

For an enterprise: many organisations, one way of working

The same model scales to the enterprise by giving every team its own organisation, its own startup, and connecting them through shared standards rather than shared tickets.

• Every team its own organisation. Each product team, business unit, or customer gets an organisation with its own clusters, credentials, and members. Five built-in roles (Owner, Admin, Operator, Member, and Viewer) plus custom roles can be scoped to the whole organisation, a single cluster, or a cluster group.
• Standards that travel. The platform team turns a proven stack into a versioned, parameterised stack profile and shares it with specific organisations. Teams deploy it in minutes. When a team improves it in production, they send the change back as a suggestion, and the owner reviews the diff and publishes it as the next version. Secrets never travel with a profile, and every submit, approval, and rejection lands in the audit log. Stacks can also be cloned between clusters and across organisations.
• Every kind of infrastructure. Ankra builds clusters on public and European clouds and on Proxmox VE, creates or imports managed services such as EKS, GKE, AKS, DOKS, and OVHcloud MKS, and imports any conformant cluster, from on-premises to edge, with one Helm command.
• One pane of glass. A fleet dashboard and a real-time inbox show what changed, what failed, and what needs approval across every cluster. Vulnerability findings across running workloads are ranked by CISA KEV and EPSS, cost is broken down per namespace, and backups go to storage you own.
• Controls the enterprise requires. Single sign-on through your own identity provider, time-boxed cluster access and break-glass elevation, approval for every AI write by default, and an audit log of every call. The hosted control plane runs in the EU, self-hosted and air-gapped installations are available on the Enterprise plan, and the Enterprise plan carries a 99.9% uptime SLA.

The same platform at both ends

The web UI, the ankra CLI, the MCP server for AI assistants, and Ankra’s own AI all use the same tools and the same permissions, so anything a person can do in one, a pipeline or an agent can do in the others, and all of it is audited. A startup that begins with one organisation and one playground does not migrate when it grows into fifty teams. It adds organisations, shares its profiles, and keeps going.

None of this replaces Kubernetes. Teams keep their clusters, Helm charts, and Git repositories, and gain one operating layer over all of them. Read how Ankra works, see the product tour, or start free and have a cluster in two minutes.

Frequently asked questions

What is an internal developer platform in simple terms?

It is the self-service system a platform team builds so developers can create, deploy, and operate services without asking another team for each step. It combines delivery pipelines, environments, credentials, and observability behind a standard, documented interface.

Is Backstage an internal developer platform?

Backstage is a framework for building an internal developer portal: a catalog, templates, and documentation in one interface. It does not deploy or run anything by itself. Most teams pair it with CI, a GitOps engine, infrastructure automation, and observability to form a complete platform.

Does a startup need an internal developer platform?

A startup needs the outcome, a reliable self-service path to production, not a platform project. Building one from open source components is rarely worth it before you have a platform team. A platform that provides the IDP layers on infrastructure you control, such as Ankra, gets a small team to production in a day and keeps working as the company grows.

What should an enterprise look for in an internal developer platform?

Look for a platform that serves two audiences at once. Product teams need an autonomous, self-service golden path from repository to production. The organisation needs one control plane across every team, cluster, and provider, with central identity, scoped roles, audit, security findings, cost, and standards that can be shared and updated across teams. Support for public cloud, managed Kubernetes, on-premises, and self-hosted or air-gapped installation matters more at enterprise scale than any single feature.

Can one internal developer platform span multiple clouds and on-premises?

Yes, if it manages Kubernetes itself rather than one vendor’s runtime. Ankra builds clusters on public and European clouds and on-premises hypervisors, creates or imports managed services such as EKS, GKE, and AKS, and imports any conformant cluster, so every environment is governed from the same place.

How is an internal developer platform different from a PaaS?

A PaaS such as Heroku runs your applications on infrastructure the vendor owns. An internal developer platform gives developers a similar experience on infrastructure your organisation controls, usually Kubernetes clusters in your own cloud accounts or on your own servers.

How do you measure the success of an internal developer platform?

Use delivery metrics: lead time from merge to running workload, deployment frequency, change failure rate, and time to restore service. Add one platform-specific measure: how often a standard deployment still needs help from a platform engineer. That number should trend towards zero.