Clone Stacks Between Clusters & Organisations

Learn how to clone one or multiple stacks from one cluster to another - including across organisations - for consistent deployments across environments

Cloning stacks allows you to replicate your infrastructure configurations across multiple clusters - even across different organisations. You can clone a single stack or select multiple stacks at once. With Deploy on the target after cloning left on, a cloned stack deploys on the target straight away; turn it off to keep the clone as a draft for review first. A stack whose encrypted values had to be removed is always held as a draft, marked Needs input, until you re-enter them.

Cloning a Stack Between Clusters

AI Prompts

Use these prompts with the AI Assistant (Cmd+J) to clone stacks with natural language.

---

Overview

Stack cloning is useful when you want to:

Use Case	Example
Promote configurations	Clone a tested stack from staging to production
Standardize environments	Replicate your monitoring stack across all clusters
Create templates	Use a well-configured stack as a starting point for new clusters
Keep a standby ready	Run the same configuration on a second cluster, ready to take over
Cross-org sharing	Clone a stack from a development org to a client or production org
Replicate entire clusters	Select all stacks and clone them to a new cluster in one operation

By default a clone copies configuration only, and it reads the live source. A clone reproduces the stack’s definition on the target; persistent volumes and database contents stay where they are unless you add them with the Data step in the dialog or --with-data on the CLI. Cloning with data needs a backup vault. It also needs the source cluster to be readable, so it is not a disaster-recovery mechanism - for that, protect the stack and restore a restore point.

Security Note: Encrypted values (secrets) are not transferred during cloning for security reasons. You’ll need to reconfigure them in the target cluster. This includes passwords, API keys, and any values encrypted with SOPS. A stripped Secret is still a valid Kubernetes object - each cleared key holds the ENCRYPTED_VALUE_REMOVED placeholder (base64-encoded under data) so the draft deploys and the workload fails clearly on the placeholder rather than the apply failing on the manifest.

---

Prerequisites

• At least two clusters imported into Ankra (can be in different organisations)
• A deployed stack in the source cluster that you want to clone
• Access to both the source and target clusters
• For cross-org cloning: membership in both the source and target organisations

---

Clone Using the Dashboard

1. Navigate to Source Stack

   Go to your source cluster and navigate to Stacks. Find the stack you want to clone.

2. Open Clone Dialog

   Click the menu icon (three dots) on the stack card and select Clone to Cluster.

3. Target

   On the Target step:

   1. If you belong to multiple organisations, select the target organisation. The cluster list updates to show clusters in that organisation.
   2. Choose the destination cluster.
   3. Optionally change the Stack name.

   If your stack contains encrypted values, a warning says they do not travel. For a cross-organisation clone, a banner says you are taken to the target organisation once the copy is made.

4. Data (optional)

   A Data step lets you carry the stack’s volumes and database contents as well, through a backup vault.

5. Review

   Check the summary. Include addon configurations copies the Helm values and settings of every add-on. Deploy on the target after cloning is on by default; turn it off to keep the clone as a draft.

6. Clone the Stack

   Click Clone stack. A deployed clone takes you to the running stack on the target; a clone that needs input opens its draft in the builder, with a banner naming the values to re-enter. If you cloned to a different organisation, Ankra automatically switches your active organisation.

7. Finish on the target

   If the clone was held as a draft (you turned deploy off, or encrypted values had to be removed), add any missing secrets, adjust cluster-specific settings, and deploy it from the builder.

---

Clone Multiple Stacks at Once

You can select multiple stacks and clone them all to another cluster in a single operation. Each stack is created as a separate draft on the target cluster.

1. Select Stacks

   On the Stacks page, click any stack card’s avatar (the colored circle) to start selecting. Click additional avatars to add more stacks to your selection.

   Alternatively, click the Clone Stacks button to the left of the search bar - this selects all stacks on the page.

2. Open the Clone Dialog

   With stacks selected, a floating action bar appears at the bottom of the screen showing the count. Click Clone to Cluster in the bar, or click the Clone N Stacks button next to the search bar.

3. Choose a Target

   In the dialog:

   1. Select the target organisation (if you belong to multiple)
   2. Choose the destination cluster
   3. Toggle whether to include addon configurations

   The dialog shows a list of all selected stacks as tags.

4. Clone

   Click Clone N Stacks. Each stack is cloned sequentially - you’ll see a progress bar and each stack tag turns green on success. Name conflicts are auto-resolved with suffixes (e.g. -copy).

