Stack Profiles

A Stack Profile is a reusable template captured from a real stack. Build a stack once, save it as a profile, and instantiate it on any cluster - with parameters filled in per environment. Profiles are versioned, so you can publish updates, diff versions, and see which deployments have drifted behind the latest.

A profile is a template, not a running deployment. Instantiating a profile produces a stack draft on a target cluster, which you then review and commit like any other stack change.

Watch a working OpenSearch stack reviewed, parameterised and published as a profile.

Why use profiles

Standardise a golden stack (monitoring, ingress, security baseline) and reuse it across clusters.
Parameterise the bits that differ per environment - domains, replica counts, sizes - instead of copy-pasting YAML.
Version changes with a changelog and channels, and diff any two versions.
Track drift: a profile shows how many instantiations are behind its latest version.

Anatomy of a profile

Concept	Description
Version	An immutable snapshot of the stack spec. Versions increment as you publish updates and carry a `channel` (e.g. `stable`) and an optional changelog.
Parameters	Typed inputs callers fill in at instantiation. Each parameter has a `type` (`string`, `number`, `boolean`, `enum`, or `secret`), and may be `required`, have a `default`, an `enum` list, or a validation `pattern`.
Choices	A parameter can offer `options`, and each option can `set` other parameters. One Model size choice of `8b` or `32b` then moves the model id, the context length and the volume size together, so the operator picks one thing instead of keeping four consistent. See Choices that set other inputs.
Protection	The stack’s backup block, carried as one parameter group. A profile captured from a protected stack keeps `enabled`, the schedule, the retention tiers and the selection; the vault travels by name and is resolved against the organisation the profile is launched into. See Protection.
Visibility	`organisation` (default) keeps the profile private to your org; `public` shares it more widely. Independently of visibility, a profile can be shared with specific organisations.
Category & tags	Metadata for organising and searching profiles.
Publisher	The organisation that owns the profile. Publisher names, logos, and verified badges help you identify trusted profiles. Verified Ankra profiles appear first in profile results.
Drafts	An editable working copy used to build or edit a profile before publishing a version.
Suggestions	Proposed versions submitted by other organisations that can see the profile. The owner reviews the diff and approves (publishing it as the next version) or rejects. See Suggestions.

Secret-typed parameters and other sensitive values are redacted when a profile is captured, so credentials are never baked into a shared template.

Create a profile

You can create a profile two ways:

From an existing stack

Capture a profile directly from a stack already running on a cluster. Optionally include addon configurations. This is the fastest path - build and validate the stack first, then snapshot it.

Import

Import a profile from exported IaC content, for sharing across organisations or storing in Git.

In the portal, Save as Profile starts with the stack’s existing name and description. Categories combine common options with values your organisation already uses, and tags are suggested as you type. Choose who can use the profile before saving:

This organisation keeps it private to members of your organisation.
Public makes it available to every organisation.
Specific organisations keeps it private and grants access to the organisation slugs you enter.

Public and specific-organisation sharing require an organisation admin. Quick save publishes immediately. Save and customise opens the profile builder so you can review inputs before publishing.

# Capture from a cluster's stack
POST /org/stack-profiles
{
  "name": "platform-baseline",
  "description": "Shared platform services",
  "category": "platform",
  "tags": ["baseline", "production"],
  "visibility": "organisation",
  "share_organisation_slugs": ["partner-org"],
  "source_cluster_id": "...",
  "stack_name": "platform",
  "include_addon_configurations": true
}

Organisation admins can upload a publisher logo under Organisation Settings. Profile cards fall back to the organisation’s initials when no logo is configured.

Build with drafts

For more control, work in a draft: create a draft (optionally seeded from a cluster’s stack), edit its spec and parameters, validate it, then publish it as a new version.

Create a draft

POST /org/stack-profiles/drafts - optionally seeded from an existing profile or a source cluster stack.

Edit and validate

Update the draft’s spec and parameters, then POST /org/stack-profiles/drafts/{draft_id}/validate to surface any issues before publishing.

Publish a version

POST /org/stack-profiles/drafts/{draft_id}/publish with a channel and changelog. This creates the profile (or a new version of it).

To update an existing profile, always author through a draft (Edit Builder in the portal, or ankra stack-profiles drafts from the CLI) rather than exporting the IaC, editing it, and re-importing. A draft seeded from the profile keeps the version’s input annotations - titles, descriptions, enum choices, and choices that set other inputs - and publishes a new version of the same profile. Importing an edited export re-detects the inputs from the spec, drops those annotations, and creates a separate new profile.

