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 →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 →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 →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 growsankra 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 → · Managing destinations 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 →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 →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 →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 →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 put12xCPU 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 namespacemonitoring - 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 →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 askube-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.AI Assistant →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 →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 →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 asEU-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: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.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 →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 → · Publishing add-ons →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 environmentSecret is called out for the same reason.Existing versions keep working unchanged; those published before changelogs simply have none.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 →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:manage_actions_secrets: true opts back in.Using your own registry →Pull request builds no longer publish images
The generated workflow ran onpull_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.GitOps → · ImportCluster reference →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 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 asandbox-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: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 →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.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 →
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 →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’sEXPOSE, 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 →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 →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 renderedkind: 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 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 →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 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 →The cluster trail and the organisation trail now join up
The organisation 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 →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 - a0 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 →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 →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 →The Ankra CLI adds Proxmox, Morpheus, and control over agent runs
Ankra CLI v0.9.0 is out, and it is the largest CLI release so far:- Proxmox VE and HPE Morpheus clusters -
ankra cluster proxmoxandankra cluster morpheuscover 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 updatefor 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 agentslists 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 | listdrives 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 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 --setapplies the new value in memory before encrypting, so the plaintext never reaches git history.
ankra cluster encrypt -f and cluster clone no longer strip fields and comments from your cluster YAML.CLI Changelog → | 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 now agree on what can be built.Ankra 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 usingCREATE EXTENSION vector work.Preview demos →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 →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 apaths: 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 →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 →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 →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 →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 →Secret detection that reads the value, not just the key
The plaintext-secret scan used to flag anything whose key looked secret-like, sotimeout: 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 →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 →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 →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 →Declare Helm registries in the cluster file
The ImportCluster file can now carry a top-levelspec.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 →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-scopedcluster-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 →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 →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 →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 →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 holdVM.GuestAgent.Unrestricted, in addition to the VM.GuestAgent.Audit privilege address discovery already needs.Proxmox VE credentials →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 →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’sconfig.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 →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 →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 →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 →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 →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 →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 → · DigitalOcean → · Proxmox VE → · Morpheus →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 →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 →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 →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 →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 →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 →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 markedmanual (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 →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 fromankra 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 → · 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 newankra 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 →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 →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 gainsankra cluster scaleway stop|start, closing the remaining CLI lifecycle gap.Stopping and Starting →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 needmcp: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 → · 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 →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 delegatedankra.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 →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 →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 →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 has been rebuilt as a single, statically compiled Go binary and is now the production agent on the new2.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
1536Mito512Miand the request from512Mito256Mi, 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/metricsendpoints on port8080, and the sameextra_envtuning knobs.
A fleet dashboard with a world map
The organisation 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 is enabled.Cloud cost estimates
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 to get started.Scoped kubectl access through Ankra
Grant teammates SSO-backed, scoped Kubernetes access with Cluster Access, then reach the cluster with your ownkubectl through Ankra’s API proxy - 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, then instantiate it on any cluster - with diffing, update tracking, and IaC export.Applications: from repo to running workload
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 without leaving Ankra - with AI triage, attachments, and threaded replies - and keep an eye on everything that needs you in your new 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 →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:- Provider-agnostic cluster verbs -
ankra cluster upgrade | scale | node-group | deprovision | k3s-versionsdetect Hetzner, OVH, or UpCloud automatically from the cluster. - Cluster access and kubectl - grant scoped RBAC with
ankra cluster accessand write short-lived, SSO-backedankra-*kubeconfig contexts withankra cluster kubeconfig add. - Cluster metrics - run PromQL against a cluster’s Prometheus with
ankra cluster metrics queryandquery-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 withankra cluster draft. - Live operations - follow a deploy or reconcile with
ankra get operations --watchandankra get jobs. - Self-update -
ankra upgradeupdates or rolls back the CLI in place with checksum verification.
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.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.
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 →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 this month:- Variables at every scope -
ankra org variables,ankra cluster variables, andankra cluster stacks variablesgive full CRUD over the values substituted into manifests and addon values (resolution is stack > cluster > organisation). - Live-cluster SOPS -
ankra cluster encrypt/decryptrun directly against a running cluster’s manifests and addon values, with no localcluster.yamlneeded. - 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 upgradeandmanifests upgradechange a single Helm value or manifest field in place with helm-style--set(field selectors likecontainers[name=app]),--from-file, and--dry-run. - Any organisation - a global
--orgflag (andANKRA_ORG) runs a command against any organisation you belong to without switching your selection. - Curated AI skills -
ankra skills installdrops Ankra’s Agent Skills into Cursor or Claude Code (--editor claude-code), embedded in the binary so it works offline.
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 → | Cluster Settings →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 →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 tokubectl 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 →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 dedicatedhcloud namespace, API token secret, the hcloud-cloud-controller-manager (3 replicas, PDB), and the hcloud-csi 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
Enableinclude_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. Providegitops_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: Newankra cluster {hetzner|ovh|upcloud} node-group commands for list, add, scale, upgrade, and delete.Hetzner Node Groups → | Cluster 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 →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 →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 →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 →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 →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 keyboardj/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 →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 clusterankra helm registries/ankra helm credentials- Manage Helm registries and credentialsankra cluster pods/ankra cluster resources/ankra cluster logs- Access Kubernetes resources and stream pod logsankra cluster select <name>- Select a cluster directly by name without the interactive pickerankra cluster info [name]- Show cluster details (defaults to selected cluster; replacescluster get)- HTTP client timeouts, response body limits, URL encoding, config file permission hardening
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 UpCloudankra credentials upcloud/ankra cluster upcloud- UpCloud credential and cluster managementankra credentials ovh/ankra cluster ovh- OVH credential and cluster management
Node Group API Endpoints
Available for all three cloud providers (Hetzner, OVH, UpCloud):Hetzner Node Groups →
UpCloud API Endpoints
Full REST API coverage for UpCloud clusters and credentials:API Reference →
OVH API Endpoints
Full REST API coverage for OVH clusters and credentials:API Reference →
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 →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 →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 →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.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 →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 →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 →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 →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 →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 → | 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 →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 →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 → | Clone Cluster Guide →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 →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 →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 → | Prometheus Integration →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 oldankra 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 → | API Reference →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.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 stacksList all stacks in the active clusterankra get stacks <name>View stack details with manifests and addonsankra clone <source> <dest>Clone stacks between clustersankra applyf stack.yamlApply stack configurations
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 → | Registry Setup →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 →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
- “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
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 →New Guides
Build a Monitoring Stack: Step-by-step guide to deploy kube-prometheus-stack with Loki for logs. Read the guideCloudflare Tunnel: Expose services without public IPs or open firewall ports. Read the guideNew Integrations
Prometheus: Connect your Prometheus instance as a metrics data source. Powers Insight Metrics and AI analysis. Learn moreHelm Registries: Expanded documentation for HTTP and OCI registries with provider-specific setup. Learn moreNew Documentation
Kubernetes Resources: Complete pages for Workloads, Networking, Storage, Configuration, and RBAC.Command Palette Guide: Full reference for⌘+K navigation, shortcuts, and commands. Learn moreDocumentation Improvements
Restructured Navigation: Reorganized into logical groups with AI Assistant prominently featured in Get Started.Consistent Formatting: Standardized formatting across all pages.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 DocsMonitoring Stack Walk-Through: Step-by-step video guide with GitOps examples. Watch VideoGitOps Enhancements: Bidirectional syncing & auto-cleanup of stale files. Learn MoreAnkra CLI: Scriptable imports, builds, and add-on management right in your terminal. Get the CLIUsability & 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.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.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 thehelm 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