Skip to main content
A stack profile demo installs a profile’s add-ons and manifests into their own isolated namespace on your organisation’s staging cluster, and stops itself when the timer runs out. Use it to see what a profile actually deploys before you instantiate it onto a real cluster, to check a new version against the old one, or to hand a colleague something running instead of a YAML file.
This is the profile-side twin of branch demos. A branch demo runs an application’s build; a profile demo runs the stack itself, with no application in front of it.

​
Prerequisites

1

Set the organisation's staging cluster

An admin sets it under AI → Settings → Workspaces. Every demo lands there. Without it, the Demos tab explains that and offers nothing to launch.
2

Have a stack profile you can read

Your own profiles, profiles shared with your organisation, and public profiles can all be demoed. The demo runs on your staging cluster, so demoing someone else’s public profile costs them nothing.
3

Hold the stacks deploy permission

A demo is a real deployment through the resource engine. Without the permission the Demos tab is read-only and says so.

​
Launch a demo

Open the profile and go to the Demos tab, then choose Launch demo. The dialog asks for two things:
  • Parameters - whatever the profile’s current version declares. Required inputs are marked; secret parameters bind to an organisation secret slot rather than a typed value, so the plaintext never travels through the browser and is resolved from Vault only at deploy time.
  • Lifetime - how long the demo lives, defaulted to your organisation’s demo TTL and capped by your role.
Ankra then creates the namespace, applies its quota, and instantiates the profile into it with every member forced into that one namespace.

​
One demo per profile

A profile has at most one live demo per organisation. Its namespace is derived from the organisation and profile ids - ankra-demo-sp-<org>-<profile> - so launching again replaces the running demo rather than adding a second copy. That is also why renaming a profile never strands a demo. Relaunch to pick up a new profile version or changed parameter values.

​
Capacity

The demo namespace carries a hard ResourceQuota at the full-stack tier, because a profile installs a whole stack rather than one workload:

​
Watch it come up

The demo list shows the status and what the stack is doing - waiting to instantiate, installing add-ons, stack deployed. Open Details for the live picture, read from the staging cluster on every poll:
  • Progress - namespace created, guardrails applied, stack instantiated. A profile demo deploys no workload of its own, so there is no image or routing step to wait on: the stack operation completing is readiness.
  • What the profile installed - every Deployment, Service, Ingress, ReplicaSet and Pod in the namespace, with the live manifest behind each one.
  • Events - the Kubernetes events for the namespace, newest first.
  • Logs - a bounded tail from any pod in the namespace, fetched on demand.
If a chart fails to install, the failure text is the stack’s own - “no matching PVC storage class” rather than “the demo failed”.

​
Stopping

Stop uninstalls the stack and deletes the namespace. Because Helm uninstall jobs have to drain before the namespace can go, a stop is asynchronous: the demo is marked stopping and the reaper finishes the teardown. Every demo also stops on its own at the end of its lifetime, whether or not anyone remembers it.

​
Application demos and profile demos

An application’s demo settings can designate a stack profile, in which case every demo of that application deploys its own replica of the profile alongside the app (see Branch Demos). That replica and a profile demo are the same stack seen from two sides, so each list links to the other:
  • The application’s Demos tab names the profile its demos replicate and lists that profile’s own live demos, each linking straight to its details.
  • The profile’s Demos tab lists the applications designating it.
When you only want to look at the stack, launching the profile demo is cheaper than launching a whole application demo for it.

​
API

All endpoints sit under the profile and require authentication; the mutations require a CSRF header for browser-originated requests. Bearer-PAT twins live under /api/v1/org/stack-profiles/... for the CLI. See Stack Profiles for authoring and versioning, and Branch Demos for the application lane.