Instantiate a profile

Instantiating turns a profile into a stack on a target cluster:

Choose a profile and version

Pick the profile and, optionally, a specific version. When no version is given, the profile’s current version is used - the pinned version, which can be older than latest after a rollback.

Bind parameters

Supply values for the profile’s parameters. Required parameters must be set; others fall back to their defaults.In the portal, Use Profile opens a page of its own rather than a dialog: the destination and the inputs on the left, and a summary beside them that stays in view while you scroll, ticking off the target cluster, the stack name and the required inputs until Create draft is ready. The form opens on the inputs the profile left blank and folds the ones that already carry a default behind a disclosure, with a counter for the required inputs still empty. Each field names the addon or manifest it writes into, so a key declared on two components stays unambiguous. Secret inputs can be generated, revealed, and copied, and any input changed away from its default can be reset. An input whose name ends in host, hostname, fqdn, or domain offers Use cluster domain, filling in that hostname under the target cluster’s delegated zone.

Review the draft

Instantiation creates a stack draft on the cluster (with the resolved addons and manifests). Review it.

Commit

Commit the draft to deploy, exactly like any other stack change.

Choices that set other inputs

Some inputs only make sense together. A chat profile that can run a small model on one GPU or a large one on a bigger card has four inputs that must agree - the model id, the context length, the GPU memory ceiling and the size of the model store - and an operator asked for each one separately has to know all four answers. A profile author can instead give one input options, and have each option set the others:

- name: model_size
  title: Model size
  type: enum
  default: 8b
  options:
    - value: 8b
      title: Qwen3 8B on one L4 (24 GB)
      sets:
        model_id: Qwen/Qwen3-8B
        max_model_len: "16384"
        gpu_memory_utilization: "0.90"
        model_store_size: 60Gi
    - value: 32b
      title: Qwen3 32B on one L40S (48 GB)
      sets:
        model_id: Qwen/Qwen3-32B
        max_model_len: "28672"
        gpu_memory_utilization: "0.95"
        model_store_size: 120Gi

When the profile is used, the values resolve in one fixed order, on every surface:

a value you set  >  what the selected option sets  >  the parameter's own default

In the portal, the choice renders as a card of options above the rest of the form, each naming how many inputs it answers. The inputs an option answers show the value it assigned, labelled with the choice that made it; type over one and it is marked customised, and Reset hands it back to the option. A required input an option answers counts as answered.
From the CLI, ankra stack-profiles get prints a Choices for model_size block listing what every option sets, and ankra stack-profiles apply <profile> --cluster <name> --set model_size=32b deploys the whole set with no other bindings. A --set of your own on one of those inputs still wins over the option.
The platform resolves the choice server-side, so the AI assistant, the MCP tools and Terraform get the same stack from the same selection, and the deployment’s recorded parameters are the values that actually deployed.

A profile may declare any number of such inputs, each driving a different slice of the form (model size, storage tier, ingress mode); when two set the same input, the one declared later wins. An option can never set a secret input - a profile never stores secret values - and cannot set another input that itself offers options, so every resolution is a single readable pass. Options are authored on the builder’s Inputs tab; a choice-only input that no manifest references can be added there directly, and mistakes that would be refused at publish (a value the target input would reject, a default that names no option, an unknown target) are shown inline while you edit.

From the CLI

The Ankra CLI can instantiate a profile directly. Inspect a profile’s parameters first, then apply it to a cluster as a draft (or pass --deploy to deploy in one step):

# See the profile's versions and parameters
ankra stack-profiles get <profile-id>

# Create a draft on a cluster, binding parameters
ankra stack-profiles apply <profile-id> --cluster production \
  --set replicas=3 \
  --set-env api_token=MONITORING_API_TOKEN

# Or apply a specific version and deploy immediately
ankra stack-profiles apply <profile-id> --cluster production --version 3 --deploy

For secret parameters use --set-file <name=path> or --set-env <name=ENV_VAR> rather than --set so the value never appears in your shell history or process list.

Protection: backups travel with the profile

A stack you protect with a backup policy keeps that policy when you save it as a profile, and every instance launched from the profile is protected too - so a fleet does not come up unprotected and need protecting again one cluster at a time. What the profile carries is the declaration, never the rendered schedules. The Velero, CloudNativePG and Percona objects a backup policy materialises are bound to one cluster’s vault, storage classes and object prefix; they are recomputed per cluster from the block and are deliberately left out of a capture. The builder renders it as a single Protection section with three inputs:

