THE CATEGORY
What teams actually want from an IDP
An internal developer platform is the self-service layer between developers and infrastructure. The disappointment is that most stop at the catalog: they show the work without doing it.
01
Developer self-service
Engineers provision an environment or ship a service on their own, without filing a ticket and waiting on the platform team.
02
Golden paths, not blank pages
A paved, repeatable way from code to production, so every team ships the same governed way instead of inventing its own.
03
Guardrails the org can trust
Standards and policy encoded once and enforced automatically: autonomy for developers, control for the platform team.
THE REAL DISTINCTION
A portal shows you things. An execution IDP does them.
Portal-first platforms catalog a stack you still 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
- Shows what is deployed, but doesn't provision or ship it
VS
EXECUTION IDP · ATMOSLY
Does the work itself
- Provisions clusters and cloud resources and ships code directly
- Reads a running workload and turns it into CD, nothing to rebuild
- Software you set up yourself, no platform team to staff it
- Guardrails enforced on every action, so 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
Not a portal pointing at these capabilities. The capabilities themselves, working out of the box.
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 and add-ons from blueprints
- A curated Helm marketplace, signed, deployed and tracked
- Guardrails on every provisioning action
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, never a blank page.
- Workload → blueprint → CD, no pipelines to rebuild
- On-demand preview environments cloned from production
- Visual and GitOps pipelines with one-click rollback
Autonomy for developers, control for the platform team
Standards are encoded once and enforced on every action: spend caps, region and instance allow-lists, approval flows, scoped RBAC and SSO. Every provision, deploy and rollback lands in one audit trail.
- Auto-approve under threshold, escalate above
- Fine-grained RBAC per team, environment and action, with SSO
- One audit trail and one-click revert
INSIDE THE PLATFORM
Every layer is a real capability
Each part of the Atmosly IDP is a product that does the work. Explore the capabilities behind provision, ship and govern.
PROVISION
Cluster provisioning
Import any cluster, public, private or air-gapped, read-only in minutes.
ExplorePROVISION
Cloud resources
Databases, node groups and add-ons developers request from blueprints.
ExplorePROVISION
Helm marketplace
Curated, signed charts with your defaults pre-applied, deployed and tracked.
ExploreSHIP
Pipeline builder
Visual and GitOps CI/CD from code to production, with one-click rollback.
ExploreSHIP
Workload blueprints
Turn any running service into a deployable blueprint and CD pipeline.
ExploreSHIP
Environment cloning
Isolated preview environments cloned from production, on demand.
ExploreGOVERN
Guardrails
Scheduled ops, spend caps and allow-lists, scoped and audited.
ExploreGOVERN
Service catalog
Every service with owner, pipeline and environments, read from what is running.
ExploreBUILD 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 for golden paths, then maintaining it forever.
BUILD IT IN-HOUSE
4–6 eng
to build and staff a DIY platform
~12 mo
before developers see golden paths
RUN IT ON ATMOSLY
Day one
self-service on the cluster you already run
No rebuild
ingests existing workloads, GitOps and Helm
THE IDP FOR YOUR STAGE
One platform, mapped to where you are
THE SQUAREOPS SUITE
Atmosly runs the platform. Security, cost and incidents have their own products.
Customer stories
Atmosly in production
Real engagements delivered by SquareOps.
Nimbbl
FinTechHow SquareOps Helped Nimbbl's 40 Engineers Self-Manage Kubernetes Environments on AWS EKS
How SquareOps helped Nimbbl's 40-person engineering team self-manage non-prod Kubernetes environments on AWS EKS, with standard pipelines.
32nd Avenue
GeneralHow SquareOps Modernized and Scaled 32nd Avenue's Applications on AWS EKS With Karpenter
How SquareOps moved 32nd Avenue's valet parking, restaurant and ERP workloads to AWS EKS with Karpenter autoscaling and CI/CD for faster, safer releas…
QUESTIONS
Internal developer platforms, answered
Not covered? An engineer replies within one business day.
consult@squareops.comAn internal developer platform is the self-service layer between developers and infrastructure. It gives engineers golden paths to provision environments and ship code on their own, while the platform team encodes standards and guardrails centrally. The goal is developer autonomy without every request becoming a ticket.
A portal IDP, such as Backstage, Port or Cortex, is a catalog and dashboard that sits on top of other tools and visualizes them. An execution IDP like Atmosly does the work itself: it provisions infrastructure and ships code directly, so the platform is the thing operating, not a front door to a stack you still assemble.
Yes, for teams that want the platform to run things rather than catalog them. Atmosly ships with the execution layer already working: provisioning, guardrails, CI/CD and environment cloning. It can also coexist, powering the workflows while a portal stays the front door.
Building in-house typically means a dedicated platform team and roughly a year before developers see golden paths, then a permanent cost center. Buying gives you the same self-service and governance in days, on the clusters you already run.
No. Atmosly delivers the provisioning and delivery a platform team would build, as software you set up yourself. Larger teams use it to scale a small platform team across many clusters instead of growing headcount.
It doesn't require ripping anything out. Atmosly runs on standard Kubernetes, GitOps and Helm, and reads a running workload to turn it into a deployable blueprint. You adopt it workload by workload.
A PaaS like Heroku or Cloud Run abstracts the infrastructure away entirely. An internal developer platform keeps you on your own Kubernetes and cloud, adding self-service and golden paths on top, so you keep portability and governance.
At minimum: self-service provisioning, a paved code-to-production path, and centralized guardrails. Atmosly adds cluster and cloud-resource provisioning, CI/CD, environment cloning, RBAC and one audit trail under one control plane.
Into their own SquareOps products. Incident response and AI SRE is Alert6, Kubernetes and cloud security is Verity, and cost optimization is SpendZero. Connect a cluster once and it is available to all of them.