Pipelines, Security, Cost, Clusters, AI, GitOps, CLI, API or Fixes - the selection is in the URL, so a filtered view is a link you can share. Subscribe at docs.ankra.ai/changelog/rss.xml to get each change as it ships.
Records up to and including August 2026 are grouped by month; everything after is one entry per change. Command-line releases have their own CLI changelog.
PipelinesSecurity
An application opens as a workspace, and its Security section ranks findings by exploitability
An application now opens as a workspace: Overview, Pipelines, Deployments, Previews, Security, Environment, Source & config and Settings, each its own page, with?tab= links redirecting. Demos are called Previews. Security ranks findings by CISA KEV, then EPSS, then severity, with a Known exploited filter and a sheet per finding carrying CVSS, EPSS, CISA’s deadline and required action, the fix and the advisory. Exploitability reads Unknown until the catalog has synced. The Applications list gains a Needs attention filter.The application workspace →Clusters
A stack profile carries its backup policy, so a fleet launch protects every instance
Saving a protected stack as a profile now keeps its protection. The builder shows a Protection section - whether to protect, which backup vault, how often - and the vault travels by name, resolved against the organisation you launch into, so one profile protects a whole fleet. A launch with no ready vault says so and keeps the draft rather than starting a stateful stack unprotected. Public profiles carry no vault name.Protection: backups travel with the profile →Pipelines
Ankra says when a branch’s runs are queueing behind each other
Aconcurrency.group that varies per branch with no cancel_in_progress makes a new commit’s run wait for the run it replaces. ankra pipeline validate now says so as advice - never blocking, never failing the command - naming the group and the line that changes it. A queued run’s waiting reason carries the same recommendation when it is stuck behind its own branch, and a converted GitHub workflow gets a conversion note. Your existing definitions keep their behaviour.Newest commit wins →ClustersCLI
Protect a stack, take restore points, and restore it in place
Protecting a stack schedules its databases and named volumes into a backup vault you own, and installs the backup data plane. Take a restore point whenever you like, read what it carries and what it could not, then restore the stack in place behind a typed confirmation.ankra runs follows every capture and restore, and a protection pill now says where data is exposed. CloudNativePG and Percona restore in place is not available yet.Backups and restore points →Pipelines
A generated pipeline is checked against your repository before the setup pull request carries it
Ankra now checks a generated.ankra/pipeline.yaml against your repository before proposing it, not only against the pipeline grammar. Each build stage’s Dockerfile is resolved the way the builder resolves it and looked for in your branch plus the files the same run commits. Findings name the stage and appear on the setup run, so nothing is discovered by a push that fails after you merge.Ankra Pipelines →Pipelines
Generated test stages run your project’s own commands
A generated test stage now follows the lock file your component commits. Auv.lock project runs uv sync --locked && uv run pytest; pnpm-lock.yaml and yarn.lock run pnpm and Yarn with a frozen lockfile instead of npm. Go components each get their own GOCACHE and GOTMPDIR inside the workspace, and a monorepo’s workspace is sized by its component count.Ankra Pipelines →PipelinesFixes
A build stage with no dockerfile builds its own context, and a refused build says why
Abuild stage declaring a context and no dockerfile now builds that context’s own Dockerfile, which is what docker build backend reads; a declared dockerfile: is still a path from the repository root. A build refused before it starts settles as recipe_missing or build_emulation_missing carrying the runner’s own sentence, instead of the step exited with status 78.Ankra Pipelines →PipelinesSecurity
A generated scan stage stops running the GitHub Actions Semgrep pack on a repository with no workflows
Semgrep’sp/github-actions pack no longer appears in a generated scan stage when Ankra has established your repository commits no GitHub Actions workflow. An incomplete file listing keeps the pack, because not having looked is not the same as having found none.Ankra Pipelines →PipelinesCLI
Convert an application from its GitHub workflow to Ankra Pipelines with one click
An application still building from a GitHub Actions workflow now shows Convert to Ankra Pipelines on its journey card and Convert in the Applications list;ankra application pipeline convert <application-id> does the same. The click takes effect at once: Ankra stores the converted pipeline, builds the next push through it, switches the generated workflow off on GitHub, and opens a pull request that commits the pipeline file and removes the workflow.Migrate an existing application with one call →ClustersGitOps
Protect a stack with a backup block in the cluster file
A stack can now declare its own backup policy in the cluster file, and Ankra takes the scheduled restore points from it. Databases are captured by default; volumes only the ones you name, so protecting a stack does not start copying every claim in its namespaces. A file that omits the block leaves protection exactly as it was, and an apply that narrows protection says what stops being covered. Closed beta, enabled per organisation.Protect a stack →CostFixes
Hetzner clusters are priced from Hetzner’s live price list
Cloud Cost now reads Hetzner’s price list every hour with your stored Hetzner credential and prices each server type, load balancer, IPv4 and volume per location, instead of from a built-in copy that predated Hetzner’s June 2026 increase. A server ordered before that increase keeps the list it was ordered under, matching the two rates your invoice shows for the same type. Estimates readmedium confidence, not high, when no live list could be fetched.Where the prices come from →ClustersFixes
Cluster Mesh: UpCloud clusters built before the overlay can be meshed day-2
make-ready now joins an existing UpCloud node to the WireGuard overlay from its update job, so a cluster built before the overlay converges instead of looping. Service ranges may overlap across members; a second cluster on the default pod range is refused by name until --pod-cidr auto moves it onto a fresh range, one node at a time. ankra cluster mesh up runs readiness, make-ready and the joins for a set of clusters in one command.Make an existing cluster mesh-capable →SecurityCLI
Create your own robot accounts on the Ankra registry
Ankra minted every registry login itself. You can now create robots of your own for anything that logs in without Ankra in the loop - CI you run, a laptop, a cluster Ankra does not manage.ankra registry robots create <name>, the Registry robots page, or the API mints one with push or pull rights on your project and shows its secret once; list, rotate and revoke it the same way, and reference its managed credential ankra-harbor-robot-<name> anywhere.Robot accounts you create yourself →PipelinesFixes
The setup pull request no longer gates an application Ankra Pipelines builds
The Applications list and the application journey no longer say Merge the setup pull request to go live once your application builds on an Ankra pipeline or on your own workflow: that pull request only proposes committing Ankra’s generated files. A push now also re-checks a setup pull request still recorded open against GitHub, and an application whose pipeline Ankra stores and runs is recorded as building on Ankra Pipelines. Reconcile moves an existing application over.Ankra Pipelines →AICost
Stack READMEs, code review and background runs follow your model settings
Stack README generation, AI code review with no model picked, and background agent runs now follow your organisation’s model settings instead of a fixed Claude model, defaulting to the Think tier: GLM 5.2 on the Ankra provider. Stack README and AI code review each get their own setting, and only admins can change a function’s model. Chat on the default models now counts against the free monthly AI allowance.Models per function →ClustersAPI
Self-managed k3s clusters on AWS EC2
Ankra now builds self-managed k3s or kubeadm clusters on EC2: a VPC across one or three zones with NAT egress (or a VPC you adopt), a bastion, nodes in private subnets with no public IP, the AWS cloud controller and EBS CSI driver on instance profiles, a Network Load Balancer for Traefik, stop and start, node groups, upgrades and teardown with a retention policy. The provisioning credential covers it. Closed beta, behind theaws_provider organisation flag (ankra-rtpno).AWS clusters →ClustersFixes
Cluster Mesh readiness refuses clusters the mesh can never reach, and retries a missed trust root
A cluster created with networking off has no Cilium release the platform manages, so a mesh could never reach it. Readiness now says so under a newcilium_stack check, and the join and make-ready refuse it instead of leaving the member in configuring. A member whose trust-root job never ran, or never reported, is re-dispatched by the mesh reconciler after fifteen minutes rather than waiting for a peer change that never comes.Cluster Mesh requirements →ClustersAPI
Update a stack to a newer profile version in place
A deployment behind its profile used to be updated by instantiating the profile again, which produced a second stack renamed around the name collision. Update on the profile’s Deployments tab now replaces the contents of the stack that deployment already runs, in place, so Kubernetes rolls the workloads, and records the deployment at the new version - so the “behind” counters follow. Non-secret inputs are carried forward; secret inputs are asked for again.Versioning, diffing, and updates →ClustersAPI
Cloned stacks deploy on their own; the ones missing secrets say what they need
Cloning a stack or a whole cluster no longer leaves a row of drafts to open and deploy one by one. Deploy after cloning is on by default and deploys every clone that has what it needs. A stack whose encrypted values had to be removed is held as a draft marked Needs input, and the clone result, the stack card and the builder name each member and field to re-enter, with a link straight to it.Clone a cluster →ClustersAPI
Clone a cluster onto a different cloud provider
Clone Cluster can now build the copy on a cloud provider instead of an import cluster. Choose Build on a cloud provider, pick Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, Proxmox VE or HPE Morpheus, and finish on that provider’s create page: the cluster is provisioned and every source stack lands on it as a draft. Stacks the provider installs itself - cloud controller, networking, DNS, Cilium - are skipped and reported. The API takestarget_provider and target.Clone a cluster →CLIAPI
Import a Claude Design export as an application
A canvas exported from Claude Design - artboards,canvas.json and images, a zip, or a saved canvas page - becomes a deployable application in one step: Ankra turns it into a static site, creates a GitHub repository with a Dockerfile, and registers the application. Use ankra application import claude-design <export>, Claude Design under Add application in the portal, or POST /api/v1/org/applications/imports/claude-design. Behind the claude_design_import organisation flag; ask Ankra to enable it.From Claude Design to a live application →Cost
Compare providers prices the fleet on AWS, Google Cloud, Azure, Proxmox and Morpheus too
The Where the same fleet would bill row now offers every provider Ankra can price. AWS, Google Cloud and Azure are priced from their own per-region catalogues, and each column says which region it was priced in. Proxmox VE and HPE Morpheus are priced per vCPU, GB and disk from your rate card, and the column names whether those rates are yours or Ankra’s defaults. Unpriced is still never free.Compare providers →CLI
Pipeline commands read the checkout you are standing in
ankra pipeline run and ankra pipeline list resolve the application from your origin remote and the commit from HEAD, and say which they used. Inside a checkout they need no flags. Name --application or --sha yourself outside one, or when a repository carries more than one application.Ankra Pipelines →CLI
application add --wait prints the setup pull request
Adding an application ended on “Ankra is now analyzing the repository”. With --wait the command follows that analysis, reports its progress, and prints the setup pull request’s link when it finishes, or the platform’s reason when it fails.Quickstart →Fixes
One unreachable repository no longer blocks adding an application
ankra application add refused whenever any application in the organisation pointed at a repository the GitHub App installation could not reach, and told you to install an App that was already installed. It now asks whether the installation can read the repository you are adding, and names the page that grants access when it cannot.GitHub integration →CLI
credentials get says whether a credential is usable
The detail view showed no health at all, so a credential listed as down had no explanation anywhere obvious. It now prints whether Ankra can use the credential and, for a GitHub one it cannot, the recorded reason and the command that lists the repositories.GitHub integration →SecurityCLI
A cluster’s security history and scheduled report work from the CLI and MCP
The daily posture snapshots behind the trend chart and the weekly or monthly emailed security report now answer to an API token,ankra security history and ankra security report-schedule (show, set, send), and to four MCP tools: get_cluster_security_history, get_cluster_security_report_schedule, set_cluster_security_report_schedule and send_cluster_security_report_now. The two writes are confirmed before they run.Security reports →Clusters
Product films now play inside the docs, starting with the playground spin-up
Eleven short films from the Ankra channel are embedded on the pages they explain: the playground spinning up in 82 seconds, Compare providers, the Security Center, stack profiles, applications, AI agents, Cluster Mesh, the AI assistant, importing a cluster and creating one on Hetzner. Each sits under the heading it demonstrates, so a page can be watched before it is read.Playground →Cost
Playground sizes are repriced, and the pricing is now documented on the billing page and the Playground page
New list prices, EUR a month excluding VAT: Trial free, Small €5.21 (2 vCPU / 4 GB), Medium €8.06 (4 vCPU / 8 GB), Large €15.19 (8 vCPU / 16 GB) and Extra large €28.01 (16 vCPU / 32 GB), storage bundled, pods and PVCs capped. A playground you already run keeps the price you ordered at. The billing page carries the rules: pro-rata by the second, nothing metered on top, an 8 GB organisation memory budget.Playground environments →Security
A package in the bill of materials now opens where it runs
Every figure in an SBOM component row opens the list it counts. The package name, and the images, workloads and clusters figures beside it, open a package page listing the images that carry that exact version, the workload containers running them and the clusters they run on; each entry links onward to the image’s bill of materials, the workload’s live page or the cluster’s security tab. On the CLI:ankra security sbom component.Software bill of materials →Cost
Compare providers: staying put is a column, and today shows its list price
The cluster’s own provider now appears beside the others: the same fleet re-sized in place on its own price book, marked Stay, so a cheaper plan family where you already run is weighed against a move. Today’s tile shows what the same shape costs at list next to the metered bill. The estimate API accepts the cluster’s own provider as the target for the same read.Compare providers →Cost
Compare providers: the whole bill on every cloud, like for like
A cluster’s cost page gains Compare providers: the same fleet - node groups, control plane, volumes and load balancers - priced on every provider Ankra can build on, side by side, with today metered where it runs. Matching is like-for-like by default, so a fleet on dedicated cores is never quoted as a saving on shared ones. A target the book can only partly price keeps a floor instead of a blank.Compare providers →Pipelines
Pipeline logs and scan reports are kept without a backup vault of your own
A first pipeline run no longer waits on an object-storage bucket. An organisation with no ready backup vault has its step logs, scan reports and declared artifacts kept in an Ankra-managed default vault, under a key prefix of its own, with the same retention and the same per-object download links - soscan, gate and publish work from the start. Register a vault of your own for data residency, and it takes precedence from the next step onward.Ankra Pipelines →SecurityCLI
Everything the Security Center shows is now on the CLI and the MCP server
Dispositions, compliance frameworks and their evidence export, per-cluster benchmarks, policy violations, the policy mode switch, NetworkPolicy over-privilege, the security baseline install, add-on posture, workloads, namespaces, pods and an application’s image versions each gained anankra security command and an MCP tool, and every Security Center route now answers to an API token under /api/v1. Writes confirm first and enforce the same permissions as the portal.MCP tool reference →Clusters
A stack shows what it is running, not only what it declares
A stack’s new Runtime tab shows what its add-ons put on the cluster: the hosts its Ingresses publish, as links you can open; the pods it owns, with the statuskubectl prints; its Services and their ports; and the events raised against its own objects. Pods are attributed by ownership rather than namespace, so stacks sharing a namespace never show each other’s. A listing that could not be read says so instead of reading as empty.What a stack is running →Security
Security drills down from the cluster to a container
A cluster’s Security page now opens on Stacks: one row per stack with its attribution, actionable and known-exploited findings and SBOM coverage, plus an Outside any stack row so the rows add up to the cluster. A stack’s members expand into the workloads they deploy, then their pods, then each container’s CVEs. The same path is on the API, the CLI (ankra security stacks|stack|pod) and Ankra AI.Cluster security →AI
What the AI review reads besides the diff, written down
The review searches your repository for a changed declaration’s other callers, and - for names a diff removes - the repositories your organisation deploys beside it, so it can flag a removal that breaks a different repository before the deploy does. The page now says where that repository set comes from, that only removals trigger it, that silence may mean the search never ran, and how aDepends-on: line declares merge order.AI code review →Security
Licence risk on every bill of materials, and a warning when a private repository owes its source
Every SBOM package now carries a licence risk tier - network copyleft (AGPL, SSPL), source-available (BUSL, Elastic), copyleft (GPL), weak copyleft, permissive or unclassified - as a filter, a summary figure, a per-image breakdown, a CSV column and a CLI flag. An application whose repository is private and whose newest scanned version links a network-copyleft package gets a Licence obligation notice naming the packages that oblige you to publish your source or move them behind a separate service.Licence risk →AI
AI code review has a page of its own
Every switch under Source control & AI review is now documented in one place: what AI review, review drafts, the per-pull-request cap, mention replies and PR previews do, how a repository rule overrides the connection-wide defaults, what Ask and Agent mode allow, where the review model and review instructions live, what the posted review looks like, and why a review is skipped. GitLab also gets the connection guide it never had.AI code review →Security
Pod security enforced by Kubernetes itself, not a policy engine
Version 5 of the security baseline drops Kyverno. Pod security is enforced by Pod Security Admission, built into every API server, with a ValidatingAdmissionPolicy stopping anyone but the agent lowering a managed namespace’s label. Nothing here runs as a pod. The Security Center’s Policies tab now shows the full check table for every cluster, with or without a policy engine, and says which mode and standard it is in.Security baseline →Pipelines
Ankra Pipelines: egress-https reaches only public addresses
The tier could reach any address on 443, and port 53 on any pod in the cluster. It now excludes RFC1918, link-local and carrier-grade NAT with their IPv6 equivalents, and restricts DNS to kube-system. This breaks a step that reaches a private HTTPS endpoint, so ci_egress_allowed_cidrs names the ranges a step may still reach. An image policy prefix ending in a separator now admits exactly its own boundary.Ankra Pipelines →Pipelines
Ankra Pipelines: forks never share a cache, and every cache carries a trust scope
A pull request from a fork resolved the same cache volume a trusted run does. A restricted fork run now resolves no shared cache at all, and every claim carries a trust scope ofdefault_branch or branch that no exact key or prefix match crosses. Claims written before the deploy were backfilled as untrusted, costing one cold build per key, once. Fork runs are budgeted as well as restricted.Ankra Pipelines →Pipelines
Ankra Pipelines: one approval route, and a dispatch that proves its commit
A security review found seven ways a caller holding onlypipelines.manage could give a run more authority than an administrator ever approved. All seven are closed: one approval route, requiring a human actor and the repository’s current default-branch definition, and a dispatch that resolves its ref through the host and proves any caller-supplied head_sha. Re-approve your definitions at this release, and re-run anything that was mid-flight.Ankra Pipelines →Pipelines
Ankra Pipelines: a stage nothing can run is skipped, not left hanging
A pipeline declaring a stage kind Ankra cannot execute yet validated cleanly, then satpending forever, holding its run and its concurrency group. Those kinds now raise a validation warning and the planner skips them with reason kind_unavailable, so the run concludes on the stages that do execute. uses: is refused at validation, scan.fail_on tightens the gate per scanner, and ci_run_retention_days bounds how long concluded runs are kept.Ankra Pipelines →Security
Every container has its own CVE, SBOM and KEV reports
A stack’s Security tab opens on its running pods, grouped under the add-on or manifest that deploys each, with every container listed and three openers into a dedicated container view: CVE, SBOM and KEV. That view carries the image’s findings, its bill of materials with the CycloneDX and CSV downloads, and the ring of links around it. An unscanned cluster reads Not scanned rather than clean.Cluster security →Security
A pod reads container by container
A pod’s detail page has a Security tab listing every container and init container with the CVEs the scanner attributes to it, through the pod’s owner chain, and the bill of materials of its image. Findings opens the image’s CVE list and Components its package inventory, the same views the Security Center uses. A container no report covers reads Not scanned; one without a bill of materials reads Absent.Cluster security →Security
A stack reads as one security object
A stack’s detail page has a Security tab reading every CVE, every CISA-listed exploited vulnerability and every bill of materials behind the workloads its add-ons and manifests deploy, as one object. An add-on is attributed by its Helm release identity, a manifest by the objects its YAML declares, both walking two owner levels down. The findings and components views carry facets computed for the stack alone.Cluster security →GitOps
Hand-maintained files survive every sync
The reconciler’s export of stored state wrote back to Git without checking who last wrote each file, so a value maintained by hand - an image tag pinned above a chart’sappVersion for a CVE fix - could be reverted. Every write path now applies one rule: .ankra-owned.json records a digest of the bytes Ankra last wrote, and a file whose bytes no longer match it is kept, never overwritten.GitOps →Pipelines
Ankra Pipelines: connect a repository and watch it run
Connecting a repository is now self-service, and on GitHub the same call reads its committed.ankra/pipeline.yaml as the definition of record. A new application’s setup pull request commits that file instead of a generated GitHub Actions workflow. checkout joins run as a stage that executes end to end, and a pull request changing a protected section runs with the last approved authority instead, saying so on the check run.Ankra Pipelines →Pipelines
Ankra Pipelines: build, scan, gate and publish by digest
A commit is now a straight line to a deployed image.build produces a digest in a rootless BuildKit pod and pushes it to your organisation’s CI staging repository; scan runs Trivy, Semgrep and Checkov against it; gate judges them against a policy a pipeline may only tighten; and publish re-tags the one digest gate approved. A pull request from a fork runs restricted rather than refused.Ankra Pipelines →Pipelines
Ankra Pipelines: the review reads the run, and you can say merge when green
Ankra’s pull request review answered whether a change was passing from a GitHub check run alone, so a repository on Ankra Pipelines got a review blind to its own pipeline. It now resolves the commit’s newest run first and carries its facts: the failing step, findings by tool and severity, the gate verdict, the build digest. Mention@ankraai merge when green and Ankra merges the moment those conditions hold.Ankra Pipelines →Pipelines
Migrate an existing application onto Ankra Pipelines with one call
Moving an application already running its own CI meant converting the workflow by hand and opening the pull request yourself.GET /org/applications/{id}/pipeline now reads what builds it today and what a migration would do, and POST .../pipeline/migrate converts it and opens the pull request for you. Merging that pull request is what switches the application over, with no separate Reconcile click.Migrate from GitHub Actions →Pipelines
The platform-operated build fallback actually builds
ci_build_fallback: platform_builders was a setting with nothing reading it back. When the CI cluster’s own agent cannot run pipeline steps and an organisation has opted in, a build step now runs on Ankra’s own platform-builders lane instead, with the same push, scan, gate and publish downstream. The step’s executor records which lane actually built it.Ankra Pipelines →AI
Live usage, agent and GitOps posture from chat and the MCP server
Nineankra cluster commands the assistant and the MCP server could not answer now have tools. Ask what is eating CPU on a cluster and Ankra AI reads live usage per node or pod from metrics-server, never a cached figure. It also reads GitOps sync state including the two failures the overview hides, reports and upgrades the agent, lists every Helm release, and discovers managed clusters already running.MCP Tool Reference →AI
Raise support tickets from chat and the MCP server
The assistant could diagnose a problem but not hand it to a human, and an MCP client had no way to open a ticket at all. Tell Ankra AI to raise a support ticket and it proposes one with the subject, category, severity and the cluster you were looking at; confirm, and it is filed. Ask what support said and it reads the thread; reply in chat and it lands on the ticket.Support →Pipelines
One status comment per pull request
Ankra used to leave several comments on a pull request as it worked, each in its own place and each edited on its own clock. It now keeps one comment with a section for each thing it has to say - the pipeline, the preview, the review, and the promotion when there is one - updated in place. An older preview card is adopted into it rather than left beside it.Pull request reviews →Pipelines
Convert a workflow into an Ankra pipeline from chat
Ask Ankra AI to convert an existing GitHub Actions workflow, GitLab CI file, Bitbucket Pipelines file or CircleCI config into.ankra/pipeline.yaml, and to validate a definition you have written. It answers with the file and every diagnostic: what it mapped, what it could only carry over as a plain run step, what it refused. Actions with an Ankra equivalent are mapped; the rest is kept as the script it was.Migrate from GitHub Actions →AI
Ask Ankra AI to create your alerts
Ankra AI could list your alerts and mute them, but asked to create one it could only point you at the New alert button. Describe the alert in chat and it now proposes a Create alert action with severity, the clusters or environments it watches, the conditions and the cooldown spelled out. It writes only conditions the evaluator implements, so an alert it creates cannot sit dead while reading as configured.Alerts →AI
Rollout verifications that stop paging you
After you approve a change in chat, Ankra opens a follow-up turn once the rollout settles and verifies chart version, health and sync. That turn was treated as a reply you were waiting on, so every verified rollout sent a completion message to Slack or Teams and to the inbox. A verification that finds the rollout healthy is now quiet; one that finds a failure, or parks a fix, still reaches you.Notification routing →Security
A software bill of materials for the fleet
The Security Center gains an SBOM tab: every package the scanner found in every container image, where it runs, and whether a finding names it. When the next CVE lands you search the package and read the workloads, namespaces and clusters running that exact version, without a rescan. Images are keyed by digest and stored once. Generation is opt-in per cluster and off by default.Cluster security →Security
Security by namespace, workload and pod
A Workloads tab breaks the fleet down the way a platform team owns it: cluster, then namespace, then workload, then pod. Each namespace row carries its scanned workloads and images, the pods running there right now, the actionable findings by severity, the known-exploited count and the last scan. Show pods resolves each workload’s owner chain to its live pods. A container the scanner never covered says Not scanned.Cluster security →Cost
A what-if draft that predicts the bill before you resize
Every cluster’s cost drill-down carries a what-if draft: the node groups as they run today, with the load balancers beside them, editable in place. Grow a group, shrink one, add a spot group, and the panel prices the draft and shows today’s bill, the predicted bill and the change side by side. Pricing comes from the same price book the bill is metered from. Nothing is applied to the cluster.What if the node groups changed? →Cost
Your money, in your currency
The organisation sets a default display currency; you can now set your own on top, and every cost figure you see follows - the fleet overview, cluster drill-downs, credentials, workloads and savings. Provider quotes got honest at the same time: UpCloud quotes arrive in US dollars and were being shown with a euro sign. Thirteen currencies are supported, each with a live exchange rate refreshed twice a day.Cost settings →Cost
A Cost center that answers whose money, and what it runs
The Cost page could say what the fleet costs, but not whose account the money is on, or what it is actually running. It now breaks spend down across six tabs: Clusters is the whole fleet in one table, Credentials groups the same money by the account paying for it, and Workloads answers where the money runs with names you recognise, linked through to each application.Cloud cost →Cost
Cost for the capacity nobody publishes a price for
If your clusters run on Proxmox, VMware or hardware you imported yourself, the Cost page had nothing to show you. You can now state what it costs: a rate card is three monthly rates in your own currency - per vCPU, per GB of memory, per GB of storage - set on the credential that provisions the capacity. Proxmox ships with defaults; other private providers read not priced rather than free.Cloud cost →Clusters
The overview says what every cluster is
The cluster overview opens with a configuration card for every cluster kind: provider and region, the distribution actually running your API server, the Kubernetes version with the kubelet range, the CNI, and the node shape with each group’s instance type and autoscaling bounds. Provider-managed clusters finally show their real version everywhere instead of a placeholder. Cells the platform has no honest data for disappear rather than reading Unknown.Cluster nodes →Clusters
Playground storage says what it is
The playground’s create wizard, settings card and live card now say plainly that storage is local to the playground host and not backed up - keep anything you cannot afford to lose in your own repositories and registries. The storage quota got honest too: the size a plan sells is now fully yours, with the virtual cluster control plane’s own volume reserved on top rather than taken out of your budget.Playgrounds →AI
Connect to Ankra from the Teams welcome card
When the Ankra AI bot is added to Microsoft Teams, its welcome card offers a Connect to Ankra button that opens the portal with the claim code already filled in. Since that button shipped in August it led to a 404, and admins were falling back to reading the code out of the card by hand. It now opens the portal as intended, taking you through sign-in and back with the code intact.Connecting Microsoft Teams →Cluster Mesh across providers, cost evidence and a waste scan, power schedules, audit trails, and the largest CLI release yet
Connect clusters with Cluster Mesh
Cluster Mesh connects your clusters into one Cilium ClusterMesh over the platform-managed WireGuard overlay - across providers, accounts and sites, with nothing exposed publicly.ankra cluster mesh readiness says whether a set of clusters can mesh and exactly why not; create and join do the rest: the mesh’s shared certificate authority is minted and handed to every member, each member’s Cilium re-renders with its identity and peer list, and every node gets an encrypted tunnel - and a route - to every node of every other member, with the clustermesh-apiserver dialled inside the tunnel on the peer’s overlay address. Statuses (pending / configuring / ready / degraded) are derived from what each cluster’s agent actually proved, never from intent, and a global service (service.cilium.io/global) resolves to healthy backends in whichever cluster has them. Clusters that already exist join the party with ankra cluster mesh make-ready - the identity and overlay range are allocated day-2 and the nodes converge in place, nothing deleted or recreated (one kubelet restart per node is the whole disruption). UpCloud and Proxmox are wired today; a Proxmox site brings one public address and a UDP port-range forward, and everything else is the platform’s job.Cluster Mesh →Notifications on your phone
The Ankra mobile app now receives push notifications, on iOS and Android.Nothing arrives by default, and that is deliberate: a notification reaches a phone only when a routing rule sends it to a push audience, the same way a rule sends one to a webhook. Set the destination type to Push notification and pick the audience - all cluster members, or organisation admins - then filter by kind and severity as usual. “Every critical notification” and “only when a bastion goes offline” are each a single rule.Devices add themselves. Sign in to the app, accept the prompt, and the phone appears under Profile → Notifications. The app holds no credential of its own: it hands the token to the signed-in page, which registers it against your session, so a device always belongs to exactly the member who signed in on it. From there you can mute one phone without signing out of it, remove it, or Send test - which delivers straight to that device without consulting any rule, so you can prove the path works before writing one.Severity decides whether a notification interrupts. A critical arrives time-sensitive on iOS, so it breaks through Focus, and at high priority on Android, so it is delivered even in Doze; informational ones arrive quietly and will not light the screen. On Android the three importance levels are real notification channels - Critical alerts, Warnings and Updates - which means Android hands them to you: set Warnings to silent in system settings and it stays silent through every app update. Your existing snoozes apply unchanged, so a kind you have muted is muted on your phone too, and a notification addressed to one person reaches only their devices.A device that registers but never rings is almost always a missing routing rule rather than a broken phone, which is why the devices page shows what the platform knows: the last delivery, and - when Apple or Google reports a token is dead, because the app was removed or the token rotated - the reason delivery stopped, rather than a silent gap.Mobile push notifications →A Cost section with one-click savings
Cloud cost now has its own place in the sidebar, between Credentials and Security. Overview is the fleet rollup - projected month end with its pace against the run rate, month to date, run rate, priced coverage, the split by provider and the costliest clusters. Savings turns the same data into money: right-size idle capacity (one click opens Ankra AI’s cost optimisation, whose scaling updates apply to the cluster after your confirmation), stop non-production clusters off-hours (one click writes a weekday 19:00 stop / 07:00 start pair - workers scale to zero, weekends stay down), and reduce unallocated spend - plus a per-cluster breakdown of where the money goes and the costliest namespaces fleet-wide, so every team sees the cost of what it runs. Settings holds the display currency - euro by default now - your effective discount and the network egress estimate, admin-only and applied to every figure at read time. The clusters list carries the rollup as a collapsible strip above the table. The same figures answer everywhere else:ankra cost summary|cluster|settings in the CLI, and get_fleet_cloud_cost / get_cost_settings / update_cost_settings in Ankra AI chat and over MCP.Cloud Cost →Cost recommendations that show their evidence
A savings recommendation used to ask for trust: right-size this cluster with nothing on screen proving anything was idle. Every cluster in Cost → Savings now opens its own drill-down page with the proof. For each node, the measured average, p95 and peak CPU and memory usage over a selectable window (24h / 7d / 30d) stands against what the scheduler reserved, with the node’s own monthly cost and a defensible verdict: underutilised (with the saving from sizing to 1.5x the observed p95) only when even the busy moments fit well under the reservation on both resources, spiky - keep headroom when bursts make the average misleading - a bursty node is never called safe to shrink, whatever its average - and no metrics when usage is genuinely unknown, never “0% used”. Around the node evidence: the 30-day cost trend, a component donut of where the money goes, the per-node usage charts so the pattern behind the statistics is visible, namespace allocation next to requested-vs-used efficiency, and the same one-click resolves, now with the evidence attached. The Overview gains a fleet cost trend, honestly scoped to the analysed clusters.And because some waste never shows up in utilisation at all, a six-hourly waste scan now inventories your cloud accounts for resources that bill while doing nothing: stopped Hetzner servers (billed fully as long as they exist), unattached volumes, unassigned primary IPv4 and floating IPs, load balancers with no targets, and Kubernetes persistent volumes stuck inReleased. Findings land on the Savings page and each cluster’s drill-down with their monthly price and a one-click Resolve with AI naming the exact resource; a credential that could not be listed renders as a partial scan, never as “no waste”. Two new reads carry it all: GET /org/clusters/{id}/metrics/utilisation and GET /org/cloud-cost/waste.Per-cluster drill-down →API tokens the organisation owns
An API token used to belong to whoever created it, in two ways that made it a poor fit for automation. It authenticated only while that person was still a member, so removing someone from the organisation stopped every token they had minted - the deploy pipeline they set up two years ago fails with a401 and nothing in the log says why. And it carried their whole authority rather than a capability anybody had chosen for it. It was not really scoped to an organisation either: the same header the CLI’s --org flag uses re-pointed any token at any organisation its owner belonged to.Organisation → Service tokens is the other kind. A service token authenticates as a service account - a principal the organisation owns, holding one role an administrator picked - so it survives offboarding, appears where any administrator can review and revoke it, and reaches its own organisation and no other. Creating one takes a name, a role and an expiry; the secret is shown once. Minting under an existing name adds a second token to that same account, which is how a credential is rotated with no gap: issue the new one, roll the deployment, revoke the old one, and the account keeps one continuous audit history across the rotation. Revoking stops a single credential and leaves the account’s others alone; deleting an account’s last token stands the account down, so a token minted under that name later needs its role granted again deliberately.Minting requires members.manage, and so does reading the list - an inventory of standing credentials and the authority each one carries is not the member list. One guard goes further than the role-assignment surface needs: you cannot mint a token carrying permissions you do not hold yourself. Granting a colleague a role hands them nothing until they sign in as themselves, but a token works the moment it exists, so without that rule “can manage members” would quietly have meant “can escalate to owner”. A service token can also be scoped to mcp:read or mcp:write, reaching the hosted MCP server only. The same surface is available to automation at /api/v1/org/organisation/service-tokens.Service tokens →Move a cluster to another organisation
An imported cluster can now change organisations without being re-imported. From the cluster’s ⋯ menu, the cluster overview or Settings → Danger Zone → Move cluster, an organisation admin picks a destination organisation they also administer, types the cluster name, and the cluster - with its agent, executions, resources, findings, insights and variables - now belongs there, still connected. Access grants, cluster-scoped role assignments, kube tokens, notification routes and mutes, report schedules and cluster group memberships from the previous organisation are detached and listed in the result; billing, audit and chat history stay where they were. Ankra-provisioned and managed Kubernetes clusters stay put for now - their provider credential belongs to the organisation that created them. Both organisations record the move in their audit trails. The move is refused while operations are running, while the cluster is in a cluster mesh, while it has DNS zones bound to the current organisation, for playground and sandbox clusters, and when the destination already has a cluster with that name. The same move isankra cluster move <cluster> --organisation <id|slug|name> in the CLI and the move_cluster_to_organisation tool in Ankra AI, both behind the same two-organisation admin check.Move to another organisation →Security counts that open what they count
A finding row in the Security Center used to say Open · 7 and Resolved · 2 next to 7 clusters · 7 workloads and leave you there: none of it was clickable, and the two resolved occurrences were not even loaded, so the sheet’s own Resolved filter answered no occurrences match under a chip that said two. Every number on a row is now a way in. A status chip opens the finding on that status - the live ones filter the remediation plan, Resolved lists the occurrences the latest scan no longer reports, most recently resolved first, with the workload, the image and when each went away. The affected cell opens a new Affected clusters table: one row per cluster with its live workloads, the same four counts, and when it last reported the finding, each cluster deep-linking into its own Security tab with the finding already open. The chips are now labelled Occurrences and say so in the sheet - one per workload, container and image - which is why seven open occurrences can sit beside seven workloads and two resolved ones. Counts and lists come from the same query, so a chip never names a row the sheet cannot show; the API carries both asclusters on the finding detail and a paginated GET /api/v1/org/security/findings/{finding_id}/occurrences?status=…&cluster_id=….Security Center findings →A verified email before invitations
Signing in now proves the mailbox before it proves anything else. An account whose email address is still unverified can no longer pick up an invitation sent to that address: Pending invitations stays closed and accepting one answers Verify your email address before acting on invitations until the verification link has been opened - then the same account is admitted and the invitation is waiting where it was. A first sign-in with a provider that does not share an email address at all (some Microsoft Entra ID and social identities) is refused with a clear message instead of creating an organisation that could never be contacted or invited; sign in with an account that carries an address. Accounts created before this keep signing in as they did.Roles and access →The Ankra registry cleans up after itself
Images pushed to your organisation’s private Ankra registry no longer accumulate forever. Every organisation project now carries a retention policy that Harbor runs once a day: an artifact is kept while it was pushed within the last 30 days, and the three most recently pushed tagged versions of every repository are kept regardless of age. Older tagged images beyond those, and the untagged leftovers of overwritten tags once they are 30 days old, are removed. Plan rollbacks around it - a version is reachable while it is one of the last three or under 30 days old - and redeploy long-lived workloads from a recent build so a reschedule never reaches for an image that is gone. Registries you operate yourself are not touched.Image retention →Move a Docker deployment into a cluster in one command
Getting an application off Docker Compose used to be two jobs, and the second one was the hard one: translating the services into Kubernetes objects, and then getting the data out of the containers and into the databases you just deployed, by hand, with a laptop in the middle holding a copy of production.ankra migrate up ./app --cluster production does both. It converts the Compose project into a stack, applies it to the cluster, waits until each database workload has a ready pod, dumps the deployment’s PostgreSQL, MySQL and MariaDB databases, and restores them in-cluster. --plan prints what it found first and changes nothing: the databases with their sizes read from the running containers, the estimated dump size against your free disk, and an explicit list of what will not be carried across. The run is re-runnable, so you rehearse against a live source and then cut over with --stop-source, which stops the source’s non-database services before the final dump and prints the docker start command to bring them back.The dumps travel through your own backup vault: the CLI uploads to your bucket on presigned URLs, and the cluster’s agent runs a Job that verifies the SHA-256 sums and restores. Ankra never holds the data, no vault credential reaches the cluster, and nothing on your machine needs kubectl or a database client. The individual steps stay available as ankra migrate convert, export, data, restore and restore-status when you want to inspect what each produced.Compose is only the format that ships with it. The conversion and the export are done by a module, and any executable named ankra-module-<name> on your PATH or in ~/.ankra/modules is one: it answers describe, detect and convert with JSON on stdin and stdout, adds export if it can dump its own databases, and can be written in any language. ankra migrate modules lists what you have, and a worked example in about a hundred lines of Python ships in the CLI repository.Moving a Docker deployment → · Writing a module →The inbox knows who a message is for
A notification is now addressed either to the whole organisation or to one person. Personal messages reach only their addressee, wear a For you marker in the Activity feed, and count separately - so a direct message never drowns in the organisation’s pile. Filter the Activity page by audience (All messages / For you / Organisation) to see just yours or just the shared ones. Reading, acknowledging and dismissing were already per person; the audience makes the distinction visible everywhere, API included (audience on every notification, an audience list filter, and personal_unread on the counts).Activity & Inbox →A DevSecOps agent on every AI team
Every organisation’s default AI team gains a sixth member: DevSecOps, a security specialist whose job is to resolve the critical and high vulnerabilities in the images running on a cluster. Open it from a cluster’s chat and it reads that cluster’s security report, maps each vulnerable image to the connected application deployed there - or to the add-on the report attributes it to - and fixes at the source: base-image and dependency bumps opened as pull requests on the application’s repository, one per application with every CVE it clears listed, and add-on upgrades proposed with a rollback. Known-exploited CVEs come first; a CVE with no fix is reported, not hidden. Its capability envelope refuses deleting a resource, an application, a stack, or an add-on, so a finding is never made to disappear by removing what runs.Organisations that already have the five-agent team get the DevSecOps agent the next time anyone opens AI → Agents; a default you deleted stays deleted. It arrives ready to act: it ships acting as your organisation’s agent identity, which Ankra provisions on the operator role the first time the roster is opened - no board-staffing setup first - while its Propose autonomy keeps every cluster write behind your approval. Stand the identity down under Settings → Autonomy → Board staffing if you would rather it only reports.The DevSecOps agent →Every platform agent now runs on the cheap rung
The six default roles and the four catalog agents (Incident Responder, Gap Scanner, Reviewer, Nightly Auditor) now ship pinned to Quick, and agents already seeded or hired from those templates that nobody had pinned move to Quick too. Agents you created yourself, and any agent whose model you chose, keep their setting. Raise a single agent to Think or Expert from its Edit dialog when its work needs deeper reasoning.Model →Every AI agent can run on a cheaper model and carry a daily token limit
Every organisation AI agent now has two cost controls of its own. Model pins the agent’s turns to a rung of your model catalog - Quick, Think, Expert, or a custom entry - instead of leaving each turn to the router; the DevSecOps agent ships on Quick. Daily token limit caps what the agent may consume in one UTC day across its runs and persona chats. An agent that reaches its limit is not dispatched again until midnight, a turn already running finishes with one wrap-up iteration rather than being cut mid-thought, and a notification - in the inbox and through your notification routes - names the agent, the tokens used, and how to raise the limit. Today’s usage sits beside the limit on the agent page. The DevSecOps agent ships with a 2,000,000-token day; the other defaults stay unlimited until you set one.Models and daily token limits →Debug pods that impersonate a workload
A distroless image has no shell to attach to, and a crash-looping container is gone before a terminal can reach it. Debug on any pod now spins up a separate pod that impersonates it - the same service account, the same node, the same volumes and volume mounts, the same environment variables andenvFrom sources, the same tolerations and security context - under an image chosen for its tools: netshoot by default, or busybox, alpine, ubuntu, or any image you name. You land in its terminal with the workload’s mounts and environment in front of you, and the workload itself is never modified. New debug pod on the pods list does the same from a namespace, with nothing mirrored.Two things are deliberately not copied. Labels never are, so a debug pod never sits behind the workload’s Service or inside its PodDisruptionBudget; and host namespaces are left alone. Every debug pod carries a lifetime (30 minutes to 8 hours) that the kubelet enforces on its own, the agent removes expired ones, and creating or deleting one writes an audit row naming the image and what was mirrored. Creation needs kubernetes.write and kubernetes.exec. From the CLI: ankra cluster debug create --namespace <ns> --from-pod <pod>, plus list, delete and images. Needs cluster agent 2.1.1074 or newer.Debug pods →Every pod terminal session is recorded
Opening a terminal into a pod used to leave no trace. It now writes anopen_pod_terminal audit row, and everything typed and everything the container answered is stored with the session (up to 4 MiB; longer sessions are marked truncated). In the organisation audit log and a cluster’s Audit tab, the row shows the session’s facts - who, which container, which shell, how long, how it ended - and Replay session plays the recorded output back into a read-only terminal with the typed input listed beside it. ankra org terminal-session <id> --transcript prints the same recording. Transcripts are readable with audit.read and never travel inside the audit row itself.Recorded sessions →Multi-zone UpCloud clusters on a WireGuard mesh
UpCloud has no multi-zone region - every private network, router and load balancer is bound to one datacenter - so an UpCloud cluster was a single failure domain, and the only answer to “what if Helsinki goes down” was a second cluster.A cluster can now be created across a zone pool: passzones (at least three, with three control planes, one per zone) and Ankra builds a router, private network and NAT gateway in every zone, joins the nodes with a platform-managed kernel WireGuard mesh over UpCloud’s account-wide utility network, and has Kubernetes advertise the overlay address on every node. Control planes spread one per zone, node groups spread across the pool or pin to a zone with zone, day-2 growth follows the pool, and ankra cluster upcloud zones adds zones later. Losing a zone costs capacity, not the cluster. Load balancers and volumes stay in the primary zone - both are zone-local on UpCloud - and every node carries the standard topology labels.Multi-zone placement is rolling out per organisation; ask us to enable it for yours.Multi-zone clusters →GitOps repoints are atomic, and a wrong branch cannot strand a cluster
Moving a cluster to a different GitOps repository or branch withankra cluster apply --allow-repoint used to commit the switch first and write the cluster’s state to the new source second. A target Ankra could not write to - a branch that did not exist, a branch protected against direct pushes - left the cluster bound to it with its sync baseline cleared, one sync away from applying whatever stale file sat at the target’s head.The write now happens first, on the same transaction as the switch, so a failed write changes nothing: the cluster keeps syncing from its current source and the error says so. A branch that does not exist is refused before anything is attempted, together with the branches the repository does have. The refusal you see without the flag also describes what a repoint actually does - Ankra writes the cluster’s current state to the new source before syncing from it - instead of predicting a prune from the target’s current contents.Repointing a cluster →Find an organisation by typing its name
If you belong to many organisations, the profile menu’s Switch organisation submenu used to run off the bottom of the screen with no way to scroll it, and the All organisations and Create organisation links at its foot went with it. The submenu now opens with a search box: start typing anywhere in it to narrow the list by name, slug or id, press Enter to switch to the first match, or use the arrow keys to pick one. The list scrolls within the screen, and the links stay pinned below it - All organisations now shows how many you belong to.The All organisations page gained the same search, lists your current organisation first, and pages through the rest twenty at a time; its page controls, previously decorative, now work.Switching organisations →Known exploited vulnerabilities (CISA KEV) and EPSS in the Security Center
A CVSS 9.8 nobody is exploiting used to outrank a CVSS 7.5 that is being exploited right now. The Security Center now cross-references every finding with the public CISA Known Exploited Vulnerabilities catalog and the FIRST EPSS exploit-prediction scores, joined platform-side by CVE id, so no image data leaves your cluster and Trivy Operator needs no extra configuration.Findings carry a KEV marker with CISA’s date added and remediation deadline, plus the EPSS probability and percentile. Filter with the new Known exploited (CISA KEV) chip, sort by Exploitability (KEV first, then EPSS, then severity), and read a Known exploited tile on the fleet scorecard. Cluster, workload, and add-on posture views count known-exploited findings, remediation candidates rank them first, and the scheduled security email calls them out with their own banner. Alert rules gain twosecurity_findings metrics - kev and new_kev_cves - and the new-CVE notification now flags KEV listings of any severity. The same fields ship on the security API (known_exploited, kev_date_added, kev_due_date, kev_ransomware_use, epss_score, epss_percentile, plus a known_exploited filter) and in the AI security context.Exploitation intelligence →Every CVE has an Ankra advisory page
A finding used to hand you off to the scanner’s advisory site - avd.aquasec.com, nvd.nist.gov - to learn what a CVE actually is. The Security Center now has its own advisory page for every CVE: the platform reads the public record from the NVD 2.0 API and OSV, parses it, and renders it in the Security Center’s vocabulary. The Advisory link on every findings row and Open advisory in the finding sheet lead there.The page carries the analyst description with CWE ids and aliases; CISA’s KEV entry, the EPSS probability and CISA’s SSVC decision under Exploitation; the lead CVSS score with its vector spelled out component by component and every published assessment behind it; the affected products and version ranges from both sources, written as “2.34 before 2.39 (fixed in 2.39)”; the organisation’s own findings for the CVE with a link into each; and the sources’ references grouped patches-first. It tells “not read yet” (the page polls while the platform fetches the record, and opening it puts that CVE at the front of the queue) apart from “no public record”, and a provenance footnote says when NVD and OSV were last read. Stored records are re-read every two weeks. The API serves the same content atGET /api/v1/org/security/advisories/{cve_id}.Advisory pages →Known-exploited vulnerabilities are now impossible to miss, and the Security Center answers in milliseconds
The KEV signal was easy to walk past: a small marker in a column, on a list sorted by scan time. Now, when CISA lists any of your actionable findings, the Overview, the Findings page, and every cluster’s Security tab open with a red exploited in the wild banner that says how many vulnerabilities are being exploited, how many are past CISA’s remediation deadline, and how many CISA links to ransomware campaigns - with Review exploited findings and Fix with AI one click away. Findings open ranked by Exploitability (KEV first, then EPSS, then severity), each listed row shows CISA’s deadline in explicit tense and a ransomware marker, the Known exploited tile carries the overdue and ransomware subsets, and the finding sheet quotes CISA’s own entry: vulnerability name, vendor and product, and CISA required action. The API addskev_vendor_project, kev_product, kev_vulnerability_name, and kev_required_action on findings and candidates, and known_exploited_overdue and known_exploited_ransomware on the overview; the AI security context carries the deadline and required action too.Underneath, the Security Center stopped re-counting every scanner observation your organisation has ever recorded on each page load. The overview, the findings list and its filter counts, the remediation candidates, and the cluster posture now read from posture rollups the platform keeps current inside the same transaction that records a scan or a disposition change - so a findings page that took four to twelve seconds on a large fleet (and timed out under load) answers in milliseconds, and acknowledging a finding is reflected on the very next load.Exploitation intelligence →kubeadm is the default distribution everywhere
A cluster created without adistribution now gets kubeadm - vanilla upstream Kubernetes with Cilium - on every surface: the API, the CLI --distribution flag, the AI create tools and the Terraform provider, matching what the create wizards already preselected. An omitted cni follows the distribution: Cilium on kubeadm, Flannel on k3s. k3s stays fully supported - pass --distribution k3s (or "distribution": "k3s") to get it - it is just never a default. Existing clusters are untouched.Order playgrounds at the size you need
The playground is no longer one fixed try-it size. Create cluster now offers Playground as a first-class option: pick a size - from the free Trial up to 16 vCPU / 32 GB - and Ankra provisions it on its own infrastructure, no cloud account or credentials needed. Each size shows its flat monthly price in the picker.Only the free Trial is limited to one per organisation; paid playgrounds can be many, bounded by a per-organisation memory budget of 8 GB by default. Ordering a paid size requires billing permissions, a billing plan and a payment card on file - the Trial needs none of that. When a size does not fit, the picker offers a limit-increase request - the new limit and a short justification, reviewed by the Ankra team, with a notification when it is decided. The free monthly AI allowance gains the same request path from the billing page’s allowance card.Paid playgrounds also resize in place (Settings → General, orankra cluster playground resize): the quota and the monthly price change, billed pro-rata across the change, and nothing you deployed is touched. Billing is fair by construction - it runs from the moment the environment is ready, never from the order that placed it - and every order, resize and destroy leaves a notification receipt. Organisations with long-overdue invoices have new paid orders refused and, after three weeks, paid playgrounds reclaimed.The price you order at is the price you keep - later catalog changes never re-rate a running environment. Sizes the shared pool cannot place right now are shown greyed out rather than hidden, and the free trial keeps its one-click path everywhere it exists today: the first-run screen, the create-cluster dialog’s banner, and ankra cluster playground create.The whole lane now speaks every surface: alongside the portal, the /api/v1 API and the CLI, Ankra AI and the MCP tool catalog can list the sizes with live availability and budget headroom, order a playground, check its provisioning, resize it, destroy it, and file a limit-increase request. The mutating actions are confirmation-gated - the approval card names the size and the monthly price before anything is ordered - and every billing gate applies identically to what a chat agent orders and what a click orders.Limit requests live under billing, and the billing page now shows it: a Playground memory budget card reports how much of the budget your paid playgrounds use, carries the same request path the size picker offers, and - like the AI allowance card beside it - shows a pending request under review and a declined one with its outcome, so a decision is discoverable where the request was made.Billing now opens with This month - what each thing has cost so far and where it is heading. Compute and playgrounds, which are charged to your invoice in EUR, sit in one group; the AI allowance included with your plan, priced in USD and never invoiced, sits in another - so the two currencies are never added together. Every row reads the same way: what you used, so far, projected, and the limit that applies. Playground spend, previously invisible on every billing surface, is now reported and split from compute, and each invoice shows its playground share as its own column. Two fixes landed with it: the playground memory budget counts only environments you actually have (a destroyed or failed environment no longer holds your budget), and reads the organisation whose billing page you are on rather than the one you last switched to.The playground memory budget now names the playgrounds it counts - plan, name, memory and when each was ordered - on the billing page’s budget card and in the plan catalog (GET /org/clusters/playground/plans, and the list_playground_plans chat and MCP tool). A budget past its limit, such as a Large ordered before the budget existed, reads as what it is rather than as a miscount, with a line on what over budget means: new playgrounds and upgrades wait, what you run keeps running. The order gate now counts exactly what the catalog shows. And billing stops when the receipt says it does: destroying a playground closes its price of record at the request, not when the teardown finishes.Playground →A Nodes section for every cluster
Every cluster gains a Nodes section in its sidebar, directly above Kubernetes: the infrastructure view of the machines it is made of. The overview joins what the cloud provider knows about each VM with what Kubernetes knows about the node - role, group, instance type with vCPU, memory, disk and list price from the live catalog, a GPU chip from the node’s feature-discovery labels, Kubernetes readiness with the kubelet version, the VM’s state, location and addresses - and puts the controls on the row: cordon, uncordon and drain with progress, restart the VM, resize the bastion, open the node in Kubernetes, or the provider’s record. A machine Kubernetes has never seen reads Not joined or Not a node, never as broken. Stat tiles sum the fleet - machines by role, ready nodes, vCPU, memory, GPUs, monthly run rate - and say not reporting rather than zero when a figure cannot be read.Node groups, the control plane and the bastion each get a tab. The node-groups tab carries everything Settings → Nodes offered plus Max out: Ankra reads your cloud account’s remaining quota through the cluster’s credential and sizes a group to the most it can hold - the tightest of remaining servers, vCPUs and memory for the group’s instance type, capped at 100 - naming the bound and the added cost before you confirm, and saying unavailable when a provider hides its limits rather than guessing. The bastion tab shows its health as the scheduler last recorded it, with diagnose-over-SSH, restart and resize. The same quota report is on the API asGET /org/clusters/{provider}/{cluster_id}/quotas. Settings → Nodes redirects to the section, so older links keep working.Playgrounds carry their size card on the overview: a paid one names the direction and the monthly difference before a resize (Upgrade to Medium: +€15.30/mo), and the free trial offers Upgrade to a paid size instead of a card with no control.The same tab adds standalone VMs: a machine on the cluster’s network that is not a Kubernetes node - a database host, a build box, a jump host of your own - provisioned the way the bastion is, with the cluster’s SSH keys, private-network only unless you give it a public address, and kept running when the cluster is stopped because it carries your state. Add one by name and size from the live catalog, then restart, resize or remove it from its row; VMs also appear in the machines table with the role VM. Available on Hetzner, UpCloud, DigitalOcean, OVH and Proxmox clusters, and the bastion and every VM are now metered into the cluster’s cost as Bastion & VMs. The UpCloud node-group picker reads the cluster’s live catalog too, so GPU plans appear with their accelerator fit and price. The API carries VMs under /org/clusters/{provider}/{cluster_id}/vms.Nodes →Agent Skills for every AI assistant, not just two
ankra skills install used to reach Cursor and Claude Code. It now detects the AI assistants
configured on your machine and installs Ankra’s curated Agent Skills into all of them: Claude
Code, the Claude app, Cursor, Codex, GitHub Copilot, Windsurf, Gemini CLI, OpenCode, Cline, Zed,
OpenClaw, and anything that reads AGENTS.md. --client replaces --editor (kept as a
deprecated alias) and takes a list, all, or auto; ankra skills clients shows what was
detected and where each assistant’s skills land.Assistants with no skills mechanism of their own get the skills in a shared library plus an index
in the file they always load - which is what makes the skills work there at all. The Claude app,
which cannot read your filesystem, gets one uploadable bundle per skill. Assistants with slash
commands also get the Ankra workflows: /ankra-new-cluster, /ankra-ship-service,
/ankra-connect-app, /ankra-triage, /ankra-promote, /ankra-harden and /ankra-profile.The skill set grew to twenty-two, adding end-to-end coverage for getting started, building
clusters (provider, region, instance family), domains and DNS, deploying applications, wiring an
app to services that already run (an LLM gateway, Harbor, a database), stack profiles,
troubleshooting, security, and supervising Ankra’s own AI agents - and every ankra command the
skills document is now verified against the CLI’s real command tree at build time.Agent Skills →A ticket now shows what its agent is doing right now, and opens the session it is doing it in
A ticket said an agent was assigned and, while a run was live, showed a pulsing dot - and then nothing moved for the whole run, so there was no way to tell a busy agent from a wedged one. The timeline now ends in a live panel while a run is in flight: a spinner, the step the agent is on with what it is calling it on, and the last few steps behind it, updating as the run moves. A queued run, and one parked waiting for a person, say that instead of claiming to be working.The session behind it is now reachable, which it was not from anywhere. Open the agent’s session on the live panel, the is working chip at the top of the ticket, the timeline entries recording that a run started and how it ended, and the Agent run entry under Linked all open the transcript of the run working that ticket - to read its tool calls and results, answer a question, decide an approval, or guide it. Every run has its own address (/organisation/ai/agents/runs/<run id>), so a pasted link opens the run it names; previously each of these landed on the agent’s most recent run instead, which for an agent working several tickets was the wrong session. Picking a run on an agent’s page puts it in the address too, and the fleet run history opens the run you clicked rather than its agent. Fixed alongside: a finished run’s transcript replayed as tool calls and silence, because the agent’s own prose was dropped on the way to the page.Watching an agent work →The pod page is condensed too, and it shows what a container asks the GPU for
Following the node page, a pod’s Overview now opens on state chips (phase, QoS, the GPU it requests, restarts with their recency), an identity strip, and tiles for containers ready, restarts and the CPU / memory / GPU requested against limits. Each container is one compact card - state, restarts, the previous termination such asOOMKilled (exit 137), image with copy, requests → limits per resource including nvidia.com/gpu, ports, probes with their inferred status and the command line - instead of a fully expanded three-column block; init containers sit in the same list. Conditions read as one row each with the kubelet’s message only when something is wrong, the network, security, scheduling, topology, service-account, DNS and advanced cards fold into Placement and Runtime, volumes get a panel that names their source, and labels and annotations are collapsed and grouped like the node page’s.Pod details →A blocked ticket now asks its question as a choice - pick an option, or answer with something else
When an AI board agent found two ways forward and needed a person to pick one, it wrote them into a comment, moved the ticket to Blocked, and the page showed a blocked ticket with prose to read and a comment box to answer in - so the decision was easy to miss and easy to answer in a way the agent then had to re-ask about. An agent that blocks on a choice now hands the options over as data (decision_options on ticket_update_status, with a decision_prompt), and the ticket page opens on the question: each option with its summary, the recommended one marked, an optional note, and Something else for an answer in your own words. Send decision records a Decision: comment on the timeline and resumes the agent, which acts on the answer without asking again. The answer is also on the API at POST /api/v1/org/ai-tickets/{ticket_id}/decision.The same choice now reaches you wherever the ticket does. In AI chat (and over MCP) ticket_get shows the pending question and the new ticket_decide tool records your answer. The CLI gains an AI board: ankra tickets list|get|events|comment|transition|decide, with ankra tickets get T-8 printing the options and ankra tickets decide T-8 --option a (or --answer "...") answering them. In Slack and Teams the thread reply that announces the block, and the escalation card while the ticket still waits, carry the options as buttons - the recommended one highlighted - and Something else asks for a thread reply starting with Decision:, which is recorded as the answer rather than as a plain comment.Answering a choice →The cluster domain is your own domain once a custom DNS zone publishes it
An organisation whose domain lives in its own DNS account cannot register it as its Ankra domain, so it sets it as the Preview domain and declares it as a custom DNS zone - and was still told its cluster domain was<cluster>.<org>.ankra.cc. ${{ ankra.cluster_domain }} now resolves to the Preview domain whenever a custom DNS zone declared for the organisation or the cluster covers it, and the same rule drives Ankra AI’s hostname advice (get_preview_domain reports cluster_domain and who publishes it), ankra cluster domain (a new Public domain line), and the Preview domain’s “hostnames will not resolve” warning, which no longer fires for a domain the cluster’s own external-dns publishes.Built-in variables →The node page is redesigned, and it knows about GPUs
A Kubernetes node’s page now opens on a header of readiness, role, accelerator, instance type, provider and placement chips, a fact strip, and stat tiles for what the scheduler can hand to pods - CPU, memory, GPU, ephemeral storage and the pods placed on the node against its limit. Conditions read as Healthy or Problem with reason, message and last transition rather than a rawTrue/False; the system, network, allocatable-resources, taints and cached-images cards replace the old key/value lists; and labels are grouped by prefix with search and click-to-copy, so a node carrying sixty discovery labels is readable.On a GPU node - nvidia.com/gpu, a MIG profile, amd.com/gpu, Intel or Gaudi - an Accelerator card reads the GPU Feature Discovery labels the GPU operator stamps on the node: product, family and compute capability, count and memory per GPU, CUDA driver and runtime, sharing strategy (exclusive, time-slicing, MPS, MIG with its active profile), vGPU, driver-upgrade state and the operator components deployed, plus whether the device plugin is advertising allocatable GPUs yet. With a Prometheus metrics source connected it reads the DCGM exporter too: utilisation, framebuffer, temperature, power, clocks and the pod attached to each GPU, the pods on the node requesting GPUs, and per-GPU charts on the Metrics tab.Kubernetes Nodes →AI board tickets now show what a fix actually changed - the cluster, the stack, the operation, and a bill of materials
A ticket tracking a fix the AI chat or an agent applied used to show a timeline of tool names and a Pending action link that opened the whole Inbox - nothing on the page said which cluster or stack was touched, what changed in it, or whether the apply had actually run. The ticket now carries a Changes ledger, one entry per applied action like a commit log: the tool, who approved it, the risk and reversibility, the cluster and stack with the namespaces involved, the times it was proposed and settled, and the operation it created on the cluster’s operations ledger with its step outcome - the entry reads applying while the apply is still running and failed if it failed after the tool returned. Expanding an entry shows the same bill of materials the approver reviewed: addons with chart and version, manifests with kind and namespace, and their diffs. A Bill of materials panel in the rail folds every change into the ticket’s blast radius - clusters, stacks, namespaces, addons, manifests and executions, each linked to its page - and Cluster context gained Stacks and Operations shortcuts. The ledger is also on the API at/api/v1/org/ai-tickets/{ticket_id}/changes.Changes and the bill of materials →Declared registries can keep their flat component repositories, and an application can be moved to another GitHub credential
Two follow-ups from wiring the first organisation onto its own Harbor. A monorepo’s images were always addressed as<project>/<app>/<component>, so a registry whose pipeline had been publishing commerce-images/backend for months looked unpublished to Ankra; flat_repositories on the image registry declaration (Settings → Image registry, ankra application registry set --flat-repositories) makes publish readiness, the deploy gate and the generated workflows use <project>/<component> instead. Where the names differ altogether - commerce-images/commerce-backend - component_repositories names each component’s repository outright (--component-repository backend=commerce-backend, or one field per component in the settings panel). And the GitHub credential an application was created with can now be changed - ankra application credential set <application-id> --credential <name> - so an application bound to an App installation that cannot reach its repository no longer has to be deleted and recreated.Using your own registry →Every application now gets its own registry robot account - on Ankra’s registry and on a Harbor you operate
Applications used to log in to the registry with one push robot shared by the whole organisation, and an application that publishes to a Harbor you run got no robot from Ankra at all - you created one by hand and pasted it into the repository’s Actions secrets. Ankra now mints a push robot per application (robot$<project>+app-<application-id>) on the project it publishes to, stores it as a managed registry credential, and writes it into the repository as the build’s login, so a leaked secret is rotated or revoked for that one application and a deleted application takes its robot with it. On your organisation’s Ankra registry this happens on setup and reconcile, with no action needed; applications onboarded earlier get theirs the next time Fix automatically runs or when you create it from Settings → Image registry. On a registry you operate, name a credential with project administrator rights as admin_credential_name on the image registry declaration and Ankra mints, rotates and revokes the robot there too - without it, your robots stay yours and untouched. Create, rotate and revoke from the application’s settings, with ankra application registry robot get|ensure|rotate|revoke, or on the API at /api/v1/org/applications/{application_id}/registry-robot.Robot accounts →DigitalOcean GPU Droplets are now priced in the cloud cost view
Fixed: a DigitalOcean cluster with a GPU Droplet worker (gpu-h100x1-80gb, gpu-l40sx1-48gb, and the rest of the gpu-* sizes) showed only its CPU nodes on the Cloud Cost card and in the cluster Cost view. The GPU size had no row in the price catalog, so the worker was priced at zero and dropped out of the compute total - the coverage counter was the only hint that the estimate understated the bill, while the create wizard, which reads DigitalOcean’s live prices, showed the real figure. Every GPU Droplet size DigitalOcean sells - RTX 4000 Ada, RTX 6000 Ada, L40S, H100, H200, MI300X, MI325X, and the Spot GPU sizes - is now priced at its on-demand hourly list rate. GPU Droplets are billed per second with no monthly cap, so the hourly rate is used as published rather than fitted to a capped month. The correction lands on the next hourly metering pass; there is nothing to do.Cloud cost →A zone in your own DNS account is now served from every cluster in the organisation
A DNS zone you keep in your own provider account can be declared once, for the whole organisation, and every cluster - the ones running now and every one created afterwards - gets its own Ankra-managedexternal-dns for it. Until now the declaration was per cluster (ankra cluster custom-dns-zones), so a freshly created cluster came up with its Ingress hostnames on your domain dropped silently and its certificates waiting for DNS that nothing was publishing. ankra org dns credentials create stores your external-dns webhook credential (into the platform’s secret store - it embeds the token, so no read surface returns it), and ankra org custom-dns-zones add --zone <zone> --credential <name> declares the zone; each cluster’s controller is pinned to exactly that zone with its own record ownership, so it can never fight Ankra’s own controller, another cluster’s, or records you publish yourself. A cluster’s own declaration of the same zone still wins on that cluster, ankra cluster custom-dns-zones list now says where each zone was declared, and withdrawing the organisation’s declaration tears down only the controllers Ankra rendered. The same is available on the API at /api/v1/org/custom-dns-zones.Serving a zone in your own DNS account from every cluster →Node groups now show their availability zones
On an OVH cluster in a 3-AZ region,ankra cluster node-group list and ankra cluster ovh node-group list now end each line with az= and the zones the group’s nodes were placed into, and the node-group listing API carries them as availability_zones. Until now the only way to see where a group’s nodes sat was one ovh nodes get call per node, which is how two groups named for zones a and b came to sit entirely in zone c on a cluster built for multi-AZ without anything on the listing saying so.That placement was the balancer working as designed rather than a rendering fault: a group added without --availability-zone takes the zone with the fewest instances cluster-wide, so a one-node group lands wherever the cluster is thinnest. The guide now says so, the --availability-zone flag help says so, and the create_node_group audit action records the zone the request asked for, blank included, so whether a group was created pinned is answerable from the audit trail from now on.Availability zones →Top-level hostnames on your custom domain now publish through Ankra
With a custom Ankra domain registered, theexternal-dns Ankra installs on your clusters can now publish DNS records anywhere under the domain - top-level hostnames like app.example.com included - instead of only inside each cluster’s <cluster-id>.<org-id>.<domain> subzone. Existing clusters are re-credentialed automatically on the reconciler’s next pass; there is nothing to do. On the shared ankra.cc domain the scope is unchanged: each cluster’s external-dns writes only its own delegated subzone, because names directly under ankra.cc are shared platform namespace.Start and stop clusters from the cluster menu
Start cluster and Stop cluster now sit in the cluster’s ⋯ menu, on the cluster overview and on the clusters list — no more digging into Settings → General → Danger Zone to power a cloud cluster on or off. A running self-managed cloud cluster (Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, Proxmox VE, HPE Morpheus) offers Stop cluster; a stopped one offers Start cluster, including the choice to restore everything or the control plane first. Both entries open the same confirmation dialogs as the Danger Zone — stopping still asks you to type the cluster name — and are disabled while another operation is running on the cluster.Stopping and starting clusters →Ask Ankra AI from a pull request comment
Mention@ankraai in a comment on a pull request in a repository the Ankra GitHub App is installed on, or in a connected Bitbucket Cloud workspace, and Ankra AI answers on the pull request with the diff and the pull request’s metadata as its context. Ask it to explain a change, to check a failing pipeline against the diff, or to review the pull request on demand. The mention is matched case-insensitively, anywhere in the comment, and is answered regardless of the draft, branch, and daily-budget rules that gate automatic reviews. Ankra reacts with 👀 the moment it picks the mention up, so you know it is working before the answer lands.In an integration set to Agent mode the reply can go further: when the fix is clear, Ankra proposes it as ready-to-apply file changes and offers to open it as a pull request. Ask mode stays read-only.Mention replies sit next to the automatic AI review that runs on every opened or updated pull request, and PR previews for applications. All three are switched on per installation under Organisation settings → Integrations, with repository rules for the exceptions.Ankra AI on pull requests →A preview domain now tells you it needs DNS, and a demo stops claiming a URL that does not resolve
Fixed: a demo published on your own Preview domain reported ready with anhttps URL that had never resolved, and nothing anywhere said why.Ankra publishes DNS only inside the subzones it delegates. The external-dns credential it provisions for a cluster is scoped to that cluster’s own Ankra subzone, so a preview hostname on your domain is filtered out by the DNS provider before a record is written - and the sync goes on logging All records are already up to date, because from external-dns’s point of view there is nothing in scope. Publishing those records was always yours to do, and that was written down nowhere.Saving the settings now says so when the domain answers nothing, naming the wildcard to create and the staging cluster’s own ingress address to point it at. It also names the consequence for TLS, because the two preconditions were being checked independently and only one of them enforced: an HTTP-01 challenge is answered over the hostname being certified, so an unpublished preview domain costs you the certificate as well as the URL. A domain you have already pointed at the cluster says nothing, as before.A demo whose hostname does not resolve is no longer reported ready the moment its pods are up. It waits briefly for the name to answer, and is published anyway if it does not, so a domain nobody has pointed still gives you a demo rather than a failure - just not one that claims to be reachable.The docs now state outright that DNS for preview hostnames is the operator’s responsibility when a preview domain is set, and what a working wildcard has to point at.Previews on your own domain now get certificates
Fixed: setting a preview domain silently turned off TLS for demos, and there was no way to turn it back on.Demos published on a staging cluster’s own Ankra subzone have always been issued a certificate per preview hostname. Setting your own Preview domain stopped that, on the assumption that an organisation bringing its own zone would bring its own wildcard certificate and name it in the TLS secret field. That assumption does not survive contact with a stock cluster: ACME issues wildcards only through DNS-01, the ClusterIssuer Ankra’s networking stack installs is HTTP-01 only, and Ankra ships no DNS-01 solver for its own DNS provider. The field could not be filled, so demo ingresses carried no TLS and preview URLs quietly came back ashttp://.Nothing about your own base domain required a wildcard. Each demo’s hostname is concrete when the ingress is written and resolves publicly, so the same per-host HTTP-01 challenge completes. Ankra now requests a certificate on both paths, under the same check it already ran: only when the staging cluster carries a verified ACME HTTP-01 ClusterIssuer, so a cluster without one stays on http rather than advertising TLS against a certificate nothing will issue.The new Certificate issuer field names a different ClusterIssuer, for a cluster whose issuer is not the one the networking stack installs. A TLS secret on its own still means you supply the certificate and Ankra requests nothing.Where previews would land on plain http, saving the settings now says so, in the portal and in ankra org ai-environment, instead of succeeding without comment.The preview settings are reachable from the CLI
ankra org ai-environment get|set reads and writes the preview domain, ingress class, TLS secret and certificate issuer. These are the settings you script when standing up on-demand environments on your own domain, and until now ankra org domain covered only the organisation’s root domain - a different setting on the same screen with a much wider blast radius. Only the flags you pass are written, and passing one with an empty value clears that field alone.ankra org domain --help now names the preview domain as the separate setting it is, and points to the right command for it.Removing a cluster domain now sticks
Fixed: the documented procedure for switching an organisation’s Ankra root domain could not be completed. Removing a cluster’s domain worked - and then the domain came back, active and under the same name, about fifty seconds later. Since the switch is refused while any cluster domain still lives under the old root, every removal was undone before the next one could be made, and the switch was permanently out of reach.Two things put the domain back. Ankra treats being an organisation’s staging cluster as a standing request for a domain, and it read “this cluster has no domain” as “this cluster needs one” - a removal and a cluster that never had one were indistinguishable. A removal is now recorded as a deliberate act and held: nothing re-creates the zone, including theexternal-dns Ankra runs on that cluster, until you ask for it back with ankra cluster domain <cluster> --enable. A read reports Opted out: yes while the hold stands, so a domain that is gone no longer looks like one that is between passes.The second was a playground. A playground publishes a wildcard DNS record in the organisation’s zone, and that record is reconciled rather than written once - so deleting it only lasted until the next pass. A refused switch now separates the records you can clear from the ones the platform re-asserts, names the writer of each, and names the playground environment to destroy instead. ankra cluster playground destroy <cluster_id> is new: the platform has served that call since playgrounds shipped, but the CLI could not reach it.The refusal also explains itself better on the cluster-domain side, and the docs now answer the two questions that decide whether the switch is safe on a domain you already use:- Ankra confines itself to one subzone of the domain you register. Registering
example.comcreates<org_short_id>.example.comand nothing else. Records already published at the apex or under any other name are never read, written or deleted - not by the switch, and not by anything Ankra runs afterwards. - A switch never re-labels a zone. Labels come from the cluster and organisation ids, so a cluster keeps its label across a switch - and with it the
--txt-owner-idof itsexternal-dnsand any GitOps path built from it. The TXT ownership registry stays matched to its records, which is what makes a--policy=synccontroller safe across the change.
Approve or reject any ticket awaiting approval
Fixed: a ticket an agent parked at Awaiting approval without a plan - asking for a decision rather than a plan review, such as “needs a capacity decision or an alert threshold raise” - offered nothing to decide it with. The Approve and Request-changes buttons lived inside the Plan panel, which only renders when a plan exists, and the review endpoint refused the verdict outright. Every ticket awaiting approval now carries a decision panel at the top of the page: Approve releases the ticket to Executing; Reject asks for a reason and sends the ticket back to Planning, where the agent reads the reason and re-plans. The same panel decides automation approval gates on the run (Approve / Deny) without a trip to the Inbox, and points at the Needs your approval card when the agent is parked on a risky action instead.Debugging a broken workload without handing out kubectl
The CLI could read a cluster - fifteen resource kinds, pod logs, metrics, operation steps - but it could not answer the questions a broken workload actually raises. Why is this pod not ready? What did the container that just died print? Which container ate the memory? Each of those ended in a cluster access grant and kubectl through the gateway: broader standing access than the task needed, and outside the record Ankra keeps of everything else.Four commands close that gap, and none of them needs a grant.ankra cluster logs --previous reads the log of the container instance that terminated. For a pod in CrashLoopBackOff that is the only output with the failure in it, and it was the one log the CLI could not reach. --previous is always a bounded read, because the log is closed - it prints and exits rather than waiting on a stream that can never produce another line.ankra cluster describe <kind> <name> answers “why is this not ready?” in one call: the object’s conditions, a pod’s per-container state with the detail that explains it - CrashLoopBackOff and its exit code, ImagePullBackOff and its registry error, restart counts - and the events whose involvedObject is that resource.ankra cluster events --for pod/my-pod scopes an event listing to one object using a server-side field selector rather than filtering a namespace-wide list by name. That is the difference between “the pod is Pending” and “no node matches the nodeSelector”.ankra cluster top pods|nodes shows live CPU and memory from the Kubernetes metrics API. ankra cluster metrics queries Prometheus, which is the right tool for trends but the wrong one for “which container just got OOMKilled” - and it needs Prometheus to have been installed. top reads metrics-server directly, so it works on any cluster that has one.ankra cluster logs also grew -l <selector> and --all-containers, so a three-replica Deployment is one command instead of a pod listing followed by three invocations, and a stuck pod’s init container is read alongside its app containers. Every one of these commands takes -o json|yaml and honours --cluster, so CI and AI agents parse them instead of scraping tables.CLI reference →One choice that answers the rest of the form
Some profile inputs only make sense together. Deploying a chat stack on a small GPU or a large one changes the model id, the context length, the memory ceiling and the size of the model store at once - and until now the form asked for each of those separately, so an operator had to know all four answers to change one decision.A profile author can now give an input options, and have each option set the others. Pick Qwen3 32B on an L40S and the model id, the context length, the GPU memory ceiling and the volume size move together; pick Qwen3 8B on an L4 and they move back. The choice renders as a card of options above the rest of the form, every input an option answers shows the value it was given and which choice gave it, and typing over one marks it customised with a reset that hands it back to the option. A required input an option answers counts as answered.Nothing about this is specific to GPU sizing: a profile can declare any number of such inputs - model size, storage tier, ingress mode - each driving its own slice of the form. The platform resolves the choice server-side in one fixed order (a value you set, then what the option sets, then the input’s own default), soankra stack-profiles apply --set model_size=32b deploys the whole set from the CLI, the AI assistant and Terraform build the same stack from the same selection, and a deployment’s recorded parameters are the values that actually deployed. Options are authored on the builder’s Inputs tab, where the mistakes publish would refuse show up inline while you edit; ankra stack-profiles get lists what every choice sets before you bind anything.Choices that set other inputs →Microsoft Teams catches up with Slack
The Ankra bot has been in Teams for a while, but it could only talk. Every button Slack users had - acknowledging an alert, approving a remediation, confirming a change the AI proposed, picking up an escalated ticket - simply did not exist there, and two of the three commands the app advertised did nothing when you typed them.Teams now has all of it. Alert cards carry Acknowledge and Snooze 1h; AI remediation approvals carry Approve and Deny; a change the AI proposes arrives as a card only the person who asked can decide, and if the cluster moved underneath it the card re-renders with what changed before letting you confirm anyway. An escalated ticket’s thread reply carries Assign to me, and Approve plan / Request changes while a plan is awaiting a verdict. A decided card is replaced by its outcome, so nobody acts on it twice.help, status and logout all answer.Every button runs as your own Ankra user through your linked account, so your role decides what it may do and the audit log records your name.Alert cards themselves are fixed too. A Teams channel destination with no custom template used to receive Slack’s card format, which Teams cannot render - so a production alert arrived as a single line of raw text with no detail and no buttons. Teams destinations now get a proper Adaptive Card with the severity, the resource, the cluster and the actions. Ticket threads stopped rendering Slack’s emphasis markers, which Teams reads as italics rather than bold.Connecting Teams is one click
Connecting a Teams tenant took five steps: download a zip, sideload it, add the bot, read a claim code out of a chat message, and retype it into a browser.The bot’s welcome card now carries a Connect to Ankra button. Press it and the portal opens with the claim code already filled in - press Connect and the tenant is bound. Pasting the code by hand still works exactly as it did.For an admin starting from the portal, the Microsoft Teams card is now a guided setup rather than a list of instructions. It leads with the path that works in every tenant - the app package - as three steps that track where you are: Download package (with a copy-link for handing the URL to a Teams administrator), the exact Apps → Manage your apps → Upload an app → Upload to your org’s app catalog path with a callout for tenants where custom uploads are switched off, and the claim code. Downloading the package and confirming the upload advance the steps, done steps fold up and can be reopened, and I already have a claim code jumps straight to the end. Arriving from the bot’s welcome card lands on the last step with the first two already ticked. Once a tenant is connected the guide sits behind Add tenant, matching Slack’s Add workspace.Connecting Microsoft Teams →Routing rules you can read before you trust them
An alert firing can reach a destination two ways at once: the alert’s own Notifications → Destinations list, and a routing rule whose Kind covers alert firings. Ankra has always delivered that once, but nothing said so, and the safe-looking move was to detach the destination from every alert - which quietly turns off the delivery you were relying on. It is now documented as a guarantee: a notification is delivered at most once per destination, routing rules are netted against the alert’s own destinations, and no rule - include or exclude, at any priority - can suppress an alert’s own destinations.Kind is no longer one value. A rule can name a list of kinds, or invert it: “Operation failed and Reconciliation failing, nothing else” is one rule instead of two, and “everything except Alert firing, because alerts already have their own destinations” is one rule instead of ten. Existing single-kind rules and API clients on the oldkind field keep working unchanged.And rather than reasoning it out, you can ask. Preview on the Routing rules page - and ankra alerts routes preview - resolves a hypothetical notification against your rules and lists the destinations it would reach, the ones it would not, and the reason for each, including which rules a Stop on match skipped and which deliveries de-duplication dropped. It is a dry run: nothing is sent.Notification routing → · Alerts →Notification cards fill in, whatever kind they are about
A destination stores one payload template, and that template renders every notification the destination receives. Only alert firings ever filled it in. An operation failure, an agent update, a reconcile failure or an AI insight routed to the same Teams or Slack channel arrived as a title above a column of blank rows - Resource, Type, Job, Cluster and Condition all empty - even when the notification’s own title named the failing resource.Every notification kind now resolves the same variables.{{resource_name}}, {{resource_type}}, {{job_name}}, {{namespace}} and {{condition_type}} are read from what the notification actually recorded, and {{cluster_name}} is resolved for every kind rather than for the five that happened to store it. An alert firing that reaches a destination through a routing rule keeps its condition, its job and a button that opens the firing itself. Where a kind genuinely has no value for a row - a cluster-level alert has no job, an agent update has no condition - the row is dropped instead of shipping empty, so the built-in Slack, Teams, Discord and PagerDuty presets are correct for every kind with no editing. If you would rather show something, {{resource_name|not applicable}} supplies your own fallback.The Test button now sends the same sample through the same renderer a real delivery uses, with every variable populated - so a template that renders under Test renders on delivery. Testing a routing rule sends the sample as that rule’s kind.Template variables → · Empty values and fallbacks →Demo and preview links are now https
Branch and pull-request demos on a cluster’s delegatedankra.cc subdomain used to serve plain http, because nothing issued a certificate for that zone. Now, when the staging cluster runs the Ankra networking stack, every demo’s ingress requests a Let’s Encrypt certificate automatically - so the preview link you share is https, with a certificate browsers trust. This applies across every surface that deploys demos: the portal, the CLI, the AI assistant, and automatic pull-request previews.Preview demos →Public DNS is visible in the UpCloud create wizard
Every Ankra-provisioned cluster can come up with its own delegated subdomain onankra.cc, with external-dns installed and wired to it - no domain to buy, no DNS provider to configure. The UpCloud create wizard now surfaces this as an Include Public DNS checkbox (on by default) beside the networking stack option, so you can see what you are getting and opt out if you bring your own DNS.UpCloud clusters →Clusters that power themselves back on
When something outside the platform stops every server of a cluster - a cloud account running out of credit, a project-wide power action in the provider’s console, a facility outage - Ankra noticed within a minute and marked the cluster offline, and then waited for you to press start. The jump host already recovered itself; the nodes doing the actual work did not.Clusters on Hetzner, OVH, UpCloud, DigitalOcean, Scaleway, and Proxmox now recover on their own. Once a cluster has been offline for five minutes, the platform asks the provider to power every stopped server back on - and only the stopped ones, so a sweep can never reboot a node that is still running. A cluster you stopped deliberately, or one mid-create or mid-teardown, is never touched: recovery only acts on clusters the platform believes should be running.Recovery is bounded the way you would want it to be. Each outage gets up to three power-on sweeps, spaced out over the first forty minutes; a cluster still dark after that - typically an account that is genuinely out of credit - is left for you, with the outage recorded so you can see exactly what was tried and when. A cluster that keeps losing power repeatedly in one day is also handed back to you, because restarting it clearly is not the fix.Metrics and log sources you can write in Git
A cluster’sspec.prometheus_metrics and spec.log_source blocks used to be write-only from the platform’s side: Ankra rendered them into the cluster document, but never read them back. Hand-adding either block in Git connected nothing, and because the document is regenerated wholesale from what the platform knows, the block you wrote could later be regenerated away.Both members now round-trip. Write spec.prometheus_metrics or spec.log_source into clusters/<cluster-name>-<cluster-id>/<cluster-name>.yaml and the next sync connects the source, exactly as the settings page would; edit a field and the next sync updates it. The accepted fields are the ones the platform stores - endpoint, credential_name, flavor and verify_ssl for metrics; provider, endpoint, credential_name, tenant_id, index_pattern, field_mappings and verify_ssl for logs - and anything else is refused with an error naming the key, rather than quietly dropped.Credentials stay out of the repository. A username, password, token or auth_scheme written inside a source block is refused by name, because ignoring it would leave a live secret in your Git history while you believed it was in effect. Create the credential in the platform and reference it by credential_name; a name that matches no credential on the cluster fails the sync instead of connecting a source that queries unauthenticated.One asymmetry is deliberate: Git can create and update a source, never disconnect one. Deleting the block does not disconnect anything - the source survives and the block is re-rendered on the next push. Disconnecting stays a platform action, in Settings → Data Sources, because inferring a destructive intent from an absent key is exactly what deleted hand-written blocks before.ImportCluster schema →Add-ons that say who can see them
The add-on catalog mixed everything into one wall of identical cards: charts from Ankra’s global catalog, charts from registries your organisation connected, and charts that pull with a credential all looked the same. The only way to tell them apart was leaving the page to check the repository list’s Global column.Every card now carries the answer. A Public badge marks an add-on from Ankra’s global catalog, available to every organisation; Organisation marks one from a registry your organisation connected, visible to everyone in it; and a Private lock marks a chart whose registry pulls with a credential your organisation added - without ever naming the credential. A curated add-on that mixes public and credential-backed charts says so (“Partially private”) instead of overstating either. The same badges follow the add-on onto its detail page, chart by chart.Add-ons →The stack profile deploy form asks only for what it needs
Using a profile with a lot of parameters meant scrolling a long, flat list to find the few inputs that were actually blank. Use Profile now separates the inputs a profile left for you to fill from the ones it already answered, and folds the answered ones behind a single Show N more inputs that already have defaults. A profile shipping twenty-four parameters with five blanks opens showing five fields.A counter tracks how many required inputs are still empty and turns green once nothing is outstanding. Profiles with many parameters gain a search box that matches on name, description, and the addon or manifest an input belongs to.Every field now names the addon or manifest it writes into, so a profile that declares the same key on two different components - twoapi-key secrets for two different services, say - no longer shows two identical labels.Secret inputs gained the controls they were missing: Generate produces a strong random value for the keys nobody is meant to invent by hand, alongside a reveal toggle and a copy button for the cases where the same value belongs in more than one field. Any input changed away from its default offers a one-click Reset.Hostname inputs fill themselves in. A cluster’s public domain is a generated
slug rather than its name, so a profile asking for chat_host used to send you
off to find it - gpu-chat’s description literally told you to ask the AI. Pick a
target cluster and those inputs now offer Use cluster domain, which writes
the hostname the deploy will actually serve on. Switching cluster re-offers the
button rather than rewriting what you typed, so a hostname still pointing at the
previous cluster is visible instead of silent.The dialog names the profile and version it is about to deploy, pairs the target cluster and stack name on one row, and lets you search clusters by name with each cluster’s state shown beside it. Stack names are checked against the naming rules as you type, and the footer says what is still standing between you and a deploy.Stack Profiles →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 →A runnable path to your own Ankra domain
Registering your own domain for Ankra’s generated hostnames worked; moving an existing organisation onto it did not. The switch is refused while cluster domains or DNS records still live under the old root - correct, and fail-closed - but the refusal was a single sentence with no list, the portal replaced it with a generic “the request was rejected by the server”, and nothing enumerated the cluster domains that were blocking it. Worse, the one command that could tell you a cluster’s domain,ankra cluster domain <cluster>, was a create: checking a cluster added a blocker to the very migration you were running.The refusal now names its blockers. The portal lists every cluster domain and DNS record still under the old root beside the Custom Ankra domain field, with a link to remove them; the API returns the same list as structured blocking_cluster_zones and blocking_dns_records members; and ankra org domain set prints it along with the command that clears each kind.ankra cluster domain <cluster> is now a read. It reports the cluster’s domain, or state none when it has none, and creates nothing - enabling a domain is the explicit --enable. ankra org dns zones lists every cluster domain in the organisation with its state, so you can see what a switch has to clear before attempting one. And the organisation’s root domain itself is finally scriptable: ankra org domain get|set reads and writes the same setting the portal saves, with set --default returning you to ankra.cc.The preview URL →Your own domain for Ankra previews
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 register their own domain for all of it, dedicated to their organisation alone. Point the domain’s NS records at Ankra’s nameservers (the ones serving ankra.cc), enter it in the Custom Ankra domain field under AI → Settings → Workspaces, and every zone and preview URL minted from then on hangs off it - Ankra manages the DNS the same way it does on the platform domain. The save verifies the nameservers up front and refuses a domain another organisation already holds, so a typo or an unhosted domain can never tear down a working zone. 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.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