Input	What it decides
`ankra_protection_enabled`	Whether this launch takes scheduled restore points.
`ankra_protection_vault`	The name of the backup vault in the organisation being launched into.
`ankra_protection_schedule`	`hourly`, `daily`, `weekly`, or a five-field cron expression.

Retention tiers and the database / volume selection are not launch inputs: they describe what a restore point of this stack contains, which is the profile author’s decision, so they ride the block and the launcher does not retype them.

The vault is resolved at launch

Vault ids differ per organisation, so protection travels by vault name and is resolved against the target organisation when the profile is instantiated:

the profile names a vault the target organisation has, ready → that vault;
the profile names none and the organisation has exactly one ready vault → that one;
anything else - no ready vault, no vault by that name, several to choose from - the stack is created without a backup policy, the result carries a warning saying so, and a deploy is stopped with the draft kept rather than bringing a stateful stack up unprotected. Create and verify a vault, or bind ankra_protection_vault to the one this cluster should write to, then deploy the draft.

Bind ankra_protection_vault per cluster to send each instance’s restore points to a different vault.

A public profile carries no vault name - naming one would disclose an organisation-internal resource and describe protection the installer cannot have. enabled: true with no vault is the publishable shape: the organisation launching it supplies its own vault. Making a profile public is refused while any of its versions still names one.

Demo a profile before you deploy it

Instantiating a profile puts it on a real cluster. When you only want to see what it deploys - to review a new version, to check a public profile before adopting it, or to show someone the stack running - launch it as a demo instead. A demo installs the profile into its own throwaway namespace on your organisation’s staging cluster, quota-bounded and on a timer, and deletes itself when the timer runs out. Open the profile’s Demos tab to launch one. See Stack Profile Demos.

Making a profile public exposes it to everyone. When you want to share a golden stack with one partner, customer, or sibling organisation - and nobody else - share it directly instead:

Shared organisations can list, view, diff, export, and instantiate every version of the profile. They cannot edit, delete, or re-share it.
The profile keeps its organisation visibility; sharing is an explicit per-organisation grant.
The target organisation is identified by its organisation slug (found under organisation settings). Ask the other organisation for theirs.
Only organisation admins can grant or revoke shares, and a grant re-runs the plaintext-secret scan over every published version - a profile that still carries plaintext secrets cannot be shared. Grants and revokes are recorded in the audit log.
Revoking a share hides the profile from the other organisation again. Stacks they already deployed from it keep running - they just stop seeing profile updates.

In the portal, open a profile you own and use Share. Via the API:

# Grant an organisation access
POST /org/stack-profiles/{profile_id}/shares
{ "organisation_slug": "acme-corp" }

# List grants / revoke one
GET    /org/stack-profiles/{profile_id}/shares
DELETE /org/stack-profiles/{profile_id}/shares/{share_id}

Profiles shared with your organisation show up in your profile list marked “Shared with you”.

Suggestions: propose and review changes

Sharing is read-only, but improvements can still flow back. Any organisation that can see a profile - shared or public - can open it in the builder with Suggest changes, edit a draft of it, and submit the result as a suggestion. The owning organisation reviews the diff on the profile’s Suggestions tab and either approves it - publishing the proposed contents as the profile’s next version - or rejects it with a note. The proposer can withdraw an open suggestion. The profile stays owner-only throughout: a suggestion changes nothing until an owner approves it. Suggestions are frozen at submit and pass the same plaintext-secret and unbound-placeholder gates as publishing, at submit and again at approve, so no secret value ever travels through one. See Stack Profile Suggestions for both sides of the flow, end to end.

Versioning, diffing, and updates

Save a new version from an updated source stack, or by publishing an edited draft.
Diff any two versions to see what changed: GET /org/stack-profiles/{profile_id}/diff?from_version=1&to_version=2.
Diff a draft before publishing it, against the version it was opened from: GET /org/stack-profiles/drafts/{draft_id}/diff. The draft is redacted first, so the comparison shows what publishing would actually store rather than your working copy. A draft that will create a brand-new profile has no base, so everything in it reads as added.
Update tracking: a profile reports outdated_instantiation_count and has_update_available so you can find the deployments that are behind.
Update a deployment in place: updating a tracked deployment replaces the contents of the stack it already runs with the chosen version - the same stack, so Kubernetes performs a rolling update of the workloads and nothing is deployed twice - and records the deployment at the new version, so the counters above follow. The non-secret inputs it was last applied with are carried forward; secret inputs are asked for again. Do not instantiate the profile a second time to update a deployment: that produces a new stack beside the running one, renamed around the name collision.
Export IaC for a version to store the template in Git or move it between organisations.

