Clone Stacks Between Clusters & Organisations

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

Navigate to Source Stack

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

Open Clone Dialog

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

Target

On the Target step:

If you belong to multiple organisations, select the target organisation. The cluster list updates to show clusters in that organisation.
Choose the destination cluster.
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.

Data (optional)

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

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.

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.

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.

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.

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.

Choose a Target

In the dialog:

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

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

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).

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

You must be a member of both the source and target organisations.
In the clone dialog, an Organisation dropdown appears when you belong to more than one org. Select the target organisation to see its clusters.
Cross-organisation cloning is available from the dashboard only.
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:

Manifests: Encrypted fields are replaced with the ENCRYPTED_VALUE_REMOVED placeholder
Addon configurations: Encrypted values are replaced with the same placeholder
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:

Open the cloned draft in the target cluster
Navigate to each manifest or addon that had encrypted values
Enter the new secret values
List the keys under Encrypted Keys (SOPS) so they are sealed with the target organisation’s key
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:

Go to Stacks in your source cluster
Click the Clone Stacks button next to the search bar - all stacks are selected
Click Clone to Cluster in the floating action bar
Choose your target cluster and click Clone
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

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:

Check if the source stack had resources in a deleting or deleted state
Verify the clone included addon configurations (--include-config=true)
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.

Get Started

Use Cases

Concepts

Create and Run Clusters

Ship Your App

Ankra Pipelines

Stacks and Add-ons

Observe and Troubleshoot

Ankra AI

Connect Tools

Source Control

Security and Access

Cost and Backups

Organisation and Account

Reference

Clone Stacks Between Clusters & Organisations

AI Prompts

Overview

Prerequisites

Clone Using the Dashboard

Clone Multiple Stacks at Once

Clone Using the CLI

Basic Usage

Command Options

Examples

CLI Output

What Gets Cloned

Pre-checks in the warnings

Cloning Between Organisations

How it works

What to keep in mind

Handling Encrypted Values

Common Workflows

Troubleshooting

AI Prompts

Next Steps

SOPS Encryption

GitOps Sync

Ankra CLI

AI Prompts

​Overview

​Prerequisites

​Clone Using the Dashboard

​Clone Multiple Stacks at Once

​Clone Using the CLI

​Basic Usage

​Command Options

​Examples

​CLI Output

​What Gets Cloned

​Pre-checks in the warnings

​Cloning Between Organisations

​How it works

​What to keep in mind

​Handling Encrypted Values

​Common Workflows

​Troubleshooting

​AI Prompts

​Next Steps

SOPS Encryption

GitOps Sync

Ankra CLI

Overview

Prerequisites

Clone Using the Dashboard

Clone Multiple Stacks at Once

Clone Using the CLI

Basic Usage

Command Options

Examples

CLI Output

What Gets Cloned

Pre-checks in the warnings

Cloning Between Organisations

How it works

What to keep in mind

Handling Encrypted Values

Common Workflows

Troubleshooting

AI Prompts

Next Steps