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.
Core 02 · CI/CD & Environments
Clone a full Kubernetes environment — services, data, and config.
Pick a source environment and Atmosly duplicates the entire thing — its cluster, namespace, every application service with its build and deploy config, env vars and secrets, and every database — into a brand-new copy. Names, namespaces and passwords are regenerated so nothing collides.
- ✓ Apps + databases
- ✓ Secrets re-fetched
- ✓ Collision-free
Source environment
checkout-prod
ns: checkout-prod · prod-eu-west
Application services7
DatabasesPostgres · Redis
Env vars42
Secretsfrom Secret Mgr
Clone
New environment
checkout-prod-copy
ns: checkout-prod-copy · prod-eu-west
Services copied7 · same cfg
Databases recreatednew passwords
Env vars copied42
Parent linkedcheckout-prod
What gets cloned
The whole environment — not just the manifests
A clone carries everything that makes the source environment real: the workloads, the data layer, the config, and the wiring between them. It lands on a cluster you choose, in its own namespace.
Every application service
Each service comes with its source type — a container image or a Git-based CD config — plus its env vars, CD values (form or YAML), container registry, and the workflow it's wired to. The clone is deployable, not a shell.
image & Git-CD servicescopied
env vars · CD values · registry✓
Every datastore
Managed and self-managed databases come along — PostgreSQL, MySQL, MongoDB, Redis, Aurora, or a third-party source — with their full config: replicas, resource limits, and backup settings. Credentials are regenerated for the copy.
db config · replicas · backupscopied
passwordsregenerated
Secrets, re-fetched
Secret-backed values are pulled fresh from AWS or GCP Secret Manager at clone time — masked if you lack view-secret permission.
Cluster, namespace & labels
Choose the target cluster; the clone gets its own namespace and carries the source's labels so it's organized from the start.
Parent lineage
Each clone records the environment it came from, so you always know what a copy was based on.
Conflict-free environment clones — unique names, namespaces & secrets
Everything that has to be unique is regenerated for the copy — environment name and namespace, database passwords, record prefixes, and container-registry bindings — so a clone never clashes with its source or another clone.
How cloning works
From source to running copy
Cloning is a guided flow, not a YAML copy-paste. You review what's carried over, rename the few things that must be unique, and choose how much of the pipeline to run.
1
Pick source
Choose the environment to clone
Atmosly reads its full definition — every service, datastore, env var, and the secret references behind them — and assembles a clone payload you can review before anything is created.
source · checkout-prodloaded
services · 7 · datastores · 2✓
2
Review & rename
Set the fields that must be unique
Name the new environment and namespace; database passwords, record prefixes, and registry bindings are regenerated automatically. Target cluster is yours to pick.
name · checkout-prod-copyset
passwords · prefixesregenerated
3
Choose scope
Full pipeline, or deploy only
Clone with CI+CD to rebuild from source, or CD-only to redeploy the existing artifacts straight into the new environment when you just need a running copy fast.
mode · CD-onlyselected
artifacts · reused✓
4
Deploy
The copy comes up isolated
Services and datastores deploy into the new namespace on your chosen cluster. When you're done with it, pair a Guardrail to scale it down or destroy it on a schedule.
ns · checkout-prod-copycreated
services · running✓
teardown · via Guardrailscheduled
What teams clone for
One environment, copied for whatever you need next
Stand up a new tier
Clone prod into a staging or QA environment that matches it exactly — same services, same data layer, new credentials.
A copy per team or tenant
Give a team — or a customer tenant — its own isolated copy of a known-good environment without rebuilding it by hand.
Reproduce to debug
Spin up an exact replica to chase down a bug or test a risky change against a realistic copy — then throw it away.
Throwaway preview
Clone an environment to review a change in isolation, then let a scheduled Guardrail tear it down so nothing lingers.
The payoff
A real copy in minutes — not a day of YAML
One guided flow copies a whole environment, regenerates everything that must be unique, and lands a running clone on the cluster you choose.
Whole environment
Services, datastores, config & secrets — copied in a single pass.
Collision-free
Names, namespaces, passwords & registry bindings regenerated.
CI+CD or CD
Rebuild from source, or redeploy the existing artifacts.
Any cluster
Land the clone on whichever cluster you choose.
Same control plane
Environment Cloning is one of three cores
Build, run, and provision share one UI, one audit trail, and one permissions model.
Questions
What teams ask about cloning
What exactly gets copied?
The full environment definition: cluster placement, namespace, labels, every application service (its source type, env vars, CD values, registry, and workflow), and every datastore with its config — replicas, resource limits, and backup settings. The clone is a deployable copy, not just a set of manifests.
How are secrets and passwords handled?
Secret-backed env vars are re-fetched from your AWS or GCP Secret Manager at clone time rather than copied around — and masked if you don't have view-secret permission. Database passwords and other unique credentials are regenerated for the new copy, so the clone never shares secrets with its source.
Will a clone collide with the environment it came from?
No. Everything that must be unique — environment name, namespace, database passwords, record prefixes, and container-registry bindings — is regenerated for the copy. You review and name the new environment before it's created, and the clone records its parent for lineage.
Can I clone without rebuilding from source?
Yes. Clone CD-only to redeploy the existing artifacts straight into the new environment when you just need a running copy fast, or clone with the full CI+CD pipeline to rebuild from source. And since a clone is a normal environment, you can pair it with a Guardrail to scale it down or destroy it on a schedule.
From the blog
View all posts →
The latest on environments
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.
Copy a real environment in minutes.
Connect a cluster, read-only to start. Pick an environment, clone it — services, datastores, config and all — into an isolated copy, and watch it come up. Free, no sales call.