Deprecate a version

A published version cannot be deleted - deployments record which version they run, and that history has to stay readable - but it can be withdrawn. When a version turns out to be incompatible with what clusters run today, to carry a critical bug, or to ship a CVE, the profile’s owner deprecates it with a reason and, optionally, a note and the advisories it relates to:

ankra stack-profiles deprecate payments 3 --reason cve \
  --note "Fixed in v4." --reference CVE-2026-12345
ankra stack-profiles undeprecate payments 3

The same actions sit on each version in the profile’s History tab. From then on:

Nothing deploys the version. The launch page refuses it, and so do ankra stack-profiles apply --version 3, rollout, a demo launch and an in-place update onto it - every lane answers 409 with the reason and the note (Version 3 of this profile is deprecated (CVE): Fixed in v4. Deploy another version.), so the person who tried learns what to do instead.
It cannot be made the current version, and the current version cannot be deprecated: every launch that names no version resolves to it, so withdrawing it would leave the profile with nothing to deploy by default. Make another version current first.
Deployments still running it are flagged: the Deployments tab marks each row deprecated, ankra stack-profiles deployments counts them, and the profile detail reports update_status.deprecated_instantiation_count, so a fleet sitting on a withdrawn version is visible from the profile rather than discovered cluster by cluster.

The notice travels with the version on the API as deprecation (reason, note, references, deprecated_at, deprecated_by_user_id; null while the version is deployable), written by POST /org/stack-profiles/{profile_id}/versions/{version}/deprecation and cleared by DELETE on the same path. Removing a deprecation restores the version exactly as it was; deployments made before the notice are never touched either way.

See where a profile is deployed

The profile detail page has a Deployments tab listing every stack your organisation has created from the profile: the cluster, the stack (a link to the running stack, or to the still-open draft when it was never committed), its current state, the profile version it runs, the non-secret parameter values it was instantiated with, and when. Rows running a version older than the profile’s current version carry an Update action that opens the update flow pre-filled with the values used last time. A stack that is deleted from its cluster drops off the list, as does a draft that is discarded, so the tab always reflects what is actually running. The same rows are served by GET /org/stack-profiles/{profile_id}/instantiations.

The stack a profile was captured from is not a deployment of it

Saving a profile from a running stack - or publishing a new version from it - snapshots that stack’s contents. It does not register the stack as a deployment of the profile. The Deployments tab is therefore empty right after a capture, the source stack never reports itself as behind when you publish a new version, and it cannot be updated through the profile. Only stacks created by instantiating the profile are tracked, and there is no way to adopt an existing stack into a profile yet.

This matters most for the platform layer - a CNI, ingress or storage stack - where deleting and recreating the stack to get a tracked deployment is not an option. To move such a stack onto a profile version without deleting it, export the version and apply it to the cluster under the stack’s own name:

# Export the version you want the cluster to run
ankra stack-profiles export-iac platform-baseline --version 2 --output platform.yaml

Then edit platform.yaml before applying it:

set metadata.name to the target cluster’s name - the export carries the profile’s name there, and applying it unchanged imports a new cluster under that name;
set the stack’s name to the stack already running on that cluster.

ankra cluster apply -f platform.yaml

That updates the named stack in place, exactly as editing the stack would. Other stacks on the cluster are left alone, but any add-on or manifest of that stack the document does not list is removed - so compare the version against what the stack runs first if it has drifted from the profile. The Deployments tab still will not list the stack afterwards: applying IaC does not create the tracking record, so the profile keeps reporting no deployment.

API

All endpoints are under /org/stack-profiles and require authentication; write operations require a CSRF header for browser-originated requests.

