The 3 Cloud Leaks Every Kubernetes Bill Hides
Your AWS invoice shows what you spent, never what you wasted. Here are the three Kubernetes cost leaks hiding in every EKS bill — and how to spot them.
Internal Developer Platform
The internal developer platform that does the work.
Most IDPs are a portal — a catalog that sits on top of your tools and shows you things. Atmosly is a complete internal developer platform that executes: it provisions clusters, ships your code, and runs your workloads directly. Developers self-serve on golden paths; the platform team sets the guardrails once. No year-long build, no portal to staff.
- ✓ Developer self-service
- ✓ Governed golden paths
- ✓ No platform build-out
AI Operations
CI/CD & Environments
Provisioning & Guardrails
The category
What teams actually want from an IDP
An internal developer platform is the self-service layer between developers and infrastructure: golden paths for engineers, standards and guardrails for the platform team. The disappointment is that most IDPs stop at the catalog — they show you the work without doing it.
Developer self-service
Engineers provision an environment, ship a service, or debug an incident on their own — without filing a ticket and waiting on the platform team.
Golden paths, not blank pages
A paved, repeatable way to go from code to production — so every team ships the same governed way instead of inventing its own.
Guardrails the org can trust
Standards, security, and policy encoded once and enforced automatically — autonomy for developers, control for the platform and security teams.
The real distinction
A portal shows you things. An execution IDP does them.
This is the line that matters when you evaluate IDPs. Portal-first platforms catalog a stack you still have to build and run behind them. Atmosly is the stack — already working.
Portal IDP Backstage · Port · Cortex
Sits on top and visualizes
- A catalog and dashboards over tools you still own and operate.
- You build and maintain the pipelines, operators, and glue behind it.
- Becomes a 2–4 engineer permanent cost center to keep alive.
- Shows what broke and what's deployed — but doesn't fix or ship it.
vs
Execution IDP Atmosly
Does the work itself
- Provisions clusters & cloud resources, ships code, runs workloads directly.
- Reads a running workload and turns it into CD — nothing to rebuild.
- Runs as software you set up yourself — no platform team to staff it.
- The AI SRE diagnoses and fixes; pipelines deploy — it acts, not just reports.
Prefer to keep your portal? Atmosly coexists — it powers the workflows while Backstage or Port stays the front door.
What's in the platform
A complete IDP — three layers, one control plane
Everything a developer platform needs to provision, ship, and run software, working out of the box. Not a portal pointing at these capabilities — the capabilities themselves.
Layer 01 — Provision
Self-service infrastructure, inside guardrails
Import any cluster — public, private, or air-gapped — and let developers request clusters, node groups, databases, and add-ons from curated blueprints. Every action is scoped, audited, and reversible, so self-service never means a free-for-all.
- Clusters, cloud resources & add-ons from blueprints
- A curated Helm marketplace — signed, deployed & tracked
- Guardrails on every provisioning action
postgres-15 · blueprint
team: payments · approved
redis-cache · blueprint
team: growth · approved
gpu-node-group
needs platform approval
blueprint
build
deploy
promote
clone: prod → preview-417
full env · isolated
workload → blueprint
existing service · no rebuild
Layer 02 — Ship
Golden paths from code to production
Turn any running workload into a deployable blueprint, ship it through visual or GitOps pipelines, and clone a full environment for previews on demand. Developers get a paved road; you never hand them a blank page.
- Workload → blueprint → CD, no pipelines to rebuild
- On-demand preview environments cloned from production
- Visual + GitOps pipelines with one-click rollback
Layer 03 — Run
The platform operates it, not just observes it
Astra — our AI SRE agent — detects, diagnoses, and fixes incidents; continuous security scanning keeps CIS, PCI, and SOC 2 posture current; cost intelligence breaks spend down by team and service. This is the layer portals can't offer — Atmosly acts on what it sees.
- AI SRE — root cause and a ranked, reversible fix
- Continuous CIS · PCI · SOC 2 posture, drift caught live
- Cost & right-sizing by team and namespace
api · CrashLoopBackOff
AI SRE · OOM · fix proposed
security · CIS drift
2 controls · remediation queued
cost · right-sizing
platform-wide
Inside the platform
Every layer is a real capability — explore each one
Unlike a portal that catalogs other tools, each part of the Atmosly IDP is a product that does the work. Dive into the capabilities that make up provision, ship, and run.
Build vs. buy
The real alternative isn't a tool — it's a year of platform work
Building a usable IDP in-house means staffing a platform team and waiting roughly a year for golden paths, then maintaining it forever. Atmosly is the same self-service and governance, running on the cluster you already have.
4–6 eng
to build & staff a DIY internal developer platform
~12 mo
before developers see real golden paths
Day one
self-service on the cluster you already run
No rebuild
ingests existing workloads, GitOps & Helm
The IDP for your stage
One platform, mapped to where you are
The same execution IDP meets each team differently — from no platform hire to a governed enterprise estate.
Questions
Internal developer platforms, answered
What is an internal developer platform (IDP)?
An internal developer platform is the self-service layer between developers and infrastructure. It gives engineers golden paths to provision environments, ship code, and run services on their own, while the platform team encodes the standards, security, and guardrails centrally. The goal is developer autonomy without every request becoming a ticket.
What's the difference between a portal IDP and an execution IDP?
A portal IDP — such as Backstage, Port, or Cortex — is a catalog and dashboard that sits on top of other tools and visualizes them. It shows you things but still relies on the pipelines, scripts, and operators you build and maintain. An execution IDP like Atmosly does the work itself: it provisions, ships, and runs your clusters directly, so the platform is the thing operating, not a front door to a stack you still have to assemble.
Is Atmosly an alternative to Backstage or Port?
Yes, for teams that want the platform to actually run things rather than just catalog them. Backstage and Port are portals you staff and build behind; Atmosly ships with the execution layer — CI/CD, environment cloning, provisioning, AI SRE, security, and cost — already working. It can also coexist: Atmosly powers the workflows while a portal stays the front door.
Should we build or buy an internal developer platform?
Building a usable IDP in-house typically means a dedicated platform team and roughly a year before developers see golden paths — then it becomes a permanent cost center to maintain. Buying gives you the same self-service and governance in days, on the clusters you already run, and frees your engineers to work on the product. Atmosly is built for the buy path: import a cluster read-only and adopt capabilities at your own pace.
Do we need a platform team to run an IDP on Atmosly?
No. Atmosly delivers the operations, delivery, and provisioning a platform team would build, as software you can set up yourself. Smaller teams run it without a dedicated platform hire; larger teams use it to scale a small platform team across many clusters instead of growing headcount at the same rate.
Does an IDP replace our existing CI/CD and tools?
It doesn't require ripping anything out. Atmosly runs on standard Kubernetes, GitOps, and Helm and can ingest what you already have — it reads a running workload and turns it into a deployable blueprint, so nothing gets rebuilt. You add the platform alongside your stack and adopt it workload by workload.
What's the difference between an internal developer platform and a PaaS?
A PaaS (like Heroku or Cloud Run) abstracts the infrastructure away entirely — you give it code, it runs it, and you give up control of the underlying platform. An internal developer platform keeps you on your own Kubernetes and cloud, but adds the self-service layer and golden paths on top, so you get developer convenience without losing portability, governance, or cost control. We cover this in depth in Internal Developer Platform vs PaaS.
What are golden paths in an internal developer platform?
A golden path is a paved, opinionated route from code to production that the platform team blesses — the supported way to provision an environment, ship a service, or clone a stack. Developers follow it self-service instead of inventing their own setup, and the standards, security, and guardrails are baked in. See Golden Paths in Platform Engineering for the full pattern.
What should an internal developer platform include?
At minimum, self-service provisioning, a paved code-to-production path, and centralized guardrails. An execution IDP like Atmosly goes further and includes the running of it too: cluster and cloud-resource provisioning, CI/CD and environment cloning, an AI SRE for operations, continuous security posture, and cost intelligence — all under one control plane, so the platform operates the stack rather than just cataloging it.
How long does it take to set up an IDP with Atmosly?
Minutes to first value, not months. You connect an existing cluster read-only and immediately see Atmosly work on your own workloads — versus the roughly 12 months and 4–6 engineers a DIY platform typically takes to reach golden paths. You then adopt capabilities at your own pace, workload by workload, with nothing to rip out.
From the blog
View all posts →
The latest on platform engineering
Cost Intelligence
PlatformPortal IDP vs Execution IDP: The Difference That Actually Matters
Portal IDPs show developers a button; execution IDPs run the action. Learn the difference, four tests to classify any IDP, and which one your team needs.
Cost IntelligenceKubernetes Cost Allocation: Showback vs Chargeback (2026 Guide)
Kubernetes cost allocation turns a shared cluster bill into per-team numbers. Learn showback vs chargeback, idle/shared-cost splitting, and the maturity path.
Stop building the platform. Start shipping on one.
Connect a cluster read-only and see the execution IDP work on your own workloads — provision, ship, and run, in minutes. Free, no sales call.