> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Product updates and announcements

<Update label="August 2026">
  # A Playground for Every Organisation, An Agents Page That Shows Who Needs You, Monorepo Demos That Deploy Every App, Publish Your Add-ons to Every Organisation, See Who Did What to a Cluster, Park Clusters on a Schedule, Credentials That Show Their Capacity, A Calmer Credentials Page, Two More Cluster Platforms in Your Terminal, AI Writes That Ask First, Demos That Fix Their Own Configuration, a Full Page for Every Demo, Monorepos That Onboard One App at a Time, AI Chat That Builds Proxmox Clusters, Application Setups That Rescue Themselves, a License on Every Chart, Gateway Resizes That Wait for the Cloud, Registry and Validation Errors That Explain Themselves, Secret Detection That Reads the Value, GitOps Status From the CLI, CLI Listings Built for Scripting, a Branch Picker That Knows Your Repository, and Demos That Run Any Codebase, GitOps Status That Shows the Repository It Actually Read, a Credential Check That Counts Every Cluster, Repository Pickers That Follow the Credential You Chose, and Prerelease Chart Versions That Validate, plus a New Default AI Model, a Publish Flow That Explains Itself, Version History for Published Applications, Catalog Publishing That Checks Who Is Asking, Availability Zones for OVH Clusters, Applications That Publish to a Registry You Already Run, Pull Request Builds That Stop Publishing Images, Stack Profiles You Can Run Before You Deploy, an AI Chat That Acts on Your Defaults, Additive Deploys That Can Run Themselves, Chats That Follow the Cluster They Created, Drafts That Are Never Replaced in Silence, an UpCloud Create Wizard That Can Find the Right Plan, Demo Routing You Can Declare, AI Settings on Every Application, a Microsoft Teams Bot You Can Actually Install with Alert Cards That Keep Their Buttons, a Force Mode That Reclaims Leaked Cloud Volumes and Load Balancers, and Teams Channels You Pick Like Slack with Alert Routing You Can Script, plus an Ankra Domain You Can Choose, a Deployments Tab on Every Stack Profile, and Cluster Wizards That Start on kubeadm and Cilium

  ## Cluster wizards that start on kubeadm and Cilium

  Every self-managed create wizard - Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, Proxmox VE and Morpheus - opened its Kubernetes step on K3s, so a cluster created with the defaults got the lightweight distribution and Flannel unless you noticed the dropdown. Vanilla upstream Kubernetes was one option down, and Cilium with it.

  The wizards now preselect **kubeadm** - upstream Kubernetes bootstrapped with kubeadm and containerd, Cilium (eBPF networking, L7 policies, Hubble observability) as the CNI, and a stacked etcd - and list it first. K3s is still one click away and, when you pick it, the CNI selector behaves exactly as before. The CLI `--distribution` flag and the API keep `k3s` as their default when nothing is passed, so scripted creates are unchanged.

  [Kubernetes distribution →](/guides/digitalocean-clusters#kubernetes-distribution)

  ## See every place a stack profile is deployed

  A stack profile could tell you *that* deployments were behind - the update counter has been
  there for a while - but not *where*. The list of clusters running a profile lived in a small
  panel buried on the overview, with no links, no state, and no way in for a profile that had
  never been used.

  Profiles now carry a **Deployments** tab: every stack your organisation created from the
  profile, with the cluster and stack as links (a never-committed draft links to the draft so
  you can finish it), the stack's live state, the profile version it runs, the non-secret
  inputs it was instantiated with, and when it was deployed. Rows running an older version
  keep the one-click **Update** that pre-fills the update draft with last time's values, and
  the overview's stat card now summarises the fleet - how many deployments, on how many
  clusters, and whether anything is behind - and jumps straight to the tab.

  [See where a profile is deployed →](/concepts/stack-profiles#see-where-a-profile-is-deployed)

  ## An Ankra domain you can choose

  Every public hostname Ankra mints - your organisation's delegated DNS zone, each cluster's subzone under it, and the demo and PR preview URLs built on top - hung off a single platform apex: `ankra.cc`. Serving previews under anything else meant bringing your own domain, wildcard DNS, and TLS secret as a demo base domain.

  Organisation admins can now pick which Ankra-managed domain their zones live under. Deployments offer a list of Avura-hosted roots - `ankra.cc` stays the default, and `smartoptics.dev` is the first alternative - and an **Ankra domain** picker sits next to the preview domain under **AI** → **Settings** → **Workspaces**. Zones you already have keep the domain they were provisioned under; after a switch, Ankra tears down the organisation zone and re-creates it under the new domain automatically, and every cluster zone and preview URL minted from then on follows.

  The switch fails closed on purpose: while cluster DNS zones or manual DNS records still live under the old domain, the save is refused with a message naming exactly what to remove first - nothing is torn down behind your back. To make that removal possible, clusters can now opt **out** of their generated domain as well as in: `ankra cluster domain <cluster> --remove` (or `DELETE /api/v1/clusters/{cluster_id}/dns-zone`) hands the zone back for teardown, and the plain command re-enables it under the organisation's current domain.

  [The preview URL →](/concepts/applications#the-preview-url)

  ## Teams channels you pick like Slack, and alert routing you can script

  Slack has had it for a while: install the app, pick a channel, done. A Teams destination still meant leaving Ankra for Power Automate, building a flow, and pasting a signed URL back. The bot was right there in the AI gateway, answering chat and posting notifications - it just was not wired to alerts.

  Now it is. Once the Ankra AI bot is in a team, the destination form swaps the URL field for a **channel picker** listing every team the bot has been added to, and the bot posts the Adaptive Card itself - no flow, no URL, and the same picker on edit. Add the bot to a team and its channels appear; remove it and they leave.

  The other half of the same complaint was that alert routing lived only in the browser: no CLI, no API token access, nothing you could keep in Git. Destinations and notification routes now answer to a personal access token, and the CLI grows **`ankra alerts destinations`** (`list`, `get`, `create`, `update`, `delete`, `test`, `test-url`, `channels`) and **`ankra alerts routes`** (`list`, `create`, `update`, `delete`, `test`), all honouring `-o json` and `-o yaml`. Updates send only the flags you pass, so a route you touch keeps everything else as it was.

  [Connecting Microsoft Teams →](/platform/ai-connections#connecting-microsoft-teams) · [Managing destinations from the CLI →](/guides/webhooks#managing-destinations-and-routes-from-the-cli)

  ## A Microsoft Teams bot you can install, and Teams alert cards that keep their buttons

  The Microsoft Teams connection card asked for a claim code "the bot shows when it is first added" - but offered no way to add the bot. Ankra AI is not in the Teams app store, the card carried no app package, and the docs said only "add the Ankra bot". The connect flow dead-ended on its first step.

  The card now walks through the whole path: **Download the Teams app package** hands you the app manifest and icons as a `.zip`, built on demand with the deployment's own bot identity, ready to upload in Teams (**Apps** → **Manage your apps** → **Upload an app**) or for a Teams admin to publish to your organisation's catalog. Add **Ankra AI** to a team, paste the claim code it posts, and the tenant is bound.

  The webhook path into Teams got the same treatment. The built-in Teams payload template was a legacy **MessageCard** - a format Microsoft retired with O365 Connectors. Delivered through a Power Automate (Workflows) webhook, the flow reports success while Teams silently drops every button, so cards arrived with no **View Alert**, no **Acknowledge**, and a broken logo from a host that no longer resolves. The preset is now a severity-tinted **Adaptive Card** whose buttons actually render, alongside a new `{{severity_style}}` variable (Adaptive Cards cannot consume a hex colour), and pasting a `logic.azure.com` Workflows URL now auto-selects the Teams preset.

  Three quieter fixes ride along: `{{severity_color}}` is substituted on real deliveries (it previously resolved only for the **Test** button, so production cards shipped the literal placeholder), an alert with an empty name falls back to its rule name instead of rendering a bare "Alert:", and test deliveries no longer strip the `attachments` envelope that Teams cards live in. The template-variable list also stopped advertising a one-click snooze link that never existed.

  [Connecting Microsoft Teams →](/platform/ai-connections#connecting-microsoft-teams)

  ## A force mode that reclaims leaked cloud volumes and load balancers

  Stopping or terminating a cloud cluster released its servers, network, and gateway, but never the storage volumes its workloads had provisioned through the CSI driver, and a load balancer could survive teardown too. The disks sat detached in the account and kept billing: on one of our own UpCloud accounts, 76 orphaned volumes were 83% of the monthly spend before anyone noticed. OVH and DigitalOcean leaked the same way, and Hetzner had the opposite problem: it always deleted the volumes, so a stopped cluster restarted with empty storage.

  Stop and deprovision now take a force mode on every affected provider. `ankra cluster <provider> stop --force` and `ankra cluster deprovision --force` (or `?force=true` on the API) delete the cluster's CSI volumes and load balancers along with the rest of its infrastructure, on UpCloud, Hetzner, OVH, and DigitalOcean; on Scaleway, `--force` overrides a `retain` retention policy. Ankra records which volume IDs belong to the cluster before tearing anything down, so the sweep deletes exactly those disks and nothing else in the account, and a cluster that was stopped earlier without force can still be cleaned up by a forced terminate afterwards.

  Without the flag a plain stop keeps your data so the cluster can come back, and a plain deprovision leaves the volumes for you to reclaim later. On Hetzner that is a deliberate change: it used to delete the volumes on every stop. A forced stop destroys the data on those volumes, and the CLI says so before it asks you to confirm.

  [UpCloud clusters →](/guides/upcloud-clusters#stopping-and-starting-a-cluster)

  ## AI settings on every application

  Which Ankra AI lanes ran on a repository was an organisation-wide decision, taken in a grid of repository rules on the Integrations page. Silencing the pull request review on one noisy repository, or pointing one repository's review at a larger model, meant leaving the application you were looking at and finding its repository among every other repository the Ankra GitHub App can see.

  Every application now has an **Ankra AI** panel under **Settings**, with one card per lane Ankra AI can run on its repository: the pull request review, a branch code review, an Actions review, the organisation skills review, and the demo URL that comments a live preview on every pull request. Each card carries the lane's own model, branch scope, ignored paths, what it does when it finds something, and a daily run and input budget - and is labelled **Inherited** or **Overridden**, so it is always clear whether you are reading your organisation's default or this repository's own decision.

  Overriding is per lane and reversible. A lane you do not touch is not written at all, so an organisation admin goes on steering every application that has not opted out; **Reset to organisation default** returns one lane, and **Follow organisation for everything** drops the application's override completely. Nothing here is a second store: every write lands in the same per-repository rows the AI gateway already resolves when it gates an event, so the panel and the Integrations page cannot drift apart.

  Two lanes are visible but not running yet - the branch **Code review** and the **Actions review** cards describe what they will do with their switches disabled, rather than offering a toggle that silently does nothing. On the pull request review, **Propose a fix** is likewise stored and not acted on yet, and the card says so. One limit worth knowing: the settings are keyed by repository, so two applications connected to the same repository share one set of lanes.

  [Application AI settings →](/platform/application-ai)

  ## Demo routing you can declare, and a registry you can change your mind about

  A monorepo demo deploys every component, picks the frontend-shaped one to own the demo URL, and publishes the API-shaped one under `/api`. Good guesses - but only guesses, and the lanes with no human in the loop had no way to correct them: an automatic pull-request preview and an AI-launched demo both take the heuristic or nothing. An application whose component names read differently got a preview URL serving a UI whose API calls all 404'd, with a working API sitting unrouted in the same namespace.

  Demo routing is now something you declare once. Name the component that owns `/` and the path prefixes the others are published under, and every lane follows it - the launch dialog, the CLI, the automatic PR previews, and the AI tools alike. A declaration is authoritative, so the `/api` guess stops running and a component you leave out stays reachable in-cluster only instead of picking up a path it never asked for. Per-launch overrides still win, and clearing the declaration returns everything to the heuristics.

  The AI's `deploy_pr_demo` also stopped under-reporting what it did: its answer now names the entry component and lists every workload it provisioned with that workload's own image, container port and published path, rather than a single image describing whichever component happened to own the URL.

  Alongside it, **the image registry an application publishes to is no longer fixed at create time**. An organisation that runs its own registry could declare it when onboarding an application and never again - so an application already connected to Ankra kept being reported as never built while it published healthily to a registry Ankra simply could not see. Settings now carries an **Image registry** panel, and the CLI grows `ankra application registry get`, `set` and `clear`. All three report the host and project the declaration resolves to and the image repository each component is expected to publish to, so you can check the coordinates against where your builds actually push before wondering why readiness disagrees.

  Finally, a demo migration command now runs with your image's working directory on `PYTHONPATH`. Python resolves imports against the *script's* directory rather than the working directory, so a migration entrypoint that is a script - `python scripts/bootstrap_database.py` - could not import the application package sitting beside it and died at import.

  [Preview demos →](/concepts/applications#preview-demos)

  ## An UpCloud create wizard that can find the right plan

  Since the Ankra-managed UpCloud wizard started reading UpCloud's live catalogue, its plan pickers rendered all 174 plans as flat walls of tiles - three of them on one page, one each for the bastion, the control plane, and the workers - with no search, no filters, ordering that put `12xCPU` before `1xCPU`, and roughly forty discontinued series mixed in as if they were current. The 15 datacenter zones stacked as another full page of radio rows.

  Each picker is now the same plan browser the other provider wizards use. It opens on a one-line summary of the plan already selected; below it sit a search that spans every category, family tabs (Starter, Premium, Cloud Native, GPU, GPU Spot), vCPU quick filters, and a sortable table for the long tail. Discontinued series live behind a **Current plans / Legacy** toggle instead of dominating the page, and plans order smallest-first.

  Zones are grouped by region - Europe, North America, Asia-Pacific - as compact cards, and Helsinki #2 carries a badge for being the only zone stocking GPU plans today. Pick a GPU plan while another zone is selected and the wizard warns that the create is likely to fail at server creation, instead of letting you find out ten minutes in. The cost estimate also stopped pricing plans it has no published figure for at \$0 - it shows a dash and notes the total covers priced items only.

  ## An AI chat that acts on your defaults

  Agent-mode chat used to interrogate you: which credential, which zone, what name, which sizing, in what order - round after round of multiple-choice before any work happened, for choices that all had sensible defaults. Agent mode now acts on those defaults and states each assumption in one line ("Using namespace `monitoring` - say the word to change it"), reserving questions for decisions that are genuinely yours: destructive changes, real money, or an ambiguous goal. When it does ask, it asks once - every needed decision batched into a single question block.

  The same overhaul grounds the answers better. AI Insights the assistant cites now carry a freshness marker, so a diagnosis no scan has confirmed recently gets re-verified against live state instead of being repeated as fact. Chart-configuration lookups always return readable, navigable data - when a chart's options run long, the assistant gets a trimmed view with named paths it can drill into, never cut-off text. And the assistant can look up your organisation's preview domain from any conversation, so the public URL it proposes for a new service is on a domain that will actually resolve.

  [AI Assistant →](/platform/ai-assistant)

  ## Additive deploys that can run themselves

  With the chat's autonomy setting on **Auto**, a stack deploy whose change set removes nothing - new add-ons, new manifests, configuration changes to what is already there - now executes immediately with a receipt carrying its full bill of materials, instead of stopping at a confirmation card. The bill of materials is generated and validated before anything runs; if validation fails, or the same deploy would remove or replace a deployed add-on or manifest, the confirmation card comes back exactly as before. Cluster create, scale, upgrade, stop, and delete are pinned to always ask, whatever the setting - cost stays a human decision - and writes into protected system namespaces such as `kube-system` remain refused outright.

  Autonomy is off unless you turn it on. Every conversation starts on **Manual** - every write confirmed, exactly as before - the setting is per conversation, and it appears once AI autonomy is enabled for your organisation. It is also not the **Auto** in the model picker, which only routes between models. Every auto-approved action lands in the conversation as a receipt and in the audit log with its autonomy attribution, so what ran, and why it was allowed to, is always reconstructable.

  <Warning>
    On **Auto**, a validated additive stack deploy applies to your cluster without a human click in between. Switch it on for conversations where you want that speed; stay on Manual where every change should be gated.
  </Warning>

  [AI Assistant →](/platform/ai-assistant#autonomy-manual-or-auto)

  ## Chats that follow the cluster they created

  Ask the AI to build a cluster and the conversation now follows it: when the create you approved goes through, a conversation that wasn't already scoped to a cluster is scoped to the new one - so once provisioning finishes, designing stacks, deploying workloads, and reading live state carry on right there, with no more "no cluster selected" from the conversation that did the selecting. Long provisioning runs also stopped crying wolf: the live tracker now gives a cluster build the time it actually takes - 40 minutes, up from 15 - and when it does hand off, it says the build is still in progress rather than calling it a failure. And a failed action no longer strands the conversation mid-flight: the portal now waits for the session to finish its turn before delivering the follow-up that explains what happened, instead of dropping it.

  [AI Assistant →](/platform/ai-assistant)

  ## Drafts that are never replaced in silence

  Designing a new stack while another draft was in progress used to overwrite the previous draft without a word - finished work, gone. A replaced draft is now retired with a full audit trail instead of silently overwritten, and the chat tells you exactly what happened and which draft it replaced, with guidance to deploy or discard a finished draft before starting the next one. Namespaces behave too: the namespace you ask for is the namespace you get, per-chart overrides are supported, and moving a deployed add-on between namespaces from chat now works - the AI can supply the migration strategy the engine requires instead of dead-ending.

  [AI Assistant →](/platform/ai-assistant)

  ## Stack profiles you can run before you deploy

  A stack profile could only be tried by instantiating it onto a real cluster. Reviewing a new version, checking a public profile before adopting it, or showing a colleague what a stack actually deploys all meant putting it somewhere real first.

  A profile now has a **Demos** tab of its own. Launch one and Ankra installs the profile's add-ons and manifests into a throwaway, quota-bounded namespace on your organisation's staging cluster - the same lane branch demos have always used - on a timer that deletes it when it runs out.

  The details view reads the namespace live: how far the stack got, every object it installed with its manifest, the namespace's Kubernetes events, and a log tail from any pod. A chart that fails to install reports its own reason ("no matching PVC storage class"), not a generic failure. A profile demo deploys no application of its own, so there is no image or routing step to sit and wait on - the stack finishing is what makes it ready.

  One demo runs per profile: launching again replaces it rather than stacking a second copy on the staging cluster, so relaunch is how you pick up a new version or changed parameters.

  The two demo lists are now tied together. An application whose demo settings designate a stack profile shows that profile in its **Demos** tab, along with the profile's own live demos and a link straight into each - the stack is often already running, and launching a whole application demo just to look at it wastes staging capacity. The profile's tab lists the applications designating it, from the other side.

  Everything is available to the CLI too, under `/api/v1/org/stack-profiles/{profile_id}/demos`.

  ## Availability zones for OVH clusters

  An OVH cluster in a 3-AZ region such as `EU-WEST-PAR` put every node in the same availability zone, control plane included, and there was no way to ask for anything else. Nothing in the create path could carry a zone, so OVH chose one and used it for the whole cluster.

  You can now spread a cluster across the zones of a 3-AZ region, and pin a node group to one zone:

  ```bash theme={null}
  ankra cluster ovh regions --credential-id <ovh-credential-id> --with-zones

  ankra cluster ovh create --name my-cluster --region EU-WEST-PAR \
    --availability-zones eu-west-par-a,eu-west-par-b,eu-west-par-c \
    --control-plane-count 3

  ankra cluster ovh node-group add <cluster-id> --name database-par-a \
    --instance-type r3-128 --availability-zone eu-west-par-a
  ```

  Control planes and etcd spread per role, workers per node group, and every day-2 path - node group add, node group scale, worker scale, control plane growth - balances new instances around where the existing ones already are. Spreading needs at least 3 control planes, because fewer cannot hold etcd quorum through the loss of a zone; the create is refused rather than promising fault tolerance it cannot deliver.

  Every OVH node now also carries the standard `topology.kubernetes.io/zone` and `/region` labels, taken from the zone OVH reports for the live instance rather than the one that was requested. That makes them correct on clusters created before any of this existed too - Ankra records the zone the next time it reads the instance, and `ankra cluster reconcile <cluster-id>` applies the labels without waiting for a change to trigger a sync.

  <Warning>
    OVH High Speed block storage is zonal: a volume is replicated within one zone and cannot attach from another. A single database pod with one PersistentVolume is not zone-fault-tolerant however the nodes are spread. Zone tolerance needs replication at the application layer, one replica and one volume per zone. The default StorageClass on OVH clusters is now `csi-cinder-sc-topology`, which binds `WaitForFirstConsumer` so a volume is created in the zone its pod was scheduled to instead of stranding it.
  </Warning>

  New OVH clusters also stop installing k3s's bundled local-path provisioner, which marked itself the default StorageClass alongside the cinder one. Two defaults left the class an unqualified PersistentVolumeClaim resolves to undefined, and resolving to local-path put the volume on a single node's disk with no replication. Existing clusters keep local-path untouched, since removing a StorageClass would orphan any volume already bound to it - name the class you want explicitly there rather than relying on the default.

  [Availability zones →](/guides/ovh-clusters#availability-zones)

  ## A publish flow that explains itself

  Publishing to a catalog was three different screens depending on what you were publishing, and each of them failed late. Publishing an application was four unlabelled text boxes; if the version was already taken, or the application was not publishable at all, you found out after submitting.

  Every publish flow is now the same shape: check, review, confirm. Before anything is submitted you see what will be published, where it lands, and — the useful part — **why it cannot be published, if it cannot**. Publishing an application now starts from Ankra's readiness check, which has always existed but never had anywhere to appear: a missing image registry declaration is reported up front, with a **Fix automatically** button where Ankra can resolve it for you.

  A version that is already published is refused inline, before anything is snapshotted, instead of coming back as a conflict after submitting.

  [Publishing applications as add-ons →](/platform/application-addons) · [Publishing add-ons →](/platform/addon-publishing)

  ## Version history for published applications

  A published application listed its versions as a flat row of numbers. It now has a history: each version carries a **changelog** you write at publish time, who published it, and a **Compare** against the version before it.

  Comparing shows which manifest files were added, removed or modified with their contents side by side, and — separately — which **deploy options** changed. That distinction matters: options are the add-on's install-time contract, so changing one is a breaking change for anyone who already installed it. A version that starts or stops referencing an environment `Secret` is called out for the same reason.

  Existing versions keep working unchanged; those published before changelogs simply have none.

  [Version history →](/platform/application-addons#version-history)

  ## Catalog publishing now checks who is asking

  Proposing an add-on to the global Ankra Catalog puts your organisation's name on a pull request against a public repository, and once merged the entry is visible to every organisation. It now requires the **Manage Helm registries** permission, held by organisation admins and owners. Members and operators can still open the flow and review exactly what would be proposed — they just cannot submit it, and the flow says so on the first step rather than failing at the end.

  Ankra also screens the rendered manifest before it can be proposed, refusing credentials embedded in a URL and recognisable provider tokens, naming the field so it can be corrected. A pull request is effectively permanent: a credential that reaches a public repository is in its history even if the branch is later closed.

  [Publishing add-ons →](/platform/addon-publishing#who-can-publish)

  ## Applications can publish to a registry you already run

  An Application's container images went to your organisation's private Ankra registry, and there was no way to say otherwise. If you already operate a registry — often the same Harbor whose OCI charts Ankra indexes for you — your images existed, they were simply not where Ankra looked. Publish readiness reported "no image has been pushed yet" indefinitely while the application ran healthily from the registry it actually uses, and the deploy gate stayed shut behind an artifact that was never going to appear.

  An Application can now declare the registry it publishes to, pointing at a registry credential Ankra already holds:

  ```json theme={null}
  "image_registry": {
    "url": "oci://artifact.example.com/commerce-images",
    "credential_name": "example-harbor-pull",
    "pull_secret_name": "harbor-registry",
    "username_secret_name": "HARBOR_USERNAME",
    "password_secret_name": "HARBOR_PASSWORD"
  }
  ```

  Everything downstream follows it: the generated workflow pushes there and logs in with the secret names you gave, publish readiness verifies the tag **in that registry** with the credential you named, the deploy gate and image listings probe it, container scanning reads its tags, generated Deployments reference the pull Secret you named, and Ankra creates that Secret in the deploy namespace from the same credential. One credential serves chart pull, image pull, and readiness.

  On a monorepo, a component may declare its own registry — apps that live in different projects with their own robots and retention rules are addressed individually.

  **Ankra does not mint robots for a registry you operate.** Setup names the two Actions secrets the workflow reads and leaves them to you, rather than writing a credential Ankra happens to hold over a push robot you administer. Readiness reports whether they exist; `manage_actions_secrets: true` opts back in.

  [Using your own registry →](/concepts/applications#using-your-own-registry)

  ## Pull request builds no longer publish images

  The generated workflow ran on `pull_request` with `push: true`, so a build from unmerged code published an image — into a registry whose retention and tag-immutability rules are governed elsewhere, tagged as though it were a real build.

  Pull request runs now build and scan the source without pushing. The image scan follows the push, so it runs on branch builds, where there is an artifact to pull back and scan.

  ## GitOps status now shows the repository it actually read

  `ankra cluster gitops status` and the cluster's GitOps settings reported the repository Ankra has **stored** for a cluster. A sync now records the repository, branch and provider it actually read, and the status answer carries it as `observed_source` alongside a `source_mismatch` flag. If the two ever disagree, you can see it rather than having to infer it by comparing commits across repositories.

  Underneath, the cause of that disagreement is gone. A cluster could end up carrying more than one GitOps repository record, and different parts of the platform picked different ones — so a cluster could sync from one repository while reporting another. Applying a cluster definition now leaves exactly one active record, and the sync loop and the status view resolve it the same way by construction.

  Repointing a cluster through `spec.git_repository` works as documented, including onto a **non-default branch**: one repository with a branch per environment is a supported layout.

  <Warning>
    Repointing prunes what the new source does not define, PersistentVolumeClaims included. Diff the two sources over the cluster's directory before you apply.
  </Warning>

  [GitOps →](/concepts/gitops) · [ImportCluster reference →](/reference/importcluster)

  ## A credential check that counts every cluster

  Before replacing or deleting a GitHub credential, `get_github_credential_usages` tells you what depends on it. It was only counting **imported** clusters, so any cluster Ankra provisioned — on DigitalOcean, Hetzner, OVH, UpCloud, GKE, EKS, AKS and the rest — was missing from the answer. Acting on that count, you could revoke a credential that a live GitOps sync was riding.

  Every cluster is now counted, whoever provisioned it. The response also separates `usage_count` (clusters) from `application_count` (Applications built from the credential's repositories) and adds `dependent_count` for the total, and a credential name shared by more than one credential now returns the full superset instead of an empty answer.

  ## Repository pickers that follow the credential you chose

  In a cluster's **Settings → GitOps**, changing the credential left the repository selection pointing at the previous credential's repository, and **Sync Repositories** refreshed the credential you were replacing rather than the one you had just picked. Moving a cluster to a repository under a different GitHub organisation could not be completed.

  Choosing a different credential now clears the repository so you pick one the new credential can actually see, and syncing follows your current selection.

  ## Prerelease chart versions now validate

  `ankra cluster validate` could reject a `chart_version` that was deployed and running — typically a CI-published prerelease such as `0.1.6-ci-ankra-pipeline`.

  Prereleases were never excluded from indexing. The real cause was tag pagination: Ankra stopped reading an OCI repository's tags after the first page unless the registry sent a `Link: rel="next"` header, which not every registry does. Charts with many tags therefore lost their newest versions from the index, and a pin `validate` was asked about could never resolve. Ankra now pages through every tag, and reports a truncated listing instead of indexing a partial one.

  The error also stops pointing at the wrong thing: it now says the version is not **indexed**, and suggests re-syncing the registry.

  ## A playground for every organisation

  The **playground** — a real, writable Kubernetes environment Ankra provisions for you — is now available to every organisation. There is nothing to enable and nothing to install: click **Start playground** in the create-cluster dialog, and a couple of minutes later you have a cluster with the Ankra agent already connected.

  It is a genuine cluster, not a simulation. Each playground is a [vcluster](https://www.vcluster.com/) with its own API server, isolated per organisation, running on Ankra's infrastructure. Deploy stacks through the normal pipeline, browse live resources, stream logs, open a terminal, and ask the AI to build things — all before you connect a cluster of your own. One per organisation, expiring after a few days of inactivity, with a heads-up before it goes.

  Organisations created before this change may still see a `sandbox-demo` cluster. It keeps working, but its deploys are simulated rather than run on real infrastructure — start a playground for the real thing.

  From the terminal:

  ```bash theme={null}
  ankra cluster playground create
  ankra cluster playground status <cluster_id>
  ```

  [Playground →](/guides/cluster-sandbox)

  ## An agents page that shows who needs you

  The **AI Agents** overview now tells you where your fleet stands without opening every agent. Each row carries a status chip for the agent's latest run — **Needs your input**, **Blocked**, **Failed**, **Working**, **Goal met**, or **Never run** — plus the run's outcome summary, and a call to action that matches the state: **Respond** jumps straight into the chat conversation a parked agent is waiting in, **Review** opens a blocked or failed run's transcript, **View live** follows a run in flight, and **Run now** dispatches an agent that has never run.

  Agents waiting on a person sort to the top, a summary strip counts and filters them, and finished one-off missions fold away under **Completed missions** so old dispatches stop burying the live ones. The sidebar's **AI Agents** item now badges the number of agents waiting on your input — an unanswered agent question is no longer something you discover by accident.

  [AI Agents →](/platform/ai-agents)

  ## A new default AI model

  Ankra AI now runs on **Kimi K3** by default, with **GLM 5.2** as the Think tier. Both are served through Ankra's managed access - there is nothing to configure, and existing conversations carry on unchanged.

  | Tier                 | Model            | Context     |
  | -------------------- | ---------------- | ----------- |
  | **Expert** (default) | Kimi K3          | 1M tokens   |
  | **Think**            | GLM 5.2          | 1M tokens   |
  | **Quick**            | Claude Haiku 4.5 | 200k tokens |

  Both new tiers carry a **1M-token context window**, up from 200k, so long troubleshooting sessions and large manifests fit without compaction. Expert accepts images and reasons before it answers; Think reasons at high effort on text. **Auto** still picks per question, and sends anything with an attachment to Expert.

  Reasoning is now visible on these models the same way it always was on Claude - you see the thinking as it streams, not just the answer.

  None of this is a limit. Under **AI** → **Settings** → **Models** you can still edit any tier, point it at your own model, or switch the whole organisation onto your own Anthropic, OpenRouter, or self-hosted OpenAI-compatible key - which serves every tier from your provider instead.

  [AI Provider →](/platform/ai-provider)

  ## Monorepo demos deploy every app

  A demo of a monorepo used to run exactly one of its components - so a two-app repository demoed its API where the frontend belonged, and the preview URL answered with a bare JSON 404. Demos now deploy **every component of the application by default**, each as its own pod in the demo namespace, and the demo only reports ready once all of them accept connections.

  The **web entry** - the frontend-shaped component - owns the demo URL, and the API component is published under `/api` on the same host, routed straight to its own service, so the browser reaches both halves without the app needing environment-specific proxy configuration. Components also reach each other in-namespace by name (`http://crm-api:8090`), and demo env values can reference `${{ ankra.demo_component.<name>.url }}` placeholders that resolve at deploy time.

  The launch dialog now shows each component's build status and tag side by side, lets you include or exclude components, and lets you move the entry. The demo detail page groups the bill of materials per component and lists each component's public path next to the preview URL. Automatic PR previews and the AI's `deploy_pr_demo` tool deploy every component the same way - and PR previews of monorepos, which previously always reported "build missing", now resolve their images correctly.

  [Applications → Monorepo demos →](/concepts/applications#monorepo-demos-every-component-one-url)

  ## Demos that run any codebase

  Launching a demo of a real application used to fail in three quiet ways: the readiness probe watched a port the app never listened on, a database-backed app crashed with no database, and a fresh database had no schema. All three are now handled end to end.

  **Ports resolve themselves - twice.** The launch resolves the container port from what the repository actually declares (recorded component ports, the runtime Dockerfile's `EXPOSE`, the generated Deployment manifest, the analysed target port), and the launch dialog no longer overrides that resolution with a default. And when the artifacts themselves are wrong, the platform reads the running container's own startup banner - `Accepting connections at http://localhost:8001` - and repoints the demo at the announced port on the fly, once, recording the correction so the next launch is right from the start. A demo that still times out now tells you exactly what happened: *"Nothing accepted connections on port 3000. The container's logs say it listens on port 8001."*

  **Databases arrive configured.** Analysing a repository now detects a database dependency - a Postgres client, an ORM config, a composed database - and seeds the demo configuration: throwaway database on, the connection variables the code actually reads wired to `${{ ankra.demo_database.* }}`, and the repository's migration command. Demos run migrations as an init container inside your own image, after the database accepts connections, so a fresh demo database provisions its schema before the first request. Schemas needing Postgres extensions declare them (`database_extensions: ["vector"]`) and the database creates them at initdb.

  **And the CLI can drive all of it.** `ankra application demo detail` shows the provisioning steps and failure detail, `demo logs` fetches a bounded log tail, `demo config get/set` edits the saved defaults - environment, database, migration command, extensions - and `demo fix` dispatches the pre-setup agent, which now also repairs failed migrations and wrong ports.

  [Applications → Preview demos →](/concepts/applications#preview-demos)

  ## Create applications on a branch that actually exists

  The **Create application** form no longer asks you to type a branch name into a free-text field and hope. Once you pick a repository, the branch field becomes a searchable list of the repository's real branches with its default branch preselected - and **Enter a different branch** stays one click away for a branch you have not pushed yet. If your organisation has a single GitHub App installed, it is selected for you, and repository search now ranks an exact name first instead of last.

  The form also spells out what **Create** will do before you commit to it: an AI agent analyses the repository and generates a Dockerfile, CI/CD pipeline, and Kubernetes manifests where they are missing, opens a setup pull request for you to review and merge, and publishes container images to your organisation's private registry.

  [Applications →](/concepts/applications)

  ## Publish your add-ons to the whole platform

  An add-on your organisation curated can now be proposed to the global Ankra Catalog - the add-on catalog every organisation sees. **Publish to Ankra Catalog** on the add-on's page shows exactly what would be proposed: the rendered `kind: Addon` manifest, a diff against the currently published version when one exists, the target repository, and a version-history link into the catalog's Git log. Confirming opens a pull request against the public [ankraio/ankra-global-resources](https://github.com/ankraio/ankra-global-resources) repository on your behalf - review and merge is the approval gate, so nothing ships silently.

  A **Publish history** section then tracks each request through its life: pull request open, merged and awaiting sync, live in the catalog, or closed - with the pull request linked at every step. Once merged, the platform sync ingests the manifest and the add-on appears for **all organisations**; your own organisation's copy keeps shadowing the global one, so publishing never changes what you see. The catalog repository itself gained the new `Addon` manifest kind alongside its Helm registries, and removing a manifest retires the global add-on again.

  [Publishing Add-ons →](/platform/addon-publishing)

  ## Every manual cluster action, on the record

  Cluster **Settings** grew an **Audit** tab: a chronological trail of every manual action performed on that cluster - who did it, what it was, and when. Starting, stopping, upgrading, or terminating a cluster, scaling workers or the control plane, creating, editing, or deleting node groups, restarting a node, resizing the bastion, deploying, updating, redeploying, retrying, or deleting stacks, and agent-side Helm upgrades and rollbacks all now write attributed entries - the acting member's email, the resource touched, the timestamp, and expandable structured details such as the previous and requested counts of a scale.

  The tab is the per-cluster view of the organisation [Audit Log](/guides/audit-log) and shares its permission gate: audit read, held by owners and admins by default and grantable to custom roles. Entries are append-only, so the answer to "who scaled this cluster last Tuesday?" is one click away instead of an archaeology exercise. And when a stack edit results in a GitOps commit, the entry links straight to it - the platform action and the repository change it produced, side by side.

  [Cluster Settings → Audit →](/platform/cluster-settings#audit)

  ## The cluster trail and the organisation trail now join up

  The organisation [Audit Log](/guides/audit-log) and a cluster's **Audit** tab always read the same record, but you could not travel between them. Now every organisation entry names the cluster it belongs to, and that name links straight into the cluster's own tab; organisation-level events such as sign-ins and invitations show no cluster, and a cluster you have since deleted keeps its name marked deleted, because the record outlives the cluster. A **cluster** filter joins the existing user, action, and date filters, and it lives in the page URL, so "everything anyone did to this cluster" is a link you can share.

  From the other side, the cluster tab gained **View in organisation audit log** - the full trail with that cluster preselected - plus **Export CSV** and **Export JSON** for the cluster's own entries. Exports run through the organisation export narrowed to the cluster, so a per-cluster download and the filtered organisation view can never disagree, and every exported row now carries the cluster next to the actor and action.

  [Audit Log →](/guides/audit-log)

  ## Stop and start clusters on a schedule

  Every self-managed cluster - Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, Proxmox VE, and HPE Morpheus - can now park itself. A new **Power schedules** card in cluster **Settings** → **General** holds up to 20 schedules per cluster, each one a stop or a start that fires either once at a chosen date and time or repeatedly on a 5-field cron expression in the timezone you pick. The classic pair - a `0 19 * * 1-5` stop and a `0 7 * * 1-5` start - shuts a development cluster down on weekday evenings and has it back before the team arrives, so it only accrues compute cost while someone is using it.

  Schedules are careful about cluster state: a stop is skipped if the cluster is already stopped, a start only fires when it is stopped, and if the cluster is busy with another operation the schedule retries every 5 minutes for up to 24 hours before recording a failure. Each schedule shows its next run and last outcome, and a toggle pauses it without deleting it.

  [Power Schedules →](/platform/cluster-power-schedules)

  ## Credentials that show what you have left

  Open a cloud credential and the detail page now reads capacity straight from the provider - and it works for every cloud provider Ankra supports. A Proxmox VE credential shows the cluster behind it: every node with used and total CPU and memory, storage pools with shared pools counted once, and how many guests are running with the vCPUs and memory allocated to them. An UpCloud credential shows the account's real resource limits - cores, memory, storage, IPs, networks, load balancers - as usage bars, next to remaining credits. OVHcloud shows its true per-region project quotas the same way: vCPUs, instances, memory, and volume storage per region, each with how much of the quota is spent. Azure shows the subscription's virtual machines and AKS clusters with regional vCPU and VM quota bars, and DigitalOcean shows droplet and floating IP limits. HPE Morpheus shows each cloud on the appliance with used and total memory and storage. Hetzner and Scaleway expose no limits over their APIs, so their views are live usage reports: servers with combined vCPUs, memory, and storage, plus the networking resources around them.

  The numbers come from the provider at view time, so they include everything in the account, also what was created outside Ankra. Capacity questions like "will another three workers fit?" get answered on the credential page instead of in the provider console.

  [Credentials →](/platform/credentials#capacity-and-usage)

  ## A calmer credentials page

  The credentials surface got a visual and structural cleanup. The list page now has a single quiet toolbar - search, provider filter, sort, and paging in one row - and flatter cards that keep to the essentials: provider, type, health, and when the credential was last updated. The credential detail page, which had grown into one long scroll of identity, capacity, connection details, rotation, and usage all at once, is now a compact identity header with tabs: **Overview** for connection details and the verify check, **Capacity** for the provider report, **Used by** for the clusters and operations on the credential, and **Rotation** for in-place secret rotation. Each tab loads its own data, so opening a credential no longer fires every provider query at once, and the layout now matches the GitHub credential cockpit, so every credential detail page reads the same way.

  [Credentials →](/platform/credentials#view-credentials)

  ## The Ankra CLI adds Proxmox, Morpheus, and control over agent runs

  [Ankra CLI v0.9.0](/integrations/ankra-cli-changelog) is out, and it is the largest CLI release so far:

  * **Proxmox VE and HPE Morpheus clusters** - `ankra cluster proxmox` and `ankra cluster morpheus` cover the full lifecycle, node groups, control plane, SSH keys, autoscaling, and upgrades, plus discovery of what each platform offers and their own credential commands.
  * **Managed Kubernetes parity** - provider-native stop and start, `node-pool update` for in-place node count and autoscaling changes, autoscaling bounds at create time, and Scaleway Kapsule as a new provider.
  * **See and stop what your AI agents are doing** - `ankra agents` lists dispatched agent runs, shows one in full, reads the session transcript of what the agent actually said and did, and cancels a live run.
  * **Agent-mode chat asks before it writes** - every mutating tool halts the turn and proposes the write. The stream now shows each proposal with its risk and parameters, an interactive session prompts to run or discard it, and `ankra chat actions confirm | reject | list` drives the same decision from a script. (One exception has since joined: a conversation switched to the new **Auto** autonomy setting executes validated additive stack deploys with a receipt instead of halting - see [Additive deploys that can run themselves](#additive-deploys-that-can-run-themselves) above.)
  * **Node restarts and bastion resize** - restart any provisioned node as a tracked operation across Hetzner, OVH, UpCloud, DigitalOcean, Scaleway, and Proxmox, and resize the bastion in place.
  * **Secrets encrypted in a single commit** - `ankra cluster encrypt manifest --set` applies the new value in memory before encrypting, so the plaintext never reaches git history.

  The release also fixes a batch of commands that were decoding response shapes the API never sent, and therefore showed nothing: manifest and member listings, chat health, and stack history all return real data again, and `ankra cluster encrypt -f` and `cluster clone` no longer strip fields and comments from your cluster YAML.

  [CLI Changelog →](/integrations/ankra-cli-changelog) | [Ankra CLI →](/integrations/ankra-cli)

  ## Ask the AI to build you a Proxmox cluster

  Cluster provisioning in chat now covers Proxmox VE. Ask the assistant for a new cluster on your Proxmox credential and it drives the real flow: it reads the credential, lists your host nodes with their CPU and memory alongside the px-\* instance presets, and - once a node is picked - that node's storage pools, network bridges (SDN vnets included), and clone-source templates, then proposes the create for your confirmation like every other provisioning action. Credentials that reach Proxmox through an SSH jumphost work too - the chat reads ride the same tunnel the rest of the platform uses.

  Hetzner, OVH, UpCloud, and Scaleway were already there; Proxmox VE joins them, so the platform chat and the [MCP tool surface](/platform/mcp-tools) now agree on what can be built.

  [Ankra AI Assistant →](/platform/ai-assistant)

  ## Demos that fix their own configuration

  An application image that validates its environment on boot used to make a hopeless demo: deployed bare, it crash-loops, and the preview never comes up. Now, when a demo fails with a startup crash, Ankra dispatches a **pre-setup agent** automatically. It reads the crashed container's logs, works out which variables the application demands, and generates the demo configuration: database URLs become references to the demo's own throwaway Postgres, secrets get fresh random values, and mode flags get the value without external side effects. It saves the result as the application's demo defaults - every future demo inherits them - and redeploys the failed demo to prove it boots.

  The agent's run is visible on the AI agents page like any other mission, it never weakens the application's own validation, and it runs at most once per demo per day. You can also trigger the same fix on demand, or ask the AI assistant to repair a failed demo in chat - the same diagnostics, configuration, and redeploy tools back both. Two supporting fixes ship alongside: demo redeploys switch to a Recreate rollout, so a configuration change can never wedge against the namespace resource quota, and the throwaway demo database now runs a pgvector-capable Postgres, so migrations using `CREATE EXTENSION vector` work.

  [Preview demos →](/concepts/applications#automatic-pre-setup-when-a-demo-crashes)

  ## A full page for every demo

  Inspecting a demo used to mean a dialog stacked over the Demos tab - cramped, unlinkable, and gone the moment it closed. Every demo now has its own page, opened from a demo row's status pill or **Details** button. A header carries the demo's identity - branch or pull request, status, full-stack and database badges, namespace, image tag, and the time left - with **Open preview** and **Stop demo** alongside. Below it, the view reads live from the staging cluster and refreshes itself: the provisioning timeline, the namespace's bill of materials with each resource's manifest a click away, the Kubernetes events that explain a stall, and on-demand pod logs. Side cards cover how to reach the demo - the preview URL or the exact port-forward command - the demo's facts, and the staging cluster it runs on.

  Because it is a page, it has a URL: share a provisioning demo with a teammate and they land on the same live view, breadcrumbs and all.

  [Preview demos →](/concepts/applications#preview-demos)

  ## Monorepos onboard as applications, one component per app

  An application used to mean one deployable app per repository: a single image, a single build workflow, a single container port. Point Ankra at a monorepo and the generated pipeline built each app correctly and pushed each image to its own place - but everything that read the result looked somewhere none of them published to, so a repository whose builds were green reported "No built images were found for this application yet." and the demos tab had nothing to launch.

  Applications now model a repository's **components**. An ordinary repository has one, covering the root; a monorepo has one per app, each with its own Dockerfile under its directory, its own manifests, its own workflow carrying a `paths:` filter so touching one app does not rebuild the others, and its own image at `<your-registry-project>/<repository>/<component>`. Build state, published images, publish readiness, deploys, demos, and container scanning are all reported per component, so an application whose API component built and whose frontend did not says exactly that instead of collapsing the two into one wrong answer.

  Ankra works out the components from what the repository already declares first - a repository it has onboarded before keeps the component names its live workflows use, so re-running analysis never renames an app and orphans the images it has published - then from what the analysis proposes, then from the repository's structure. A Dockerfile at the repository root always means a single app. Nothing needs migrating: an application with no recorded components still resolves to exactly the coordinates it always used, and re-running analysis records the components it finds.

  The launch dialog gained a **Component** picker for monorepos, with the container port following your pick. That was the sharpest edge of the old behaviour: a component inherited whichever port appeared first among the repository's generated files, so an API component on 8090 could be probed on port 3000 of a frontend and the demo sat in *provisioning* until it timed out.

  [Monorepos →](/concepts/applications#monorepos)

  ## Application setups that rescue themselves

  Adding an application kicks off an AI setup that analyses the repository and generates the Dockerfile, Kubernetes manifests, and CI/CD pipeline. Until now that screen could over-promise: before any agent had actually picked the task up it already said "AI Agent assigned to task", and if the setup stalled or failed there was no agent anywhere in the product to look at. The first step now reads **Waiting for an AI agent to pick up the task** until real progress arrives, so the screen tells you what is actually happening.

  More importantly, stuck setups no longer depend on you noticing them. A setup that sits silent for fifteen minutes, or fails its analysis, now dispatches a **rescue mission** automatically: a one-shot agent that appears on the AI Agents page with a full transcript, diagnoses what went wrong, retries the setup when that is the fix, and reports exactly where things are stuck when it is not. The setup screen links straight to the AI Agents page from its stall warning and its failure state, and dispatch is bounded to one rescue per application per day.

  Alert delivery got the same discipline behind the scenes: a notification whose webhook can never deliver - the webhook was deleted, or never had a URL - now records its failure and stops retrying instead of piling up as pending work, and stale undelivered notifications are swept automatically. One organisation's undeliverable-webhook backlog was what starved new application setups in the first place.

  [Applications →](/concepts/applications)

  ## Every chart version shows its license

  Every chart version's overview in the chart browser now carries a **License** field with the license's SPDX identifier - `Apache-2.0`, `MIT`, `AGPL-3.0-only`, and so on. Ankra reads the chart's `artifacthub.io/license` annotation from `Chart.yaml`, and falls back to detecting the license from the `LICENSE` or `COPYING` file inside the chart package when the annotation is missing.

  Copyleft licenses - the AGPL and GPL family - are visually highlighted, so a chart whose license carries obligations for your own code stands out before it lands in a stack.

  [Helm Charts →](/platform/helm-charts)

  ## Gateway resizes that wait for the cloud

  Resizing a cluster's gateway could be reported as failed even though it was proceeding normally: the platform timed out while the cloud provider was still completing the resize. Resize operations now wait for the provider to finish, so a resize that succeeds on the provider side succeeds in Ankra too.

  ## Registry creation tells you what is wrong

  Creating a Helm registry with a malformed spec used to answer with a bare 500 and no hint at the cause. The API now validates the spec first and answers with a clear 422 naming exactly what is wrong. The CLI side got friendlier too: registry creation accepts both flat and YAML spec files, plus `--name` and `--url` flags for the simple case where a file is overkill. The 422's example now shows both accepted shapes - the raw API body and the pre-wrap file that `ankra helm registries create -f` expects - so copying the example works from either caller.

  [Registries →](/guides/registries)

  ## Cluster validation that names the real problem

  Validating a cluster definition whose add-on could not be resolved used to give one undifferentiated error. Validation now distinguishes the three cases: the registry is not connected in your organisation, the chart does not exist in that registry, or the chart exists but the pinned version does not. `chart_version` itself is validated too, so a typo in a version pin is caught at validation time instead of at deploy time.

  Version pins compare the way Helm resolves them: `1.20.0` matches a chart published as `v1.20.0` and vice versa, so a pinned production config validates no matter which spelling of the version your chart's publisher uses.

  `ankra cluster validate` now also runs the per-resource field checks that apply enforces - add-on namespace rules, group names, empty manifest bodies - so a rule that would reject your file at deploy time is caught at validation time, in CI, before anything touches a cluster. And the namespace rule itself got saner: add-on namespaces now accept everything Kubernetes accepts (1-63 characters, lowercase letters, digits and dashes), so short names like `ory`, `ops`, or `dev` are valid - the old 4-character minimum is gone.

  [ImportCluster YAML Schema →](/reference/importcluster#validation)

  ## Secret detection that reads the value, not just the key

  The plaintext-secret scan used to flag anything whose key looked secret-like, so `timeout: 30s`, port numbers, and references to already-encrypted values all raised warnings. Detection is now value-shape aware: durations, ports, booleans, and references no longer count, while values that actually look like credentials still do. High-confidence findings can also gate CI - enable `strict_secrets` and a definition carrying a likely plaintext secret fails instead of warning.

  [SOPS Secrets →](/guides/sops)

  ## CLI listings built for scripting

  List commands across the CLI now page properly: pagination flags control the window, `--all` fetches everything, and a listing with more results than it shows says so instead of silently truncating. JSON output uses a consistent envelope across commands, so scripts can parse every listing the same way. And `ankra cluster encrypt` grew batch ergonomics: `--key` is repeatable and `--all-data` encrypts every data field in one pass.

  [Ankra CLI →](/integrations/ankra-cli)

  ## See what GitOps is actually syncing

  `ankra cluster gitops status` shows the cluster's live GitOps source: the connected repository, the branch Ankra reads from, the credential in use, and the last synced commit with its sync state. When a cluster is not picking up changes, the first question - is it even looking at the right branch? - is one command away.

  [GitOps →](/concepts/gitops)

  ## Preview a chart's manifests before anything deploys

  `ankra charts template` renders an add-on's chart with your values server-side, from the same mirrored package Ankra deploys, and prints the resulting Kubernetes manifests - or the exact rendering error a deploy would have hit. Wrong secret key names, surprising Service ports, and values that leak into a ConfigMap all surface on your laptop instead of against a production cluster. `ankra charts values` prints a chart version's default values document, the baseline you diff your overrides against. Neither command needs direct registry access on your side.

  [Stacks and add-ons →](/concepts/stacks)

  ## Declare Helm registries in the cluster file

  The ImportCluster file can now carry a top-level `spec.helm_registries` block. Registries declared there are connected automatically before any add-on deploys - same name and URL is an idempotent no-op, private registries reference an existing credential by name so secrets stay out of Git - which makes a GitOps repository genuinely self-contained: clone, apply, and the declared state is reachable on a fresh organisation with no side-channel setup commands.

  [ImportCluster reference →](/reference/importcluster)
</Update>

<Update label="July 2026">
  # More Clouds, Vulnerability Scanning, and Team Roles

  ## Whoever creates a cluster can reach it with kubectl

  Creating or importing a cluster now grants you cluster-scoped `cluster-admin` Kubernetes access to it, so `ankra cluster kubeconfig add` works as soon as the cluster is up instead of answering "You do not have access to this cluster" until an admin granted you access by hand. The grant is an ordinary Cluster Access grant: it shows up in the cluster's **Access** view and in `ankra cluster access list`, reconciles into native RBAC, and can be revoked. Clusters created before this change have had the same grant seeded for their creator, so kubeconfig access there starts working without any operator action.

  [Cluster Access →](/guides/cluster-access)

  ## Branch and PR demos detect your application's port

  Launching a demo no longer assumes your application listens on port 8080. Every demo lane — the Launch demo dialog, AI-deployed PR demos, and the automatic pull-request previews — now reads the port from your application's generated Dockerfile (`EXPOSE`) and deploys with it, so a Next.js app on 3000 or a Flask app on 5000 comes up ready instead of sitting in "provisioning" forever behind a readiness probe on the wrong port. The launch dialog pre-fills the detected port, and the advanced override still wins when you need something different.

  ## Security Center overview and findings, modernised

  The Security Center's **Overview** and **Findings** tabs now share the visual language the Compliance tab introduced. The overview leads with a fleet security scorecard: a posture ring showing the share of scanned clusters with no actionable critical or high findings, a verdict at a glance, and tiles for critical, high, fixable-severe, and scan coverage. Findings swaps its second tab bar and boxed filter panel for pill filter chips with live counts pulled from your fleet's data.

  Ankra AI is now one click away from both tabs: **Fix top findings with AI** on the overview hands the top remediation candidates to the AI with a fleet-wide remediation ask, and every finding's detail sheet gains **Ask Ankra AI**, grounded in the finding and the cluster it was observed on.

  [Security Center →](/guides/cluster-security)

  ## The Security Center overview shows which application is generating the risk

  The overview no longer stops at fleet totals. A new **Risk breakdown** row splits your observed occurrences three ways: a **Severity mix** with a bar per band, a **Review state** split across open, acknowledged, and accepted risk, and a **Fix readiness** number telling you what share of your critical and high occurrences actually have a published fix to move to. The **Observed fleet trend** chart grew up too - gridlines, a filled area, the observed range on the axis, a change chip, and a tooltip on every snapshot.

  Most usefully, **Application hotspots** now ranks the workloads generating the most actionable risk across your whole fleet, weighted so criticals outrank a pile of lows. Each row names the workload, the namespace and cluster it runs in, the add-on it was attributed to, how many of its findings already have a fix, and links straight into that cluster's findings filtered to it. Alongside it, **Risk by cluster** ranks your clusters by actionable occurrences, so "where is the heat" and "who owns it" are both answerable without leaving the overview.

  The overview also lays itself out based on the space it actually has rather than the size of your screen, so reading it beside the docked AI panel no longer squeezes the scorecard tiles into unreadable slivers.

  [Security Center →](/security/overview)

  ## Ankra AI now runs on Claude Opus 5

  The platform's highest-capability AI tier moved from Claude Opus 4.8 to Claude Opus 5. Everything that escalates to the Expert model — plan mode, image analysis, high-risk and multi-resource changes, complex architectural questions, deploy analysis, and CI/CD pipeline generation — now runs on Opus 5, at the same price and with the same 1M-token context window. Organisations that customised their model catalog keep their pinned models; the built-in Expert entry upgrades automatically.

  ## Application images now build to your private Ankra registry

  Application CI/CD no longer publishes to GitHub Container Registry. When Applications is enabled, Ankra provisions a private project for your organisation in its own registry, together with the GitHub Actions credentials and the Kubernetes pull secret each cluster needs. The generated pipeline builds your source, scans the image, and pushes it to that private registry; the generated manifests already reference the image and its pull secret, so a merged pull request flows straight through to a running workload. The Ankra GitHub App now requests the **Secrets** permission to install that registry login, replacing the old GHCR make-public flow.

  [Applications →](/concepts/applications)

  ## AI Insights gets out of the way when your cluster is healthy

  The cluster AI Insights page no longer fills the screen with empty charts and zeroed counters when there is nothing wrong. A healthy cluster now shows a single compact "All quiet" summary confirming that monitoring is active, with one-click access to the resolved-fault history and to alert creation. The full analytics dashboard returns automatically the moment new activity appears — and the Faults tab no longer suggests your filters are hiding results when the cluster is simply healthy.

  ## Fleet overview: every Ankra-created cluster on the globe, plus a new fleet world

  The dashboard's fleet globe now places every cluster Ankra created for you — self-managed (Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway) and managed Kubernetes (DOKS, UKS, GKE, AKS, EKS, OVHcloud MKS, Kapsule) alike. When a cluster's nodes don't carry cloud topology labels (common on k3s and fresh clusters), the platform falls back to the region you picked at create time, so "not on the globe" is now reserved for genuinely unlocatable clusters. Proxmox and Morpheus clusters keep resolving through agent GeoIP.

  Next to the globe, the fleet overview gains a **fleet world**: an isometric 3D view where every cluster is a tower — height tracks node count, colour and glow track live status — so the whole fleet is readable at a glance, including clusters with no geolocation. Click a tower to jump into the cluster. The section layout was also rebalanced so the globe, fleet world, vital signs, utilisation, and security posture fill the page consistently.

  ## DigitalOcean clusters: reliable DNS and LoadBalancers that just work

  DigitalOcean's default DNS resolvers are flaky enough to intermittently break name resolution on nodes and inside pods. Ankra-provisioned DigitalOcean clusters now pin node DNS to Cloudflare (`1.1.1.1` / `1.0.0.1`) with a self-healing setup that re-applies within a minute if anything reverts — on new clusters at provision time, and on existing clusters automatically through the platform's drift detection.

  LoadBalancers on private-node DigitalOcean clusters also work out of the box now: the DigitalOcean cloud controller ships at v0.1.68+ (private-IP-only droplet support), is wired with the cluster's VPC UUID automatically (no more 422 "target droplets don't belong to the same VPC"), and the bundled Traefik ingress carries the `REGIONAL` load-balancer type its Service needs on private-only topologies. Existing clusters converge without any operator action.

  ## Chat turns survive disconnects

  An AI chat answer no longer depends on your browser staying connected. Every interactive turn is now written to a durable server-side event log as it streams, and the turn keeps running even if your tab closes, your network blips, or the platform restarts mid-deploy — tool calls finish, the answer completes, and nothing is lost. A new resume endpoint (`GET /chat/conversations/{conversation_id}/events`) replays the missed frames from where you left off, with live tailing and `Last-Event-ID` support. Provider hiccups were already covered by automatic failover; now the conversation itself is just as durable.

  ## Proxmox host-spread clusters now provision across nodes

  Control planes and workers placed on different Proxmox hosts previously stalled at the first cross-host node - the private SDN network is node-local, so the bastion had no path to a VM on another host. When a Proxmox VE credential carries Tailscale/Headscale settings, every VM now joins the tailnet at create time (through the Proxmox guest agent, before it has any other network path), and Ankra uses that tailnet address for SSH, kubeadm join, etcd peering, and haproxy upstreams. Enabling this requires the credential's Proxmox API token to hold `VM.GuestAgent.Unrestricted`, in addition to the `VM.GuestAgent.Audit` privilege address discovery already needs.

  [Proxmox VE credentials →](/platform/credentials/proxmox#tailscale-and-headscale-optional)

  ## Stack Profiles now show who you can trust

  Saving a stack as a profile now carries its existing description into a cleaner, modern save flow. Categories are searchable and reusable, tags are suggested as interactive chips, and you can choose whether the profile stays private to your organisation, becomes public, or is shared with specific organisation slugs.

  Profile cards and details now show the publisher's organisation name, logo, and verified status. Verified Ankra profiles appear first, so official profiles are easy to identify before you use them. Organisation admins can upload or replace their publisher logo from organisation settings.

  [Stack Profiles →](/concepts/stack-profiles)

  ## Profile capture understands every secret path you can declare

  Saving or publishing a stack profile no longer fails when a secret sits inside a YAML list — think fluent-bit's `config.pipeline.outputs[0].http_passwd` — or when an encrypted path is declared by its SOPS leaf key alone (`api-key`), the same shorthand `ankra cluster encrypt` uses. Both spellings now redact cleanly into required secret parameters. Values that are runtime environment references like `${OPENSEARCH_PASSWORD}` are no longer mistaken for plaintext secrets, so stacks that already inject credentials from Kubernetes Secrets capture without forcing a bogus secret parameter.

  [Stack Profiles →](/concepts/stack-profiles)

  ## Breadcrumbs everywhere you are

  Every page in the portal now carries a breadcrumb trail derived live from where you are — `Home / Clusters / prod-eu / Stacks / loki` instead of guessing your way back with the browser button. Dynamic segments show real names, not identifiers: the cluster crumb reads the cluster's name, operations show their display name, stack profiles and AI agents theirs. Each crumb that corresponds to a real page is clickable (the cluster crumb jumps to its overview), structural URL noise is hidden, and the trail stays out of the way on phones where the back button already does the job.

  ## Organisation menu goes straight to your organisation

  **Organisation** in the profile menu (and `/organisation`) now lands directly on your current organisation's overview instead of a list. Switching moved closer to hand: a **Switch organisation** submenu in the profile menu lists all your organisations with your current one marked — one click to switch, plus shortcuts to pending invites, the full organisation list, and creating a new organisation. The full list with per-organisation switching lives on **All organisations**.

  [Organisations →](/concepts/organisations)

  ## Your AI team, preloaded

  Every organisation now starts with a five-agent **AI team** — AI Team Lead, Developer, Database Admin, SRE, and DevOps — waiting under **AI → Agents**. Each one is chattable directly: open an agent and the conversation carries its persona, so the SRE talks evidence and the Database Admin checks backups first. Creating your own agent is now an **AI-guided interview** — pick a role, shuffle a name, choose focus areas and guardrails, and the wizard writes the persona for you (the classic form is one click away). Defaults are safe by construction: propose-only autonomy, hard budgets, and nothing runs until you ask.

  [AI Agents →](/platform/ai-agents)

  ## Demos now run real applications — env vars, secrets, and a throwaway database

  Demos used to run the container image bare, so anything needing configuration crash-looped on boot. Now every application carries **demo environment defaults** (the gear on the Demos tab) that all lanes inherit — manual launches, `deploy_pr_demo`, and automatic PR previews — with **per-launch overrides** in the launch dialog. Values marked secret ride Vault-backed secret slots and reach the demo as a Kubernetes Secret; plaintext never persists. Need a database? Toggle **Attach a throwaway Postgres** and an ephemeral instance spins up inside the demo namespace with a random per-demo password, wiped with the demo — your env values reference `${{ ankra.demo_database.* }}` placeholders, so any codebase's configuration naming just works.

  [Preview demos →](/concepts/applications#environment-variables-and-a-throwaway-database)

  ## Application demos get a shareable URL

  Deploy a throwaway demo of an application's pull request or branch build and Ankra now hands back a **public preview URL** automatically - no manual ingress or DNS wiring. When your organisation has a demo base domain configured, the demo is served under it; otherwise, if the staging cluster has an active Ankra DNS zone, it gets a `*.ankra.cc` host that resolves on that cluster. Without either, the demo still deploys and stays reachable in-cluster. The same URL is returned everywhere you deploy a demo - the portal Demos tab, `ankra application demo deploy`, the `deploy_pr_demo` AI/MCP tool, and the automatic preview posted on a connected application's pull requests.

  [Preview demos →](/concepts/applications#preview-demos)

  ## A home for Ankra

  Pick a **home channel** and Ankra starts the conversation on its own. When something important happens - a failed deployment, an agent going offline, a new severe CVE - and no routing rule already handles it, Ankra posts to your home Slack channel. Set it under **Organisation Settings → AI → Workspaces** ("Ankra's home"); only critical and warning events reach it, and it never double-notifies what a routing rule already sent.

  [Home channel →](/guides/webhooks#home-channel)

  ## Managed Kubernetes and three more clouds

  Ankra now provisions and operates **provider-managed Kubernetes** - DOKS, UKS, GKE, OVHcloud MKS, AKS, and EKS - with node pools, autoscaling (all but UKS), upgrades, and discovery/import of existing clusters. Self-managed provisioning also gained **DigitalOcean**, **Proxmox VE**, and **Morpheus** alongside Hetzner, OVH, and UpCloud.

  [Managed Kubernetes →](/guides/managed-kubernetes) · [DigitalOcean →](/guides/digitalocean-clusters) · [Proxmox VE →](/guides/proxmox-clusters) · [Morpheus →](/guides/morpheus-clusters)

  ## Proxmox VE zero-config bootstrap

  Saving a Proxmox VE credential now sets up everything a cluster needs on an empty host: VM storage, the management bridge, a private NAT network (`ankra`, 10.20.0.0/16) with DHCP built on Proxmox SDN, and an Ubuntu 24.04 cloud-init template. Cluster VMs on the private network get their addresses from Proxmox IPAM automatically — no guest agent required in the image — and reach the internet through the host's public interface.

  [Proxmox VE →](/guides/proxmox-clusters)

  ## Tailscale for Proxmox VMs

  Attach a Tailscale/Headscale login server and a reusable auth key to a Proxmox VE credential, and every VM Ankra provisions with it installs Tailscale and joins your tailnet on first boot — each VM getting its own tailnet address, reachable across Proxmox hosts and from your own networks. You can add, change, or remove it on an existing credential without recreating it.

  [Proxmox VE →](/platform/credentials/proxmox)

  ## Cluster vulnerability scanning with Trivy

  Install the Trivy Operator add-on and Ankra reads its vulnerability reports into a dedicated **Security** console: severity breakdowns, a blast-radius-ranked priority queue, remediation campaigns, and a phased burn-down plan. The AI assistant can summarise and prioritise CVEs with the same data.

  [Cluster Security →](/guides/cluster-security)

  ## Cluster compliance is now actionable

  Selecting a cluster from **Security → Compliance** now opens a full cluster Security page instead of a narrow drawer. The Compliance tab shows failed and passed CIS, NSA/CISA, and Pod Security Standards checks, configuration-audit hotspots, affected counts, remediation guidance, and filters for the exact result you need.

  Every failed check has **Fix with AI**. The cluster-scoped agent receives the benchmark and remediation context, can inspect the affected Kubernetes resources, apply safe fixes with the usual confirmation guardrails, and verify the result.

  [Cluster compliance →](/guides/cluster-security#cluster-security-view)

  ## Team roles, cluster groups, and scoped access

  Access is now governed by **roles** you assign at a scope - the whole organisation, a single cluster, or a **cluster group** (static or label-selected). A role can bundle Kubernetes access that Ankra provisions on every cluster in scope, and every change is captured in an organisation audit log.

  [Roles & Access →](/guides/roles-and-access)

  ## Pipeline agents

  Build CI-native infrastructure agents from plain pipeline jobs and the Ankra CLI - PR review, deploy watching, and scheduled health checks - with no framework or orchestration layer.

  [Build pipeline agents →](/guides/pipeline-agents)

  ## Proxmox automatic setup supports DHCP and provider-managed interfaces

  The "Set up storage and network automatically" bootstrap now works on dedicated servers where the management interface is configured via DHCP or marked `manual` (the provider assigns the IP outside Proxmox's network config, common on Scaleway and similar bare-metal hosts). Previously only statically addressed interfaces were accepted.

  [Proxmox VE credentials →](/platform/credentials/proxmox)

  ## Restart a node or resize the bastion, from the UI, CLI, or chat

  The **Nodes** tab now has a **Restart** action for every control plane node, worker, and bastion/gateway (Hetzner, OVH, UpCloud, DigitalOcean, Proxmox), and a **Resize** action for the bastion/gateway (those five plus HPE Morpheus). Both run as tracked operations, and the node table now shows each node's live status straight from the cloud provider's API so a crashed or externally-stopped VM is visible before you act on it. The same actions are available from `ankra cluster <provider> nodes restart` / `bastion resize`, and by asking the Ankra AI assistant - in the portal, Slack, or Teams - to restart a node or the bastion by name.

  [Nodes Settings →](/platform/cluster-settings#nodes-settings) · [Restarting a Node →](/guides/hetzner-clusters#restarting-a-node)

  ## Managed networking stack on Proxmox VE and HPE Morpheus

  Proxmox VE and HPE Morpheus clusters now ship the same Ankra-managed networking stack as every other self-managed provider: Traefik and cert-manager are installed as Ankra stacks after bootstrap (visible and manageable in the platform) instead of relying on the k3s-bundled Traefik. The **Include Networking Stack** option in the create wizard is on by default; ingress is exposed through the built-in k3s service load balancer on node IPs, since these providers have no cloud load-balancer API. Storage still comes from add-ons such as Longhorn — install one from the add-on catalog for persistent volumes.

  Both providers also reached full surface parity: `ankra cluster proxmox` and `ankra cluster morpheus` CLI commands (create plus catalogs for hosts, storages, bridges, templates, and plans, with stop/start and the generic scale, upgrade, node-group, and SSH-key verbs), and the Ankra AI assistant can now create Proxmox VE and HPE Morpheus clusters in chat with the same guided, confirmation-gated flow as the other providers.

  ## Lifecycle parity across self-managed clouds

  The canonical self-managed provider set is now **Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, Proxmox VE, and HPE Morpheus**. All seven can be stopped and started from the portal, CLI, API, and Ankra's AI or any MCP client. The new `ankra cluster scaleway stop|start` commands close the remaining CLI gap for Scaleway.

  ## Stack draft editor reliability

  Three draft-editor bugs are fixed: drafts no longer disappear after a few minutes of editing (live edits now keep the draft's idle timer fresh, so the cleanup job only removes genuinely abandoned drafts), saving no longer fails with a spurious "modified by another request" conflict (a background sync task stopped invalidating the editor's save token), and renaming a stack inside the editor no longer detaches the draft from its deployed stack - the draft stays linked under the stack's current name and the rename is applied when you deploy.

  ## Managed Kubernetes catches up on day-2

  Managed clusters closed three long-standing gaps. **AKS clusters can now be stopped and started** from the portal, CLI (`ankra cluster managed stop|start`), API, and Ankra's AI or any MCP client - Azure deallocates the compute while every setting is preserved, and Ankra advertises the capability per provider so each surface only offers it where it works. **Node pool machine sizes can finally be changed**: since no provider allows in-place size changes, Ankra performs a blue/green replacement - a new pool with the new size is created and brought to ready before the old one is deleted, with labels, taints, and autoscaling carried over. And the **CLI reached managed parity**: node pools take autoscaling bounds at create and via the new `node-pool update` command, and pool counts and autoscaling can be changed without touching the portal.

  [Managed Kubernetes reference →](/reference/managed-kubernetes)

  ## The AI Assistant runs your clusters' day-2 operations

  The AI Assistant (and every MCP client) can now do far more than create clusters. Seventeen new tools cover the full day-2 surface for Ankra-provisioned clusters - **scale workers and node groups, add, update, and delete node groups, change the control plane, stop, start, upgrade, and even deprovision a cluster** (with a type-the-name-to-confirm guardrail) - plus a **managed Kubernetes family**: create and operate **EKS, AKS, GKE, DOKS, UKS, OVHcloud MKS, and Scaleway Kapsule** clusters and their node pools from chat. DigitalOcean cluster creation from chat is also live. Every mutating tool goes through the same confirmation card and drift-checked approval flow as before.

  [MCP Tool Reference →](/platform/mcp-tools)

  ## Start a stopped Hetzner cluster

  Hetzner clusters can now be **started** again after a stop, like every other self-managed provider - previously only stop was available, and bringing a cluster back meant adding a fresh node group. Stopping releases the Hetzner compute while keeping the cluster's configuration, stacks, and credentials; starting re-provisions the saved topology and reconciles the cluster back online. Also fixed: managed **GKE**, **DigitalOcean (DOKS)**, and **OVHcloud MKS** clusters now correctly advertise node-pool autoscaling support in the create wizard.

  The portal now derives **Stop** and **Start** from one canonical self-managed provider set, so Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, Proxmox VE, and HPE Morpheus stay in sync. Scaleway also gains `ankra cluster scaleway stop|start`, closing the remaining CLI lifecycle gap.

  [Stopping and Starting →](/guides/hetzner-clusters#stopping-and-starting-a-cluster)

  ## The full platform lifecycle over MCP and chat

  The Ankra MCP server and the AI assistant now cover the core lifecycle of **stacks, add-ons, applications, and credentials** - around 35 new tools. From Cursor, Claude, in-product chat, or chat over Slack, Teams, and SCM comments (all backed by the same tool registry), you can list, inspect, create, update, redeploy, clone, and delete stacks; read and update add-on settings and values; run the application lifecycle end to end including deploys and workflow runs; and manage credentials - list and inspect them (secrets always redacted), delete unused ones, and plan and apply a GitHub credential rotation. Creating credentials stays deliberately off-limits to the AI: it would mean handing it the secret itself, which the platform refuses. Reads need `mcp:read`; mutations need `mcp:write` and stay confirmation-gated in chat. A new reference page lists every tool with its scope.

  Alongside, the CLI gained `ankra credentials proxmox` and `ankra credentials morpheus` command groups (list and create, including SSH keys), and `ankra application delete` and `ankra application make-public` now ask for confirmation before acting.

  [MCP Tool Reference →](/platform/mcp-tools) · [MCP Server →](/platform/mcp-server)

  ## The sandbox demo is now fully editable

  The seeded "sandbox-demo" cluster is no longer read-only. You can now add, configure, move, clone, and delete stacks, add-ons, and manifests, work with drafts, and hit Deploy - the full stack-editing experience, before importing a cluster of your own. Deploys in the sandbox are simulated: they complete instantly and mark resources green without running anything on real infrastructure. Cluster-level operations that need a live agent (archive, agent tokens, add-on sync) remain unavailable there.

  [Playground & sandbox →](/guides/cluster-sandbox)

  ## Custom DNS records under your organisation's ankra.cc subdomain

  Organisation admins can now manage their own **CNAME, A, and TXT records** under their organisation's delegated `ankra.cc` subdomain - handy for aliasing an add-on's auto-generated hostname to something memorable. The **DNS records** console (under **Organisation Settings**) shows your zone and its status, a searchable, type-filterable records table, and lets you add, **edit in place**, and delete records with a chosen **TTL**. New and edited records provision asynchronously and show their state (pending, active, or failed, with the reason) in the list.

  [DNS Records →](/platform/organisation-settings#dns-records)

  ## Approving a plan on the AI board now starts the work

  Fixed: approving an agent's plan on an AI board ticket left the ticket waiting indefinitely - the assigned agent was never re-dispatched, and nothing happened until someone manually moved the ticket to "Executing". A human approval now releases the ticket to **Executing** (and "Request changes" sends it back to **Planning**), and the dispatcher picks it up on the next cycle instead of waiting out its re-dispatch backoff. Assigning a ticket to an agent right after approving its plan now behaves the same way.

  ## Reply to a board ticket and the agent replies back

  The AI board is now conversational. Commenting on a ticket assigned to an AI agent - from the ticket page, or by replying in its mirrored Slack or Microsoft Teams thread - re-dispatches the agent, which reads your comment and answers on the timeline. This works even while the ticket sits in **Awaiting review** or **Awaiting approval** (exactly where questions about a plan come up - previously a comment there was never seen), and the agent is instructed to respond and revise only, never to start executing before the plan is approved. Slack and Teams replies now also appear in the agent's work brief. Closing or cancelling a ticket now cancels any agent runs still working it, so nothing keeps burning tokens on dead work.

  ## Inspect and cancel AI agent runs - from MCP, the CLI, and the API

  Every dispatched agent run is now visible and controllable outside the portal. Three new MCP tools - `list_agent_runs`, `get_agent_run` (optionally with the session transcript tail), and `cancel_agent_run` (organisation admins only) - let the AI assistant and any MCP client watch and stop the AI team's work. The same surface ships in the CLI as the new **`ankra agents`** family (`runs`, `run`, `transcript`, `cancel`) and as PAT-authenticated API routes under `/api/v1/org/ai-agent-runs`. Cancelling a run flips its session and the platform interrupts the in-flight turn within seconds, without pausing the agent itself - and run transcripts are now readable by any organisation member through the run, not just the agent's creator.

  [MCP Tool Reference →](/platform/mcp-tools)

  ## Archived clusters are off the fleet map

  Fixed: archiving a cluster removed it from the cluster list but left its pin on the Dashboard's world map and, when it had no resolvable region, in the "not on the globe" tray. Archived clusters are now excluded from the map entirely - the same treatment they already get in the health summary - so the globe shows only the fleet you still run.

  [Dashboard →](/platform/dashboard)
</Update>

<Update label="June 2026">
  # A Go-Native Agent, Fleet Dashboard, Cloud Cost, kubectl Access, Stack Profiles, Applications, Support, and a Provider-Agnostic CLI

  June was a big month across the whole platform: a rebuilt cluster agent, a new fleet dashboard with cost visibility, scoped cluster access, reusable stack templates, application delivery, in-product support, and a CLI that caught up with the web UI.

  ## A faster, leaner cluster agent, rebuilt in Go

  The [Ankra Agent](/concepts/cluster-agent) has been rebuilt as a single, statically compiled Go binary and is now the production agent on the new `2.0.x` version track.

  It is a drop-in replacement: the same Helm chart, values, install command, NATS connectivity, and behaviour as before - resource streaming, log streaming, Helm management, add-on deployment, and `kubectl` proxying all work exactly the same. Nothing changes in how you install or operate it.

  What you get for free:

  * **A smaller footprint.** The default memory limit drops from `1536Mi` to `512Mi` and the request from `512Mi` to `256Mi`, alongside lower CPU usage and faster startup.
  * **Automatic rollout.** Existing clusters are upgraded to the new agent automatically by the platform, a few clusters at a time - no action required. You can still upgrade on demand from **Cluster Settings → Upgrade Agent**.
  * **Identical operations.** Same outbound-only connectivity, same `/livez`, `/readyz`, and `/metrics` endpoints on port `8080`, and the same `extra_env` tuning knobs.

  See the [Ankra Agent](/concepts/cluster-agent) docs for the full configuration reference.

  ## A fleet dashboard with a world map

  The organisation [Dashboard](/platform/dashboard) now opens on a world map of every cluster, alongside health and cost rollups. Clusters are placed by cloud region, or by the agent's public egress IP when [public IP reporting](/concepts/cluster-agent) is enabled.

  ## Cloud cost estimates

  [Cloud Cost](/platform/cloud-cost) estimates per-cluster and fleet-wide spend from your live node and volume inventory plus cloud pricing - broken down by compute, storage, network, and per-namespace allocation. Connect an [AWS or GCP credential](/platform/credentials) to get started.

  ## Scoped kubectl access through Ankra

  Grant teammates SSO-backed, scoped Kubernetes access with [Cluster Access](/guides/cluster-access), then reach the cluster with your own `kubectl` through Ankra's [API proxy](/guides/kubeconfig) - short-lived credentials, no inbound network access, works with private clusters.

  ## Reusable Stack Profiles

  Capture a working stack as a versioned, parameterised template with [Stack Profiles](/concepts/stack-profiles), then instantiate it on any cluster - with diffing, update tracking, and IaC export.

  ## Applications: from repo to running workload

  [Applications](/concepts/applications) connect an app's Git repository, generate the Dockerfile, Helm chart, and CI/CD via a pull request, then build and deploy the result as a stack.

  ## In-product support

  Raise and track [support tickets](/platform/support) without leaving Ankra - with AI triage, attachments, and threaded replies - and keep an eye on everything that needs you in your new [Activity & Inbox](/platform/activity-inbox).

  ## More reliable apply for large manifest stacks

  Applying a stack with many manifests at once - and reconciling stacks on clusters with lots of Custom Resource Definitions - is now far more reliable. Manifests are given more time to apply before they're considered stalled, and the agent no longer re-runs expensive API discovery on every single apply, so a large stack reconciles cleanly instead of failing partway through with a timeout.

  The change applies automatically: existing stacks pick it up on their next deploy with no action required. Any per-manifest timeout you set previously is honoured as long as it's at least the new, more generous default, and custom timeouts above the default are kept as-is.

  [Manifests →](/concepts/manifests)

  ## The Ankra CLI caught up with the platform

  Most of what you can do to a cluster in the web UI is now scriptable from the [Ankra CLI](/integrations/ankra-cli):

  * **Provider-agnostic cluster verbs** - `ankra cluster upgrade | scale | node-group | deprovision | k3s-versions` detect Hetzner, OVH, or UpCloud automatically from the cluster.
  * **Cluster access and kubectl** - grant scoped RBAC with `ankra cluster access` and write short-lived, SSO-backed `ankra-*` kubeconfig contexts with `ankra cluster kubeconfig add`.
  * **Cluster metrics** - run PromQL against a cluster's Prometheus with `ankra cluster metrics query` and `query-range`.
  * **Full OVH management** - stop/start, SSH access info, control-plane and node-group changes, region discovery, and node labels/taints.
  * **Config safety** - gate changes before they go live with `ankra cluster validate` (structure, chart existence, plaintext-secret detection) and stage them with `ankra cluster draft`.
  * **Live operations** - follow a deploy or reconcile with `ankra get operations --watch` and `ankra get jobs`.
  * **Self-update** - `ankra upgrade` updates or rolls back the CLI in place with checksum verification.

  See the [CLI Changelog](/integrations/ankra-cli-changelog) for the full, versioned detail.

  ## Removed: Add-on Subscriptions

  Add-on subscriptions have been retired. Add-ons are now managed directly on the cluster or stack that uses them - through your GitOps repository, `ankra cluster apply`, or the cluster editor - which keeps a single, declarative source of truth for what runs where, rather than a separate subscription that has to be kept in sync.

  The legacy add-on subscription endpoints now return `410 Gone`. If you relied on subscriptions, move those add-ons into the relevant stack definition; existing deployed add-ons are unaffected.
</Update>

<Update label="May 2026">
  # Editable Stopped-Cluster Topology, Self-Healing Hetzner Updates, Live Operations, and a Big CLI Wave

  May focused on cloud-cluster reliability - editable topology while stopped, self-healing Hetzner updates, cleaner offline reconciliation, and a live-updating operations page - alongside a large batch of CLI commands for variables, secrets, dependencies, and in-place upgrades.

  ## Edit cluster topology while stopped

  Stopped cloud clusters (Hetzner, OVH, UpCloud) now expose the full Nodes settings tab. While the cluster stays offline you can:

  * Switch the control plane between **1** and **3** controllers (only 1 or 3 - etcd needs an odd number of voting members to form quorum).
  * Change the **controller instance type**. Because the cluster is recreated fresh on next start, downgrades are safe here - there is no live disk resize.
  * Add and remove **node groups**, scale them, change their worker instance type, and edit labels and taints.

  Changes are saved against the stopped topology and applied the next time you start the cluster from the General settings tab. Topology edits now also serialize against each other and against start/stop, so two operators clicking at the same time can't end up with a half-applied change.

  [Cluster Settings →](/platform/cluster-settings#nodes-settings)

  ## Hetzner: Resilient Cluster Updates

  Hetzner cluster update jobs are now self-healing. The reconciler persists install-time addresses (`bind-address`, `advertise-address`, `node-ip`) into `/etc/rancher/k3s/config.yaml` so k3s always restarts bound to the correct private IP, and version bumps now swap the k3s binary in place instead of re-running the upstream installer - which previously rewrote the systemd unit and wiped `K3S_URL` / `K3S_TOKEN` on joined nodes. Clusters that had drifted into authentication-error loops after an upgrade recover on the next reconcile.

  ## Offline Cloud Clusters: Cleaner Reconciliation

  When a Hetzner, OVH, or UpCloud cluster is in the **stopped** state (after Delete Kubernetes), the reconciler now only acts on provider-owned resources - servers, networks, SSH keys, the k8s control plane. Addons, manifests, and other in-cluster resources are held until the cluster is back online, so you no longer see repeated failures for resources that have no API server to talk to.

  [Hetzner Cluster Lifecycle →](/guides/hetzner-clusters#cluster-lifecycle)

  ## Operations Page: Live Updates

  The cluster **Operations** page now refreshes itself in the background. Newly-triggered operations appear without a manual reload, and the status, duration, and finish time of in-flight operations update as they progress. The page polls faster while something is actively running and slows down once everything is idle, so you get near-real-time feedback while a deploy is happening without hammering the backend when nothing is going on.

  ## The Ankra CLI: variables, secrets, dependencies, and in-place upgrades

  A large batch of stack-management commands landed in the [Ankra CLI](/integrations/ankra-cli) this month:

  * **Variables at every scope** - `ankra org variables`, `ankra cluster variables`, and `ankra cluster stacks variables` give full CRUD over the values substituted into manifests and addon values (resolution is stack > cluster > organisation).
  * **Live-cluster SOPS** - `ankra cluster encrypt` / `decrypt` run directly against a running cluster's manifests and addon values, with no local `cluster.yaml` needed.
  * **Dependencies, reads, and deletes** - edit deployment-ordering parents (`--add-parent` / `--remove-parent` / `--set-parent`), print current addon values and manifest YAML, and delete a manifest from its stack.
  * **Surgical upgrades** - `ankra cluster addons upgrade` and `manifests upgrade` change a single Helm value or manifest field in place with helm-style `--set` (field selectors like `containers[name=app]`), `--from-file`, and `--dry-run`.
  * **Any organisation** - a global `--org` flag (and `ANKRA_ORG`) runs a command against any organisation you belong to without switching your selection.
  * **Curated AI skills** - `ankra skills install` drops Ankra's Agent Skills into Cursor or Claude Code (`--editor claude-code`), embedded in the binary so it works offline.

  See the [CLI Changelog](/integrations/ankra-cli-changelog) for the full, versioned detail.
</Update>

<Update label="April 2026">
  # Cluster Lifecycle: Delete Kubernetes & Scale Back Up, Multi-Stack Cloning

  ## Delete Kubernetes & Scale Back Up

  Cloud provider clusters (Hetzner, OVH, UpCloud) now support a **Delete Kubernetes** action that destroys all cloud infrastructure - servers, networks, SSH keys - while keeping the cluster registered in Ankra. The cluster moves to a stopped state and you stop incurring infrastructure charges.

  When you're ready to bring the cluster back, simply **add a node group**. Ankra automatically restores the full control plane infrastructure (bastion, network, SSH keys, control plane servers), installs Kubernetes, creates your new worker nodes, and begins reconciling stacks and addons. The restored cluster gets entirely fresh infrastructure with new servers and IPs.

  Previously existing worker node groups are not restored - the node group you add is the only worker pool. Add additional node groups as needed after the cluster is online.

  The **Terminate Cluster** action permanently deletes all infrastructure and removes the cluster from Ankra entirely. This is irreversible.

  Both actions are available in cluster **Settings → Danger Zone**.

  [Hetzner Cluster Lifecycle →](/guides/hetzner-clusters#cluster-lifecycle) | [Cluster Settings →](/platform/cluster-settings#danger-zone)

  ## Clone Multiple Stacks to Another Cluster

  You can now select multiple stacks and clone them all to another cluster in a single operation. On the **Stacks** page, click any stack card's avatar to start selecting, or click the **Clone Stacks** button next to the search bar to select all. A floating action bar appears showing the selection count with a **Clone to Cluster** button.

  The clone dialog shows a live progress bar as each stack is cloned sequentially. Name conflicts are auto-resolved with suffixes. After completion, click **Go to Target Cluster** to review the drafts. Cross-organisation cloning is fully supported.

  This is useful for replicating an entire cluster's stack configuration to a new environment, promoting multiple stacks from staging to production, or setting up disaster recovery clusters.

  [Clone Stacks Guide →](/guides/clone-stack#clone-multiple-stacks-at-once)
</Update>

<Update label="March 2026">
  # Automatic Hetzner Cloud Integration, Ingress & GitOps, Node Groups, UpCloud & OVH Cloud, AI Insights Overhaul, Kubernetes Node Cordon & Drain, Light Mode, Billing & Platform Performance

  ## Kubernetes Node Cordon, Uncordon & Drain

  The **Kubernetes → Nodes** view now supports full node lifecycle management for workload migration scenarios. Cordon, uncordon, and drain nodes from both the node detail page and the node list with multi-select bulk actions.

  **Cordon & Uncordon**: Mark nodes as unschedulable or restore scheduling. Available as a single-node action in the node detail header or as a bulk action by selecting multiple nodes in the list. Cordoned nodes display a "SchedulingDisabled" label.

  **Drain**: Cordon a node and evict all running pods in one operation - equivalent to `kubectl drain --ignore-daemonsets --delete-emptydir-data`. Real-time progress tracking shows each phase: cordoning, fetching pods, and evicting pods. Available for single nodes and in bulk.

  **Workload Migration**: Use cordon and drain together to safely move workloads between node groups. Cordon old nodes to stop new scheduling, drain them to evict existing pods, and let Kubernetes reschedule onto your new node group.

  [Kubernetes Nodes →](/platform/kubernetes-workloads#nodes)

  Hetzner clusters now automatically deploy the Cloud Controller Manager and CSI driver during provisioning - no manual setup. An optional ingress stack adds ingress-nginx, cert-manager, and Let's Encrypt. GitOps integration pushes cluster state to GitHub. Node groups bring per-group instance types, scaling, labels, and taints. UpCloud and OVH Cloud support across the platform. AI Insights gets a dedicated detail page with analytics dashboard, adaptive scanning, and platform-aware remediation. The Command Palette now navigates directly to every Kubernetes resource type, and the Log Viewer is rebuilt for large clusters.

  ## Hetzner: Automatic CCM & CSI Provisioning

  Hetzner clusters now automatically deploy a complete **hcloud stack** during provisioning: a dedicated `hcloud` namespace, API token secret, the [hcloud-cloud-controller-manager](https://github.com/hetznercloud/hcloud-cloud-controller-manager) (3 replicas, PDB), and the [hcloud-csi](https://github.com/hetznercloud/csi-driver) driver (3 replicas, PDB, `hcloud-volumes` default StorageClass). Previously this required manual setup via the AI Assistant or Stack Builder. Now it's fully automated using the same Hetzner API credential used to create the cluster.

  ## Hetzner: Optional Ingress Stack

  Enable `include_ingress` during cluster creation to deploy ingress-nginx with a Hetzner Load Balancer, cert-manager, and a pre-configured `letsencrypt-prod` ClusterIssuer for automatic TLS. Toggle in the UI wizard or pass `"include_ingress": true` in the API.

  ## Hetzner: GitOps Integration

  Push cluster stack state to a GitHub repository on creation. Provide `gitops_credential_name`, `gitops_repository`, and `gitops_branch` to enable version-controlled infrastructure for Hetzner clusters.

  ## Node Groups Per-Group Instance Types, Labels & Taints

  A new **Nodes** tab in cluster settings lets you manage node groups for Hetzner, OVH, and UpCloud clusters. Each node group has its own instance type, node count, Kubernetes labels, and taints giving you fine-grained control over your worker fleet.

  **Full Lifecycle Management**: Add, scale (0–100 nodes), upgrade instance type, edit labels/taints, and delete node groups from the UI, CLI, or API. Node groups can be defined at cluster creation time in the wizard or API.

  **Instance Type Upgrades**: Upgrade any group to a larger instance type. Each node is powered off, resized, and powered back on. Downgrades are not possible due to Hetzner disk resize limitations. To use a smaller type, create a new node group and delete the old one. The UI shows a confirmation dialog warning that upgrades are irreversible.

  **Labels & Taints**: Attach Kubernetes node labels and taints to node groups. Labels and taints are applied to all nodes in the group and can be edited at any time. Useful for workload scheduling with nodeSelectors, affinities, and tolerations.

  **No Online Requirement**: Node group operations work regardless of cluster state. No need to wait for the cluster to be online.

  **CLI Support**: New `ankra cluster {hetzner|ovh|upcloud} node-group` commands for list, add, scale, upgrade, and delete.

  [Hetzner Node Groups →](/guides/hetzner-clusters#node-groups) | [Cluster Settings →](/platform/cluster-settings#nodes-settings)

  ## Hetzner: Multi-SSH-Key Support & Access Settings

  Attach multiple SSH key credentials to Hetzner clusters at creation or post-creation. A new **Access** tab in cluster settings provides copy-pasteable SSH jump and kubectl port-forward commands, a network topology view, and SSH key management.

  [Hetzner Clusters Guide →](/guides/hetzner-clusters)

  ## UpCloud Clusters

  Provision and manage Kubernetes clusters on UpCloud with managed SDN Routers and NAT Gateways for private networking.

  **Full Lifecycle Management**: Create, scale, upgrade, and deprovision UpCloud clusters through the UI, CLI, or API. Clusters deploy with a router, private network, NAT gateway, bastion server, and k3s distribution.

  **Zone Support**: Deploy to any UpCloud zone including Helsinki (Finland), Frankfurt (Germany), Chicago (United States), Amsterdam (Netherlands), London (United Kingdom), Singapore, Sydney (Australia), and Warsaw (Poland).

  **Worker Scaling**: Scale worker nodes between 1 and 10. Scaling up provisions new instances and installs Kubernetes. Scaling down removes workers from the highest index.

  **Kubernetes Upgrades**: Upgrade k3s versions across all nodes with one command. Control planes are upgraded first, then workers.

  **DAG-Based Deprovisioning**: Cluster deletion creates a tracked operation with individual delete jobs that run in dependency order. Multiple server deletions run in parallel, reducing deprovision time.

  [UpCloud Clusters Guide →](/guides/upcloud-clusters)

  ## UpCloud API Credentials

  Securely store UpCloud API credentials (API token) with automatic validation against the UpCloud API.

  **Credential Validation**: Credentials are validated on creation by calling the UpCloud API. Clear error messages for invalid tokens (401) and permission issues.

  **SSH Key Support**: Create and manage SSH key credentials for UpCloud cluster provisioning. Generate new keypairs or bring your own public key.

  [Credentials Guide →](/platform/credentials/upcloud)

  ## OVH Cloud Clusters

  Provision fully managed Kubernetes clusters on OVH Cloud with configurable control planes, workers, and networking.

  **Full Lifecycle Management**: Create, scale, upgrade, and deprovision OVH clusters through the UI, CLI, or API. Clusters deploy with a private network, gateway for SSH access, and k3s distribution.

  **Region Support**: Deploy to any OVH Cloud region including Gravelines (France), Strasbourg (France), Beauharnois (Canada), Warsaw (Poland), Frankfurt (Germany), London (UK), Singapore, and Sydney.

  **Worker Scaling**: Scale worker nodes between 1 and 10. Scaling up provisions new instances and installs Kubernetes. Scaling down removes workers from the highest index.

  **Kubernetes Upgrades**: Upgrade k3s versions across all nodes with one command. Control planes are upgraded first, then workers.

  [OVH Clusters Guide →](/guides/ovh-clusters)

  ## OVH API Credentials

  Securely store OVH Cloud API credentials (application key, application secret, consumer key, and project ID) with automatic validation against the OVH API.

  **Credential Validation**: Credentials are validated on creation by calling the OVH API. Clear error messages for permission issues (403) and invalid credentials (401).

  **SSH Key Support**: Create and manage SSH key credentials for OVH cluster provisioning. Generate new keypairs or bring your own public key.

  [Credentials Guide →](/platform/credentials/ovh)

  ## AI Insights Overhaul

  A major upgrade to Proactive AI Insights with a dedicated detail page, analytics dashboard, advanced filtering, adaptive scanning, and platform-aware remediation.

  **Insight Detail Page**: Each insight now has a full-page view with four tabs Overview (root cause analysis with summary, severity, confidence score, affected resources, and conversation starters for AI chat), Remediation (copy-pasteable commands and platform-aware actions), Health (snapshot and anomaly data at time of detection), and History (previous resolutions with effectiveness tracking). Navigate to related Kubernetes resources directly from the affected resources list.

  **Analytics Dashboard**: New analytics tab with configurable time ranges (7, 30, or 90 days). Tracks mean time to resolution (MTTR), shows severity trends by day, breaks down issues by namespace and category, and indicates whether cluster health is improving, degrading, or stable.

  **Dashboard View**: A new dashboard tab on the insights page with a severity donut chart, mini trend chart, and category breakdown at a glance.

  **Advanced Filtering**: Filter insights by namespace, category, and date range. Three view modes cards, compact list, and grouped (by category or namespace). Root cause summary shown inline on insight cards.

  **Related Insights**: Insights sharing the same namespace or category are linked on the detail page, helping you spot patterns across related issues.

  **Adaptive Scanning**: The maintenance scheduler now adapts scan frequency based on cluster health clusters with critical issues are scanned every 60 seconds, clusters with active issues every 3 minutes, and healthy clusters every 10 minutes.

  **Platform-Aware Remediation**: AI analysis now suggests platform-native actions (stack changes, add-on configuration, resource navigation) alongside kubectl commands. Remediation commands and platform actions are stored per-insight and displayed on the detail page.

  **Resolution Tracking**: Resolving an insight now captures resolution type, resolution context, and a health snapshot at resolution time. When an issue recurs, previous resolutions include effectiveness data so you can see if a past fix held.

  **RAG Learning Loop**: Marking an insight as "helpful" indexes its root cause analysis and recommendations for RAG, improving future AI analysis quality.

  **Keyboard Shortcuts**: Navigate and manage insights entirely from the keyboard `j`/`k` to navigate, `Enter` to open detail, `p` to quick peek, `a` to acknowledge, `r` to resolve, `d` to dismiss, `c` to ask AI, `/` to search, `1`–`4` to switch tabs, `v` to cycle view mode, and `?` for help.

  [AI Insights Docs →](/platform/ai-insights)

  ## CLI v0.2.0

  Helm management, Kubernetes resource access, direct cluster selection, and client hardening.

  * `ankra cluster helm releases` / `ankra cluster helm uninstall` - Manage Helm releases in the cluster
  * `ankra helm registries` / `ankra helm credentials` - Manage Helm registries and credentials
  * `ankra cluster pods` / `ankra cluster resources` / `ankra cluster logs` - Access Kubernetes resources and stream pod logs
  * `ankra cluster select <name>` - Select a cluster directly by name without the interactive picker
  * `ankra cluster info [name]` - Show cluster details (defaults to selected cluster; replaces `cluster get`)
  * HTTP client timeouts, response body limits, URL encoding, config file permission hardening

  [CLI Changelog →](/integrations/ankra-cli-changelog) | [Ankra CLI →](/integrations/ankra-cli)

  ## CLI v0.1.129

  Node group management commands and new UpCloud/OVH commands for cluster and credential management.

  * `ankra cluster <provider> node-group` - List, add, scale, upgrade, and delete node groups for Hetzner, OVH, and UpCloud
  * `ankra credentials upcloud` / `ankra cluster upcloud` - UpCloud credential and cluster management
  * `ankra credentials ovh` / `ankra cluster ovh` - OVH credential and cluster management

  [CLI Changelog →](/integrations/ankra-cli-changelog) | [Ankra CLI →](/integrations/ankra-cli)

  ## Node Group API Endpoints

  Available for all three cloud providers (Hetzner, OVH, UpCloud):

  | Endpoint                                                            | Method | Description           |
  | ------------------------------------------------------------------- | ------ | --------------------- |
  | `/api/v1/clusters/{provider}/{id}/node-groups`                      | GET    | List node groups      |
  | `/api/v1/clusters/{provider}/{id}/node-groups`                      | POST   | Add a node group      |
  | `/api/v1/clusters/{provider}/{id}/node-groups/{name}/scale`         | PUT    | Scale a node group    |
  | `/api/v1/clusters/{provider}/{id}/node-groups/{name}/instance-type` | PUT    | Upgrade instance type |
  | `/api/v1/clusters/{provider}/{id}/node-groups/{name}/labels`        | PUT    | Update labels         |
  | `/api/v1/clusters/{provider}/{id}/node-groups/{name}/taints`        | PUT    | Update taints         |
  | `/api/v1/clusters/{provider}/{id}/node-groups/{name}`               | DELETE | Delete a node group   |

  [Hetzner Node Groups →](/guides/hetzner-clusters#node-groups)

  ## UpCloud API Endpoints

  Full REST API coverage for UpCloud clusters and credentials:

  | Endpoint                                            | Method | Description                  |
  | --------------------------------------------------- | ------ | ---------------------------- |
  | `/api/v1/clusters/upcloud`                          | POST   | Create an UpCloud cluster    |
  | `/api/v1/clusters/upcloud/{id}`                     | DELETE | Deprovision a cluster        |
  | `/api/v1/clusters/upcloud/{id}/worker-count`        | GET    | Get worker count             |
  | `/api/v1/clusters/upcloud/{id}/scale-workers`       | POST   | Scale workers                |
  | `/api/v1/clusters/upcloud/{id}/k8s-version`         | GET    | Get Kubernetes version       |
  | `/api/v1/clusters/upcloud/{id}/upgrade-k8s-version` | POST   | Upgrade Kubernetes version   |
  | `/api/v1/credentials/upcloud`                       | GET    | List UpCloud credentials     |
  | `/api/v1/credentials/upcloud`                       | POST   | Create an UpCloud credential |
  | `/api/v1/credentials/upcloud/ssh-keys`              | GET    | List SSH key credentials     |
  | `/api/v1/credentials/upcloud/ssh-key`               | POST   | Create an SSH key credential |

  [API Reference →](/api-reference/introduction)

  ## OVH API Endpoints

  Full REST API coverage for OVH clusters and credentials:

  | Endpoint                                        | Method | Description                  |
  | ----------------------------------------------- | ------ | ---------------------------- |
  | `/api/v1/clusters/ovh`                          | POST   | Create an OVH cluster        |
  | `/api/v1/clusters/ovh/{id}`                     | DELETE | Deprovision a cluster        |
  | `/api/v1/clusters/ovh/{id}/worker-count`        | GET    | Get worker count             |
  | `/api/v1/clusters/ovh/{id}/scale-workers`       | POST   | Scale workers                |
  | `/api/v1/clusters/ovh/{id}/k8s-version`         | GET    | Get Kubernetes version       |
  | `/api/v1/clusters/ovh/{id}/upgrade-k8s-version` | POST   | Upgrade Kubernetes version   |
  | `/api/v1/credentials/ovh`                       | GET    | List OVH credentials         |
  | `/api/v1/credentials/ovh`                       | POST   | Create an OVH credential     |
  | `/api/v1/credentials/ovh/ssh-keys`              | GET    | List SSH key credentials     |
  | `/api/v1/credentials/ovh/ssh-key`               | POST   | Create an SSH key credential |

  [API Reference →](/api-reference/introduction)

  ## Command Palette Direct Links to All Kubernetes Resources

  The Command Palette (`⌘+K` / `Ctrl+K`) now navigates directly to every Kubernetes resource type in your cluster not just Ankra pages. Type any resource kind and jump straight to it.

  **33 Kubernetes resource types** organized by category: Workloads (Pods, Deployments, StatefulSets, DaemonSets, ReplicaSets, Jobs, CronJobs, PodDisruptionBudgets, HorizontalPodAutoscalers), Networking (Services, Ingresses, Ingress Classes, Endpoints, NetworkPolicies, CSI resources), Configuration (ConfigMaps, Secrets, Namespaces, Events), Storage (PersistentVolumes, PVCs, Storage Classes, VolumeAttachments), RBAC (Roles, RoleBindings, ClusterRoles, ClusterRoleBindings, ServiceAccounts, LimitRanges), and more (CRDs, Helm Releases, Nodes).

  **New cluster pages**: Logs, Metrics, Resources, General Settings, and GitOps Settings are now accessible from the palette.

  **New actions**: Base64 Encode/Decode utilities, Keyboard Shortcuts reference, Documentation link, and Switch Organisation.

  [Command Palette →](/platform/command-palette)

  ## Log Viewer Redesign

  Rebuilt the Log Viewer for large clusters and high-volume streams.

  **Scalable Pod Loading**: Pods are fetched on-demand per namespace when you select a workload, replacing the previous 500-pod cap that caused "0 pods" for large clusters.

  **Accurate Matching**: Pod-to-workload matching now uses Kubernetes label selectors instead of name prefix heuristics.

  **Scroll Stability**: Scrolling up to investigate older logs now holds your position even under high-throughput streams. Auto-follow only re-engages on explicit user action.

  **Live Filtering**: Search and log level filters apply to incoming lines in real-time, not just existing logs.

  **Performance**: Batched rendering (150ms flush interval) with virtualized display handles tens of thousands of log lines without UI freezes.

  [Log Viewer Docs →](/platform/logs)

  ## Light Mode

  Full theme customization with Light, Dark, and System modes - the platform is now suitable for bright or dark developer caves. Set your preference from **Profile → Appearance** or use the sidebar theme toggle to cycle modes instantly. Your choice syncs across all devices.

  [User Profile →](/platform/user-profile)

  ## Billing & Subscription Management

  Stripe integration with vCPU-based metering, automated invoice generation, and subscription auto-provisioning for new organisations. The billing pipeline covers plan management, usage tracking, invoice history, and Stripe webhook handling. A billing analytics dashboard provides visibility into resource consumption and cost trends.

  ## Distributed Tracing

  OpenTelemetry tracing across the API, maintenance scheduler, and work scheduler services. Request-level observability with trace propagation, structured logging integration, and circuit breaker improvements provide end-to-end visibility into platform operations.

  ## Registry Performance & Reliability

  Registry listing, detail views, and sync operations significantly optimised. Cache invalidation after frontend changes, Harbor edge case handling, and backoff logic for failing registries improve reliability across all registry types.

  ## Database & Platform Performance

  Database index audit with unused index removal via pg\_stat\_statements, improved connection pool management, and reduced database pressure under load. Listing performance improvements across clusters, stacks, and AI insights result in faster page loads throughout the platform.

  ## Helm Charts Version Tracking

  New charts version comparison and a clusters tab showing which clusters run which chart versions, making it easier to track Helm chart drift across your fleet.
</Update>

<Update label="February 2026">
  # Hetzner Cloud Provisioning, AI Goes Agentic, Full Observability & Secrets at Scale

  Hetzner Cloud provisioning lands across the platform, AI goes agentic with 58 tools, full observability arrives with log streaming and pod terminals, and secrets management scales up with SOPS and variables.

  ## Hetzner Cloud Provision Clusters from Ankra

  Ankra now provisions and manages Hetzner Cloud clusters end-to-end. Create k3s clusters across five Hetzner locations (Falkenstein, Nuremberg, Helsinki, Ashburn, Hillsboro), scale workers, and upgrade Kubernetes all from the dashboard, CLI, or API. The full provisioning pipeline handles networking, SSH keys, bastion servers, control planes, workers, k3s installation, and Ankra Agent setup automatically. Deprovision in one click when you're done.

  [Hetzner Clusters Guide →](/guides/hetzner-clusters)

  ## Hetzner Cluster Provisioning in the Dashboard

  A guided wizard walks you through creating a Hetzner cluster select credentials, pick a location, choose server types (cost-optimized, regular, or dedicated vCPU), set control plane and worker counts, and launch. A live provisioning progress view tracks every step from network creation to Ankra Agent installation. Once running, scale workers and upgrade k3s versions directly from cluster settings.

  ## Hetzner CLI Commands

  Full Hetzner lifecycle from your terminal. `ankra cluster hetzner create` provisions a cluster with configurable network ranges, server types, and k3s versions. Scale workers with `ankra cluster hetzner scale`, upgrade Kubernetes with `ankra cluster hetzner upgrade`, and tear everything down with `ankra cluster hetzner deprovision`. Manage Hetzner API tokens and SSH keys via `ankra credentials hetzner` including automatic keypair generation.

  [CLI Reference →](/integrations/ankra-cli)

  ## Hetzner REST API

  Every Hetzner operation is available via the REST API with Bearer token authentication. Create and deprovision clusters, scale workers, upgrade k3s, and manage Hetzner credentials and SSH keys programmatically. Integrate Hetzner cluster provisioning into your CI/CD pipelines or custom tooling.

  [API Reference →](/api-reference/introduction)

  ## Sandbox Cluster Try Ankra Instantly

  No Kubernetes cluster? No problem. Spin up a sandbox cluster in one click and explore the full Ankra experience: pre-populated nodes, workloads, services, stacks, and live-looking metrics. It's read-only, always online, and requires zero setup. The fastest way to see what Ankra can do.

  [Sandbox Docs →](/guides/cluster-sandbox)

  ## AI Agentic Mode & 58 Tools

  The AI Assistant is now a fully autonomous agent. It reads your cluster state, chains up to 10 tool calls per response, and proposes infrastructure changes with a built-in confirmation system. 58 tools span Kubernetes read/write, stack management, and addon lifecycle.

  [Learn more →](/platform/ai-assistant)

  ## AI Incident Reports & Root Cause Analysis

  When an alert triggers, Ankra automatically generates a detailed AI incident report with root cause analysis, severity assessment, affected resources, and actionable recommendations. Reports are delivered to Slack, Teams, PagerDuty, Discord, and Opsgenie alongside alert notifications.

  [Configure Alerts →](/guides/alerts) | [AI Incidents →](/platform/ai-incidents)

  ## Alerting Built Into All Ankra Resources

  Alerts now monitor every resource type clusters, stacks, addons, manifests, and GitHub repositories. Define custom rules with AND/OR logic, set severity levels, and get notified via six built-in integrations plus generic webhooks.

  [Configure Alerts →](/guides/alerts)

  ## Log Explorer

  Stream logs in real-time from up to 20 pods simultaneously with full-text and regex search, auto-detected log levels, adjustable display settings, and export to clipboard or file.

  [Learn more →](/platform/logs)

  ## Terminal to Any Pod

  Open an interactive terminal directly into any running pod container from the dashboard. Choose your shell, select the target container, and debug issues without leaving the browser.

  ## Stack Cloning

  Clone any stack between clusters with automatic name conflict resolution, SOPS-encrypted value handling, and parent relationship preservation. Available in the dashboard and via the CLI.

  [Clone Stack Guide →](/guides/clone-stack) | [Clone Cluster Guide →](/guides/clone-cluster)

  ## SOPS Integration with ArgoCD

  End-to-end secret encryption using SOPS with AGE keys, fully integrated with ArgoCD. Encrypt specific YAML keys while keeping the rest readable. Automatic decryption during GitOps sync no manual steps.

  [SOPS Guide →](/guides/sops)

  ## Variables: Org, Cluster & Stack Levels

  Define reusable variables at three levels with automatic precedence resolution. Use `${{ ankra.variable_name }}` in manifests and Helm values. Mark variables as secrets for masked display in the UI.

  [Variables Guide →](/concepts/variables)

  ## Metrics Revamp

  Redesigned metrics with area charts for CPU and memory by node, network RX/TX rate charts, disk I/O, pod restarts by namespace, summary cards, and AI-powered health insights surfaced in dashboard widgets.

  [Cluster Metrics →](/platform/cluster-metrics) | [Prometheus Integration →](/integrations/prometheus)

  ## Multi-Select Delete for Kubernetes Resources

  Bulk select and delete Kubernetes resources across 20+ resource types with checkbox selection, confirmation dialog, sequential deletion with progress tracking, and per-item error reporting.

  ## CLI v0.1.125 & API Updates

  New SOPS encryption commands replace the old `ankra cluster sops` command. Granular encrypt/decrypt for manifests and addon values. Full REST API with Bearer token auth, alerts API with AI analysis endpoints, and interactive OpenAPI docs.

  [Ankra CLI →](/integrations/ankra-cli) | [API Reference →](/api-reference/introduction)
</Update>

<Update label="December 2025">
  # Dashboard V2

  A completely redesigned dashboard with real-time health monitoring, AI insights, and guided onboarding.

  ## Health Overview Grid

  Visual cluster cards sorted by health status with critical issues surfaced first.

  **Status Indicators**: Color-coded health status (healthy, warning, critical, offline) with animated pulse for critical issues.

  **Resource Breakdown**: Running, pending, and failed resource counts with visual progress bars.

  **Quick Actions**: Create stacks directly from cluster cards. GitOps connection and agent update indicators visible at a glance.

  ## Operations & Alerts

  **Alerts Summary**: Real-time alert statistics with severity breakdown and quick navigation to alert management.

  **Operations Activity**: Timeline of recent operations across all clusters with status, progress, and timestamps.

  ## GitOps & AI Insights

  **GitOps Sync Status**: Repository connection overview showing connected vs disconnected clusters with direct links to configuration.

  **AI Insights**: Summary of recent AI-powered analyses including incident investigations and cluster health assessments.

  ## Stacks & Registries

  **Stacks Overview**: Stack deployment statistics per cluster with status indicators.

  **Helm Repositories**: Connected registry summary with sync status and navigation to registry management.

  **Recently Accessed**: Quick access to your most recently viewed resources across all clusters.

  ## Onboarding Experience

  **Guided Setup**: Step-by-step checklist for new users with video tutorials and documentation links.

  **Progress Tracking**: Floating progress widget showing completion percentage. Dismissible once core setup is complete.

  **Quick Actions Bar**: Common actions accessible from the dashboard including import cluster and command palette shortcuts.

  ## Stack Builder Improvements

  **Node Position Management**: Improved automatic layout calculations and smoother drag-and-drop interactions.

  **Performance**: Faster stack loading with reduced API calls and improved caching.

  **Bug Fixes**: Fixed manifest rename inconsistencies and improved Bill of Materials calculations.

  ## Performance & Stability

  **Backend Optimizations**: Optimized database queries and reduced API response times.

  **WebSocket Support**: Real-time updates via WebSocket for faster event propagation.

  **Resource Limits**: Increased API limits for clusters with larger resource counts.

  ## AI Assistant

  **Mobile View**: Improved responsive layout and touch interactions for mobile devices.

  ## Agent Updates

  **ArgoCD SSL Handling**: Fixed SSL verification issues and improved certificate handling.

  **Label Selector**: Enhanced resource filtering and ArgoCD relationship handling.
</Update>

<Update label="November 2025">
  # AI Takes Center Stage

  This month we've revamped our documentation to put the AI Assistant front and center, added comprehensive guides for building production stacks, and expanded integrations.

  ## Stack Builder

  The visual Stack Builder is now a first-class citizen with comprehensive documentation.

  **ReactFlow Canvas**: Drag-and-drop interface powered by ReactFlow for composing add-ons and manifests into deployable stacks.

  **Visual Dependency Management**: Connect components on the canvas to define deployment order. Arrows show the flow source deploys before target.

  **Draft Stacks**: Work-in-progress configurations with auto-save, validation, and preview before publishing.

  **Node Operations**: Click any component to edit values, view deployment status, or configure namespaces. Safe node deletion prevents dangling edges.

  **Stack Cloning**: Clone any Stack to quickly create variations. Deploy the same Stack across dev, staging, and production with environment-specific tweaks.

  **AI-Powered Assistance**: Describe what you need and the AI recommends add-ons, suggests configurations, and provides guidance on dependencies.

  **CLI Integration**: Manage Stacks from the terminal with the Ankra CLI:

  * `ankra get stacks` List all stacks in the active cluster
  * `ankra get stacks <name>` View stack details with manifests and addons
  * `ankra clone <source> <dest>` Clone stacks between clusters
  * `ankra applyf stack.yaml` Apply stack configurations

  Perfect for CI/CD pipelines and automation.

  [Explore Stack Builder →](/concepts/stacks)

  ## Insight Metrics

  Real-time cluster metrics powered by Prometheus integration.

  **Resource Usage Cards**: At-a-glance CPU and memory utilization across your cluster with current values and totals.

  **Time Series Charts**: Interactive graphs for CPU by node, memory by node, disk I/O, and network traffic (RX/TX).

  **Pod Restarts**: Bar chart showing restart counts by namespace to quickly identify unstable workloads.

  **Configurable Time Ranges**: View metrics from 15 minutes to 7 days with automatic refresh intervals.

  **Node-Level Drill-Down**: Click any series to isolate and focus on specific nodes.

  ## Helm Charts & Registries

  Completely revamped Helm chart discovery and registry management.

  **Chart Explorer**: Browse, search, and filter Helm charts from all connected registries. View chart metadata, versions, and dependencies.

  **HTTP & OCI Registries**: Full support for both HTTP-based Helm repositories and OCI registries (GHCR, GAR, ECR, ACR, Docker Hub, Harbor).

  **Auto-Sync**: Registries sync automatically to keep chart catalogs up to date. Configure sync intervals per registry.

  **Credential Management**: Securely store and manage registry credentials with support for tokens, basic auth, and cloud provider authentication.

  [Explore Helm Charts →](/platform/helm-charts) | [Registry Setup →](/integrations/helm-registries)

  ## Alerting

  New alerting system to stay on top of cluster issues.

  **Slack Webhooks**: Send alerts directly to Slack channels via incoming webhooks. Configure per-cluster or organisation-wide.

  **Alert Rules**: Define custom alert conditions based on cluster events, resource states, and thresholds.

  **Event-Driven Notifications**: Get notified on deployments, failures, scaling events, and health changes.

  [Configure Alerts →](/guides/alerts)

  ## AI Assistant Enhancements

  The AI Assistant is now the centerpiece of the Ankra experience.

  **Page-Aware Context**: The AI automatically knows what you're looking at. Open a pod and it already has the logs, manifest, events, and related resources. No copy-pasting or explaining.

  **Incident Triangulation**: Root cause analysis across multiple data sources:

  * Container logs with error detection
  * Prometheus metrics and anomalies
  * Kubernetes manifests and configurations
  * Stack deployment history and changes
  * Resource relationships and dependencies

  **Stack Building**: Describe infrastructure in natural language and the AI helps you build it:

  * *"I need a monitoring stack with Prometheus and Grafana"*
  * AI recommends add-ons, suggests values, and explains dependencies
  * You add the components to your Stack based on the recommendations
  * Review and deploy with one click

  **Unified Context Layers**: The AI combines all context for comprehensive understanding:

  | Layer     | What AI Sees                            |
  | --------- | --------------------------------------- |
  | Logs      | Container stdout/stderr, error patterns |
  | Metrics   | CPU, memory, network, custom metrics    |
  | Manifests | Current and desired state, diffs        |
  | Events    | Kubernetes events, warnings, errors     |
  | History   | Deployment timeline, who changed what   |

  **New Shortcut**: Press `⌘+J` (Mac) or `Ctrl+J` (Windows/Linux) from anywhere.

  **Claude Opus 4.5**: The AI Assistant now runs on Claude Opus 4.5 Anthropic's most capable model by default. No configuration needed.

  [Learn more →](/platform/ai-assistant)

  ## New Guides

  **Build a Monitoring Stack**: Step-by-step guide to deploy kube-prometheus-stack with Loki for logs. [Read the guide](/guides/monitoring-stack)

  **Cloudflare Tunnel**: Expose services without public IPs or open firewall ports. [Read the guide](/guides/cloudflare-tunnel)

  ## New Integrations

  **Prometheus**: Connect your Prometheus instance as a metrics data source. Powers Insight Metrics and AI analysis. [Learn more](/integrations/prometheus)

  **Helm Registries**: Expanded documentation for HTTP and OCI registries with provider-specific setup. [Learn more](/integrations/helm-registries)

  ## New Documentation

  **Kubernetes Resources**: Complete pages for Workloads, Networking, Storage, Configuration, and RBAC.

  **Command Palette Guide**: Full reference for `⌘+K` navigation, shortcuts, and commands. [Learn more](/platform/command-palette)

  ## Documentation Improvements

  **Restructured Navigation**: Reorganized into logical groups with AI Assistant prominently featured in Get Started.

  **Consistent Formatting**: Standardized formatting across all pages.
</Update>

<Update label="June 2025">
  # Supercharging Stack Builder & Workflows!

  Safety, speed, visibility & brand-new integrations-everything you need to build, manage, and share infra.

  ## Stack Builder

  **Safe Node Deletion**: Prevent new nodes linking to those being removed-no dangling edges or race conditions.

  **Drag-and-Drop Layout**: Manually reposition nodes, then snap them back into a tidy grid with "Reorder."

  **Reconcile Quick-Jump**: Click a resource's badge to dive directly into the underlying operation.

  **Unsaved-Changes Prompt**: Real-time draft indicators highlight pending edits-and you'll be warned before leaving.

  ## Agent & Import Flow

  **Upgrade Available**: Get notified when a new agent version is available-no more missing out on improvements.

  **Pending-Upgrade Fix**: Agents no longer stall in "pending-upgrade"-rollbacks are a thing of the past.

  ## AI & Automation

  **In-Context AI Chat**: AI Assistant now lives on every page-get guidance right where you work. It's like having a personal DevOps expert at your fingertips.

  **Chat History**: View past conversations in the AI Assistant sidebar-no more lost context.

  **Anthropic Models**: Use some of the most advanced AI models available today. Choose between: Claude 3.5 Haiku, Claude 3.7 Sonnet, Claude Sonnet 4 and Claude Opus 4.

  ## Resource & CRD Management

  **CRD Explorer**: Browse all CRDs in-app, with filters to zero in on exactly what you need.

  **IaC Source View**: Click "View Source" on any generated resource to inspect the GitHub-hosted files.

  ## Search & Shareability

  **Shareable URLs**: Bookmark or share any filtered list-teammates see exactly what you see.

  **Enter-Key Power-Up**: Press Enter in ⌘+K to immediately run searches or actions.

  ## Integrations & Ecosystem

  **Terraform Provider (Alpha)**: Define clusters, stacks, and add-ons as code-live on Terraform & OpenTofu. [Read Docs](https://docs.ankra.ai/integrations/terraform)

  **Monitoring Stack Walk-Through**: Step-by-step video guide with GitOps examples. [Watch Video](https://www.youtube.com/watch?v=__EQEh0GZAY\&t=4s)

  **GitOps Enhancements**: Bidirectional syncing & auto-cleanup of stale files. [Learn More](https://docs.ankra.ai/essentials/cluster-gitops-multiple)

  **Ankra CLI**: Scriptable imports, builds, and add-on management right in your terminal. [Get the CLI](https://docs.ankra.ai/integrations/ankra-cli)

  ## Usability & Productivity

  **Sidebar State Saver**: Hide or show the sidebar without losing your custom panel layout.

  **Download & Copy**: One-click download or copy of cluster add-on configs for backups and sharing.

  **Improved Error Messages**: Actionable hints (e.g. invalid URL format) instead of cryptic failures.

  **OCI-Backed Add-on Sources**: Support for OCI Helm charts now live-private & credential-based OCI coming next month.
</Update>

<Update label="May 2025">
  # Stack Builder, Supercharging Infrastructure!

  The new Stack Builder update is packed with features to speed up your workflows and make infrastructure building easier than ever. Here's what's live:

  ## Stack Builder: Go from 0 to 100 in 2.3s

  **Unified Stacks**: Build with manifests and add‑ons side by side. Apply your organisation's custom configs and get add‑ons working out of the box.

  **Cluster Manifest List & View**: Instantly browse and inspect all manifests in your cluster.

  **Edge Management**: Delete and manage edges in your stack. Nodes now require at least one incoming edge for safety.

  **Live Node Status**: See the status of each node directly from the builder review. Watch it go from planned to live from within the interactive builder.

  **Cluster Stack Deletion**: Instantly remove entire stacks when you need to reset.

  ## Repository & GitOps Integration

  **Repo Sync**: Keep your infrastructure and code always in sync.

  **Create GitHub Repo**: Launch new repositories directly from Ankra, ready for GitOps.

  **GitHub Credential Banner**: Get notified if your integration needs attention. Every cluster needs a GitHub repo for full GitOps integration and to build your first stack.

  ## AI & Automation

  **AI Stack Recommendations**: Get AI-powered recommendations for building infrastructure stacks.

  **AI Assistant**: When you select an add‑on or manifest, the assistant guides you through creating and understanding manifests.

  ## Team Collaboration

  **Multi‑Org & Multi‑User**: Easily invite your team and collaborate across multiple organisations.

  ## Add‑on Experience

  **Stack Add‑on Cards**: Visual add‑on cards for fast browsing.

  **Add‑on Listing Toggle**: Switch between only subscribed add‑ons and all available for easier management.

  ## Usability & Productivity

  **LocalStorage Drafts**: Your changes are auto‑saved as you work.

  **Background Stack Refresh**: See instant, real‑time updates to your stacks.

  **Parent Validation**: Prevents duplicate names and parent mismatches automatically.

  **Live Documentation**: Comprehensive documentation is now available across the platform.
</Update>

<Update label="March–April 2025">
  # Enhanced import cluster flow with automated drafts, agent improvements, and expanded Kubernetes resource insights

  ## Upgraded Import Cluster Flow

  **Cluster Drafts Saved Automatically**: Drafts persist in your browser session so you never lose your work if you navigate away. Resume drafts by clicking the island at the top center of any page.

  **Real‑Time Stack Building**: When you have a draft, click the floating Add button in the top "island" panel to watch your full YAML manifest assemble live. Once you're done looking around the add‑ons and profiles, click the import icon to return to the draft and submit it for completion to get the command and import your cluster.

  ## Import Cluster Agent Enhancements

  **Seamless Local‑to‑Cloud Parity**: Use the `helm install ankra-agent` command from the import cluster on your laptop or on your Kubernetes clusters.

  **Expanded Resource Insights**: Live access to Kubernetes resources.

  **ARM & macOS Native Support**: Prebuilt binaries for Apple Silicon (M1/M2) and generic ARM64 servers. Easy helm install from the import cluster: `helm install ankra-agent`.

  ## Roadmap Preview: Kubernetes‑Native Integrations

  Upcoming support for streaming capabilities that will allow real‑time exploration of the Kubernetes environment:

  * Expand ArgoCD integration to simplify troubleshooting
  * Log streaming of pods
  * Creation of Kubernetes resources with add‑ons

  ## Cluster Add‑on Management

  **Add Multiple Add‑ons**: When you click add‑ons of an existing cluster, you can now add a stack of add‑ons in a single form. Just keep selecting add‑ons from the options.

  ## Bug Fixes & Improvements

  **General Fixes**: Resolved an issue where multi‑line strings were not being preserved.

  **Quality of Life Improvements**: General improvements in the UI for a better user experience.
</Update>