5. Navigate to Target

   The summary says how many stacks are deploying and how many were held for your input, with a link into each held draft’s builder tab. Click Go to Target Cluster to watch them come up.

Multi-stack cloning is useful for replicating an entire cluster’s configuration. Select all stacks and clone to a new cluster; the ones without secrets deploy on their own, and the Needs input chip on the stack list shows which are waiting for you.

---

Clone Using the CLI

The Ankra CLI provides a clone command for scripting and automation.

Basic Usage

# Select the source cluster first
ankra cluster select my-source-cluster

# Clone a stack to another cluster
ankra cluster stacks clone monitoring-stack --to production-cluster

Command Options

Flag	Short	Description
--to	-t	Target cluster name or ID (required)
--name	-n	Custom name for the cloned stack
--include-config		Include addon configurations (default: true)
--deploy		Deploy the clone on the target (default: false, so the CLI creates a draft)
--with-data		Carry the stack’s data through a restore point (needs a backup vault)

This table covers the common flags. --deploy, --with-data and the data flags need CLI v0.18.0 or later; see the CLI reference for --from, --vault, --wait and the rest.

The CLI and the dashboard have opposite defaults: the dashboard deploys the clone unless you turn Deploy on the target after cloning off, while ankra cluster stacks clone creates a draft unless you pass --deploy.

Examples

Clone with a custom name:

ankra cluster stacks clone my-stack --to production --name my-stack-prod

Clone without addon configurations:

ankra cluster stacks clone my-stack --to production --include-config=false

Clone using cluster IDs:

ankra cluster stacks clone monitoring-stack --to 550e8400-e29b-41d4-a716-446655440000

CLI Output

Cloning stack 'monitoring-stack' to cluster 'production'...

Stack cloned successfully!
  Draft ID:    a1b2c3d4-e5f6-7890-abcd-ef1234567890
  Stack Name:  monitoring-stack
  Addons:      3
  Manifests:   2
  Applications: 1

Warnings:
  - Addon 'grafana' had encrypted configuration that needs to be reconfigured.
  - Cluster variable 'db_host' was copied from the source cluster onto the cloned stack; review its value for the target cluster.
  - Manifest 'prometheus' pins scheduling to nodes labelled purpose=monitoring - make sure the target cluster has matching nodes.
  - Deploy check for addon 'grafana': registry 'bitnami' is not connected in this organisation.

The stack has been created as a draft. Open the Ankra dashboard to review and deploy.

---

What Gets Cloned

Component	Cloned	Notes
Stack name & description	Yes	Can be renamed during clone
Stack variables	Yes	Transferred as-is; cluster variables the content references are copied onto the stack (same organisation)
Manifests	Yes	YAML content (encrypted values cleared)
Addons	Yes	Chart references, versions, settings, job timeouts and AGENTS.md notes
Applications	Yes	Same organisation only - applications are organisation-scoped, so a cross-organisation clone drops them with a warning
Addon configurations	Optional	Include addon configurations in the dialog, or --include-config
Encrypted secrets	No	Must be reconfigured
Deployment state	By default	Deploy on the target after cloning (dashboard) or --deploy (CLI) deploys the clone; a stack whose secrets were removed is held as a draft
Resource positions	Yes	Canvas layout and deploy wave carry over
Dependencies	Yes	Parent relationships preserved by name and kind

Pre-checks in the warnings

The clone runs the checks a deploy would, and reports what it finds as warnings rather than refusing - a clone never fails on them:

• Variables: a ${{ ankra.* }} token the target cannot resolve is named, and a same-organisation clone copies the source cluster’s value onto the stack so the manifest does not deploy the literal token.
• Node pinning: manifests and applications whose nodeSelector targets labels the target may not have.
• SOPS readiness: encrypted paths that survived the strip, on a target with no deployed SOPS key.
• Chart references: registries not connected in the target organisation, and charts or versions the catalog does not know.

---

Cloning Between Organisations

Ankra supports cloning stacks to clusters that belong to a different organisation. This is useful for sharing configurations with clients, replicating setups from a template org to a production org, or migrating workloads.

How it works

1. You must be a member of both the source and target organisations.
2. In the clone dialog, an Organisation dropdown appears when you belong to more than one org. Select the target organisation to see its clusters.
3. Cross-organisation cloning is available from the dashboard only.
4. After a cross-org clone, the dashboard switches your active organisation to the target automatically.

What to keep in mind