Method	Path	Purpose
`GET`	`/org/stack-profiles`	List profiles (paginated)
`POST`	`/org/stack-profiles`	Create a profile from a cluster’s stack, with optional visibility and organisation shares
`GET`	`/org/stack-profiles/metadata-suggestions`	List categories and tags already used by your organisation
`POST`	`/org/stack-profiles/import`	Import a profile from IaC content
`GET`	`/org/stack-profiles/{profile_id}`	Profile detail, versions, and update status
`PATCH`	`/org/stack-profiles/{profile_id}`	Update metadata (name, description, category, tags, visibility; making a profile public requires the org admin role)
`DELETE`	`/org/stack-profiles/{profile_id}`	Delete a profile
`POST`	`/org/stack-profiles/{profile_id}/current-version`	Pin the current version (roll back / roll forward)
`POST`	`/org/stack-profiles/{profile_id}/versions`	Save a new version from a source stack
`GET`	`/org/stack-profiles/{profile_id}/versions/{version}`	Get a version’s spec and parameters
`GET`	`/org/stack-profiles/{profile_id}/versions/{version}/iac-export`	Export a version as IaC
`GET`	`/org/stack-profiles/{profile_id}/diff`	Diff two versions
`GET`	`/org/stack-profiles/{profile_id}/instantiations`	List the live deployments of the profile (cluster, stack, state, version, parameters)
`GET`	`/org/stack-profiles/{profile_id}/shares`	List the organisations a profile is shared with
`POST`	`/org/stack-profiles/{profile_id}/shares`	Share the profile with an organisation by slug (org admin role required)
`DELETE`	`/org/stack-profiles/{profile_id}/shares/{share_id}`	Revoke a share (org admin role required)
`GET`/`POST`	`/org/stack-profiles/drafts`	List or create drafts
`GET`/`POST`/`DELETE`	`/org/stack-profiles/drafts/{draft_id}`	Get, update, or delete a draft
`POST`	`/org/stack-profiles/drafts/{draft_id}/validate`	Validate a draft
`POST`	`/org/stack-profiles/drafts/{draft_id}/publish`	Publish a draft as a profile version
`POST`	`/org/stack-profiles/drafts/{draft_id}/rebase`	Move a stale draft onto the profile’s latest version (`reseed` replaces its contents; `acknowledge` keeps them)
`POST`	`/org/stack-profiles/drafts/{draft_id}/submit-suggestion`	Submit a draft as a suggestion to another organisation’s profile
`GET`	`/org/stack-profiles/{profile_id}/suggestions`	List suggestions (owners see all; others see their own organisation’s)
`GET`	`/org/stack-profiles/{profile_id}/suggestions/{suggestion_id}`	One suggestion with its frozen spec and diffs
`POST`	`/org/stack-profiles/{profile_id}/suggestions/{suggestion_id}/approve`	Approve: publish the suggestion as the profile’s next version (owner only)
`POST`	`/org/stack-profiles/{profile_id}/suggestions/{suggestion_id}/reject`	Reject with an optional note (owner only)
`POST`	`/org/stack-profiles/{profile_id}/suggestions/{suggestion_id}/withdraw`	Withdraw an open suggestion (proposer only)

See Stacks for the deploy/commit flow and the API Reference for full schemas.

Get Started

Concepts

Create and Run Clusters

Ship Your App

Stacks and Add-ons

Observe and Troubleshoot

Ankra AI

Connect Tools

Source Control

Security and Access

Cost and Backups

Organisation and Account

Reference

Why use profiles

Anatomy of a profile

Create a profile

From an existing stack

Import

Build with drafts

Instantiate a profile

Choices that set other inputs

From the CLI

Protection: backups travel with the profile

The vault is resolved at launch

Demo a profile before you deploy it

Suggestions: propose and review changes

Versioning, diffing, and updates

Deprecate a version

See where a profile is deployed

The stack a profile was captured from is not a deployment of it

API

​Why use profiles

​Anatomy of a profile

​Create a profile

From an existing stack

Import

​Build with drafts

​Instantiate a profile

​Choices that set other inputs

​From the CLI

​Protection: backups travel with the profile

​The vault is resolved at launch

​Demo a profile before you deploy it

​Share with specific organisations

​Suggestions: propose and review changes

​Versioning, diffing, and updates

​Deprecate a version

​See where a profile is deployed

​The stack a profile was captured from is not a deployment of it

​API

Why use profiles

Anatomy of a profile

Create a profile

Build with drafts

Instantiate a profile

Choices that set other inputs

From the CLI

Protection: backups travel with the profile

The vault is resolved at launch

Demo a profile before you deploy it

Share with specific organisations

Suggestions: propose and review changes

Versioning, diffing, and updates

Deprecate a version

See where a profile is deployed

The stack a profile was captured from is not a deployment of it

API