Credentials and secrets don’t transfer across organisations. Each organisation has its own SOPS keys, registry credentials, and secrets. After a cross-org clone you must reconfigure:

• Encrypted values in manifests and addon configs
• Registry credentials if images are in private registries
• Any organisation-specific variables referenced by the stack

Organisation and cluster variables are scoped to their organisation, and no variable value crosses that boundary. A cross-organisation clone names every ${{ ankra.* }} reference it could not resolve in its warnings - define those variables in the target organisation or on the target cluster before deploying.

---

Handling Encrypted Values

When you clone a stack that contains encrypted values:

1. Manifests: Encrypted fields are replaced with the ENCRYPTED_VALUE_REMOVED placeholder
2. Addon configurations: Encrypted values are replaced with the same placeholder
3. Held as a draft: the stack is not deployed; the clone result, the Needs input chip on the stack card and a banner in the builder name each member and field to re-enter, and the banner links straight to it

Re-encrypting Secrets After Clone

After cloning, you’ll need to re-encrypt secrets for the target cluster:

1. Open the cloned draft in the target cluster
2. Navigate to each manifest or addon that had encrypted values
3. Enter the new secret values
4. List the keys under Encrypted Keys (SOPS) so they are sealed with the target organisation’s key
5. Save and deploy

The SOPS key pair belongs to the organisation, not to a cluster. Clusters in the same organisation share it, so a value sealed for one can be decrypted by another. A clone into a different organisation cannot decrypt the source’s values - this is by design for security.

Automating Secret Configuration

For automated deployments, consider:

• Using external secrets management (e.g., Vault, AWS Secrets Manager)
• Storing secrets in environment-specific configuration
• Using Kubernetes ExternalSecrets operator

---

Common Workflows

Staging to Production Promotion

# Test in staging first
ankra cluster select staging
ankra cluster stacks list

# Clone to production when ready
ankra cluster stacks clone my-app-stack --to production

# Switch to production and configure secrets
ankra cluster select production
# ... configure in dashboard

Standardizing Multiple Clusters

Clone your standard monitoring stack to all clusters:

ankra cluster select template-cluster

for cluster in dev staging production; do
  ankra cluster stacks clone observability --to $cluster --name observability
  echo "Cloned to $cluster"
done

Creating a Backup Configuration

# Clone critical stacks to a DR cluster
ankra cluster select primary
ankra cluster stacks clone core-services --to dr-cluster
ankra cluster stacks clone monitoring --to dr-cluster
ankra cluster stacks clone ingress --to dr-cluster

Replicate All Stacks to a New Cluster

In the dashboard:

1. Go to Stacks in your source cluster
2. Click the Clone Stacks button next to the search bar - all stacks are selected
3. Click Clone to Cluster in the floating action bar
4. Choose your target cluster and click Clone
5. All stacks are created as drafts on the target - review and deploy each one

With the CLI:

ankra cluster select source-cluster
ankra cluster stacks list   # note the stack names

# Clone each stack to the new cluster
for stack in monitoring ingress app-data; do
  ankra cluster stacks clone "$stack" --to new-cluster
done

Sharing a Stack with Another Organisation

Clone a well-tested stack to a client or partner organisation from the dashboard: select the target organisation in the clone dialog’s Target step. After cloning, Ankra switches you to the target organisation automatically, where the stack’s secrets can be added.

---

Troubleshooting

Clone Failed: Stack Not Found

Ensure the source stack is deployed (not just a draft) and you have the correct stack name:

ankra cluster stacks list

Clone Failed: Access Denied

Verify you have access to both the source and target clusters. You must be a member of both clusters’ organizations.

Clone Failed: Target Cluster Unavailable

The clone operation only creates a draft in the database - it doesn’t require the target cluster to be online. Check your network connection to the Ankra API.

Missing Resources After Clone

If addons or manifests are missing:

1. Check if the source stack had resources in a deleting or deleted state
2. Verify the clone included addon configurations (--include-config=true)
3. Check the warnings for any resources that couldn’t be cloned

---

AI Prompts

Press Cmd+J to open the AI Assistant and use these prompts:

Clone Stack

Clone the monitoring stack to my production cluster

Duplicate and Modify

Clone the ingress stack from staging to production and rename it to prod-ingress

Replicate to Multiple Clusters

Help me clone my observability stack to all my clusters

---

Next Steps

SOPS Encryption

Learn how to encrypt secrets in your stacks.

GitOps Sync

Sync your stack configurations to a Git repository.

Ankra CLI

Learn more CLI commands for stack management.