# Create User Api Token Endpoint Source: https://docs.ankra.ai/api-reference/account-token-api/create-user-api-token-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/account/tokens # Delete User Api Token Endpoint Source: https://docs.ankra.ai/api-reference/account-token-api/delete-user-api-token-endpoint https://platform.ankra.app/openapi.json delete /api/v1/org/account/tokens/{token_id} # List User Api Tokens Endpoint Source: https://docs.ankra.ai/api-reference/account-token-api/list-user-api-tokens-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/account/tokens # Revoke User Api Token Endpoint Source: https://docs.ankra.ai/api-reference/account-token-api/revoke-user-api-token-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/account/tokens/{token_id}/revoke # Cancel Agent Run Source: https://docs.ankra.ai/api-reference/ai-agent-runs/cancel-agent-run https://platform.ankra.app/openapi.json post /api/v1/org/ai-agent-runs/{run_id}/cancel Cancel one live AI agent run and its session (organisation admins only). The runner interrupts the in-flight turn within seconds. # Get Agent Run Source: https://docs.ankra.ai/api-reference/ai-agent-runs/get-agent-run https://platform.ankra.app/openapi.json get /api/v1/org/ai-agent-runs/{run_id} Fetch one dispatched AI agent run with its owning task's name. # Get Agent Run Transcript Source: https://docs.ankra.ai/api-reference/ai-agent-runs/get-agent-run-transcript https://platform.ankra.app/openapi.json get /api/v1/org/ai-agent-runs/{run_id}/transcript Read the run's linked session transcript (ai_session_event page after `since`). # List Agent Runs Source: https://docs.ankra.ai/api-reference/ai-agent-runs/list-agent-runs https://platform.ankra.app/openapi.json get /api/v1/org/ai-agent-runs List the organisation's dispatched AI agent runs across every task, newest first. # Create a demo base stack Source: https://docs.ankra.ai/api-reference/ai-environment/create-a-demo-base-stack https://platform.ankra.app/openapi.json post /org/ai-environment/demo-base-stacks Save a new shared demo base stack in status 'configured'. Nothing reaches the cluster here - materialisation happens on the first demo launch that references it. Organisation-admin only; browser session authentication with the X-Ankra-CSRF double-submit header (no bearer twin). Secret parameter values ride as ${SECRET_SLOT:} sentinels, never resolved values. # Delete a demo base stack Source: https://docs.ankra.ai/api-reference/ai-environment/delete-a-demo-base-stack https://platform.ankra.app/openapi.json delete /org/ai-environment/demo-base-stacks/{base_stack_id} Initiate teardown of a demo base stack. Deletion is refused with a 409 while any live demo references it. A never-materialised (configured) row is deleted outright; a materialised one goes to 'deleting' and the maintainer loop finishes the job. Organisation-admin only; browser session authentication with the X-Ankra-CSRF double-submit header (no bearer twin). # List the organisation's demo base stacks Source: https://docs.ankra.ai/api-reference/ai-environment/list-the-organisations-demo-base-stacks https://platform.ankra.app/openapi.json get /org/ai-environment/demo-base-stacks List the organisation's shared demo base stacks (every status except deleted) with their live-demo reference counts. Reads are member-visible; browser session authentication only (no bearer twin). # Update a demo base stack Source: https://docs.ankra.ai/api-reference/ai-environment/update-a-demo-base-stack https://platform.ankra.app/openapi.json put /org/ai-environment/demo-base-stacks/{base_stack_id} Change the mutable designation of a demo base stack: profile, profile version, parameters, and idle TTL. The name (and thus the namespace) is immutable and ignored here; an omitted profile_id keeps the current profile. Changes are refused while the stack is deploying or deleting, and take effect on the next materialisation. Organisation-admin only; browser session authentication with the X-Ankra-CSRF double-submit header (no bearer twin). # Add Ai Ticket Link Source: https://docs.ankra.ai/api-reference/ai-tickets-api/add-ai-ticket-link https://platform.ankra.app/openapi.json post /api/v1/org/ai-tickets/{ticket_id}/links # Ai Ticket Board Summary Source: https://docs.ankra.ai/api-reference/ai-tickets-api/ai-ticket-board-summary https://platform.ankra.app/openapi.json get /api/v1/org/ai-tickets/summary # Assign Ai Ticket Source: https://docs.ankra.ai/api-reference/ai-tickets-api/assign-ai-ticket https://platform.ankra.app/openapi.json post /api/v1/org/ai-tickets/{ticket_id}/assign # Attach Ai Ticket Workspace Source: https://docs.ankra.ai/api-reference/ai-tickets-api/attach-ai-ticket-workspace https://platform.ankra.app/openapi.json post /api/v1/org/ai-tickets/{ticket_id}/workspace # Close Ai Ticket Source: https://docs.ankra.ai/api-reference/ai-tickets-api/close-ai-ticket https://platform.ankra.app/openapi.json post /api/v1/org/ai-tickets/{ticket_id}/close # Comment On Ai Ticket Source: https://docs.ankra.ai/api-reference/ai-tickets-api/comment-on-ai-ticket https://platform.ankra.app/openapi.json post /api/v1/org/ai-tickets/{ticket_id}/comments # Create Ai Sub Ticket Source: https://docs.ankra.ai/api-reference/ai-tickets-api/create-ai-sub-ticket https://platform.ankra.app/openapi.json post /api/v1/org/ai-tickets/{ticket_id}/sub-tickets # Create Ai Ticket Source: https://docs.ankra.ai/api-reference/ai-tickets-api/create-ai-ticket https://platform.ankra.app/openapi.json post /api/v1/org/ai-tickets Supports idempotent submission: pass an Idempotency-Key header (or the equivalent client_token body field). While the ticket filed for a key is live (not done/cancelled), repeating the submission with the same key returns that ticket instead of filing a duplicate. The key is stored on the ticket as source_kind 'client_token' / source_id. # Draft Ai Ticket Plan Source: https://docs.ankra.ai/api-reference/ai-tickets-api/draft-ai-ticket-plan https://platform.ankra.app/openapi.json post /api/v1/org/ai-tickets/{ticket_id}/plan # Get Ai Ticket Source: https://docs.ankra.ai/api-reference/ai-tickets-api/get-ai-ticket https://platform.ankra.app/openapi.json get /api/v1/org/ai-tickets/{ticket_id} # Get Ai Ticket Desk Settings Source: https://docs.ankra.ai/api-reference/ai-tickets-api/get-ai-ticket-desk-settings https://platform.ankra.app/openapi.json get /api/v1/org/ai-tickets/settings # List Ai Ticket Events Source: https://docs.ankra.ai/api-reference/ai-tickets-api/list-ai-ticket-events https://platform.ankra.app/openapi.json get /api/v1/org/ai-tickets/{ticket_id}/events # List Ai Ticket Links Source: https://docs.ankra.ai/api-reference/ai-tickets-api/list-ai-ticket-links https://platform.ankra.app/openapi.json get /api/v1/org/ai-tickets/{ticket_id}/links # List Ai Tickets Source: https://docs.ankra.ai/api-reference/ai-tickets-api/list-ai-tickets https://platform.ankra.app/openapi.json get /api/v1/org/ai-tickets Tickets are ordered by updated_at DESC, id DESC (stable). Prefer keyset pagination: pass the previous page's next_cursor as cursor; offset is ignored when cursor is set and remains only for existing clients. total_count is always the full filtered population. The search filter is a case-insensitive substring match on title and body; %, _ and \ in the search text match literally. # Remove Ai Ticket Link Source: https://docs.ankra.ai/api-reference/ai-tickets-api/remove-ai-ticket-link https://platform.ankra.app/openapi.json delete /api/v1/org/ai-tickets/{ticket_id}/links/{link_id} # Review Ai Ticket Plan Source: https://docs.ankra.ai/api-reference/ai-tickets-api/review-ai-ticket-plan https://platform.ankra.app/openapi.json post /api/v1/org/ai-tickets/{ticket_id}/plan/review # Transition Ai Ticket Source: https://docs.ankra.ai/api-reference/ai-tickets-api/transition-ai-ticket https://platform.ankra.app/openapi.json post /api/v1/org/ai-tickets/{ticket_id}/transition # Update Ai Ticket Source: https://docs.ankra.ai/api-reference/ai-tickets-api/update-ai-ticket https://platform.ankra.app/openapi.json patch /api/v1/org/ai-tickets/{ticket_id} # Update Ai Ticket Desk Settings Source: https://docs.ankra.ai/api-reference/ai-tickets-api/update-ai-ticket-desk-settings https://platform.ankra.app/openapi.json put /api/v1/org/ai-tickets/settings # Check Demo Build Source: https://docs.ankra.ai/api-reference/applications-api/check-demo-build https://platform.ankra.app/openapi.json get /api/v1/org/applications/{application_id}/demos/build Preflight a branch demo: resolve the branch's head SHA and probe the container registry for a matching image tag. GitHub or registry problems are reported inside the 200 payload's error and guidance fields, not as HTTP errors. A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication). # Create Application Api Endpoint Source: https://docs.ankra.ai/api-reference/applications-api/create-application-api-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/applications # Delete Application Api Endpoint Source: https://docs.ankra.ai/api-reference/applications-api/delete-application-api-endpoint https://platform.ankra.app/openapi.json delete /api/v1/org/applications/{application_id} # Deploy Application Demo Source: https://docs.ankra.ai/api-reference/applications-api/deploy-application-demo https://platform.ankra.app/openapi.json post /api/v1/org/applications/{application_id}/demos Deploy a throwaway demo of the application onto the organisation's staging cluster. Provide exactly one of branch or a positive pr_number; PR demos additionally require an explicit image_tag. Launch env entries are merged over the application's saved demo defaults (overrides win by name) and database overrides the saved throwaway-database default (null keeps it). A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication plus the X-Ankra-CSRF double-submit header). # Fix a branch's demo build Source: https://docs.ankra.ai/api-reference/applications-api/fix-a-branchs-demo-build https://platform.ankra.app/openapi.json post /org/applications/{application_id}/demos/fix-build Fix a branch whose demo build is missing: apply the deterministic Ankra-side fixes first (publish-readiness auto-fix, failed-run rerun, failed-setup retry) and, when those cannot produce an image, dispatch a one-shot mission agent that investigates the repository and opens a pull request with the fix. Browser session authentication with the X-Ankra-CSRF double-submit header only (no bearer twin). # Fix Application Demo Source: https://docs.ankra.ai/api-reference/applications-api/fix-application-demo https://platform.ankra.app/openapi.json post /api/v1/org/applications/{application_id}/demos/{workspace_id}/fix Dispatch the demo pre-setup mission agent for a failed demo whose container crashed on startup. The agent reads the crash logs, generates the missing demo environment, saves it as the application's demo defaults, and redeploys the demo. No request body. A malformed workspace_id is reported as the same 404 as an unknown demo. A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication plus the X-Ankra-CSRF double-submit header). # Get Application AI Configuration Source: https://docs.ankra.ai/api-reference/applications-api/get-application-ai-configuration https://platform.ankra.app/openapi.json get /api/v1/org/applications/{application_id}/ai-config Return the AI lanes configured for this application's repository: for each lane whether it runs, whether that decision is inherited from the organisation or overridden for this application, the settings it actually runs with, and the organisation default behind them. An application with no connected source-control binding answers 200 with binding.connected false and a reason, so the AI tab can render its empty state rather than an error. A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication). # Get Application Api Endpoint Source: https://docs.ankra.ai/api-reference/applications-api/get-application-api-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/applications/{application_id} # Get Application Demo Configuration Source: https://docs.ankra.ai/api-reference/applications-api/get-application-demo-configuration https://platform.ankra.app/openapi.json get /api/v1/org/applications/{application_id}/demo-config Return the application's saved demo defaults: the environment entries, the throwaway-database flag, and the optional stack-profile and base-stack dependency designations. Secret environment values and secret stack parameters ride as ${SECRET_SLOT:} sentinels, never resolved values. A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication). # Get Application Demo Detail Source: https://docs.ankra.ai/api-reference/applications-api/get-application-demo-detail https://platform.ankra.app/openapi.json get /api/v1/org/applications/{application_id}/demos/{workspace_id}/detail Return the demo record plus the live picture of its namespace on the staging cluster: the derived provisioning steps, the bill of materials, the namespace's Kubernetes events, and the pod/container names that drive the log viewer. A malformed workspace_id is reported as the same 404 as an unknown demo. A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication). # Get Application Demo Logs Source: https://docs.ankra.ai/api-reference/applications-api/get-application-demo-logs https://platform.ankra.app/openapi.json get /api/v1/org/applications/{application_id}/demos/{workspace_id}/logs Collect a bounded log tail from one of the demo's pods. An empty pod resolves to the demo's own pod. tail_lines defaults to 200 and is capped at 2000. A malformed workspace_id is reported as the same 404 as an unknown demo. A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication). # Get Application Demos Source: https://docs.ankra.ai/api-reference/applications-api/get-application-demos https://platform.ankra.app/openapi.json get /api/v1/org/applications/{application_id}/demos Return the application's active demos plus everything the demos tab needs in one round-trip: the caller's TTL policy, the staging-cluster status, and the default container port (the generated Dockerfile's EXPOSE port when known). A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication). # Get Application Jobs Api Endpoint Source: https://docs.ankra.ai/api-reference/applications-api/get-application-jobs-api-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/applications/{application_id}/jobs # List Applications Api Endpoint Source: https://docs.ankra.ai/api-reference/applications-api/list-applications-api-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/applications # Reconcile Application Api Endpoint Source: https://docs.ankra.ai/api-reference/applications-api/reconcile-application-api-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/applications/{application_id}/reconcile # Reset Application AI Configuration Source: https://docs.ankra.ai/api-reference/applications-api/reset-application-ai-configuration https://platform.ankra.app/openapi.json delete /api/v1/org/applications/{application_id}/ai-config Drop this application's AI lane overrides entirely so every lane follows the organisation default again, and answer with the resolved configuration. A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication plus the X-Ankra-CSRF header). # Retry Application Api Endpoint Source: https://docs.ankra.ai/api-reference/applications-api/retry-application-api-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/applications/{application_id}/retry # Stop Application Demo Source: https://docs.ankra.ai/api-reference/applications-api/stop-application-demo https://platform.ankra.app/openapi.json delete /api/v1/org/applications/{application_id}/demos/{workspace_id} Stop a demo and tear its namespace down. A malformed workspace_id is reported as the same 404 as an unknown demo. A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication plus the X-Ankra-CSRF double-submit header). # Update Application AI Configuration Source: https://docs.ankra.ai/api-reference/applications-api/update-application-ai-configuration https://platform.ankra.app/openapi.json put /api/v1/org/applications/{application_id}/ai-config Patch this application's AI lane overrides and answer with the freshly resolved configuration. Lanes the body does not mention are left untouched. A lane sent with override false is removed from the application's override so it follows the organisation again; a lane sent with override true stores whichever of enabled and settings the body carries. Overrides are stored on the ai-gateway's per-repository binding profile, the same rows that gate the webhook events. A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication plus the X-Ankra-CSRF header). # Update Application Demo Configuration Source: https://docs.ankra.ai/api-reference/applications-api/update-application-demo-configuration https://platform.ankra.app/openapi.json put /api/v1/org/applications/{application_id}/demo-config Replace the application's saved demo defaults. env and database are replaced wholesale on every PUT. The stack_profile and base_stack blocks are written only when their key is present in the body: an absent key preserves the stored designation, an explicit null clears it, so a client that predates either block cannot silently drop a demo's dependencies. Secret environment values are submitted and echoed as ${SECRET_SLOT:} sentinels. A browser session twin is mounted at the same path without the /api/v1 prefix (cookie authentication plus the X-Ankra-CSRF double-submit header). # Create a Azure credential Source: https://docs.ankra.ai/api-reference/azure-credentials-api/create-a-azure-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/azure Bearer PAT authentication; RBAC permission `credentials.write`. The secret is stored in Vault and connection-tested without echoing key material. # Create a Azure credential Source: https://docs.ankra.ai/api-reference/azure-credentials-api/create-a-azure-credential-1 https://platform.ankra.app/openapi.json post /org/credentials/azure Browser session authentication; RBAC permission `credentials.write`. The secret is stored in Vault and connection-tested without echoing key material. # Create an SSH key credential Source: https://docs.ankra.ai/api-reference/azure-credentials-api/create-an-ssh-key-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/azure/ssh-key # List Azure credentials Source: https://docs.ankra.ai/api-reference/azure-credentials-api/list-azure-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/azure Bearer PAT authentication; RBAC permission `credentials.read`. Returns credential metadata only; the client secret is never returned. # List Azure credentials Source: https://docs.ankra.ai/api-reference/azure-credentials-api/list-azure-credentials-1 https://platform.ankra.app/openapi.json get /org/credentials/azure Browser session authentication; RBAC permission `credentials.read`. Returns credential metadata only; the client secret is never returned. # List SSH key credentials Source: https://docs.ankra.ai/api-reference/azure-credentials-api/list-ssh-key-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/azure/ssh-keys # Get detailed information about a specific chart Source: https://docs.ankra.ai/api-reference/charts/get-detailed-information-about-a-specific-chart https://platform.ankra.app/openapi.json post /api/v1/org/stacks/charts/details # List available Helm charts Source: https://docs.ankra.ai/api-reference/charts/list-available-helm-charts https://platform.ankra.app/openapi.json get /api/v1/org/stacks/charts # Delete a chat conversation Source: https://docs.ankra.ai/api-reference/chat-api/delete-a-chat-conversation https://platform.ankra.app/openapi.json delete /api/v1/org/clusters/{cluster_id}/kubernetes/chat/history/{conversation_id} # Delete a general chat conversation Source: https://docs.ankra.ai/api-reference/chat-api/delete-a-general-chat-conversation https://platform.ankra.app/openapi.json delete /api/v1/chat/general/history/{conversation_id} # Get a specific chat conversation Source: https://docs.ankra.ai/api-reference/chat-api/get-a-specific-chat-conversation https://platform.ankra.app/openapi.json get /api/v1/org/clusters/{cluster_id}/kubernetes/chat/history/{conversation_id} # Get a specific general chat conversation Source: https://docs.ankra.ai/api-reference/chat-api/get-a-specific-general-chat-conversation https://platform.ankra.app/openapi.json get /api/v1/chat/general/history/{conversation_id} # Get AI-analysed cluster health Source: https://docs.ankra.ai/api-reference/chat-api/get-ai-analysed-cluster-health https://platform.ankra.app/openapi.json get /api/v1/org/clusters/{cluster_id}/kubernetes/health # List chat conversations for a cluster Source: https://docs.ankra.ai/api-reference/chat-api/list-chat-conversations-for-a-cluster https://platform.ankra.app/openapi.json get /api/v1/org/clusters/{cluster_id}/kubernetes/chat/history # List general chat conversations Source: https://docs.ankra.ai/api-reference/chat-api/list-general-chat-conversations https://platform.ankra.app/openapi.json get /api/v1/chat/general/history # List general chat conversations with unseen finished replies Source: https://docs.ankra.ai/api-reference/chat-api/list-general-chat-conversations-with-unseen-finished-replies https://platform.ankra.app/openapi.json get /api/v1/chat/general/history/unread # Mark a general chat conversation's results as seen Source: https://docs.ankra.ai/api-reference/chat-api/mark-a-general-chat-conversations-results-as-seen https://platform.ankra.app/openapi.json post /api/v1/chat/general/history/{conversation_id}/seen # Stream chat responses for cluster troubleshooting Source: https://docs.ankra.ai/api-reference/chat-api/stream-chat-responses-for-cluster-troubleshooting https://platform.ankra.app/openapi.json post /api/v1/org/clusters/{cluster_id}/kubernetes/chat # Stream general chat responses Source: https://docs.ankra.ai/api-reference/chat-api/stream-general-chat-responses https://platform.ankra.app/openapi.json post /api/v1/chat/general # Confirm or reject a pending AI action (bearer token) Source: https://docs.ankra.ai/api-reference/chat/confirm-or-reject-a-pending-ai-action-bearer-token https://platform.ankra.app/openapi.json post /api/v1/chat/actions/confirm # List pending AI actions for a conversation (bearer token) Source: https://docs.ankra.ai/api-reference/chat/list-pending-ai-actions-for-a-conversation-bearer-token https://platform.ankra.app/openapi.json get /api/v1/chat/actions/pending # Create Cluster Access Grant Endpoint Source: https://docs.ankra.ai/api-reference/cluster-access/create-cluster-access-grant-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/access/grants # Delete Cluster Access Grant Endpoint Source: https://docs.ankra.ai/api-reference/cluster-access/delete-cluster-access-grant-endpoint https://platform.ankra.app/openapi.json delete /api/v1/clusters/{cluster_id}/access/grants/{grant_id} # Generate Kubeconfig Endpoint Source: https://docs.ankra.ai/api-reference/cluster-access/generate-kubeconfig-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/kubeconfig # List Cluster Access Grants Endpoint Source: https://docs.ankra.ai/api-reference/cluster-access/list-cluster-access-grants-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/access/grants # Mint Kube Token Endpoint Source: https://docs.ankra.ai/api-reference/cluster-access/mint-kube-token-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/k8s-token # Cluster Start Endpoint Source: https://docs.ankra.ai/api-reference/cluster/cluster-start-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/provision # Create Cluster Stack Draft Endpoint Source: https://docs.ankra.ai/api-reference/cluster/create-cluster-stack-draft-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/stacks/draft # Create Or Update Import Cluster Endpoint Source: https://docs.ankra.ai/api-reference/cluster/create-or-update-import-cluster-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/import # Delete Cluster By Name Endpoint Source: https://docs.ankra.ai/api-reference/cluster/delete-cluster-by-name-endpoint https://platform.ankra.app/openapi.json delete /api/v1/clusters/{cluster_name} # Deprovision Cluster Endpoint Source: https://docs.ankra.ai/api-reference/cluster/deprovision-cluster-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/deprovision # Enable Cluster Dns Zone Endpoint Source: https://docs.ankra.ai/api-reference/cluster/enable-cluster-dns-zone-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/dns-zone # Get Cluster Gitops Status Endpoint Source: https://docs.ankra.ai/api-reference/cluster/get-cluster-gitops-status-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/gitops/status # Get Operation Endpoint Source: https://docs.ankra.ai/api-reference/cluster/get-operation-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/operations/{operation_id} # List Cluster Addons Endpoint Source: https://docs.ankra.ai/api-reference/cluster/list-cluster-addons-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/addons # List Cluster Manifests Endpoint Source: https://docs.ankra.ai/api-reference/cluster/list-cluster-manifests-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/manifests # List Cluster Stacks Endpoint Source: https://docs.ankra.ai/api-reference/cluster/list-cluster-stacks-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/stacks # List Clusters Endpoint Source: https://docs.ankra.ai/api-reference/cluster/list-clusters-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters # List Cni Options Endpoint Source: https://docs.ankra.ai/api-reference/cluster/list-cni-options-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/cni-options # List K3S Versions Endpoint Source: https://docs.ankra.ai/api-reference/cluster/list-k3s-versions-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/k3s-versions # List Kubeadm Versions Endpoint Source: https://docs.ankra.ai/api-reference/cluster/list-kubeadm-versions-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/kubeadm-versions # List Operation Updated Jobs Endpoint Source: https://docs.ankra.ai/api-reference/cluster/list-operation-updated-jobs-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/operations/{operation_id}/jobs # List Operations Endpoint Source: https://docs.ankra.ai/api-reference/cluster/list-operations-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/operations # Roll To Cluster Resource Version Endpoint Source: https://docs.ankra.ai/api-reference/cluster/roll-to-cluster-resource-version-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/resources/roll-to # Validate Import Cluster Endpoint Source: https://docs.ankra.ai/api-reference/cluster/validate-import-cluster-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/validate # Create the organisation's playground Source: https://docs.ankra.ai/api-reference/clusters/create-the-organisations-playground https://platform.ankra.app/openapi.json post /org/clusters/playground Creates the organisation's playground: a real, writable vcluster on Ankra's shared playground host. Browser session authentication. Available to every organisation; one playground per organisation, bounded globally by the host's concurrency cap. # Read the playground provisioning status Source: https://docs.ankra.ai/api-reference/clusters/read-the-playground-provisioning-status https://platform.ankra.app/openapi.json get /org/clusters/playground/{clusterId}/status Reads the provisioning phase of the organisation's playground. A playground belonging to another organisation is not found. # Delete a credential Source: https://docs.ankra.ai/api-reference/credentials-api/delete-a-credential https://platform.ankra.app/openapi.json delete /api/v1/org/credentials/{credential_id} # Get credential details Source: https://docs.ankra.ai/api-reference/credentials-api/get-credential-details https://platform.ankra.app/openapi.json get /api/v1/org/credentials/{credential_id} # List credentials Source: https://docs.ankra.ai/api-reference/credentials-api/list-credentials https://platform.ankra.app/openapi.json get /api/v1/org/credentials # Validate credential name Source: https://docs.ankra.ai/api-reference/credentials-api/validate-credential-name https://platform.ankra.app/openapi.json get /api/v1/org/credentials/validate # Add Node Group Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/add-node-group-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/digitalocean/{cluster_id}/node-groups # Change Control Plane Count Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/change-control-plane-count-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/digitalocean/{cluster_id}/control-plane # Change Control Plane Instance Type Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/change-control-plane-instance-type-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/digitalocean/{cluster_id}/control-plane/instance-type # Create a DigitalOcean cluster Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/create-a-digitalocean-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/digitalocean # Delete Node Group Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/delete-node-group-endpoint https://platform.ankra.app/openapi.json delete /api/v1/clusters/digitalocean/{cluster_id}/node-groups/{group_name} # Deprovision a DigitalOcean cluster Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/deprovision-a-digitalocean-cluster https://platform.ankra.app/openapi.json delete /api/v1/clusters/digitalocean/{cluster_id} # Get Control Plane Info Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/get-control-plane-info-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/digitalocean/{cluster_id}/control-plane # Get current Kubernetes version Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/get-current-kubernetes-version https://platform.ankra.app/openapi.json get /api/v1/clusters/digitalocean/{cluster_id}/k8s-version # Get current worker count Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/get-current-worker-count https://platform.ankra.app/openapi.json get /api/v1/clusters/digitalocean/{cluster_id}/worker-count # Get Digitalocean Access Info Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/get-digitalocean-access-info-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/digitalocean/{cluster_id}/access-info # Get Digitalocean Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/get-digitalocean-ssh-keys-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/digitalocean/{cluster_id}/ssh-keys # Get Node Detail Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/get-node-detail-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/digitalocean/{cluster_id}/nodes/{node_id} # List available DigitalOcean droplet sizes Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/list-available-digitalocean-droplet-sizes https://platform.ankra.app/openapi.json get /api/v1/clusters/digitalocean/sizes # List available DigitalOcean regions Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/list-available-digitalocean-regions https://platform.ankra.app/openapi.json get /api/v1/clusters/digitalocean/regions # List Cluster Nodes Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/list-cluster-nodes-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/digitalocean/{cluster_id}/nodes # List Node Groups Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/list-node-groups-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/digitalocean/{cluster_id}/node-groups # Resync Digitalocean Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/resync-digitalocean-ssh-keys-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/digitalocean/{cluster_id}/ssh-keys/resync # Scale DigitalOcean cluster workers Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/scale-digitalocean-cluster-workers https://platform.ankra.app/openapi.json post /api/v1/clusters/digitalocean/{cluster_id}/scale-workers # Scale Node Group Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/scale-node-group-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/digitalocean/{cluster_id}/node-groups/{group_name}/scale # Start a DigitalOcean cluster Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/start-a-digitalocean-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/digitalocean/{cluster_id}/start Recreate the DigitalOcean cloud resources for a stopped cluster and reconcile it back to a running state. # Stop a DigitalOcean cluster Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/stop-a-digitalocean-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/digitalocean/{cluster_id}/stop Initiate async deletion of DigitalOcean cloud resources (droplets, VPCs, firewalls, SSH keys) without removing the cluster from the database. # Update Digitalocean Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/update-digitalocean-ssh-keys-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/digitalocean/{cluster_id}/ssh-keys # Update Instance Type Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/update-instance-type-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/digitalocean/{cluster_id}/node-groups/{group_name}/instance-type # Update Labels Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/update-labels-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/digitalocean/{cluster_id}/node-groups/{group_name}/labels # Update Taints Endpoint Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/update-taints-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/digitalocean/{cluster_id}/node-groups/{group_name}/taints # Upgrade Kubernetes version Source: https://docs.ankra.ai/api-reference/digitalocean-cluster-api/upgrade-kubernetes-version https://platform.ankra.app/openapi.json post /api/v1/clusters/digitalocean/{cluster_id}/upgrade-k8s-version # Create a DigitalOcean API credential Source: https://docs.ankra.ai/api-reference/digitalocean-credentials-api/create-a-digitalocean-api-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/digitalocean # Create an SSH key credential Source: https://docs.ankra.ai/api-reference/digitalocean-credentials-api/create-an-ssh-key-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/digitalocean/ssh-key # List DigitalOcean API credentials Source: https://docs.ankra.ai/api-reference/digitalocean-credentials-api/list-digitalocean-api-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/digitalocean # List SSH key credentials Source: https://docs.ankra.ai/api-reference/digitalocean-credentials-api/list-ssh-key-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/digitalocean/ssh-keys # Cancel a batch of executions Source: https://docs.ankra.ai/api-reference/executions-api/cancel-a-batch-of-executions https://platform.ankra.app/openapi.json post /api/v1/org/executions/cancel # Cancel a step within an execution Source: https://docs.ankra.ai/api-reference/executions-api/cancel-a-step-within-an-execution https://platform.ankra.app/openapi.json post /api/v1/org/executions/{execution_id}/steps/{step_id}/cancel # Cancel an execution Source: https://docs.ankra.ai/api-reference/executions-api/cancel-an-execution https://platform.ankra.app/openapi.json post /api/v1/org/executions/{execution_id}/cancel # Get execution detail Source: https://docs.ankra.ai/api-reference/executions-api/get-execution-detail https://platform.ankra.app/openapi.json get /api/v1/org/executions/{execution_id} # Get execution status events Source: https://docs.ankra.ai/api-reference/executions-api/get-execution-status-events https://platform.ankra.app/openapi.json get /api/v1/org/executions/{execution_id}/events # Get execution step results Source: https://docs.ankra.ai/api-reference/executions-api/get-execution-step-results https://platform.ankra.app/openapi.json get /api/v1/org/executions/{execution_id}/result # List execution steps Source: https://docs.ankra.ai/api-reference/executions-api/list-execution-steps https://platform.ankra.app/openapi.json get /api/v1/org/executions/{execution_id}/steps # List executions Source: https://docs.ankra.ai/api-reference/executions-api/list-executions https://platform.ankra.app/openapi.json get /api/v1/org/executions # Retry a terminal execution Source: https://docs.ankra.ai/api-reference/executions-api/retry-a-terminal-execution https://platform.ankra.app/openapi.json post /api/v1/org/executions/{execution_id}/retry # Create Helm Registry Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/create-helm-registry-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/helm/registries # Create Registry Credential Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/create-registry-credential-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/helm/credentials # Delete Helm Registry Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/delete-helm-registry-endpoint https://platform.ankra.app/openapi.json delete /api/v1/org/helm/registries/{registry_name} # Delete Registry Credential Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/delete-registry-credential-endpoint https://platform.ankra.app/openapi.json delete /api/v1/org/helm/credentials/{credential_name} # Get Helm Chart Clusters Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/get-helm-chart-clusters-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/charts/clusters/{repository_name}/{chart_name} # Get Helm Chart Default Values Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/get-helm-chart-default-values-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/charts/chart/{repository_name}/{chart_name}/{chart_version}/values # Get Helm Chart Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/get-helm-chart-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/charts/chart/{repository_name}/{chart_name}/{chart_version} # Get Helm Chart File Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/get-helm-chart-file-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/charts/chart/{repository_name}/{chart_name}/{chart_version}/file # Get Helm Chart Files Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/get-helm-chart-files-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/charts/chart/{repository_name}/{chart_name}/{chart_version}/files # Get Helm Chart Releases Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/get-helm-chart-releases-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/charts/releases/{repository_name}/{chart_name} # Get Helm Registry Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/get-helm-registry-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/registries/{registry_name} # Get Registry Credential Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/get-registry-credential-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/credentials/{credential_name} # List Helm Charts Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/list-helm-charts-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/charts # List Helm Registries Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/list-helm-registries-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/registries # List Registry Credentials Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/list-registry-credentials-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/credentials # List Registry Sync Jobs Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/list-registry-sync-jobs-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/helm/registries/{registry_name}/sync-jobs # Render a chart version's manifests with helm template Source: https://docs.ankra.ai/api-reference/helm-api/render-a-chart-versions-manifests-with-helm-template https://platform.ankra.app/openapi.json post /api/v1/org/helm/charts/template # Sync Helm Registry Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/sync-helm-registry-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/helm/registries/{registry_name}/sync # Update Helm Registry Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/update-helm-registry-endpoint https://platform.ankra.app/openapi.json put /api/v1/org/helm/registries/{registry_name} # Update Registry Credential Endpoint Source: https://docs.ankra.ai/api-reference/helm-api/update-registry-credential-endpoint https://platform.ankra.app/openapi.json put /api/v1/org/helm/credentials/{credential_name} # Add Node Group Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/add-node-group-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/hetzner/{cluster_id}/node-groups # Change Control Plane Count Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/change-control-plane-count-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/hetzner/{cluster_id}/control-plane # Change Control Plane Instance Type Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/change-control-plane-instance-type-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/hetzner/{cluster_id}/control-plane/instance-type # Create a Hetzner cluster Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/create-a-hetzner-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/hetzner # Delete Node Group Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/delete-node-group-endpoint https://platform.ankra.app/openapi.json delete /api/v1/clusters/hetzner/{cluster_id}/node-groups/{group_name} # Deprovision a Hetzner cluster Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/deprovision-a-hetzner-cluster https://platform.ankra.app/openapi.json delete /api/v1/clusters/hetzner/{cluster_id} # Get Control Plane Info Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/get-control-plane-info-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/hetzner/{cluster_id}/control-plane # Get current Kubernetes version Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/get-current-kubernetes-version https://platform.ankra.app/openapi.json get /api/v1/clusters/hetzner/{cluster_id}/k8s-version # Get current worker count Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/get-current-worker-count https://platform.ankra.app/openapi.json get /api/v1/clusters/hetzner/{cluster_id}/worker-count # Get Hetzner Access Info Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/get-hetzner-access-info-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/hetzner/{cluster_id}/access-info # Get Hetzner Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/get-hetzner-ssh-keys-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/hetzner/{cluster_id}/ssh-keys # Get Node Detail Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/get-node-detail-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/hetzner/{cluster_id}/nodes/{node_id} # List available Hetzner locations Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/list-available-hetzner-locations https://platform.ankra.app/openapi.json get /api/v1/clusters/hetzner/locations # List available Hetzner server types Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/list-available-hetzner-server-types https://platform.ankra.app/openapi.json get /api/v1/clusters/hetzner/server-types # List Cluster Nodes Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/list-cluster-nodes-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/hetzner/{cluster_id}/nodes # List Node Groups Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/list-node-groups-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/hetzner/{cluster_id}/node-groups # Resync Hetzner Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/resync-hetzner-ssh-keys-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/hetzner/{cluster_id}/ssh-keys/resync # Scale Hetzner cluster workers Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/scale-hetzner-cluster-workers https://platform.ankra.app/openapi.json post /api/v1/clusters/hetzner/{cluster_id}/scale-workers # Scale Node Group Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/scale-node-group-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/hetzner/{cluster_id}/node-groups/{group_name}/scale # Start a Hetzner cluster Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/start-a-hetzner-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/hetzner/{cluster_id}/start Recreate the Hetzner cloud resources for a stopped cluster and reconcile it back to a running state. # Stop a Hetzner cluster Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/stop-a-hetzner-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/hetzner/{cluster_id}/stop Initiate async deletion of Hetzner cloud resources (servers, networks, SSH keys) without removing the cluster from the database. # Update Hetzner Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/update-hetzner-ssh-keys-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/hetzner/{cluster_id}/ssh-keys # Update Instance Type Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/update-instance-type-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/hetzner/{cluster_id}/node-groups/{group_name}/instance-type # Update Labels Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/update-labels-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/hetzner/{cluster_id}/node-groups/{group_name}/labels # Update Taints Endpoint Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/update-taints-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/hetzner/{cluster_id}/node-groups/{group_name}/taints # Upgrade Kubernetes version Source: https://docs.ankra.ai/api-reference/hetzner-cluster-api/upgrade-kubernetes-version https://platform.ankra.app/openapi.json post /api/v1/clusters/hetzner/{cluster_id}/upgrade-k8s-version # Create a Hetzner API credential Source: https://docs.ankra.ai/api-reference/hetzner-credentials-api/create-a-hetzner-api-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/hetzner # Create an SSH key credential Source: https://docs.ankra.ai/api-reference/hetzner-credentials-api/create-an-ssh-key-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/hetzner/ssh-key # List Hetzner API credentials Source: https://docs.ankra.ai/api-reference/hetzner-credentials-api/list-hetzner-api-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/hetzner # List SSH key credentials Source: https://docs.ankra.ai/api-reference/hetzner-credentials-api/list-ssh-key-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/hetzner/ssh-keys # Clone Stack To Cluster Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/clone-stack-to-cluster-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/clusters/imported/{cluster_id}/stacks/clone # Create Cluster Stack Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/create-cluster-stack-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/clusters/imported/{cluster_id}/stacks # Delete Cluster Stack Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/delete-cluster-stack-endpoint https://platform.ankra.app/openapi.json delete /api/v1/org/clusters/imported/{cluster_id}/stacks/{stack_name} # Disconnect Cluster Stack Manifest Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/disconnect-cluster-stack-manifest-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/clusters/imported/{cluster_id}/stacks/{stack_name}/manifests/{manifest_name}/disconnect Disconnects (removes) a manifest from a stack. Mirrors the web UI disconnect endpoint but is exposed on the bearer-token CLI API so `ankra cluster manifests delete` can remove a manifest's resources from the cluster. # Generate Identity Token Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/generate-identity-token-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/clusters/imported/{cluster_id}/cluster-agent/token # Get Addon Settings Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/get-addon-settings-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/clusters/imported/{cluster_id}/addons/{addon_name}/settings # Get Addon Values Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/get-addon-values-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/clusters/imported/{cluster_id}/addons/{addon_name}/configuration Returns the addon's DB-stored values (plaintext, base64-encoded). Unlike the web UI v2 endpoint this never queries the cluster agent or Argo CD; the CLI only needs the values for Helm-style --set mutation. # Get Cluster Agent Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/get-cluster-agent-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/clusters/imported/{cluster_id}/agent # Get Cluster Iac Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/get-cluster-iac-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/clusters/imported/{cluster_id}/iac Returns the full ImportCluster YAML (base64-encoded) for a cluster. Mirrors the web UI endpoint but uses bearer-token auth for CLI access. Returns 404 when the cluster has no resources to generate IaC from. # Get Cluster Stack History Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/get-cluster-stack-history-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/clusters/imported/{cluster_id}/stacks/{stack_name}/history # Get Identity Token Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/get-identity-token-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/clusters/imported/{cluster_id}/cluster-agent/token # Get Manifest Configuration Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/get-manifest-configuration-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/clusters/imported/{cluster_id}/manifests/{manifest_name}/configuration Returns the manifest's base64-encoded content. Used by `ankra cluster manifests upgrade` to preserve manifest_base64 when the user supplies only metadata changes (e.g. --namespace). # Instantiate Stack Profile Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/instantiate-stack-profile-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/clusters/imported/{cluster_id}/stacks/from-profile # List Available Cluster Addons Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/list-available-cluster-addons-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/clusters/imported/{cluster_id}/addons/available # List Cluster Stacks Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/list-cluster-stacks-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/clusters/imported/{cluster_id}/stacks # Reconcile Cluster Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/reconcile-cluster-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/clusters/imported/{cluster_id}/reconcile # Rename Cluster Stack Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/rename-cluster-stack-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/clusters/imported/{cluster_id}/stacks/{stack_name}/rename-stack # Uninstall Cluster Addon Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/uninstall-cluster-addon-endpoint https://platform.ankra.app/openapi.json delete /api/v1/org/clusters/imported/{cluster_id}/addons/{addon_resource_id} # Update Addon Settings Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/update-addon-settings-endpoint https://platform.ankra.app/openapi.json put /api/v1/org/clusters/imported/{cluster_id}/addons/{addon_name}/settings # Update Cluster Stack Partial Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/update-cluster-stack-partial-endpoint https://platform.ankra.app/openapi.json patch /api/v1/org/clusters/imported/{cluster_id}/stacks/{stack_name} Surgical partial update of a stack's addons/manifests. Accepts the same body as the web UI endpoint. Callers must set partial_stack=true to merge-update (vs replace) the named stack. # Upgrade Cluster Agent Endpoint Source: https://docs.ankra.ai/api-reference/imported-clusters/upgrade-cluster-agent-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/clusters/imported/{cluster_id}/agent/upgrade # Introduction Source: https://docs.ankra.ai/api-reference/introduction Automate cluster operations, integrate with CI/CD, and build on the Ankra platform via REST. Automate cluster operations, integrate with your CI/CD, and build on top of the Ankra platform. The Ankra REST API lets you programmatically manage Ankra resources - such as clusters and add-ons - run operations, and retrieve statuses from your own tools, scripts, and pipelines. *** ## Quickstart ### 1) Generate an API token 1. Click your profile avatar (bottom‑left) in the Ankra dashboard. 2. **Profile → API Tokens → Add Token**. 3. Name the token, set permissions (if applicable), and **copy it somewhere safe**. > You won’t be able to view the token again after closing the dialog. ### 2) Make your first request **Bash (cURL)** ```bash theme={null} export ANKRA_API_TOKEN="" curl -sS \ -H "Authorization: Bearer $ANKRA_API_TOKEN" \ -H "Accept: application/json" \ https://platform.ankra.app/api/v1/clusters ``` **Python** ```python theme={null} import requests headers = {"Authorization": "Bearer "} resp = requests.get("https://platform.ankra.app/api/v1/clusters", headers=headers) resp.raise_for_status() print(resp.json()) ``` **Node.js** ```javascript theme={null} const res = await fetch("https://platform.ankra.app/api/v1/clusters", { headers: { Authorization: "Bearer " } }); if (!res.ok) throw new Error(await res.text()); console.log(await res.json()); ``` *** ## Authentication Use an API token in the `Authorization` header: ```http theme={null} Authorization: Bearer ``` * Tokens are created in the dashboard and may be scoped (if your organisation uses scoped tokens). * Revoke tokens anytime from **Profile → API Tokens**. * Prefer separate tokens for different use cases (e.g., CLI vs. CI/CD). ### Security best practices * Treat tokens like passwords - never commit them to source control. * Grant only the minimum required permissions. * Rotate/revoke tokens regularly and immediately if you suspect compromise. * Store tokens as secrets in your CI/CD system (e.g., GitHub Actions, GitLab CI, Jenkins). **CLI example (authenticate once):** ```bash theme={null} export ANKRA_API_TOKEN="" ``` **GitHub Actions example:** ```yaml theme={null} env: ANKRA_API_TOKEN: ${{ secrets.ANKRA_API_TOKEN }} ``` *** ## Errors The API uses standard HTTP status codes. Error responses include a machine‑readable body to help diagnose issues. | Code | Meaning | | ---- | ------------------------------ | | 200 | Success | | 400 | Bad request / validation | | 401 | Missing or invalid token | | 403 | Insufficient permissions | | 404 | Resource not found | | 429 | Too many requests (rate limit) | | 5xx | Server errors | *** ## Pagination & filtering Endpoints that return collections may support pagination and filters. Refer to the endpoint’s page for available query parameters and response shapes. *** ## Versioning This reference covers the **v1** API (`/api/v1`). Breaking changes are introduced only in new major versions; minor, non‑breaking updates may be added to v1. *** ## Help & support * Check the endpoint pages for required parameters and examples. * Review token permissions if you receive 401/403 errors. * If you’re stuck, you can always reach us through the community slack. # Get Helm Release Detail Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/get-helm-release-detail-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/kubernetes/helm/releases/{namespace}/{name} # Get Helm Release History Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/get-helm-release-history-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/kubernetes/helm/releases/{namespace}/{name}/history # Get Helm Releases Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/get-helm-releases-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/kubernetes/resources/helm/get # Get Kubernetes Resources Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/get-kubernetes-resources-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/kubernetes/resources/get # List Pods Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/list-pods-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/kubernetes/pods # Query Prometheus Instant Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/query-prometheus-instant-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/kubernetes/metrics/query # Query Prometheus Range Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/query-prometheus-range-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/kubernetes/metrics/query_range # Rollback Helm Release Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/rollback-helm-release-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/kubernetes/helm/releases/{namespace}/{name}/rollback # Stream Pod Logs Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/stream-pod-logs-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/{cluster_id}/kubernetes/pod/logs # Uninstall Helm Release Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/uninstall-helm-release-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/kubernetes/resources/helm/uninstall # Upgrade Helm Release Endpoint Source: https://docs.ankra.ai/api-reference/kubernetes-api/upgrade-helm-release-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/{cluster_id}/kubernetes/helm/releases/{namespace}/{name}/upgrade # (Removed) Cancel a job within an operation Source: https://docs.ankra.ai/api-reference/operations-api/removed-cancel-a-job-within-an-operation https://platform.ankra.app/openapi.json post /api/v1/org/operations/{operation_id}/jobs/{job_id}/cancel # (Removed) Cancel an operation Source: https://docs.ankra.ai/api-reference/operations-api/removed-cancel-an-operation https://platform.ankra.app/openapi.json post /api/v1/org/operations/{operation_id}/cancel # Create a new organisation Source: https://docs.ankra.ai/api-reference/organisation-api/create-a-new-organisation https://platform.ankra.app/openapi.json post /api/v1/org/organisation # Delete user from organisation Source: https://docs.ankra.ai/api-reference/organisation-api/delete-user-from-organisation https://platform.ankra.app/openapi.json delete /api/v1/org/organisation/user # Export the organisation audit log Source: https://docs.ankra.ai/api-reference/organisation-api/export-the-organisation-audit-log https://platform.ankra.app/openapi.json get /org/organisation/audit-logs/export # Get organisation details Source: https://docs.ankra.ai/api-reference/organisation-api/get-organisation-details https://platform.ankra.app/openapi.json get /api/v1/org/organisation/{organisation_id} # Get organisation logo Source: https://docs.ankra.ai/api-reference/organisation-api/get-organisation-logo https://platform.ankra.app/openapi.json get /api/v1/org/organisation/{organisation_id}/logo # Invite user to organisation Source: https://docs.ankra.ai/api-reference/organisation-api/invite-user-to-organisation https://platform.ankra.app/openapi.json post /api/v1/org/organisation/invite # List organisations Source: https://docs.ankra.ai/api-reference/organisation-api/list-organisations https://platform.ankra.app/openapi.json get /api/v1/org/organisation # List the audit log of one cluster Source: https://docs.ankra.ai/api-reference/organisation-api/list-the-audit-log-of-one-cluster https://platform.ankra.app/openapi.json get /org/clusters/{cluster_id}/audit-logs # Switch user organisation Source: https://docs.ankra.ai/api-reference/organisation-api/switch-user-organisation https://platform.ankra.app/openapi.json post /api/v1/org/organisation/switch # Delete organisation logo Source: https://docs.ankra.ai/api-reference/organisation/delete-organisation-logo https://platform.ankra.app/openapi.json delete /org/organisation/{organisation_id}/logo # Get organisation logo Source: https://docs.ankra.ai/api-reference/organisation/get-organisation-logo https://platform.ankra.app/openapi.json get /org/organisation/{organisation_id}/logo # Store organisation logo Source: https://docs.ankra.ai/api-reference/organisation/store-organisation-logo https://platform.ankra.app/openapi.json put /org/organisation/{organisation_id}/logo # Add Node Group Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/add-node-group-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/ovh/{cluster_id}/node-groups # Change Control Plane Count Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/change-control-plane-count-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/ovh/{cluster_id}/control-plane # Change Control Plane Instance Type Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/change-control-plane-instance-type-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/ovh/{cluster_id}/control-plane/instance-type # Create an OVH cluster Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/create-an-ovh-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/ovh # Delete Node Group Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/delete-node-group-endpoint https://platform.ankra.app/openapi.json delete /api/v1/clusters/ovh/{cluster_id}/node-groups/{group_name} # Deprovision an OVH cluster Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/deprovision-an-ovh-cluster https://platform.ankra.app/openapi.json delete /api/v1/clusters/ovh/{cluster_id} # Get Control Plane Info Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/get-control-plane-info-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/ovh/{cluster_id}/control-plane # Get current Kubernetes version Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/get-current-kubernetes-version https://platform.ankra.app/openapi.json get /api/v1/clusters/ovh/{cluster_id}/k8s-version # Get current worker count Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/get-current-worker-count https://platform.ankra.app/openapi.json get /api/v1/clusters/ovh/{cluster_id}/worker-count # Get Node Detail Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/get-node-detail-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/ovh/{cluster_id}/nodes/{node_id} # Get Ovh Access Info Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/get-ovh-access-info-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/ovh/{cluster_id}/access-info # Get Ovh Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/get-ovh-ssh-keys-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/ovh/{cluster_id}/ssh-keys # List Cluster Nodes Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/list-cluster-nodes-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/ovh/{cluster_id}/nodes # List Node Groups Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/list-node-groups-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/ovh/{cluster_id}/node-groups # List OVH flavors available to a credential in a region Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/list-ovh-flavors-available-to-a-credential-in-a-region https://platform.ankra.app/openapi.json get /api/v1/clusters/ovh/flavors Return the OVH Cloud instance flavors the supplied credential's project can deploy in the given region. Only available flavors are valid for cluster creation. # List OVH regions available to a credential Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/list-ovh-regions-available-to-a-credential https://platform.ankra.app/openapi.json get /api/v1/clusters/ovh/regions Return the OVH Cloud regions the supplied credential's project can deploy in. Only these regions are valid for cluster creation. # Resync Ovh Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/resync-ovh-ssh-keys-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/ovh/{cluster_id}/ssh-keys/resync # Scale Node Group Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/scale-node-group-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/ovh/{cluster_id}/node-groups/{group_name}/scale # Scale OVH cluster workers Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/scale-ovh-cluster-workers https://platform.ankra.app/openapi.json post /api/v1/clusters/ovh/{cluster_id}/scale-workers # Start an OVH cluster Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/start-an-ovh-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/ovh/{cluster_id}/start Recreate the OVH cloud resources for a stopped cluster and reconcile it back to a running state. # Stop an OVH cluster Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/stop-an-ovh-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/ovh/{cluster_id}/stop Initiate async deletion of OVH cloud resources (servers, networks, SSH keys) without removing the cluster from the database. # Update Instance Type Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/update-instance-type-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/ovh/{cluster_id}/node-groups/{group_name}/instance-type # Update Labels Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/update-labels-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/ovh/{cluster_id}/node-groups/{group_name}/labels # Update Ovh Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/update-ovh-ssh-keys-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/ovh/{cluster_id}/ssh-keys # Update Taints Endpoint Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/update-taints-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/ovh/{cluster_id}/node-groups/{group_name}/taints # Upgrade Kubernetes version Source: https://docs.ankra.ai/api-reference/ovh-cluster-api/upgrade-kubernetes-version https://platform.ankra.app/openapi.json post /api/v1/clusters/ovh/{cluster_id}/upgrade-k8s-version # Create an OVH API credential Source: https://docs.ankra.ai/api-reference/ovh-credentials-api/create-an-ovh-api-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/ovh # Create an SSH key credential Source: https://docs.ankra.ai/api-reference/ovh-credentials-api/create-an-ssh-key-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/ovh/ssh-key # List OVH API credentials Source: https://docs.ankra.ai/api-reference/ovh-credentials-api/list-ovh-api-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/ovh # List SSH key credentials Source: https://docs.ankra.ai/api-reference/ovh-credentials-api/list-ssh-key-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/ovh/ssh-keys # Read what a cluster is for Source: https://docs.ankra.ai/api-reference/read-what-a-cluster-is-for https://platform.ankra.app/openapi.json get /org/clusters/{cluster_id}/criticality Reports the cluster's criticality, the denominator the insight scanner grades blast radius against. Clusters that have never been classified read as production, which is the column's default and the value the grading falls back to. # Add a managed node pool Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/add-a-managed-node-pool https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/{cluster_id}/node-pools Bearer PAT authentication; RBAC permission `clusters.write`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Add a managed node pool Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/add-a-managed-node-pool-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/{cluster_id}/node-pools Browser session authentication; RBAC permission `clusters.write`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Add node group Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/add-node-group https://platform.ankra.app/openapi.json post /api/v1/clusters/scaleway/{cluster_id}/node-groups Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Add node group Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/add-node-group-1 https://platform.ankra.app/openapi.json post /org/clusters/scaleway/{cluster_id}/node-groups Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Create a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/create-a-managed-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider} Bearer PAT authentication; RBAC permission `clusters.create`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Create a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/create-a-managed-cluster-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider} Browser session authentication; RBAC permission `clusters.create`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Create a provider network Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/create-a-provider-network https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/networks Provision a provider network with the scoping credential so the create wizard can offer an inline create-network flow. GKE creates an auto subnet-mode VPC (a subnetwork in every region, like the GCP default network) and waits for the compute operation to finish; other providers answer 400. The GCP service account needs the compute.networks.create permission (for example via the Compute Network Admin role, roles/compute.networkAdmin); a credential without it answers 400 with the provider's permission message. The response is the created network in the options catalog's private_networks shape. # Create a provider network Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/create-a-provider-network-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/networks Provision a provider network with the scoping credential so the create wizard can offer an inline create-network flow. GKE creates an auto subnet-mode VPC (a subnetwork in every region, like the GCP default network) and waits for the compute operation to finish; other providers answer 400. The GCP service account needs the compute.networks.create permission (for example via the Compute Network Admin role, roles/compute.networkAdmin); a credential without it answers 400 with the provider's permission message. The response is the created network in the options catalog's private_networks shape. # Create a Scaleway credential Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/create-a-scaleway-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/scaleway Bearer PAT authentication; RBAC permission `credentials.write`. The secret is stored in Vault and connection-tested without echoing key material. # Create a Scaleway credential Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/create-a-scaleway-credential-1 https://platform.ankra.app/openapi.json post /org/credentials/scaleway Browser session authentication; RBAC permission `credentials.write`. The secret is stored in Vault and connection-tested without echoing key material. # Create a Scaleway Instances cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/create-a-scaleway-instances-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/scaleway Bearer PAT authentication; RBAC permission `clusters.create`. External cloud provider mode is mandatory; kubeadm accepts only Cilium. # Create a Scaleway Instances cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/create-a-scaleway-instances-cluster-1 https://platform.ankra.app/openapi.json post /org/clusters/scaleway Browser session authentication; RBAC permission `clusters.create`. External cloud provider mode is mandatory; kubeadm accepts only Cilium. # Create an SSH key credential Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/create-an-ssh-key-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/scaleway/ssh-key # Delete a managed node pool Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/delete-a-managed-node-pool https://platform.ankra.app/openapi.json delete /api/v1/clusters/managed/{provider}/{cluster_id}/node-pools/{node_pool_name} Bearer PAT authentication; RBAC permission `clusters.write`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Delete a managed node pool Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/delete-a-managed-node-pool-1 https://platform.ankra.app/openapi.json delete /org/clusters/managed/{provider}/{cluster_id}/node-pools/{node_pool_name} Browser session authentication; RBAC permission `clusters.write`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Delete node group Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/delete-node-group https://platform.ankra.app/openapi.json delete /api/v1/clusters/scaleway/{cluster_id}/node-groups/{group_name} Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Delete node group Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/delete-node-group-1 https://platform.ankra.app/openapi.json delete /org/clusters/scaleway/{cluster_id}/node-groups/{group_name} Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Delete the provider cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/delete-the-provider-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/{cluster_id}/delete-provider-cluster Bearer PAT authentication; RBAC permission `clusters.delete`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Delete the provider cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/delete-the-provider-cluster-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/{cluster_id}/delete-provider-cluster Browser session authentication; RBAC permission `clusters.delete`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Deprovision a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/deprovision-a-managed-cluster https://platform.ankra.app/openapi.json delete /api/v1/clusters/managed/{provider}/{cluster_id} Bearer PAT authentication; RBAC permission `clusters.delete`. For Kapsule this legacy DELETE is disconnect-only; provider deletion requires the explicit delete-provider-cluster endpoint. provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. # Deprovision a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/deprovision-a-managed-cluster-1 https://platform.ankra.app/openapi.json delete /org/clusters/managed/{provider}/{cluster_id} Browser session authentication; RBAC permission `clusters.delete`. For Kapsule this legacy DELETE is disconnect-only; provider deletion requires the explicit delete-provider-cluster endpoint. provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. # Deprovision a Scaleway Instances cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/deprovision-a-scaleway-instances-cluster https://platform.ankra.app/openapi.json delete /api/v1/clusters/scaleway/{cluster_id} Bearer PAT authentication; RBAC permission `clusters.delete`. Ordered teardown preserves explicitly retained storage and reports orphaned provider IDs. # Deprovision a Scaleway Instances cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/deprovision-a-scaleway-instances-cluster-1 https://platform.ankra.app/openapi.json delete /org/clusters/scaleway/{cluster_id} Browser session authentication; RBAC permission `clusters.delete`. Ordered teardown preserves explicitly retained storage and reports orphaned provider IDs. # Disconnect a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/disconnect-a-managed-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/{cluster_id}/disconnect Bearer PAT authentication; RBAC permission `clusters.delete`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Disconnect a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/disconnect-a-managed-cluster-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/{cluster_id}/disconnect Browser session authentication; RBAC permission `clusters.delete`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Discover managed clusters Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/discover-managed-clusters https://platform.ankra.app/openapi.json get /api/v1/clusters/managed/{provider}/discover Bearer PAT authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Discover managed clusters Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/discover-managed-clusters-1 https://platform.ankra.app/openapi.json get /org/clusters/managed/{provider}/discover Browser session authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Import a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/import-a-managed-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/import Bearer PAT authentication; RBAC permission `clusters.create`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Import a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/import-a-managed-cluster-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/import Browser session authentication; RBAC permission `clusters.create`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List live cluster Scaleway gateway types Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-live-cluster-scaleway-gateway-types https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/gateway-types Bearer PAT authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List live cluster Scaleway gateway types Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-live-cluster-scaleway-gateway-types-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/gateway-types Browser session authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List live cluster Scaleway instance types Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-live-cluster-scaleway-instance-types https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/instance-types Bearer PAT authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List live cluster Scaleway instance types Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-live-cluster-scaleway-instance-types-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/instance-types Browser session authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List live node-pool catalog for a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-live-node-pool-catalog-for-a-managed-cluster https://platform.ankra.app/openapi.json get /api/v1/clusters/managed/{provider}/{cluster_id}/node-pools/catalog Bearer PAT authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List live node-pool catalog for a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-live-node-pool-catalog-for-a-managed-cluster-1 https://platform.ankra.app/openapi.json get /org/clusters/managed/{provider}/{cluster_id}/node-pools/catalog Browser session authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List managed-cluster upgrades Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-managed-cluster-upgrades https://platform.ankra.app/openapi.json get /api/v1/clusters/managed/{provider}/{cluster_id}/upgrades Bearer PAT authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List managed-cluster upgrades Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-managed-cluster-upgrades-1 https://platform.ankra.app/openapi.json get /org/clusters/managed/{provider}/{cluster_id}/upgrades Browser session authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List managed node pools Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-managed-node-pools https://platform.ankra.app/openapi.json get /api/v1/clusters/managed/{provider}/{cluster_id}/node-pools Bearer PAT authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List managed node pools Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-managed-node-pools-1 https://platform.ankra.app/openapi.json get /org/clusters/managed/{provider}/{cluster_id}/node-pools Browser session authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List managed-provider options Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-managed-provider-options https://platform.ankra.app/openapi.json get /api/v1/clusters/managed/{provider}/options Bearer PAT authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List managed-provider options Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-managed-provider-options-1 https://platform.ankra.app/openapi.json get /org/clusters/managed/{provider}/options Browser session authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List node groups Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-node-groups https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/node-groups Bearer PAT authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # List node groups Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-node-groups-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/node-groups Browser session authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # List nodes Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-nodes https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/nodes Bearer PAT authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # List nodes Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-nodes-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/nodes Browser session authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # List options using the cluster's stored provider context Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-options-using-the-clusters-stored-provider-context https://platform.ankra.app/openapi.json get /api/v1/clusters/managed/{provider}/{cluster_id}/options Bearer PAT authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List options using the cluster's stored provider context Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-options-using-the-clusters-stored-provider-context-1 https://platform.ankra.app/openapi.json get /org/clusters/managed/{provider}/{cluster_id}/options Browser session authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # List Scaleway credentials Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/scaleway Bearer PAT authentication; RBAC permission `credentials.read`. Returns credential metadata only; access_key and secret_key are never returned. # List Scaleway credentials Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-credentials-1 https://platform.ankra.app/openapi.json get /org/credentials/scaleway Browser session authentication; RBAC permission `credentials.read`. Returns credential metadata only; access_key and secret_key are never returned. # List Scaleway gateway types Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-gateway-types https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/gateway-types Bearer PAT authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway gateway types Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-gateway-types-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/gateway-types Browser session authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway instance types Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-instance-types https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/instance-types Bearer PAT authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway instance types Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-instance-types-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/instance-types Browser session authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway locations Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-locations https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/locations Bearer PAT authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway locations Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-locations-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/locations Browser session authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway networks Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-networks https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/networks Bearer PAT authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway networks Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-networks-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/networks Browser session authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway pricing Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-pricing https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/pricing Bearer PAT authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway pricing Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-pricing-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/pricing Browser session authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway regions Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-regions https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/regions Bearer PAT authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway regions Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-regions-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/regions Browser session authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway zones Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-zones https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/zones Bearer PAT authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List Scaleway zones Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-scaleway-zones-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/zones Browser session authentication; RBAC permission `clusters.read`. Catalog prices carry currency/SKU metadata and explicit incomplete-pricing reasons. # List SSH key credentials Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/list-ssh-key-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/scaleway/ssh-keys # Preflight a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/preflight-a-managed-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/preflight Bearer PAT authentication; RBAC permission `clusters.create`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Preflight a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/preflight-a-managed-cluster-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/preflight Browser session authentication; RBAC permission `clusters.create`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Preflight a Scaleway Instances cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/preflight-a-scaleway-instances-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/scaleway/preflight Bearer PAT authentication; RBAC permission `clusters.create`. External cloud provider mode is mandatory; kubeadm accepts only Cilium. # Preflight a Scaleway Instances cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/preflight-a-scaleway-instances-cluster-1 https://platform.ankra.app/openapi.json post /org/clusters/scaleway/preflight Browser session authentication; RBAC permission `clusters.create`. External cloud provider mode is mandatory; kubeadm accepts only Cilium. # Read control-plane sizing Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-control-plane-sizing https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/control-plane Bearer PAT authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read control-plane sizing Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-control-plane-sizing-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/control-plane Browser session authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read Kubernetes version Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-kubernetes-version https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/k8s-version Bearer PAT authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read Kubernetes version Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-kubernetes-version-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/k8s-version Browser session authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read managed-cluster status Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-managed-cluster-status https://platform.ankra.app/openapi.json get /api/v1/clusters/managed/{provider}/{cluster_id}/status Bearer PAT authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Read managed-cluster status Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-managed-cluster-status-1 https://platform.ankra.app/openapi.json get /org/clusters/managed/{provider}/{cluster_id}/status Browser session authentication; RBAC permission `clusters.read`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Read node Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-node https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/nodes/{node_id} Bearer PAT authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read node Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-node-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/nodes/{node_id} Browser session authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read node-group autoscaling Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-node-group-autoscaling https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/node-groups/{group_name}/autoscaling Bearer PAT authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read node-group autoscaling Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-node-group-autoscaling-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/node-groups/{group_name}/autoscaling Browser session authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read private cluster access Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-private-cluster-access https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/access-info Bearer PAT authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read private cluster access Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-private-cluster-access-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/access-info Browser session authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read SSH keys Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-ssh-keys https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/ssh-keys Bearer PAT authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read SSH keys Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-ssh-keys-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/ssh-keys Browser session authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read worker count Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-worker-count https://platform.ankra.app/openapi.json get /api/v1/clusters/scaleway/{cluster_id}/worker-count Bearer PAT authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Read worker count Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/read-worker-count-1 https://platform.ankra.app/openapi.json get /org/clusters/scaleway/{cluster_id}/worker-count Browser session authentication; RBAC permission `clusters.read`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Replace a managed node pool with a new size Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/replace-a-managed-node-pool-with-a-new-size https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/{cluster_id}/node-pools/{node_pool_name}/replace Bearer PAT authentication; RBAC permission `clusters.write`. Requests a blue/green replacement of the node pool with a new instance size: a scheduler job creates a replacement pool with the requested size (same count, labels, taints, zone, and autoscaling), waits for it to become ready, deletes the replaced pool, and rebinds the stored definition to the replacement pool's deterministic name. No managed provider supports in-place pool resizing, so the 202 answer only accepts the intent. # Replace a managed node pool with a new size Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/replace-a-managed-node-pool-with-a-new-size-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/{cluster_id}/node-pools/{node_pool_name}/replace Browser session authentication; RBAC permission `clusters.write`. Requests a blue/green replacement of the node pool with a new instance size: a scheduler job creates a replacement pool with the requested size (same count, labels, taints, zone, and autoscaling), waits for it to become ready, deletes the replaced pool, and rebinds the stored definition to the replacement pool's deterministic name. No managed provider supports in-place pool resizing, so the 202 answer only accepts the intent. # Resize control-plane nodes Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/resize-control-plane-nodes https://platform.ankra.app/openapi.json put /api/v1/clusters/scaleway/{cluster_id}/control-plane/instance-type Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Resize control-plane nodes Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/resize-control-plane-nodes-1 https://platform.ankra.app/openapi.json put /org/clusters/scaleway/{cluster_id}/control-plane/instance-type Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Resize node group Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/resize-node-group https://platform.ankra.app/openapi.json put /api/v1/clusters/scaleway/{cluster_id}/node-groups/{group_name}/instance-type Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Resize node group Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/resize-node-group-1 https://platform.ankra.app/openapi.json put /org/clusters/scaleway/{cluster_id}/node-groups/{group_name}/instance-type Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Resize Public Gateway Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/resize-public-gateway https://platform.ankra.app/openapi.json put /api/v1/clusters/scaleway/{cluster_id}/bastion/instance-type Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Resize Public Gateway Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/resize-public-gateway-1 https://platform.ankra.app/openapi.json put /org/clusters/scaleway/{cluster_id}/bastion/instance-type Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Restart node Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/restart-node https://platform.ankra.app/openapi.json post /api/v1/clusters/scaleway/{cluster_id}/nodes/{node_id}/restart Bearer PAT authentication; RBAC permission `clusters.operate`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Restart node Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/restart-node-1 https://platform.ankra.app/openapi.json post /org/clusters/scaleway/{cluster_id}/nodes/{node_id}/restart Browser session authentication; RBAC permission `clusters.operate`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Resync SSH keys Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/resync-ssh-keys https://platform.ankra.app/openapi.json post /api/v1/clusters/scaleway/{cluster_id}/ssh-keys/resync Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Resync SSH keys Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/resync-ssh-keys-1 https://platform.ankra.app/openapi.json post /org/clusters/scaleway/{cluster_id}/ssh-keys/resync Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Scale a managed node pool Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/scale-a-managed-node-pool https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/{cluster_id}/node-pools/{node_pool_name}/scale Bearer PAT authentication; RBAC permission `clusters.operate`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Scale a managed node pool Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/scale-a-managed-node-pool-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/{cluster_id}/node-pools/{node_pool_name}/scale Browser session authentication; RBAC permission `clusters.operate`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Scale node group Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/scale-node-group https://platform.ankra.app/openapi.json put /api/v1/clusters/scaleway/{cluster_id}/node-groups/{group_name}/scale Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Scale node group Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/scale-node-group-1 https://platform.ankra.app/openapi.json put /org/clusters/scaleway/{cluster_id}/node-groups/{group_name}/scale Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Scale workers Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/scale-workers https://platform.ankra.app/openapi.json post /api/v1/clusters/scaleway/{cluster_id}/scale-workers Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Scale workers Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/scale-workers-1 https://platform.ankra.app/openapi.json post /org/clusters/scaleway/{cluster_id}/scale-workers Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Start Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/start https://platform.ankra.app/openapi.json post /api/v1/clusters/scaleway/{cluster_id}/start Bearer PAT authentication; RBAC permission `clusters.operate`. # Start Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/start-1 https://platform.ankra.app/openapi.json post /org/clusters/scaleway/{cluster_id}/start Browser session authentication; RBAC permission `clusters.operate`. # Start a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/start-a-managed-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/{cluster_id}/start Bearer PAT authentication; RBAC permission `clusters.operate`. Requests the provider-native cluster start; only providers advertising `supports_stop_start` in capabilities (AKS today) support it, others answer 400. The provider completes the transition asynchronously and subsequent status reads converge the resulting power state. # Start a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/start-a-managed-cluster-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/{cluster_id}/start Browser session authentication; RBAC permission `clusters.operate`. Requests the provider-native cluster start; only providers advertising `supports_stop_start` in capabilities (AKS today) support it, others answer 400. The provider completes the transition asynchronously and subsequent status reads converge the resulting power state. # Stop Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/stop https://platform.ankra.app/openapi.json post /api/v1/clusters/scaleway/{cluster_id}/stop Bearer PAT authentication; RBAC permission `clusters.operate`. # Stop Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/stop-1 https://platform.ankra.app/openapi.json post /org/clusters/scaleway/{cluster_id}/stop Browser session authentication; RBAC permission `clusters.operate`. # Stop a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/stop-a-managed-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/{cluster_id}/stop Bearer PAT authentication; RBAC permission `clusters.operate`. Requests the provider-native cluster stop; only providers advertising `supports_stop_start` in capabilities (AKS today) support it, others answer 400. The provider completes the transition asynchronously and subsequent status reads converge the resulting power state. # Stop a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/stop-a-managed-cluster-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/{cluster_id}/stop Browser session authentication; RBAC permission `clusters.operate`. Requests the provider-native cluster stop; only providers advertising `supports_stop_start` in capabilities (AKS today) support it, others answer 400. The provider completes the transition asynchronously and subsequent status reads converge the resulting power state. # Update control-plane count Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-control-plane-count https://platform.ankra.app/openapi.json put /api/v1/clusters/scaleway/{cluster_id}/control-plane Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Update control-plane count Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-control-plane-count-1 https://platform.ankra.app/openapi.json put /org/clusters/scaleway/{cluster_id}/control-plane Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Update managed node-pool autoscaling Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-managed-node-pool-autoscaling https://platform.ankra.app/openapi.json patch /api/v1/clusters/managed/{provider}/{cluster_id}/node-pools/{node_pool_name} Bearer PAT authentication; RBAC permission `clusters.write`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Update managed node-pool autoscaling Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-managed-node-pool-autoscaling-1 https://platform.ankra.app/openapi.json patch /org/clusters/managed/{provider}/{cluster_id}/node-pools/{node_pool_name} Browser session authentication; RBAC permission `clusters.write`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Update node-group autoscaling Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-node-group-autoscaling https://platform.ankra.app/openapi.json put /api/v1/clusters/scaleway/{cluster_id}/node-groups/{group_name}/autoscaling Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Update node-group autoscaling Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-node-group-autoscaling-1 https://platform.ankra.app/openapi.json put /org/clusters/scaleway/{cluster_id}/node-groups/{group_name}/autoscaling Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Update node-group labels Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-node-group-labels https://platform.ankra.app/openapi.json put /api/v1/clusters/scaleway/{cluster_id}/node-groups/{group_name}/labels Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Update node-group labels Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-node-group-labels-1 https://platform.ankra.app/openapi.json put /org/clusters/scaleway/{cluster_id}/node-groups/{group_name}/labels Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Update node-group taints Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-node-group-taints https://platform.ankra.app/openapi.json put /api/v1/clusters/scaleway/{cluster_id}/node-groups/{group_name}/taints Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Update node-group taints Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-node-group-taints-1 https://platform.ankra.app/openapi.json put /org/clusters/scaleway/{cluster_id}/node-groups/{group_name}/taints Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Update SSH keys Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-ssh-keys https://platform.ankra.app/openapi.json put /api/v1/clusters/scaleway/{cluster_id}/ssh-keys Bearer PAT authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Update SSH keys Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/update-ssh-keys-1 https://platform.ankra.app/openapi.json put /org/clusters/scaleway/{cluster_id}/ssh-keys Browser session authentication; RBAC permission `clusters.write`. PAT mutations support `wait=false` where implemented; browser mutations require CSRF. # Upgrade a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/upgrade-a-managed-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/managed/{provider}/{cluster_id}/upgrade Bearer PAT authentication; RBAC permission `clusters.operate`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Upgrade a managed cluster Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/upgrade-a-managed-cluster-1 https://platform.ankra.app/openapi.json post /org/clusters/managed/{provider}/{cluster_id}/upgrade Browser session authentication; RBAC permission `clusters.operate`. For Kapsule, provider_cluster_id is the opaque region-qualified `regions/{region}/clusters/{id}` reference. CNI is immutable. Imported/unknown provenance is disconnect-only; provider deletion is allowed by default only for created clusters. # Upgrade K8S Version Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/upgrade-k8s-version https://platform.ankra.app/openapi.json post /api/v1/clusters/scaleway/{cluster_id}/upgrade-k8s-version Bearer PAT authentication; RBAC permission `clusters.operate`. # Upgrade K8S Version Source: https://docs.ankra.ai/api-reference/scaleway-kapsule/upgrade-k8s-version-1 https://platform.ankra.app/openapi.json post /org/clusters/scaleway/{cluster_id}/upgrade-k8s-version Browser session authentication; RBAC permission `clusters.operate`. # Create vulnerability disposition policy Source: https://docs.ankra.ai/api-reference/security/create-vulnerability-disposition-policy https://platform.ankra.app/openapi.json post /org/security/vulnerability-dispositions # Enable the curated security baseline stack Source: https://docs.ankra.ai/api-reference/security/enable-the-curated-security-baseline-stack https://platform.ankra.app/openapi.json post /org/security/clusters/{cluster_id}/enable-baseline # Export the organisation compliance evidence report Source: https://docs.ankra.ai/api-reference/security/export-the-organisation-compliance-evidence-report https://platform.ankra.app/openapi.json get /org/security/compliance-report # Get imported cluster add-on security posture Source: https://docs.ankra.ai/api-reference/security/get-imported-cluster-add-on-security-posture https://platform.ankra.app/openapi.json get /org/clusters/imported/{cluster_id}/addons/{addon_name}/security # Get one imported cluster's aggregated policy violations Source: https://docs.ankra.ai/api-reference/security/get-one-imported-clusters-aggregated-policy-violations https://platform.ankra.app/openapi.json get /org/clusters/imported/{cluster_id}/security/policy-violations # Get one imported cluster's compliance view Source: https://docs.ankra.ai/api-reference/security/get-one-imported-clusters-compliance-view https://platform.ankra.app/openapi.json get /org/clusters/imported/{cluster_id}/security/compliance # Get one imported cluster's NetworkPolicy over-privilege score Source: https://docs.ankra.ai/api-reference/security/get-one-imported-clusters-networkpolicy-over-privilege-score https://platform.ankra.app/openapi.json get /org/clusters/imported/{cluster_id}/security/network-policy-overprivilege # Get organization security finding detail Source: https://docs.ankra.ai/api-reference/security/get-organization-security-finding-detail https://platform.ankra.app/openapi.json get /org/security/findings/{finding_id} # Get organization security overview Source: https://docs.ankra.ai/api-reference/security/get-organization-security-overview https://platform.ankra.app/openapi.json get /org/security/overview # Get the organisation compliance rollup Source: https://docs.ankra.ai/api-reference/security/get-the-organisation-compliance-rollup https://platform.ankra.app/openapi.json get /org/security/compliance # List cluster security posture Source: https://docs.ankra.ai/api-reference/security/list-cluster-security-posture https://platform.ankra.app/openapi.json get /org/security/clusters # List organization security findings Source: https://docs.ankra.ai/api-reference/security/list-organization-security-findings https://platform.ankra.app/openapi.json get /org/security/findings # List organization security workloads Source: https://docs.ankra.ai/api-reference/security/list-organization-security-workloads https://platform.ankra.app/openapi.json get /org/security/workloads # List vulnerability disposition policies Source: https://docs.ankra.ai/api-reference/security/list-vulnerability-disposition-policies https://platform.ankra.app/openapi.json get /org/security/vulnerability-dispositions # Preview vulnerability disposition policy Source: https://docs.ankra.ai/api-reference/security/preview-vulnerability-disposition-policy https://platform.ankra.app/openapi.json post /org/security/vulnerability-dispositions/preview # Set the security baseline policy mode (audit or enforce) Source: https://docs.ankra.ai/api-reference/security/set-the-security-baseline-policy-mode-audit-or-enforce https://platform.ankra.app/openapi.json post /org/clusters/imported/{cluster_id}/security/policy-mode # Soft-revoke vulnerability disposition policy Source: https://docs.ankra.ai/api-reference/security/soft-revoke-vulnerability-disposition-policy https://platform.ankra.app/openapi.json post /org/security/vulnerability-dispositions/{policy_id}/revoke # Update vulnerability disposition policy Source: https://docs.ankra.ai/api-reference/security/update-vulnerability-disposition-policy https://platform.ankra.app/openapi.json patch /org/security/vulnerability-dispositions/{policy_id} # Set what a cluster is called and what it is for Source: https://docs.ankra.ai/api-reference/set-what-a-cluster-is-called-and-what-it-is-for https://platform.ankra.app/openapi.json patch /org/clusters/imported/{cluster_id}/environment Sets the environment label and, when the body carries one, the criticality that decides how loudly the cluster reports. Both are written in a single transaction because to the operator they are one decision: picking an environment without a matching criticality is how a cluster ends up labelled for testing while the insight scanner still grades every finding on it at production weight. A body without a criticality leaves the stored one untouched and answers with the environment alone, which is the shape every caller written before the two settings were merged sends and expects. # Set what a cluster is for Source: https://docs.ankra.ai/api-reference/set-what-a-cluster-is-for https://platform.ankra.app/openapi.json put /org/clusters/{cluster_id}/criticality Records the cluster's criticality, the denominator the insight scanner grades blast radius against. A production cluster reports exactly as it always has; a lower criticality needs a correspondingly larger blast radius before a finding reaches a severity that opens a ticket. # Decrypt content using SOPS Source: https://docs.ankra.ai/api-reference/sops-api/decrypt-content-using-sops https://platform.ankra.app/openapi.json post /api/v1/org/sops/decrypt # Encrypt content using SOPS Source: https://docs.ankra.ai/api-reference/sops-api/encrypt-content-using-sops https://platform.ankra.app/openapi.json post /api/v1/org/sops/encrypt # Get SOPS configuration including public key Source: https://docs.ankra.ai/api-reference/sops-api/get-sops-configuration-including-public-key https://platform.ankra.app/openapi.json get /api/v1/org/sops/config # Create stack profile Source: https://docs.ankra.ai/api-reference/stack-profiles/create-stack-profile https://platform.ankra.app/openapi.json post /org/stack-profiles # Delete stack profile logo Source: https://docs.ankra.ai/api-reference/stack-profiles/delete-stack-profile-logo https://platform.ankra.app/openapi.json delete /org/stack-profiles/{profile_id}/logo # Get stack profile logo Source: https://docs.ankra.ai/api-reference/stack-profiles/get-stack-profile-logo https://platform.ankra.app/openapi.json get /org/stack-profiles/{profile_id}/logo # Get stack profile metadata suggestions Source: https://docs.ankra.ai/api-reference/stack-profiles/get-stack-profile-metadata-suggestions https://platform.ankra.app/openapi.json get /api/v1/org/stack-profiles/metadata-suggestions # Get stack profile metadata suggestions Source: https://docs.ankra.ai/api-reference/stack-profiles/get-stack-profile-metadata-suggestions-1 https://platform.ankra.app/openapi.json get /org/stack-profiles/metadata-suggestions # Share stack profile Source: https://docs.ankra.ai/api-reference/stack-profiles/share-stack-profile https://platform.ankra.app/openapi.json post /org/stack-profiles/{profile_id}/shares # Store stack profile logo Source: https://docs.ankra.ai/api-reference/stack-profiles/store-stack-profile-logo https://platform.ankra.app/openapi.json put /org/stack-profiles/{profile_id}/logo # Add Ticket Attachment Endpoint Source: https://docs.ankra.ai/api-reference/support-api/add-ticket-attachment-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/support/tickets/{ticket_id}/attachments # Add Ticket Comment Endpoint Source: https://docs.ankra.ai/api-reference/support-api/add-ticket-comment-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/support/tickets/{ticket_id}/comments # Close Ticket Endpoint Source: https://docs.ankra.ai/api-reference/support-api/close-ticket-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/support/tickets/{ticket_id}/close # Create Ticket Endpoint Source: https://docs.ankra.ai/api-reference/support-api/create-ticket-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/support/tickets # Get Ticket Attachment Endpoint Source: https://docs.ankra.ai/api-reference/support-api/get-ticket-attachment-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/support/tickets/{ticket_id}/attachments/{attachment_id} # Get Ticket Endpoint Source: https://docs.ankra.ai/api-reference/support-api/get-ticket-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/support/tickets/{ticket_id} # List Tickets Endpoint Source: https://docs.ankra.ai/api-reference/support-api/list-tickets-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/support/tickets # Review Ticket Endpoint Source: https://docs.ankra.ai/api-reference/support-api/review-ticket-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/support/tickets/review # Add Node Group Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/add-node-group-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/upcloud/{cluster_id}/node-groups # Change Control Plane Count Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/change-control-plane-count-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/upcloud/{cluster_id}/control-plane # Change Control Plane Instance Type Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/change-control-plane-instance-type-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/upcloud/{cluster_id}/control-plane/instance-type # Create an UpCloud cluster Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/create-an-upcloud-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/upcloud # Delete Node Group Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/delete-node-group-endpoint https://platform.ankra.app/openapi.json delete /api/v1/clusters/upcloud/{cluster_id}/node-groups/{group_name} # Deprovision an UpCloud cluster Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/deprovision-an-upcloud-cluster https://platform.ankra.app/openapi.json delete /api/v1/clusters/upcloud/{cluster_id} # Get Control Plane Info Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/get-control-plane-info-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/upcloud/{cluster_id}/control-plane # Get current Kubernetes version Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/get-current-kubernetes-version https://platform.ankra.app/openapi.json get /api/v1/clusters/upcloud/{cluster_id}/k8s-version # Get current worker count Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/get-current-worker-count https://platform.ankra.app/openapi.json get /api/v1/clusters/upcloud/{cluster_id}/worker-count # Get Node Detail Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/get-node-detail-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/upcloud/{cluster_id}/nodes/{node_id} # Get Upcloud Access Info Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/get-upcloud-access-info-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/upcloud/{cluster_id}/access-info # Get Upcloud Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/get-upcloud-ssh-keys-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/upcloud/{cluster_id}/ssh-keys # List Cluster Nodes Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/list-cluster-nodes-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/upcloud/{cluster_id}/nodes # List Node Groups Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/list-node-groups-endpoint https://platform.ankra.app/openapi.json get /api/v1/clusters/upcloud/{cluster_id}/node-groups # Resync Upcloud Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/resync-upcloud-ssh-keys-endpoint https://platform.ankra.app/openapi.json post /api/v1/clusters/upcloud/{cluster_id}/ssh-keys/resync # Scale Node Group Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/scale-node-group-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/upcloud/{cluster_id}/node-groups/{group_name}/scale # Scale UpCloud cluster workers Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/scale-upcloud-cluster-workers https://platform.ankra.app/openapi.json post /api/v1/clusters/upcloud/{cluster_id}/scale-workers # Start an UpCloud cluster Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/start-an-upcloud-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/upcloud/{cluster_id}/start Recreate the UpCloud cloud resources for a stopped cluster and reconcile it back to a running state. # Stop an UpCloud cluster Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/stop-an-upcloud-cluster https://platform.ankra.app/openapi.json post /api/v1/clusters/upcloud/{cluster_id}/stop Initiate async deletion of UpCloud cloud resources (servers, networks, gateways, SSH keys) without removing the cluster from the database. # Update Instance Type Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/update-instance-type-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/upcloud/{cluster_id}/node-groups/{group_name}/instance-type # Update Labels Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/update-labels-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/upcloud/{cluster_id}/node-groups/{group_name}/labels # Update Taints Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/update-taints-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/upcloud/{cluster_id}/node-groups/{group_name}/taints # Update Upcloud Ssh Keys Endpoint Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/update-upcloud-ssh-keys-endpoint https://platform.ankra.app/openapi.json put /api/v1/clusters/upcloud/{cluster_id}/ssh-keys # Upgrade Kubernetes version Source: https://docs.ankra.ai/api-reference/upcloud-cluster-api/upgrade-kubernetes-version https://platform.ankra.app/openapi.json post /api/v1/clusters/upcloud/{cluster_id}/upgrade-k8s-version # Create an SSH key credential Source: https://docs.ankra.ai/api-reference/upcloud-credentials-api/create-an-ssh-key-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/upcloud/ssh-key # Create an UpCloud API credential Source: https://docs.ankra.ai/api-reference/upcloud-credentials-api/create-an-upcloud-api-credential https://platform.ankra.app/openapi.json post /api/v1/credentials/upcloud # List SSH key credentials Source: https://docs.ankra.ai/api-reference/upcloud-credentials-api/list-ssh-key-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/upcloud/ssh-keys # List UpCloud API credentials Source: https://docs.ankra.ai/api-reference/upcloud-credentials-api/list-upcloud-api-credentials https://platform.ankra.app/openapi.json get /api/v1/credentials/upcloud # Create Cluster Variable Api Endpoint Source: https://docs.ankra.ai/api-reference/variables/create-cluster-variable-api-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/clusters/imported/{cluster_id}/variables # Create Organisation Variable Api Endpoint Source: https://docs.ankra.ai/api-reference/variables/create-organisation-variable-api-endpoint https://platform.ankra.app/openapi.json post /api/v1/org/variables # Delete Cluster Variable Api Endpoint Source: https://docs.ankra.ai/api-reference/variables/delete-cluster-variable-api-endpoint https://platform.ankra.app/openapi.json delete /api/v1/org/clusters/imported/{cluster_id}/variables/{variable_name} # Delete Organisation Variable Api Endpoint Source: https://docs.ankra.ai/api-reference/variables/delete-organisation-variable-api-endpoint https://platform.ankra.app/openapi.json delete /api/v1/org/variables/{variable_name} # List Cluster Variables Api Endpoint Source: https://docs.ankra.ai/api-reference/variables/list-cluster-variables-api-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/clusters/imported/{cluster_id}/variables # List Organisation Variables Api Endpoint Source: https://docs.ankra.ai/api-reference/variables/list-organisation-variables-api-endpoint https://platform.ankra.app/openapi.json get /api/v1/org/variables # Update Cluster Variable Api Endpoint Source: https://docs.ankra.ai/api-reference/variables/update-cluster-variable-api-endpoint https://platform.ankra.app/openapi.json put /api/v1/org/clusters/imported/{cluster_id}/variables/{variable_name} # Update Organisation Variable Api Endpoint Source: https://docs.ankra.ai/api-reference/variables/update-organisation-variable-api-endpoint https://platform.ankra.app/openapi.json put /api/v1/org/variables/{variable_name} # Changelog Source: https://docs.ankra.ai/changelog Product updates and announcements # A Playground for Every Organisation, An Agents Page That Shows Who Needs You, Monorepo Demos That Deploy Every App, Publish Your Add-ons to Every Organisation, See Who Did What to a Cluster, Park Clusters on a Schedule, Credentials That Show Their Capacity, A Calmer Credentials Page, Two More Cluster Platforms in Your Terminal, AI Writes That Ask First, Demos That Fix Their Own Configuration, a Full Page for Every Demo, Monorepos That Onboard One App at a Time, AI Chat That Builds Proxmox Clusters, Application Setups That Rescue Themselves, a License on Every Chart, Gateway Resizes That Wait for the Cloud, Registry and Validation Errors That Explain Themselves, Secret Detection That Reads the Value, GitOps Status From the CLI, CLI Listings Built for Scripting, a Branch Picker That Knows Your Repository, and Demos That Run Any Codebase, GitOps Status That Shows the Repository It Actually Read, a Credential Check That Counts Every Cluster, Repository Pickers That Follow the Credential You Chose, and Prerelease Chart Versions That Validate, plus a New Default AI Model, a Publish Flow That Explains Itself, Version History for Published Applications, Catalog Publishing That Checks Who Is Asking, Availability Zones for OVH Clusters, Applications That Publish to a Registry You Already Run, Pull Request Builds That Stop Publishing Images, Stack Profiles You Can Run Before You Deploy, an AI Chat That Acts on Your Defaults, Additive Deploys That Can Run Themselves, Chats That Follow the Cluster They Created, Drafts That Are Never Replaced in Silence, and an UpCloud Create Wizard That Can Find the Right Plan ## An UpCloud create wizard that can find the right plan Since the Ankra-managed UpCloud wizard started reading UpCloud's live catalogue, its plan pickers rendered all 174 plans as flat walls of tiles - three of them on one page, one each for the bastion, the control plane, and the workers - with no search, no filters, ordering that put `12xCPU` before `1xCPU`, and roughly forty discontinued series mixed in as if they were current. The 15 datacenter zones stacked as another full page of radio rows. Each picker is now the same plan browser the other provider wizards use. It opens on a one-line summary of the plan already selected; below it sit a search that spans every category, family tabs (Starter, Premium, Cloud Native, GPU, GPU Spot), vCPU quick filters, and a sortable table for the long tail. Discontinued series live behind a **Current plans / Legacy** toggle instead of dominating the page, and plans order smallest-first. Zones are grouped by region - Europe, North America, Asia-Pacific - as compact cards, and Helsinki #2 carries a badge for being the only zone stocking GPU plans today. Pick a GPU plan while another zone is selected and the wizard warns that the create is likely to fail at server creation, instead of letting you find out ten minutes in. The cost estimate also stopped pricing plans it has no published figure for at \$0 - it shows a dash and notes the total covers priced items only. ## An AI chat that acts on your defaults Agent-mode chat used to interrogate you: which credential, which zone, what name, which sizing, in what order - round after round of multiple-choice before any work happened, for choices that all had sensible defaults. Agent mode now acts on those defaults and states each assumption in one line ("Using namespace `monitoring` - say the word to change it"), reserving questions for decisions that are genuinely yours: destructive changes, real money, or an ambiguous goal. When it does ask, it asks once - every needed decision batched into a single question block. The same overhaul grounds the answers better. AI Insights the assistant cites now carry a freshness marker, so a diagnosis no scan has confirmed recently gets re-verified against live state instead of being repeated as fact. Chart-configuration lookups always return readable, navigable data - when a chart's options run long, the assistant gets a trimmed view with named paths it can drill into, never cut-off text. And the assistant can look up your organisation's preview domain from any conversation, so the public URL it proposes for a new service is on a domain that will actually resolve. [AI Assistant →](/platform/ai-assistant) ## Additive deploys that can run themselves With the chat's autonomy setting on **Auto**, a stack deploy whose change set removes nothing - new add-ons, new manifests, configuration changes to what is already there - now executes immediately with a receipt carrying its full bill of materials, instead of stopping at a confirmation card. The bill of materials is generated and validated before anything runs; if validation fails, or the same deploy would remove or replace a deployed add-on or manifest, the confirmation card comes back exactly as before. Cluster create, scale, upgrade, stop, and delete are pinned to always ask, whatever the setting - cost stays a human decision - and writes into protected system namespaces such as `kube-system` remain refused outright. Autonomy is off unless you turn it on. Every conversation starts on **Manual** - every write confirmed, exactly as before - the setting is per conversation, and it appears once AI autonomy is enabled for your organisation. It is also not the **Auto** in the model picker, which only routes between models. Every auto-approved action lands in the conversation as a receipt and in the audit log with its autonomy attribution, so what ran, and why it was allowed to, is always reconstructable. On **Auto**, a validated additive stack deploy applies to your cluster without a human click in between. Switch it on for conversations where you want that speed; stay on Manual where every change should be gated. [AI Assistant →](/platform/ai-assistant#autonomy-manual-or-auto) ## Chats that follow the cluster they created Ask the AI to build a cluster and the conversation now follows it: when the create you approved goes through, a conversation that wasn't already scoped to a cluster is scoped to the new one - so once provisioning finishes, designing stacks, deploying workloads, and reading live state carry on right there, with no more "no cluster selected" from the conversation that did the selecting. Long provisioning runs also stopped crying wolf: the live tracker now gives a cluster build the time it actually takes - 40 minutes, up from 15 - and when it does hand off, it says the build is still in progress rather than calling it a failure. And a failed action no longer strands the conversation mid-flight: the portal now waits for the session to finish its turn before delivering the follow-up that explains what happened, instead of dropping it. [AI Assistant →](/platform/ai-assistant) ## Drafts that are never replaced in silence Designing a new stack while another draft was in progress used to overwrite the previous draft without a word - finished work, gone. A replaced draft is now retired with a full audit trail instead of silently overwritten, and the chat tells you exactly what happened and which draft it replaced, with guidance to deploy or discard a finished draft before starting the next one. Namespaces behave too: the namespace you ask for is the namespace you get, per-chart overrides are supported, and moving a deployed add-on between namespaces from chat now works - the AI can supply the migration strategy the engine requires instead of dead-ending. [AI Assistant →](/platform/ai-assistant) ## Stack profiles you can run before you deploy A stack profile could only be tried by instantiating it onto a real cluster. Reviewing a new version, checking a public profile before adopting it, or showing a colleague what a stack actually deploys all meant putting it somewhere real first. A profile now has a **Demos** tab of its own. Launch one and Ankra installs the profile's add-ons and manifests into a throwaway, quota-bounded namespace on your organisation's staging cluster - the same lane branch demos have always used - on a timer that deletes it when it runs out. The details view reads the namespace live: how far the stack got, every object it installed with its manifest, the namespace's Kubernetes events, and a log tail from any pod. A chart that fails to install reports its own reason ("no matching PVC storage class"), not a generic failure. A profile demo deploys no application of its own, so there is no image or routing step to sit and wait on - the stack finishing is what makes it ready. One demo runs per profile: launching again replaces it rather than stacking a second copy on the staging cluster, so relaunch is how you pick up a new version or changed parameters. The two demo lists are now tied together. An application whose demo settings designate a stack profile shows that profile in its **Demos** tab, along with the profile's own live demos and a link straight into each - the stack is often already running, and launching a whole application demo just to look at it wastes staging capacity. The profile's tab lists the applications designating it, from the other side. Everything is available to the CLI too, under `/api/v1/org/stack-profiles/{profile_id}/demos`. ## Availability zones for OVH clusters An OVH cluster in a 3-AZ region such as `EU-WEST-PAR` put every node in the same availability zone, control plane included, and there was no way to ask for anything else. Nothing in the create path could carry a zone, so OVH chose one and used it for the whole cluster. You can now spread a cluster across the zones of a 3-AZ region, and pin a node group to one zone: ```bash theme={null} ankra cluster ovh regions --credential-id --with-zones ankra cluster ovh create --name my-cluster --region EU-WEST-PAR \ --availability-zones eu-west-par-a,eu-west-par-b,eu-west-par-c \ --control-plane-count 3 ankra cluster ovh node-group add --name database-par-a \ --instance-type r3-128 --availability-zone eu-west-par-a ``` Control planes and etcd spread per role, workers per node group, and every day-2 path - node group add, node group scale, worker scale, control plane growth - balances new instances around where the existing ones already are. Spreading needs at least 3 control planes, because fewer cannot hold etcd quorum through the loss of a zone; the create is refused rather than promising fault tolerance it cannot deliver. Every OVH node now also carries the standard `topology.kubernetes.io/zone` and `/region` labels, taken from the zone OVH reports for the live instance rather than the one that was requested. That makes them correct on clusters created before any of this existed too - Ankra records the zone the next time it reads the instance, and `ankra cluster reconcile ` applies the labels without waiting for a change to trigger a sync. OVH High Speed block storage is zonal: a volume is replicated within one zone and cannot attach from another. A single database pod with one PersistentVolume is not zone-fault-tolerant however the nodes are spread. Zone tolerance needs replication at the application layer, one replica and one volume per zone. The default StorageClass on OVH clusters is now `csi-cinder-sc-topology`, which binds `WaitForFirstConsumer` so a volume is created in the zone its pod was scheduled to instead of stranding it. New OVH clusters also stop installing k3s's bundled local-path provisioner, which marked itself the default StorageClass alongside the cinder one. Two defaults left the class an unqualified PersistentVolumeClaim resolves to undefined, and resolving to local-path put the volume on a single node's disk with no replication. Existing clusters keep local-path untouched, since removing a StorageClass would orphan any volume already bound to it - name the class you want explicitly there rather than relying on the default. [Availability zones →](/guides/ovh-clusters#availability-zones) ## A publish flow that explains itself Publishing to a catalog was three different screens depending on what you were publishing, and each of them failed late. Publishing an application was four unlabelled text boxes; if the version was already taken, or the application was not publishable at all, you found out after submitting. Every publish flow is now the same shape: check, review, confirm. Before anything is submitted you see what will be published, where it lands, and — the useful part — **why it cannot be published, if it cannot**. Publishing an application now starts from Ankra's readiness check, which has always existed but never had anywhere to appear: a missing image registry declaration is reported up front, with a **Fix automatically** button where Ankra can resolve it for you. A version that is already published is refused inline, before anything is snapshotted, instead of coming back as a conflict after submitting. [Publishing applications as add-ons →](/platform/application-addons) · [Publishing add-ons →](/platform/addon-publishing) ## Version history for published applications A published application listed its versions as a flat row of numbers. It now has a history: each version carries a **changelog** you write at publish time, who published it, and a **Compare** against the version before it. Comparing shows which manifest files were added, removed or modified with their contents side by side, and — separately — which **deploy options** changed. That distinction matters: options are the add-on's install-time contract, so changing one is a breaking change for anyone who already installed it. A version that starts or stops referencing an environment `Secret` is called out for the same reason. Existing versions keep working unchanged; those published before changelogs simply have none. [Version history →](/platform/application-addons#version-history) ## Catalog publishing now checks who is asking Proposing an add-on to the global Ankra Catalog puts your organisation's name on a pull request against a public repository, and once merged the entry is visible to every organisation. It now requires the **Manage Helm registries** permission, held by organisation admins and owners. Members and operators can still open the flow and review exactly what would be proposed — they just cannot submit it, and the flow says so on the first step rather than failing at the end. Ankra also screens the rendered manifest before it can be proposed, refusing credentials embedded in a URL and recognisable provider tokens, naming the field so it can be corrected. A pull request is effectively permanent: a credential that reaches a public repository is in its history even if the branch is later closed. [Publishing add-ons →](/platform/addon-publishing#who-can-publish) ## Applications can publish to a registry you already run An Application's container images went to your organisation's private Ankra registry, and there was no way to say otherwise. If you already operate a registry — often the same Harbor whose OCI charts Ankra indexes for you — your images existed, they were simply not where Ankra looked. Publish readiness reported "no image has been pushed yet" indefinitely while the application ran healthily from the registry it actually uses, and the deploy gate stayed shut behind an artifact that was never going to appear. An Application can now declare the registry it publishes to, pointing at a registry credential Ankra already holds: ```json theme={null} "image_registry": { "url": "oci://artifact.example.com/commerce-images", "credential_name": "example-harbor-pull", "pull_secret_name": "harbor-registry", "username_secret_name": "HARBOR_USERNAME", "password_secret_name": "HARBOR_PASSWORD" } ``` Everything downstream follows it: the generated workflow pushes there and logs in with the secret names you gave, publish readiness verifies the tag **in that registry** with the credential you named, the deploy gate and image listings probe it, container scanning reads its tags, generated Deployments reference the pull Secret you named, and Ankra creates that Secret in the deploy namespace from the same credential. One credential serves chart pull, image pull, and readiness. On a monorepo, a component may declare its own registry — apps that live in different projects with their own robots and retention rules are addressed individually. **Ankra does not mint robots for a registry you operate.** Setup names the two Actions secrets the workflow reads and leaves them to you, rather than writing a credential Ankra happens to hold over a push robot you administer. Readiness reports whether they exist; `manage_actions_secrets: true` opts back in. [Using your own registry →](/concepts/applications#using-your-own-registry) ## Pull request builds no longer publish images The generated workflow ran on `pull_request` with `push: true`, so a build from unmerged code published an image — into a registry whose retention and tag-immutability rules are governed elsewhere, tagged as though it were a real build. Pull request runs now build and scan the source without pushing. The image scan follows the push, so it runs on branch builds, where there is an artifact to pull back and scan. ## GitOps status now shows the repository it actually read `ankra cluster gitops status` and the cluster's GitOps settings reported the repository Ankra has **stored** for a cluster. A sync now records the repository, branch and provider it actually read, and the status answer carries it as `observed_source` alongside a `source_mismatch` flag. If the two ever disagree, you can see it rather than having to infer it by comparing commits across repositories. Underneath, the cause of that disagreement is gone. A cluster could end up carrying more than one GitOps repository record, and different parts of the platform picked different ones — so a cluster could sync from one repository while reporting another. Applying a cluster definition now leaves exactly one active record, and the sync loop and the status view resolve it the same way by construction. Repointing a cluster through `spec.git_repository` works as documented, including onto a **non-default branch**: one repository with a branch per environment is a supported layout. Repointing prunes what the new source does not define, PersistentVolumeClaims included. Diff the two sources over the cluster's directory before you apply. [GitOps →](/concepts/gitops) · [ImportCluster reference →](/reference/importcluster) ## A credential check that counts every cluster Before replacing or deleting a GitHub credential, `get_github_credential_usages` tells you what depends on it. It was only counting **imported** clusters, so any cluster Ankra provisioned — on DigitalOcean, Hetzner, OVH, UpCloud, GKE, EKS, AKS and the rest — was missing from the answer. Acting on that count, you could revoke a credential that a live GitOps sync was riding. Every cluster is now counted, whoever provisioned it. The response also separates `usage_count` (clusters) from `application_count` (Applications built from the credential's repositories) and adds `dependent_count` for the total, and a credential name shared by more than one credential now returns the full superset instead of an empty answer. ## Repository pickers that follow the credential you chose In a cluster's **Settings → GitOps**, changing the credential left the repository selection pointing at the previous credential's repository, and **Sync Repositories** refreshed the credential you were replacing rather than the one you had just picked. Moving a cluster to a repository under a different GitHub organisation could not be completed. Choosing a different credential now clears the repository so you pick one the new credential can actually see, and syncing follows your current selection. ## Prerelease chart versions now validate `ankra cluster validate` could reject a `chart_version` that was deployed and running — typically a CI-published prerelease such as `0.1.6-ci-ankra-pipeline`. Prereleases were never excluded from indexing. The real cause was tag pagination: Ankra stopped reading an OCI repository's tags after the first page unless the registry sent a `Link: rel="next"` header, which not every registry does. Charts with many tags therefore lost their newest versions from the index, and a pin `validate` was asked about could never resolve. Ankra now pages through every tag, and reports a truncated listing instead of indexing a partial one. The error also stops pointing at the wrong thing: it now says the version is not **indexed**, and suggests re-syncing the registry. ## A playground for every organisation The **playground** — a real, writable Kubernetes environment Ankra provisions for you — is now available to every organisation. There is nothing to enable and nothing to install: click **Start playground** in the create-cluster dialog, and a couple of minutes later you have a cluster with the Ankra agent already connected. It is a genuine cluster, not a simulation. Each playground is a [vcluster](https://www.vcluster.com/) with its own API server, isolated per organisation, running on Ankra's infrastructure. Deploy stacks through the normal pipeline, browse live resources, stream logs, open a terminal, and ask the AI to build things — all before you connect a cluster of your own. One per organisation, expiring after a few days of inactivity, with a heads-up before it goes. Organisations created before this change may still see a `sandbox-demo` cluster. It keeps working, but its deploys are simulated rather than run on real infrastructure — start a playground for the real thing. From the terminal: ```bash theme={null} ankra cluster playground create ankra cluster playground status ``` [Playground →](/guides/cluster-sandbox) ## An agents page that shows who needs you The **AI Agents** overview now tells you where your fleet stands without opening every agent. Each row carries a status chip for the agent's latest run — **Needs your input**, **Blocked**, **Failed**, **Working**, **Goal met**, or **Never run** — plus the run's outcome summary, and a call to action that matches the state: **Respond** jumps straight into the chat conversation a parked agent is waiting in, **Review** opens a blocked or failed run's transcript, **View live** follows a run in flight, and **Run now** dispatches an agent that has never run. Agents waiting on a person sort to the top, a summary strip counts and filters them, and finished one-off missions fold away under **Completed missions** so old dispatches stop burying the live ones. The sidebar's **AI Agents** item now badges the number of agents waiting on your input — an unanswered agent question is no longer something you discover by accident. [AI Agents →](/platform/ai-agents) ## A new default AI model Ankra AI now runs on **Kimi K3** by default, with **GLM 5.2** as the Think tier. Both are served through Ankra's managed access - there is nothing to configure, and existing conversations carry on unchanged. | Tier | Model | Context | | -------------------- | ---------------- | ----------- | | **Expert** (default) | Kimi K3 | 1M tokens | | **Think** | GLM 5.2 | 1M tokens | | **Quick** | Claude Haiku 4.5 | 200k tokens | Both new tiers carry a **1M-token context window**, up from 200k, so long troubleshooting sessions and large manifests fit without compaction. Expert accepts images and reasons before it answers; Think reasons at high effort on text. **Auto** still picks per question, and sends anything with an attachment to Expert. Reasoning is now visible on these models the same way it always was on Claude - you see the thinking as it streams, not just the answer. None of this is a limit. Under **AI** → **Settings** → **Models** you can still edit any tier, point it at your own model, or switch the whole organisation onto your own Anthropic, OpenRouter, or self-hosted OpenAI-compatible key - which serves every tier from your provider instead. [AI Provider →](/platform/ai-provider) ## Monorepo demos deploy every app A demo of a monorepo used to run exactly one of its components - so a two-app repository demoed its API where the frontend belonged, and the preview URL answered with a bare JSON 404. Demos now deploy **every component of the application by default**, each as its own pod in the demo namespace, and the demo only reports ready once all of them accept connections. The **web entry** - the frontend-shaped component - owns the demo URL, and the API component is published under `/api` on the same host, routed straight to its own service, so the browser reaches both halves without the app needing environment-specific proxy configuration. Components also reach each other in-namespace by name (`http://crm-api:8090`), and demo env values can reference `${{ ankra.demo_component..url }}` placeholders that resolve at deploy time. The launch dialog now shows each component's build status and tag side by side, lets you include or exclude components, and lets you move the entry. The demo detail page groups the bill of materials per component and lists each component's public path next to the preview URL. Automatic PR previews and the AI's `deploy_pr_demo` tool deploy every component the same way - and PR previews of monorepos, which previously always reported "build missing", now resolve their images correctly. [Applications → Monorepo demos →](/concepts/applications#monorepo-demos-every-component-one-url) ## Demos that run any codebase Launching a demo of a real application used to fail in three quiet ways: the readiness probe watched a port the app never listened on, a database-backed app crashed with no database, and a fresh database had no schema. All three are now handled end to end. **Ports resolve themselves - twice.** The launch resolves the container port from what the repository actually declares (recorded component ports, the runtime Dockerfile's `EXPOSE`, the generated Deployment manifest, the analysed target port), and the launch dialog no longer overrides that resolution with a default. And when the artifacts themselves are wrong, the platform reads the running container's own startup banner - `Accepting connections at http://localhost:8001` - and repoints the demo at the announced port on the fly, once, recording the correction so the next launch is right from the start. A demo that still times out now tells you exactly what happened: *"Nothing accepted connections on port 3000. The container's logs say it listens on port 8001."* **Databases arrive configured.** Analysing a repository now detects a database dependency - a Postgres client, an ORM config, a composed database - and seeds the demo configuration: throwaway database on, the connection variables the code actually reads wired to `${{ ankra.demo_database.* }}`, and the repository's migration command. Demos run migrations as an init container inside your own image, after the database accepts connections, so a fresh demo database provisions its schema before the first request. Schemas needing Postgres extensions declare them (`database_extensions: ["vector"]`) and the database creates them at initdb. **And the CLI can drive all of it.** `ankra application demo detail` shows the provisioning steps and failure detail, `demo logs` fetches a bounded log tail, `demo config get/set` edits the saved defaults - environment, database, migration command, extensions - and `demo fix` dispatches the pre-setup agent, which now also repairs failed migrations and wrong ports. [Applications → Preview demos →](/concepts/applications#preview-demos) ## Create applications on a branch that actually exists The **Create application** form no longer asks you to type a branch name into a free-text field and hope. Once you pick a repository, the branch field becomes a searchable list of the repository's real branches with its default branch preselected - and **Enter a different branch** stays one click away for a branch you have not pushed yet. If your organisation has a single GitHub App installed, it is selected for you, and repository search now ranks an exact name first instead of last. The form also spells out what **Create** will do before you commit to it: an AI agent analyses the repository and generates a Dockerfile, CI/CD pipeline, and Kubernetes manifests where they are missing, opens a setup pull request for you to review and merge, and publishes container images to your organisation's private registry. [Applications →](/concepts/applications) ## Publish your add-ons to the whole platform An add-on your organisation curated can now be proposed to the global Ankra Catalog - the add-on catalog every organisation sees. **Publish to Ankra Catalog** on the add-on's page shows exactly what would be proposed: the rendered `kind: Addon` manifest, a diff against the currently published version when one exists, the target repository, and a version-history link into the catalog's Git log. Confirming opens a pull request against the public [ankraio/ankra-global-resources](https://github.com/ankraio/ankra-global-resources) repository on your behalf - review and merge is the approval gate, so nothing ships silently. A **Publish history** section then tracks each request through its life: pull request open, merged and awaiting sync, live in the catalog, or closed - with the pull request linked at every step. Once merged, the platform sync ingests the manifest and the add-on appears for **all organisations**; your own organisation's copy keeps shadowing the global one, so publishing never changes what you see. The catalog repository itself gained the new `Addon` manifest kind alongside its Helm registries, and removing a manifest retires the global add-on again. [Publishing Add-ons →](/platform/addon-publishing) ## Every manual cluster action, on the record Cluster **Settings** grew an **Audit** tab: a chronological trail of every manual action performed on that cluster - who did it, what it was, and when. Starting, stopping, upgrading, or terminating a cluster, scaling workers or the control plane, creating, editing, or deleting node groups, restarting a node, resizing the bastion, deploying, updating, redeploying, retrying, or deleting stacks, and agent-side Helm upgrades and rollbacks all now write attributed entries - the acting member's email, the resource touched, the timestamp, and expandable structured details such as the previous and requested counts of a scale. The tab is the per-cluster view of the organisation [Audit Log](/guides/audit-log) and shares its permission gate: audit read, held by owners and admins by default and grantable to custom roles. Entries are append-only, so the answer to "who scaled this cluster last Tuesday?" is one click away instead of an archaeology exercise. And when a stack edit results in a GitOps commit, the entry links straight to it - the platform action and the repository change it produced, side by side. [Cluster Settings → Audit →](/platform/cluster-settings#audit) ## The cluster trail and the organisation trail now join up The organisation [Audit Log](/guides/audit-log) and a cluster's **Audit** tab always read the same record, but you could not travel between them. Now every organisation entry names the cluster it belongs to, and that name links straight into the cluster's own tab; organisation-level events such as sign-ins and invitations show no cluster, and a cluster you have since deleted keeps its name marked deleted, because the record outlives the cluster. A **cluster** filter joins the existing user, action, and date filters, and it lives in the page URL, so "everything anyone did to this cluster" is a link you can share. From the other side, the cluster tab gained **View in organisation audit log** - the full trail with that cluster preselected - plus **Export CSV** and **Export JSON** for the cluster's own entries. Exports run through the organisation export narrowed to the cluster, so a per-cluster download and the filtered organisation view can never disagree, and every exported row now carries the cluster next to the actor and action. [Audit Log →](/guides/audit-log) ## Stop and start clusters on a schedule Every self-managed cluster - Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, Proxmox VE, and HPE Morpheus - can now park itself. A new **Power schedules** card in cluster **Settings** → **General** holds up to 20 schedules per cluster, each one a stop or a start that fires either once at a chosen date and time or repeatedly on a 5-field cron expression in the timezone you pick. The classic pair - a `0 19 * * 1-5` stop and a `0 7 * * 1-5` start - shuts a development cluster down on weekday evenings and has it back before the team arrives, so it only accrues compute cost while someone is using it. Schedules are careful about cluster state: a stop is skipped if the cluster is already stopped, a start only fires when it is stopped, and if the cluster is busy with another operation the schedule retries every 5 minutes for up to 24 hours before recording a failure. Each schedule shows its next run and last outcome, and a toggle pauses it without deleting it. [Power Schedules →](/platform/cluster-power-schedules) ## Credentials that show what you have left Open a cloud credential and the detail page now reads capacity straight from the provider - and it works for every cloud provider Ankra supports. A Proxmox VE credential shows the cluster behind it: every node with used and total CPU and memory, storage pools with shared pools counted once, and how many guests are running with the vCPUs and memory allocated to them. An UpCloud credential shows the account's real resource limits - cores, memory, storage, IPs, networks, load balancers - as usage bars, next to remaining credits. OVHcloud shows its true per-region project quotas the same way: vCPUs, instances, memory, and volume storage per region, each with how much of the quota is spent. Azure shows the subscription's virtual machines and AKS clusters with regional vCPU and VM quota bars, and DigitalOcean shows droplet and floating IP limits. HPE Morpheus shows each cloud on the appliance with used and total memory and storage. Hetzner and Scaleway expose no limits over their APIs, so their views are live usage reports: servers with combined vCPUs, memory, and storage, plus the networking resources around them. The numbers come from the provider at view time, so they include everything in the account, also what was created outside Ankra. Capacity questions like "will another three workers fit?" get answered on the credential page instead of in the provider console. [Credentials →](/platform/credentials#capacity-and-usage) ## A calmer credentials page The credentials surface got a visual and structural cleanup. The list page now has a single quiet toolbar - search, provider filter, sort, and paging in one row - and flatter cards that keep to the essentials: provider, type, health, and when the credential was last updated. The credential detail page, which had grown into one long scroll of identity, capacity, connection details, rotation, and usage all at once, is now a compact identity header with tabs: **Overview** for connection details and the verify check, **Capacity** for the provider report, **Used by** for the clusters and operations on the credential, and **Rotation** for in-place secret rotation. Each tab loads its own data, so opening a credential no longer fires every provider query at once, and the layout now matches the GitHub credential cockpit, so every credential detail page reads the same way. [Credentials →](/platform/credentials#view-credentials) ## The Ankra CLI adds Proxmox, Morpheus, and control over agent runs [Ankra CLI v0.9.0](/integrations/ankra-cli-changelog) is out, and it is the largest CLI release so far: * **Proxmox VE and HPE Morpheus clusters** - `ankra cluster proxmox` and `ankra cluster morpheus` cover the full lifecycle, node groups, control plane, SSH keys, autoscaling, and upgrades, plus discovery of what each platform offers and their own credential commands. * **Managed Kubernetes parity** - provider-native stop and start, `node-pool update` for in-place node count and autoscaling changes, autoscaling bounds at create time, and Scaleway Kapsule as a new provider. * **See and stop what your AI agents are doing** - `ankra agents` lists dispatched agent runs, shows one in full, reads the session transcript of what the agent actually said and did, and cancels a live run. * **Agent-mode chat asks before it writes** - every mutating tool halts the turn and proposes the write. The stream now shows each proposal with its risk and parameters, an interactive session prompts to run or discard it, and `ankra chat actions confirm | reject | list` drives the same decision from a script. (One exception has since joined: a conversation switched to the new **Auto** autonomy setting executes validated additive stack deploys with a receipt instead of halting - see [Additive deploys that can run themselves](#additive-deploys-that-can-run-themselves) above.) * **Node restarts and bastion resize** - restart any provisioned node as a tracked operation across Hetzner, OVH, UpCloud, DigitalOcean, Scaleway, and Proxmox, and resize the bastion in place. * **Secrets encrypted in a single commit** - `ankra cluster encrypt manifest --set` applies the new value in memory before encrypting, so the plaintext never reaches git history. The release also fixes a batch of commands that were decoding response shapes the API never sent, and therefore showed nothing: manifest and member listings, chat health, and stack history all return real data again, and `ankra cluster encrypt -f` and `cluster clone` no longer strip fields and comments from your cluster YAML. [CLI Changelog →](/integrations/ankra-cli-changelog) | [Ankra CLI →](/integrations/ankra-cli) ## Ask the AI to build you a Proxmox cluster Cluster provisioning in chat now covers Proxmox VE. Ask the assistant for a new cluster on your Proxmox credential and it drives the real flow: it reads the credential, lists your host nodes with their CPU and memory alongside the px-\* instance presets, and - once a node is picked - that node's storage pools, network bridges (SDN vnets included), and clone-source templates, then proposes the create for your confirmation like every other provisioning action. Credentials that reach Proxmox through an SSH jumphost work too - the chat reads ride the same tunnel the rest of the platform uses. Hetzner, OVH, UpCloud, and Scaleway were already there; Proxmox VE joins them, so the platform chat and the [MCP tool surface](/platform/mcp-tools) now agree on what can be built. [Ankra AI Assistant →](/platform/ai-assistant) ## Demos that fix their own configuration An application image that validates its environment on boot used to make a hopeless demo: deployed bare, it crash-loops, and the preview never comes up. Now, when a demo fails with a startup crash, Ankra dispatches a **pre-setup agent** automatically. It reads the crashed container's logs, works out which variables the application demands, and generates the demo configuration: database URLs become references to the demo's own throwaway Postgres, secrets get fresh random values, and mode flags get the value without external side effects. It saves the result as the application's demo defaults - every future demo inherits them - and redeploys the failed demo to prove it boots. The agent's run is visible on the AI agents page like any other mission, it never weakens the application's own validation, and it runs at most once per demo per day. You can also trigger the same fix on demand, or ask the AI assistant to repair a failed demo in chat - the same diagnostics, configuration, and redeploy tools back both. Two supporting fixes ship alongside: demo redeploys switch to a Recreate rollout, so a configuration change can never wedge against the namespace resource quota, and the throwaway demo database now runs a pgvector-capable Postgres, so migrations using `CREATE EXTENSION vector` work. [Preview demos →](/concepts/applications#automatic-pre-setup-when-a-demo-crashes) ## A full page for every demo Inspecting a demo used to mean a dialog stacked over the Demos tab - cramped, unlinkable, and gone the moment it closed. Every demo now has its own page, opened from a demo row's status pill or **Details** button. A header carries the demo's identity - branch or pull request, status, full-stack and database badges, namespace, image tag, and the time left - with **Open preview** and **Stop demo** alongside. Below it, the view reads live from the staging cluster and refreshes itself: the provisioning timeline, the namespace's bill of materials with each resource's manifest a click away, the Kubernetes events that explain a stall, and on-demand pod logs. Side cards cover how to reach the demo - the preview URL or the exact port-forward command - the demo's facts, and the staging cluster it runs on. Because it is a page, it has a URL: share a provisioning demo with a teammate and they land on the same live view, breadcrumbs and all. [Preview demos →](/concepts/applications#preview-demos) ## Monorepos onboard as applications, one component per app An application used to mean one deployable app per repository: a single image, a single build workflow, a single container port. Point Ankra at a monorepo and the generated pipeline built each app correctly and pushed each image to its own place - but everything that read the result looked somewhere none of them published to, so a repository whose builds were green reported "No built images were found for this application yet." and the demos tab had nothing to launch. Applications now model a repository's **components**. An ordinary repository has one, covering the root; a monorepo has one per app, each with its own Dockerfile under its directory, its own manifests, its own workflow carrying a `paths:` filter so touching one app does not rebuild the others, and its own image at `//`. Build state, published images, publish readiness, deploys, demos, and container scanning are all reported per component, so an application whose API component built and whose frontend did not says exactly that instead of collapsing the two into one wrong answer. Ankra works out the components from what the repository already declares first - a repository it has onboarded before keeps the component names its live workflows use, so re-running analysis never renames an app and orphans the images it has published - then from what the analysis proposes, then from the repository's structure. A Dockerfile at the repository root always means a single app. Nothing needs migrating: an application with no recorded components still resolves to exactly the coordinates it always used, and re-running analysis records the components it finds. The launch dialog gained a **Component** picker for monorepos, with the container port following your pick. That was the sharpest edge of the old behaviour: a component inherited whichever port appeared first among the repository's generated files, so an API component on 8090 could be probed on port 3000 of a frontend and the demo sat in *provisioning* until it timed out. [Monorepos →](/concepts/applications#monorepos) ## Application setups that rescue themselves Adding an application kicks off an AI setup that analyses the repository and generates the Dockerfile, Kubernetes manifests, and CI/CD pipeline. Until now that screen could over-promise: before any agent had actually picked the task up it already said "AI Agent assigned to task", and if the setup stalled or failed there was no agent anywhere in the product to look at. The first step now reads **Waiting for an AI agent to pick up the task** until real progress arrives, so the screen tells you what is actually happening. More importantly, stuck setups no longer depend on you noticing them. A setup that sits silent for fifteen minutes, or fails its analysis, now dispatches a **rescue mission** automatically: a one-shot agent that appears on the AI Agents page with a full transcript, diagnoses what went wrong, retries the setup when that is the fix, and reports exactly where things are stuck when it is not. The setup screen links straight to the AI Agents page from its stall warning and its failure state, and dispatch is bounded to one rescue per application per day. Alert delivery got the same discipline behind the scenes: a notification whose webhook can never deliver - the webhook was deleted, or never had a URL - now records its failure and stops retrying instead of piling up as pending work, and stale undelivered notifications are swept automatically. One organisation's undeliverable-webhook backlog was what starved new application setups in the first place. [Applications →](/concepts/applications) ## Every chart version shows its license Every chart version's overview in the chart browser now carries a **License** field with the license's SPDX identifier - `Apache-2.0`, `MIT`, `AGPL-3.0-only`, and so on. Ankra reads the chart's `artifacthub.io/license` annotation from `Chart.yaml`, and falls back to detecting the license from the `LICENSE` or `COPYING` file inside the chart package when the annotation is missing. Copyleft licenses - the AGPL and GPL family - are visually highlighted, so a chart whose license carries obligations for your own code stands out before it lands in a stack. [Helm Charts →](/platform/helm-charts) ## Gateway resizes that wait for the cloud Resizing a cluster's gateway could be reported as failed even though it was proceeding normally: the platform timed out while the cloud provider was still completing the resize. Resize operations now wait for the provider to finish, so a resize that succeeds on the provider side succeeds in Ankra too. ## Registry creation tells you what is wrong Creating a Helm registry with a malformed spec used to answer with a bare 500 and no hint at the cause. The API now validates the spec first and answers with a clear 422 naming exactly what is wrong. The CLI side got friendlier too: registry creation accepts both flat and YAML spec files, plus `--name` and `--url` flags for the simple case where a file is overkill. The 422's example now shows both accepted shapes - the raw API body and the pre-wrap file that `ankra helm registries create -f` expects - so copying the example works from either caller. [Registries →](/guides/registries) ## Cluster validation that names the real problem Validating a cluster definition whose add-on could not be resolved used to give one undifferentiated error. Validation now distinguishes the three cases: the registry is not connected in your organisation, the chart does not exist in that registry, or the chart exists but the pinned version does not. `chart_version` itself is validated too, so a typo in a version pin is caught at validation time instead of at deploy time. Version pins compare the way Helm resolves them: `1.20.0` matches a chart published as `v1.20.0` and vice versa, so a pinned production config validates no matter which spelling of the version your chart's publisher uses. `ankra cluster validate` now also runs the per-resource field checks that apply enforces - add-on namespace rules, group names, empty manifest bodies - so a rule that would reject your file at deploy time is caught at validation time, in CI, before anything touches a cluster. And the namespace rule itself got saner: add-on namespaces now accept everything Kubernetes accepts (1-63 characters, lowercase letters, digits and dashes), so short names like `ory`, `ops`, or `dev` are valid - the old 4-character minimum is gone. [ImportCluster YAML Schema →](/reference/importcluster#validation) ## Secret detection that reads the value, not just the key The plaintext-secret scan used to flag anything whose key looked secret-like, so `timeout: 30s`, port numbers, and references to already-encrypted values all raised warnings. Detection is now value-shape aware: durations, ports, booleans, and references no longer count, while values that actually look like credentials still do. High-confidence findings can also gate CI - enable `strict_secrets` and a definition carrying a likely plaintext secret fails instead of warning. [SOPS Secrets →](/guides/sops) ## CLI listings built for scripting List commands across the CLI now page properly: pagination flags control the window, `--all` fetches everything, and a listing with more results than it shows says so instead of silently truncating. JSON output uses a consistent envelope across commands, so scripts can parse every listing the same way. And `ankra cluster encrypt` grew batch ergonomics: `--key` is repeatable and `--all-data` encrypts every data field in one pass. [Ankra CLI →](/integrations/ankra-cli) ## See what GitOps is actually syncing `ankra cluster gitops status` shows the cluster's live GitOps source: the connected repository, the branch Ankra reads from, the credential in use, and the last synced commit with its sync state. When a cluster is not picking up changes, the first question - is it even looking at the right branch? - is one command away. [GitOps →](/concepts/gitops) ## Preview a chart's manifests before anything deploys `ankra charts template` renders an add-on's chart with your values server-side, from the same mirrored package Ankra deploys, and prints the resulting Kubernetes manifests - or the exact rendering error a deploy would have hit. Wrong secret key names, surprising Service ports, and values that leak into a ConfigMap all surface on your laptop instead of against a production cluster. `ankra charts values` prints a chart version's default values document, the baseline you diff your overrides against. Neither command needs direct registry access on your side. [Stacks and add-ons →](/concepts/stacks) ## Declare Helm registries in the cluster file The ImportCluster file can now carry a top-level `spec.helm_registries` block. Registries declared there are connected automatically before any add-on deploys - same name and URL is an idempotent no-op, private registries reference an existing credential by name so secrets stay out of Git - which makes a GitOps repository genuinely self-contained: clone, apply, and the declared state is reachable on a fresh organisation with no side-channel setup commands. [ImportCluster reference →](/reference/importcluster) # More Clouds, Vulnerability Scanning, and Team Roles ## Whoever creates a cluster can reach it with kubectl Creating or importing a cluster now grants you cluster-scoped `cluster-admin` Kubernetes access to it, so `ankra cluster kubeconfig add` works as soon as the cluster is up instead of answering "You do not have access to this cluster" until an admin granted you access by hand. The grant is an ordinary Cluster Access grant: it shows up in the cluster's **Access** view and in `ankra cluster access list`, reconciles into native RBAC, and can be revoked. Clusters created before this change have had the same grant seeded for their creator, so kubeconfig access there starts working without any operator action. [Cluster Access →](/guides/cluster-access) ## Branch and PR demos detect your application's port Launching a demo no longer assumes your application listens on port 8080. Every demo lane — the Launch demo dialog, AI-deployed PR demos, and the automatic pull-request previews — now reads the port from your application's generated Dockerfile (`EXPOSE`) and deploys with it, so a Next.js app on 3000 or a Flask app on 5000 comes up ready instead of sitting in "provisioning" forever behind a readiness probe on the wrong port. The launch dialog pre-fills the detected port, and the advanced override still wins when you need something different. ## Security Center overview and findings, modernised The Security Center's **Overview** and **Findings** tabs now share the visual language the Compliance tab introduced. The overview leads with a fleet security scorecard: a posture ring showing the share of scanned clusters with no actionable critical or high findings, a verdict at a glance, and tiles for critical, high, fixable-severe, and scan coverage. Findings swaps its second tab bar and boxed filter panel for pill filter chips with live counts pulled from your fleet's data. Ankra AI is now one click away from both tabs: **Fix top findings with AI** on the overview hands the top remediation candidates to the AI with a fleet-wide remediation ask, and every finding's detail sheet gains **Ask Ankra AI**, grounded in the finding and the cluster it was observed on. [Security Center →](/guides/cluster-security) ## The Security Center overview shows which application is generating the risk The overview no longer stops at fleet totals. A new **Risk breakdown** row splits your observed occurrences three ways: a **Severity mix** with a bar per band, a **Review state** split across open, acknowledged, and accepted risk, and a **Fix readiness** number telling you what share of your critical and high occurrences actually have a published fix to move to. The **Observed fleet trend** chart grew up too - gridlines, a filled area, the observed range on the axis, a change chip, and a tooltip on every snapshot. Most usefully, **Application hotspots** now ranks the workloads generating the most actionable risk across your whole fleet, weighted so criticals outrank a pile of lows. Each row names the workload, the namespace and cluster it runs in, the add-on it was attributed to, how many of its findings already have a fix, and links straight into that cluster's findings filtered to it. Alongside it, **Risk by cluster** ranks your clusters by actionable occurrences, so "where is the heat" and "who owns it" are both answerable without leaving the overview. The overview also lays itself out based on the space it actually has rather than the size of your screen, so reading it beside the docked AI panel no longer squeezes the scorecard tiles into unreadable slivers. [Security Center →](/security/overview) ## Ankra AI now runs on Claude Opus 5 The platform's highest-capability AI tier moved from Claude Opus 4.8 to Claude Opus 5. Everything that escalates to the Expert model — plan mode, image analysis, high-risk and multi-resource changes, complex architectural questions, deploy analysis, and CI/CD pipeline generation — now runs on Opus 5, at the same price and with the same 1M-token context window. Organisations that customised their model catalog keep their pinned models; the built-in Expert entry upgrades automatically. ## Application images now build to your private Ankra registry Application CI/CD no longer publishes to GitHub Container Registry. When Applications is enabled, Ankra provisions a private project for your organisation in its own registry, together with the GitHub Actions credentials and the Kubernetes pull secret each cluster needs. The generated pipeline builds your source, scans the image, and pushes it to that private registry; the generated manifests already reference the image and its pull secret, so a merged pull request flows straight through to a running workload. The Ankra GitHub App now requests the **Secrets** permission to install that registry login, replacing the old GHCR make-public flow. [Applications →](/concepts/applications) ## AI Insights gets out of the way when your cluster is healthy The cluster AI Insights page no longer fills the screen with empty charts and zeroed counters when there is nothing wrong. A healthy cluster now shows a single compact "All quiet" summary confirming that monitoring is active, with one-click access to the resolved-fault history and to alert creation. The full analytics dashboard returns automatically the moment new activity appears — and the Faults tab no longer suggests your filters are hiding results when the cluster is simply healthy. ## Fleet overview: every Ankra-created cluster on the globe, plus a new fleet world The dashboard's fleet globe now places every cluster Ankra created for you — self-managed (Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway) and managed Kubernetes (DOKS, UKS, GKE, AKS, EKS, OVHcloud MKS, Kapsule) alike. When a cluster's nodes don't carry cloud topology labels (common on k3s and fresh clusters), the platform falls back to the region you picked at create time, so "not on the globe" is now reserved for genuinely unlocatable clusters. Proxmox and Morpheus clusters keep resolving through agent GeoIP. Next to the globe, the fleet overview gains a **fleet world**: an isometric 3D view where every cluster is a tower — height tracks node count, colour and glow track live status — so the whole fleet is readable at a glance, including clusters with no geolocation. Click a tower to jump into the cluster. The section layout was also rebalanced so the globe, fleet world, vital signs, utilisation, and security posture fill the page consistently. ## DigitalOcean clusters: reliable DNS and LoadBalancers that just work DigitalOcean's default DNS resolvers are flaky enough to intermittently break name resolution on nodes and inside pods. Ankra-provisioned DigitalOcean clusters now pin node DNS to Cloudflare (`1.1.1.1` / `1.0.0.1`) with a self-healing setup that re-applies within a minute if anything reverts — on new clusters at provision time, and on existing clusters automatically through the platform's drift detection. LoadBalancers on private-node DigitalOcean clusters also work out of the box now: the DigitalOcean cloud controller ships at v0.1.68+ (private-IP-only droplet support), is wired with the cluster's VPC UUID automatically (no more 422 "target droplets don't belong to the same VPC"), and the bundled Traefik ingress carries the `REGIONAL` load-balancer type its Service needs on private-only topologies. Existing clusters converge without any operator action. ## Chat turns survive disconnects An AI chat answer no longer depends on your browser staying connected. Every interactive turn is now written to a durable server-side event log as it streams, and the turn keeps running even if your tab closes, your network blips, or the platform restarts mid-deploy — tool calls finish, the answer completes, and nothing is lost. A new resume endpoint (`GET /chat/conversations/{conversation_id}/events`) replays the missed frames from where you left off, with live tailing and `Last-Event-ID` support. Provider hiccups were already covered by automatic failover; now the conversation itself is just as durable. ## Proxmox host-spread clusters now provision across nodes Control planes and workers placed on different Proxmox hosts previously stalled at the first cross-host node - the private SDN network is node-local, so the bastion had no path to a VM on another host. When a Proxmox VE credential carries Tailscale/Headscale settings, every VM now joins the tailnet at create time (through the Proxmox guest agent, before it has any other network path), and Ankra uses that tailnet address for SSH, kubeadm join, etcd peering, and haproxy upstreams. Enabling this requires the credential's Proxmox API token to hold `VM.GuestAgent.Unrestricted`, in addition to the `VM.GuestAgent.Audit` privilege address discovery already needs. [Proxmox VE credentials →](/platform/credentials/proxmox#tailscale-and-headscale-optional) ## Stack Profiles now show who you can trust Saving a stack as a profile now carries its existing description into a cleaner, modern save flow. Categories are searchable and reusable, tags are suggested as interactive chips, and you can choose whether the profile stays private to your organisation, becomes public, or is shared with specific organisation slugs. Profile cards and details now show the publisher's organisation name, logo, and verified status. Verified Ankra profiles appear first, so official profiles are easy to identify before you use them. Organisation admins can upload or replace their publisher logo from organisation settings. [Stack Profiles →](/concepts/stack-profiles) ## Profile capture understands every secret path you can declare Saving or publishing a stack profile no longer fails when a secret sits inside a YAML list — think fluent-bit's `config.pipeline.outputs[0].http_passwd` — or when an encrypted path is declared by its SOPS leaf key alone (`api-key`), the same shorthand `ankra cluster encrypt` uses. Both spellings now redact cleanly into required secret parameters. Values that are runtime environment references like `${OPENSEARCH_PASSWORD}` are no longer mistaken for plaintext secrets, so stacks that already inject credentials from Kubernetes Secrets capture without forcing a bogus secret parameter. [Stack Profiles →](/concepts/stack-profiles) ## Breadcrumbs everywhere you are Every page in the portal now carries a breadcrumb trail derived live from where you are — `Home / Clusters / prod-eu / Stacks / loki` instead of guessing your way back with the browser button. Dynamic segments show real names, not identifiers: the cluster crumb reads the cluster's name, operations show their display name, stack profiles and AI agents theirs. Each crumb that corresponds to a real page is clickable (the cluster crumb jumps to its overview), structural URL noise is hidden, and the trail stays out of the way on phones where the back button already does the job. ## Organisation menu goes straight to your organisation **Organisation** in the profile menu (and `/organisation`) now lands directly on your current organisation's overview instead of a list. Switching moved closer to hand: a **Switch organisation** submenu in the profile menu lists all your organisations with your current one marked — one click to switch, plus shortcuts to pending invites, the full organisation list, and creating a new organisation. The full list with per-organisation switching lives on **All organisations**. [Organisations →](/concepts/organisations) ## Your AI team, preloaded Every organisation now starts with a five-agent **AI team** — AI Team Lead, Developer, Database Admin, SRE, and DevOps — waiting under **AI → Agents**. Each one is chattable directly: open an agent and the conversation carries its persona, so the SRE talks evidence and the Database Admin checks backups first. Creating your own agent is now an **AI-guided interview** — pick a role, shuffle a name, choose focus areas and guardrails, and the wizard writes the persona for you (the classic form is one click away). Defaults are safe by construction: propose-only autonomy, hard budgets, and nothing runs until you ask. [AI Agents →](/platform/ai-agents) ## Demos now run real applications — env vars, secrets, and a throwaway database Demos used to run the container image bare, so anything needing configuration crash-looped on boot. Now every application carries **demo environment defaults** (the gear on the Demos tab) that all lanes inherit — manual launches, `deploy_pr_demo`, and automatic PR previews — with **per-launch overrides** in the launch dialog. Values marked secret ride Vault-backed secret slots and reach the demo as a Kubernetes Secret; plaintext never persists. Need a database? Toggle **Attach a throwaway Postgres** and an ephemeral instance spins up inside the demo namespace with a random per-demo password, wiped with the demo — your env values reference `${{ ankra.demo_database.* }}` placeholders, so any codebase's configuration naming just works. [Preview demos →](/concepts/applications#environment-variables-and-a-throwaway-database) ## Application demos get a shareable URL Deploy a throwaway demo of an application's pull request or branch build and Ankra now hands back a **public preview URL** automatically - no manual ingress or DNS wiring. When your organisation has a demo base domain configured, the demo is served under it; otherwise, if the staging cluster has an active Ankra DNS zone, it gets a `*.ankra.cc` host that resolves on that cluster. Without either, the demo still deploys and stays reachable in-cluster. The same URL is returned everywhere you deploy a demo - the portal Demos tab, `ankra application demo deploy`, the `deploy_pr_demo` AI/MCP tool, and the automatic preview posted on a connected application's pull requests. [Preview demos →](/concepts/applications#preview-demos) ## A home for Ankra Pick a **home channel** and Ankra starts the conversation on its own. When something important happens - a failed deployment, an agent going offline, a new severe CVE - and no routing rule already handles it, Ankra posts to your home Slack channel. Set it under **Organisation Settings → AI → Workspaces** ("Ankra's home"); only critical and warning events reach it, and it never double-notifies what a routing rule already sent. [Home channel →](/guides/webhooks#home-channel) ## Managed Kubernetes and three more clouds Ankra now provisions and operates **provider-managed Kubernetes** - DOKS, UKS, GKE, OVHcloud MKS, AKS, and EKS - with node pools, autoscaling (all but UKS), upgrades, and discovery/import of existing clusters. Self-managed provisioning also gained **DigitalOcean**, **Proxmox VE**, and **Morpheus** alongside Hetzner, OVH, and UpCloud. [Managed Kubernetes →](/guides/managed-kubernetes) · [DigitalOcean →](/guides/digitalocean-clusters) · [Proxmox VE →](/guides/proxmox-clusters) · [Morpheus →](/guides/morpheus-clusters) ## Proxmox VE zero-config bootstrap Saving a Proxmox VE credential now sets up everything a cluster needs on an empty host: VM storage, the management bridge, a private NAT network (`ankra`, 10.20.0.0/16) with DHCP built on Proxmox SDN, and an Ubuntu 24.04 cloud-init template. Cluster VMs on the private network get their addresses from Proxmox IPAM automatically — no guest agent required in the image — and reach the internet through the host's public interface. [Proxmox VE →](/guides/proxmox-clusters) ## Tailscale for Proxmox VMs Attach a Tailscale/Headscale login server and a reusable auth key to a Proxmox VE credential, and every VM Ankra provisions with it installs Tailscale and joins your tailnet on first boot — each VM getting its own tailnet address, reachable across Proxmox hosts and from your own networks. You can add, change, or remove it on an existing credential without recreating it. [Proxmox VE →](/platform/credentials/proxmox) ## Cluster vulnerability scanning with Trivy Install the Trivy Operator add-on and Ankra reads its vulnerability reports into a dedicated **Security** console: severity breakdowns, a blast-radius-ranked priority queue, remediation campaigns, and a phased burn-down plan. The AI assistant can summarise and prioritise CVEs with the same data. [Cluster Security →](/guides/cluster-security) ## Cluster compliance is now actionable Selecting a cluster from **Security → Compliance** now opens a full cluster Security page instead of a narrow drawer. The Compliance tab shows failed and passed CIS, NSA/CISA, and Pod Security Standards checks, configuration-audit hotspots, affected counts, remediation guidance, and filters for the exact result you need. Every failed check has **Fix with AI**. The cluster-scoped agent receives the benchmark and remediation context, can inspect the affected Kubernetes resources, apply safe fixes with the usual confirmation guardrails, and verify the result. [Cluster compliance →](/guides/cluster-security#cluster-security-view) ## Team roles, cluster groups, and scoped access Access is now governed by **roles** you assign at a scope - the whole organisation, a single cluster, or a **cluster group** (static or label-selected). A role can bundle Kubernetes access that Ankra provisions on every cluster in scope, and every change is captured in an organisation audit log. [Roles & Access →](/guides/roles-and-access) ## Pipeline agents Build CI-native infrastructure agents from plain pipeline jobs and the Ankra CLI - PR review, deploy watching, and scheduled health checks - with no framework or orchestration layer. [Build pipeline agents →](/guides/pipeline-agents) ## Proxmox automatic setup supports DHCP and provider-managed interfaces The "Set up storage and network automatically" bootstrap now works on dedicated servers where the management interface is configured via DHCP or marked `manual` (the provider assigns the IP outside Proxmox's network config, common on Scaleway and similar bare-metal hosts). Previously only statically addressed interfaces were accepted. [Proxmox VE credentials →](/platform/credentials/proxmox) ## Restart a node or resize the bastion, from the UI, CLI, or chat The **Nodes** tab now has a **Restart** action for every control plane node, worker, and bastion/gateway (Hetzner, OVH, UpCloud, DigitalOcean, Proxmox), and a **Resize** action for the bastion/gateway (those five plus HPE Morpheus). Both run as tracked operations, and the node table now shows each node's live status straight from the cloud provider's API so a crashed or externally-stopped VM is visible before you act on it. The same actions are available from `ankra cluster nodes restart` / `bastion resize`, and by asking the Ankra AI assistant - in the portal, Slack, or Teams - to restart a node or the bastion by name. [Nodes Settings →](/platform/cluster-settings#nodes-settings) · [Restarting a Node →](/guides/hetzner-clusters#restarting-a-node) ## Managed networking stack on Proxmox VE and HPE Morpheus Proxmox VE and HPE Morpheus clusters now ship the same Ankra-managed networking stack as every other self-managed provider: Traefik and cert-manager are installed as Ankra stacks after bootstrap (visible and manageable in the platform) instead of relying on the k3s-bundled Traefik. The **Include Networking Stack** option in the create wizard is on by default; ingress is exposed through the built-in k3s service load balancer on node IPs, since these providers have no cloud load-balancer API. Storage still comes from add-ons such as Longhorn — install one from the add-on catalog for persistent volumes. Both providers also reached full surface parity: `ankra cluster proxmox` and `ankra cluster morpheus` CLI commands (create plus catalogs for hosts, storages, bridges, templates, and plans, with stop/start and the generic scale, upgrade, node-group, and SSH-key verbs), and the Ankra AI assistant can now create Proxmox VE and HPE Morpheus clusters in chat with the same guided, confirmation-gated flow as the other providers. ## Lifecycle parity across self-managed clouds The canonical self-managed provider set is now **Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, Proxmox VE, and HPE Morpheus**. All seven can be stopped and started from the portal, CLI, API, and Ankra's AI or any MCP client. The new `ankra cluster scaleway stop|start` commands close the remaining CLI gap for Scaleway. ## Stack draft editor reliability Three draft-editor bugs are fixed: drafts no longer disappear after a few minutes of editing (live edits now keep the draft's idle timer fresh, so the cleanup job only removes genuinely abandoned drafts), saving no longer fails with a spurious "modified by another request" conflict (a background sync task stopped invalidating the editor's save token), and renaming a stack inside the editor no longer detaches the draft from its deployed stack - the draft stays linked under the stack's current name and the rename is applied when you deploy. ## Managed Kubernetes catches up on day-2 Managed clusters closed three long-standing gaps. **AKS clusters can now be stopped and started** from the portal, CLI (`ankra cluster managed stop|start`), API, and Ankra's AI or any MCP client - Azure deallocates the compute while every setting is preserved, and Ankra advertises the capability per provider so each surface only offers it where it works. **Node pool machine sizes can finally be changed**: since no provider allows in-place size changes, Ankra performs a blue/green replacement - a new pool with the new size is created and brought to ready before the old one is deleted, with labels, taints, and autoscaling carried over. And the **CLI reached managed parity**: node pools take autoscaling bounds at create and via the new `node-pool update` command, and pool counts and autoscaling can be changed without touching the portal. [Managed Kubernetes reference →](/reference/managed-kubernetes) ## The AI Assistant runs your clusters' day-2 operations The AI Assistant (and every MCP client) can now do far more than create clusters. Seventeen new tools cover the full day-2 surface for Ankra-provisioned clusters - **scale workers and node groups, add, update, and delete node groups, change the control plane, stop, start, upgrade, and even deprovision a cluster** (with a type-the-name-to-confirm guardrail) - plus a **managed Kubernetes family**: create and operate **EKS, AKS, GKE, DOKS, UKS, OVHcloud MKS, and Scaleway Kapsule** clusters and their node pools from chat. DigitalOcean cluster creation from chat is also live. Every mutating tool goes through the same confirmation card and drift-checked approval flow as before. [MCP Tool Reference →](/platform/mcp-tools) ## Start a stopped Hetzner cluster Hetzner clusters can now be **started** again after a stop, like every other self-managed provider - previously only stop was available, and bringing a cluster back meant adding a fresh node group. Stopping releases the Hetzner compute while keeping the cluster's configuration, stacks, and credentials; starting re-provisions the saved topology and reconciles the cluster back online. Also fixed: managed **GKE**, **DigitalOcean (DOKS)**, and **OVHcloud MKS** clusters now correctly advertise node-pool autoscaling support in the create wizard. The portal now derives **Stop** and **Start** from one canonical self-managed provider set, so Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, Proxmox VE, and HPE Morpheus stay in sync. Scaleway also gains `ankra cluster scaleway stop|start`, closing the remaining CLI lifecycle gap. [Stopping and Starting →](/guides/hetzner-clusters#stopping-and-starting-a-cluster) ## The full platform lifecycle over MCP and chat The Ankra MCP server and the AI assistant now cover the core lifecycle of **stacks, add-ons, applications, and credentials** - around 35 new tools. From Cursor, Claude, in-product chat, or chat over Slack, Teams, and SCM comments (all backed by the same tool registry), you can list, inspect, create, update, redeploy, clone, and delete stacks; read and update add-on settings and values; run the application lifecycle end to end including deploys and workflow runs; and manage credentials - list and inspect them (secrets always redacted), delete unused ones, and plan and apply a GitHub credential rotation. Creating credentials stays deliberately off-limits to the AI: it would mean handing it the secret itself, which the platform refuses. Reads need `mcp:read`; mutations need `mcp:write` and stay confirmation-gated in chat. A new reference page lists every tool with its scope. Alongside, the CLI gained `ankra credentials proxmox` and `ankra credentials morpheus` command groups (list and create, including SSH keys), and `ankra application delete` and `ankra application make-public` now ask for confirmation before acting. [MCP Tool Reference →](/platform/mcp-tools) · [MCP Server →](/platform/mcp-server) ## The sandbox demo is now fully editable The seeded "sandbox-demo" cluster is no longer read-only. You can now add, configure, move, clone, and delete stacks, add-ons, and manifests, work with drafts, and hit Deploy - the full stack-editing experience, before importing a cluster of your own. Deploys in the sandbox are simulated: they complete instantly and mark resources green without running anything on real infrastructure. Cluster-level operations that need a live agent (archive, agent tokens, add-on sync) remain unavailable there. [Playground & sandbox →](/guides/cluster-sandbox) ## Custom DNS records under your organisation's ankra.cc subdomain Organisation admins can now manage their own **CNAME, A, and TXT records** under their organisation's delegated `ankra.cc` subdomain - handy for aliasing an add-on's auto-generated hostname to something memorable. The **DNS records** console (under **Organisation Settings**) shows your zone and its status, a searchable, type-filterable records table, and lets you add, **edit in place**, and delete records with a chosen **TTL**. New and edited records provision asynchronously and show their state (pending, active, or failed, with the reason) in the list. [DNS Records →](/platform/organisation-settings#dns-records) ## Approving a plan on the AI board now starts the work Fixed: approving an agent's plan on an AI board ticket left the ticket waiting indefinitely - the assigned agent was never re-dispatched, and nothing happened until someone manually moved the ticket to "Executing". A human approval now releases the ticket to **Executing** (and "Request changes" sends it back to **Planning**), and the dispatcher picks it up on the next cycle instead of waiting out its re-dispatch backoff. Assigning a ticket to an agent right after approving its plan now behaves the same way. ## Reply to a board ticket and the agent replies back The AI board is now conversational. Commenting on a ticket assigned to an AI agent - from the ticket page, or by replying in its mirrored Slack or Microsoft Teams thread - re-dispatches the agent, which reads your comment and answers on the timeline. This works even while the ticket sits in **Awaiting review** or **Awaiting approval** (exactly where questions about a plan come up - previously a comment there was never seen), and the agent is instructed to respond and revise only, never to start executing before the plan is approved. Slack and Teams replies now also appear in the agent's work brief. Closing or cancelling a ticket now cancels any agent runs still working it, so nothing keeps burning tokens on dead work. ## Inspect and cancel AI agent runs - from MCP, the CLI, and the API Every dispatched agent run is now visible and controllable outside the portal. Three new MCP tools - `list_agent_runs`, `get_agent_run` (optionally with the session transcript tail), and `cancel_agent_run` (organisation admins only) - let the AI assistant and any MCP client watch and stop the AI team's work. The same surface ships in the CLI as the new **`ankra agents`** family (`runs`, `run`, `transcript`, `cancel`) and as PAT-authenticated API routes under `/api/v1/org/ai-agent-runs`. Cancelling a run flips its session and the platform interrupts the in-flight turn within seconds, without pausing the agent itself - and run transcripts are now readable by any organisation member through the run, not just the agent's creator. [MCP Tool Reference →](/platform/mcp-tools) ## Archived clusters are off the fleet map Fixed: archiving a cluster removed it from the cluster list but left its pin on the Dashboard's world map and, when it had no resolvable region, in the "not on the globe" tray. Archived clusters are now excluded from the map entirely - the same treatment they already get in the health summary - so the globe shows only the fleet you still run. [Dashboard →](/platform/dashboard) # A Go-Native Agent, Fleet Dashboard, Cloud Cost, kubectl Access, Stack Profiles, Applications, Support, and a Provider-Agnostic CLI June was a big month across the whole platform: a rebuilt cluster agent, a new fleet dashboard with cost visibility, scoped cluster access, reusable stack templates, application delivery, in-product support, and a CLI that caught up with the web UI. ## A faster, leaner cluster agent, rebuilt in Go The [Ankra Agent](/concepts/cluster-agent) has been rebuilt as a single, statically compiled Go binary and is now the production agent on the new `2.0.x` version track. It is a drop-in replacement: the same Helm chart, values, install command, NATS connectivity, and behaviour as before - resource streaming, log streaming, Helm management, add-on deployment, and `kubectl` proxying all work exactly the same. Nothing changes in how you install or operate it. What you get for free: * **A smaller footprint.** The default memory limit drops from `1536Mi` to `512Mi` and the request from `512Mi` to `256Mi`, alongside lower CPU usage and faster startup. * **Automatic rollout.** Existing clusters are upgraded to the new agent automatically by the platform, a few clusters at a time - no action required. You can still upgrade on demand from **Cluster Settings → Upgrade Agent**. * **Identical operations.** Same outbound-only connectivity, same `/livez`, `/readyz`, and `/metrics` endpoints on port `8080`, and the same `extra_env` tuning knobs. See the [Ankra Agent](/concepts/cluster-agent) docs for the full configuration reference. ## A fleet dashboard with a world map The organisation [Dashboard](/platform/dashboard) now opens on a world map of every cluster, alongside health and cost rollups. Clusters are placed by cloud region, or by the agent's public egress IP when [public IP reporting](/concepts/cluster-agent) is enabled. ## Cloud cost estimates [Cloud Cost](/platform/cloud-cost) estimates per-cluster and fleet-wide spend from your live node and volume inventory plus cloud pricing - broken down by compute, storage, network, and per-namespace allocation. Connect an [AWS or GCP credential](/platform/credentials) to get started. ## Scoped kubectl access through Ankra Grant teammates SSO-backed, scoped Kubernetes access with [Cluster Access](/guides/cluster-access), then reach the cluster with your own `kubectl` through Ankra's [API proxy](/guides/kubeconfig) - short-lived credentials, no inbound network access, works with private clusters. ## Reusable Stack Profiles Capture a working stack as a versioned, parameterised template with [Stack Profiles](/concepts/stack-profiles), then instantiate it on any cluster - with diffing, update tracking, and IaC export. ## Applications: from repo to running workload [Applications](/concepts/applications) connect an app's Git repository, generate the Dockerfile, Helm chart, and CI/CD via a pull request, then build and deploy the result as a stack. ## In-product support Raise and track [support tickets](/platform/support) without leaving Ankra - with AI triage, attachments, and threaded replies - and keep an eye on everything that needs you in your new [Activity & Inbox](/platform/activity-inbox). ## More reliable apply for large manifest stacks Applying a stack with many manifests at once - and reconciling stacks on clusters with lots of Custom Resource Definitions - is now far more reliable. Manifests are given more time to apply before they're considered stalled, and the agent no longer re-runs expensive API discovery on every single apply, so a large stack reconciles cleanly instead of failing partway through with a timeout. The change applies automatically: existing stacks pick it up on their next deploy with no action required. Any per-manifest timeout you set previously is honoured as long as it's at least the new, more generous default, and custom timeouts above the default are kept as-is. [Manifests →](/concepts/manifests) ## The Ankra CLI caught up with the platform Most of what you can do to a cluster in the web UI is now scriptable from the [Ankra CLI](/integrations/ankra-cli): * **Provider-agnostic cluster verbs** - `ankra cluster upgrade | scale | node-group | deprovision | k3s-versions` detect Hetzner, OVH, or UpCloud automatically from the cluster. * **Cluster access and kubectl** - grant scoped RBAC with `ankra cluster access` and write short-lived, SSO-backed `ankra-*` kubeconfig contexts with `ankra cluster kubeconfig add`. * **Cluster metrics** - run PromQL against a cluster's Prometheus with `ankra cluster metrics query` and `query-range`. * **Full OVH management** - stop/start, SSH access info, control-plane and node-group changes, region discovery, and node labels/taints. * **Config safety** - gate changes before they go live with `ankra cluster validate` (structure, chart existence, plaintext-secret detection) and stage them with `ankra cluster draft`. * **Live operations** - follow a deploy or reconcile with `ankra get operations --watch` and `ankra get jobs`. * **Self-update** - `ankra upgrade` updates or rolls back the CLI in place with checksum verification. See the [CLI Changelog](/integrations/ankra-cli-changelog) for the full, versioned detail. ## Removed: Add-on Subscriptions Add-on subscriptions have been retired. Add-ons are now managed directly on the cluster or stack that uses them - through your GitOps repository, `ankra cluster apply`, or the cluster editor - which keeps a single, declarative source of truth for what runs where, rather than a separate subscription that has to be kept in sync. The legacy add-on subscription endpoints now return `410 Gone`. If you relied on subscriptions, move those add-ons into the relevant stack definition; existing deployed add-ons are unaffected. # Editable Stopped-Cluster Topology, Self-Healing Hetzner Updates, Live Operations, and a Big CLI Wave May focused on cloud-cluster reliability - editable topology while stopped, self-healing Hetzner updates, cleaner offline reconciliation, and a live-updating operations page - alongside a large batch of CLI commands for variables, secrets, dependencies, and in-place upgrades. ## Edit cluster topology while stopped Stopped cloud clusters (Hetzner, OVH, UpCloud) now expose the full Nodes settings tab. While the cluster stays offline you can: * Switch the control plane between **1** and **3** controllers (only 1 or 3 - etcd needs an odd number of voting members to form quorum). * Change the **controller instance type**. Because the cluster is recreated fresh on next start, downgrades are safe here - there is no live disk resize. * Add and remove **node groups**, scale them, change their worker instance type, and edit labels and taints. Changes are saved against the stopped topology and applied the next time you start the cluster from the General settings tab. Topology edits now also serialize against each other and against start/stop, so two operators clicking at the same time can't end up with a half-applied change. [Cluster Settings →](/platform/cluster-settings#nodes-settings) ## Hetzner: Resilient Cluster Updates Hetzner cluster update jobs are now self-healing. The reconciler persists install-time addresses (`bind-address`, `advertise-address`, `node-ip`) into `/etc/rancher/k3s/config.yaml` so k3s always restarts bound to the correct private IP, and version bumps now swap the k3s binary in place instead of re-running the upstream installer - which previously rewrote the systemd unit and wiped `K3S_URL` / `K3S_TOKEN` on joined nodes. Clusters that had drifted into authentication-error loops after an upgrade recover on the next reconcile. ## Offline Cloud Clusters: Cleaner Reconciliation When a Hetzner, OVH, or UpCloud cluster is in the **stopped** state (after Delete Kubernetes), the reconciler now only acts on provider-owned resources - servers, networks, SSH keys, the k8s control plane. Addons, manifests, and other in-cluster resources are held until the cluster is back online, so you no longer see repeated failures for resources that have no API server to talk to. [Hetzner Cluster Lifecycle →](/guides/hetzner-clusters#cluster-lifecycle) ## Operations Page: Live Updates The cluster **Operations** page now refreshes itself in the background. Newly-triggered operations appear without a manual reload, and the status, duration, and finish time of in-flight operations update as they progress. The page polls faster while something is actively running and slows down once everything is idle, so you get near-real-time feedback while a deploy is happening without hammering the backend when nothing is going on. ## The Ankra CLI: variables, secrets, dependencies, and in-place upgrades A large batch of stack-management commands landed in the [Ankra CLI](/integrations/ankra-cli) this month: * **Variables at every scope** - `ankra org variables`, `ankra cluster variables`, and `ankra cluster stacks variables` give full CRUD over the values substituted into manifests and addon values (resolution is stack > cluster > organisation). * **Live-cluster SOPS** - `ankra cluster encrypt` / `decrypt` run directly against a running cluster's manifests and addon values, with no local `cluster.yaml` needed. * **Dependencies, reads, and deletes** - edit deployment-ordering parents (`--add-parent` / `--remove-parent` / `--set-parent`), print current addon values and manifest YAML, and delete a manifest from its stack. * **Surgical upgrades** - `ankra cluster addons upgrade` and `manifests upgrade` change a single Helm value or manifest field in place with helm-style `--set` (field selectors like `containers[name=app]`), `--from-file`, and `--dry-run`. * **Any organisation** - a global `--org` flag (and `ANKRA_ORG`) runs a command against any organisation you belong to without switching your selection. * **Curated AI skills** - `ankra skills install` drops Ankra's Agent Skills into Cursor or Claude Code (`--editor claude-code`), embedded in the binary so it works offline. See the [CLI Changelog](/integrations/ankra-cli-changelog) for the full, versioned detail. # Cluster Lifecycle: Delete Kubernetes & Scale Back Up, Multi-Stack Cloning ## Delete Kubernetes & Scale Back Up Cloud provider clusters (Hetzner, OVH, UpCloud) now support a **Delete Kubernetes** action that destroys all cloud infrastructure - servers, networks, SSH keys - while keeping the cluster registered in Ankra. The cluster moves to a stopped state and you stop incurring infrastructure charges. When you're ready to bring the cluster back, simply **add a node group**. Ankra automatically restores the full control plane infrastructure (bastion, network, SSH keys, control plane servers), installs Kubernetes, creates your new worker nodes, and begins reconciling stacks and addons. The restored cluster gets entirely fresh infrastructure with new servers and IPs. Previously existing worker node groups are not restored - the node group you add is the only worker pool. Add additional node groups as needed after the cluster is online. The **Terminate Cluster** action permanently deletes all infrastructure and removes the cluster from Ankra entirely. This is irreversible. Both actions are available in cluster **Settings → Danger Zone**. [Hetzner Cluster Lifecycle →](/guides/hetzner-clusters#cluster-lifecycle) | [Cluster Settings →](/platform/cluster-settings#danger-zone) ## Clone Multiple Stacks to Another Cluster You can now select multiple stacks and clone them all to another cluster in a single operation. On the **Stacks** page, click any stack card's avatar to start selecting, or click the **Clone Stacks** button next to the search bar to select all. A floating action bar appears showing the selection count with a **Clone to Cluster** button. The clone dialog shows a live progress bar as each stack is cloned sequentially. Name conflicts are auto-resolved with suffixes. After completion, click **Go to Target Cluster** to review the drafts. Cross-organisation cloning is fully supported. This is useful for replicating an entire cluster's stack configuration to a new environment, promoting multiple stacks from staging to production, or setting up disaster recovery clusters. [Clone Stacks Guide →](/guides/clone-stack#clone-multiple-stacks-at-once) # Automatic Hetzner Cloud Integration, Ingress & GitOps, Node Groups, UpCloud & OVH Cloud, AI Insights Overhaul, Kubernetes Node Cordon & Drain, Light Mode, Billing & Platform Performance ## Kubernetes Node Cordon, Uncordon & Drain The **Kubernetes → Nodes** view now supports full node lifecycle management for workload migration scenarios. Cordon, uncordon, and drain nodes from both the node detail page and the node list with multi-select bulk actions. **Cordon & Uncordon**: Mark nodes as unschedulable or restore scheduling. Available as a single-node action in the node detail header or as a bulk action by selecting multiple nodes in the list. Cordoned nodes display a "SchedulingDisabled" label. **Drain**: Cordon a node and evict all running pods in one operation - equivalent to `kubectl drain --ignore-daemonsets --delete-emptydir-data`. Real-time progress tracking shows each phase: cordoning, fetching pods, and evicting pods. Available for single nodes and in bulk. **Workload Migration**: Use cordon and drain together to safely move workloads between node groups. Cordon old nodes to stop new scheduling, drain them to evict existing pods, and let Kubernetes reschedule onto your new node group. [Kubernetes Nodes →](/platform/kubernetes-workloads#nodes) Hetzner clusters now automatically deploy the Cloud Controller Manager and CSI driver during provisioning - no manual setup. An optional ingress stack adds ingress-nginx, cert-manager, and Let's Encrypt. GitOps integration pushes cluster state to GitHub. Node groups bring per-group instance types, scaling, labels, and taints. UpCloud and OVH Cloud support across the platform. AI Insights gets a dedicated detail page with analytics dashboard, adaptive scanning, and platform-aware remediation. The Command Palette now navigates directly to every Kubernetes resource type, and the Log Viewer is rebuilt for large clusters. ## Hetzner: Automatic CCM & CSI Provisioning Hetzner clusters now automatically deploy a complete **hcloud stack** during provisioning: a dedicated `hcloud` namespace, API token secret, the [hcloud-cloud-controller-manager](https://github.com/hetznercloud/hcloud-cloud-controller-manager) (3 replicas, PDB), and the [hcloud-csi](https://github.com/hetznercloud/csi-driver) driver (3 replicas, PDB, `hcloud-volumes` default StorageClass). Previously this required manual setup via the AI Assistant or Stack Builder. Now it's fully automated using the same Hetzner API credential used to create the cluster. ## Hetzner: Optional Ingress Stack Enable `include_ingress` during cluster creation to deploy ingress-nginx with a Hetzner Load Balancer, cert-manager, and a pre-configured `letsencrypt-prod` ClusterIssuer for automatic TLS. Toggle in the UI wizard or pass `"include_ingress": true` in the API. ## Hetzner: GitOps Integration Push cluster stack state to a GitHub repository on creation. Provide `gitops_credential_name`, `gitops_repository`, and `gitops_branch` to enable version-controlled infrastructure for Hetzner clusters. ## Node Groups Per-Group Instance Types, Labels & Taints A new **Nodes** tab in cluster settings lets you manage node groups for Hetzner, OVH, and UpCloud clusters. Each node group has its own instance type, node count, Kubernetes labels, and taints giving you fine-grained control over your worker fleet. **Full Lifecycle Management**: Add, scale (0–100 nodes), upgrade instance type, edit labels/taints, and delete node groups from the UI, CLI, or API. Node groups can be defined at cluster creation time in the wizard or API. **Instance Type Upgrades**: Upgrade any group to a larger instance type. Each node is powered off, resized, and powered back on. Downgrades are not possible due to Hetzner disk resize limitations. To use a smaller type, create a new node group and delete the old one. The UI shows a confirmation dialog warning that upgrades are irreversible. **Labels & Taints**: Attach Kubernetes node labels and taints to node groups. Labels and taints are applied to all nodes in the group and can be edited at any time. Useful for workload scheduling with nodeSelectors, affinities, and tolerations. **No Online Requirement**: Node group operations work regardless of cluster state. No need to wait for the cluster to be online. **CLI Support**: New `ankra cluster {hetzner|ovh|upcloud} node-group` commands for list, add, scale, upgrade, and delete. [Hetzner Node Groups →](/guides/hetzner-clusters#node-groups) | [Cluster Settings →](/platform/cluster-settings#nodes-settings) ## Hetzner: Multi-SSH-Key Support & Access Settings Attach multiple SSH key credentials to Hetzner clusters at creation or post-creation. A new **Access** tab in cluster settings provides copy-pasteable SSH jump and kubectl port-forward commands, a network topology view, and SSH key management. [Hetzner Clusters Guide →](/guides/hetzner-clusters) ## UpCloud Clusters Provision and manage Kubernetes clusters on UpCloud with managed SDN Routers and NAT Gateways for private networking. **Full Lifecycle Management**: Create, scale, upgrade, and deprovision UpCloud clusters through the UI, CLI, or API. Clusters deploy with a router, private network, NAT gateway, bastion server, and k3s distribution. **Zone Support**: Deploy to any UpCloud zone including Helsinki (Finland), Frankfurt (Germany), Chicago (United States), Amsterdam (Netherlands), London (United Kingdom), Singapore, Sydney (Australia), and Warsaw (Poland). **Worker Scaling**: Scale worker nodes between 1 and 10. Scaling up provisions new instances and installs Kubernetes. Scaling down removes workers from the highest index. **Kubernetes Upgrades**: Upgrade k3s versions across all nodes with one command. Control planes are upgraded first, then workers. **DAG-Based Deprovisioning**: Cluster deletion creates a tracked operation with individual delete jobs that run in dependency order. Multiple server deletions run in parallel, reducing deprovision time. [UpCloud Clusters Guide →](/guides/upcloud-clusters) ## UpCloud API Credentials Securely store UpCloud API credentials (API token) with automatic validation against the UpCloud API. **Credential Validation**: Credentials are validated on creation by calling the UpCloud API. Clear error messages for invalid tokens (401) and permission issues. **SSH Key Support**: Create and manage SSH key credentials for UpCloud cluster provisioning. Generate new keypairs or bring your own public key. [Credentials Guide →](/platform/credentials/upcloud) ## OVH Cloud Clusters Provision fully managed Kubernetes clusters on OVH Cloud with configurable control planes, workers, and networking. **Full Lifecycle Management**: Create, scale, upgrade, and deprovision OVH clusters through the UI, CLI, or API. Clusters deploy with a private network, gateway for SSH access, and k3s distribution. **Region Support**: Deploy to any OVH Cloud region including Gravelines (France), Strasbourg (France), Beauharnois (Canada), Warsaw (Poland), Frankfurt (Germany), London (UK), Singapore, and Sydney. **Worker Scaling**: Scale worker nodes between 1 and 10. Scaling up provisions new instances and installs Kubernetes. Scaling down removes workers from the highest index. **Kubernetes Upgrades**: Upgrade k3s versions across all nodes with one command. Control planes are upgraded first, then workers. [OVH Clusters Guide →](/guides/ovh-clusters) ## OVH API Credentials Securely store OVH Cloud API credentials (application key, application secret, consumer key, and project ID) with automatic validation against the OVH API. **Credential Validation**: Credentials are validated on creation by calling the OVH API. Clear error messages for permission issues (403) and invalid credentials (401). **SSH Key Support**: Create and manage SSH key credentials for OVH cluster provisioning. Generate new keypairs or bring your own public key. [Credentials Guide →](/platform/credentials/ovh) ## AI Insights Overhaul A major upgrade to Proactive AI Insights with a dedicated detail page, analytics dashboard, advanced filtering, adaptive scanning, and platform-aware remediation. **Insight Detail Page**: Each insight now has a full-page view with four tabs Overview (root cause analysis with summary, severity, confidence score, affected resources, and conversation starters for AI chat), Remediation (copy-pasteable commands and platform-aware actions), Health (snapshot and anomaly data at time of detection), and History (previous resolutions with effectiveness tracking). Navigate to related Kubernetes resources directly from the affected resources list. **Analytics Dashboard**: New analytics tab with configurable time ranges (7, 30, or 90 days). Tracks mean time to resolution (MTTR), shows severity trends by day, breaks down issues by namespace and category, and indicates whether cluster health is improving, degrading, or stable. **Dashboard View**: A new dashboard tab on the insights page with a severity donut chart, mini trend chart, and category breakdown at a glance. **Advanced Filtering**: Filter insights by namespace, category, and date range. Three view modes cards, compact list, and grouped (by category or namespace). Root cause summary shown inline on insight cards. **Related Insights**: Insights sharing the same namespace or category are linked on the detail page, helping you spot patterns across related issues. **Adaptive Scanning**: The maintenance scheduler now adapts scan frequency based on cluster health clusters with critical issues are scanned every 60 seconds, clusters with active issues every 3 minutes, and healthy clusters every 10 minutes. **Platform-Aware Remediation**: AI analysis now suggests platform-native actions (stack changes, add-on configuration, resource navigation) alongside kubectl commands. Remediation commands and platform actions are stored per-insight and displayed on the detail page. **Resolution Tracking**: Resolving an insight now captures resolution type, resolution context, and a health snapshot at resolution time. When an issue recurs, previous resolutions include effectiveness data so you can see if a past fix held. **RAG Learning Loop**: Marking an insight as "helpful" indexes its root cause analysis and recommendations for RAG, improving future AI analysis quality. **Keyboard Shortcuts**: Navigate and manage insights entirely from the keyboard `j`/`k` to navigate, `Enter` to open detail, `p` to quick peek, `a` to acknowledge, `r` to resolve, `d` to dismiss, `c` to ask AI, `/` to search, `1`–`4` to switch tabs, `v` to cycle view mode, and `?` for help. [AI Insights Docs →](/platform/ai-insights) ## CLI v0.2.0 Helm management, Kubernetes resource access, direct cluster selection, and client hardening. * `ankra cluster helm releases` / `ankra cluster helm uninstall` - Manage Helm releases in the cluster * `ankra helm registries` / `ankra helm credentials` - Manage Helm registries and credentials * `ankra cluster pods` / `ankra cluster resources` / `ankra cluster logs` - Access Kubernetes resources and stream pod logs * `ankra cluster select ` - Select a cluster directly by name without the interactive picker * `ankra cluster info [name]` - Show cluster details (defaults to selected cluster; replaces `cluster get`) * HTTP client timeouts, response body limits, URL encoding, config file permission hardening [CLI Changelog →](/integrations/ankra-cli-changelog) | [Ankra CLI →](/integrations/ankra-cli) ## CLI v0.1.129 Node group management commands and new UpCloud/OVH commands for cluster and credential management. * `ankra cluster node-group` - List, add, scale, upgrade, and delete node groups for Hetzner, OVH, and UpCloud * `ankra credentials upcloud` / `ankra cluster upcloud` - UpCloud credential and cluster management * `ankra credentials ovh` / `ankra cluster ovh` - OVH credential and cluster management [CLI Changelog →](/integrations/ankra-cli-changelog) | [Ankra CLI →](/integrations/ankra-cli) ## Node Group API Endpoints Available for all three cloud providers (Hetzner, OVH, UpCloud): | Endpoint | Method | Description | | ------------------------------------------------------------------- | ------ | --------------------- | | `/api/v1/clusters/{provider}/{id}/node-groups` | GET | List node groups | | `/api/v1/clusters/{provider}/{id}/node-groups` | POST | Add a node group | | `/api/v1/clusters/{provider}/{id}/node-groups/{name}/scale` | PUT | Scale a node group | | `/api/v1/clusters/{provider}/{id}/node-groups/{name}/instance-type` | PUT | Upgrade instance type | | `/api/v1/clusters/{provider}/{id}/node-groups/{name}/labels` | PUT | Update labels | | `/api/v1/clusters/{provider}/{id}/node-groups/{name}/taints` | PUT | Update taints | | `/api/v1/clusters/{provider}/{id}/node-groups/{name}` | DELETE | Delete a node group | [Hetzner Node Groups →](/guides/hetzner-clusters#node-groups) ## UpCloud API Endpoints Full REST API coverage for UpCloud clusters and credentials: | Endpoint | Method | Description | | --------------------------------------------------- | ------ | ---------------------------- | | `/api/v1/clusters/upcloud` | POST | Create an UpCloud cluster | | `/api/v1/clusters/upcloud/{id}` | DELETE | Deprovision a cluster | | `/api/v1/clusters/upcloud/{id}/worker-count` | GET | Get worker count | | `/api/v1/clusters/upcloud/{id}/scale-workers` | POST | Scale workers | | `/api/v1/clusters/upcloud/{id}/k8s-version` | GET | Get Kubernetes version | | `/api/v1/clusters/upcloud/{id}/upgrade-k8s-version` | POST | Upgrade Kubernetes version | | `/api/v1/credentials/upcloud` | GET | List UpCloud credentials | | `/api/v1/credentials/upcloud` | POST | Create an UpCloud credential | | `/api/v1/credentials/upcloud/ssh-keys` | GET | List SSH key credentials | | `/api/v1/credentials/upcloud/ssh-key` | POST | Create an SSH key credential | [API Reference →](/api-reference/introduction) ## OVH API Endpoints Full REST API coverage for OVH clusters and credentials: | Endpoint | Method | Description | | ----------------------------------------------- | ------ | ---------------------------- | | `/api/v1/clusters/ovh` | POST | Create an OVH cluster | | `/api/v1/clusters/ovh/{id}` | DELETE | Deprovision a cluster | | `/api/v1/clusters/ovh/{id}/worker-count` | GET | Get worker count | | `/api/v1/clusters/ovh/{id}/scale-workers` | POST | Scale workers | | `/api/v1/clusters/ovh/{id}/k8s-version` | GET | Get Kubernetes version | | `/api/v1/clusters/ovh/{id}/upgrade-k8s-version` | POST | Upgrade Kubernetes version | | `/api/v1/credentials/ovh` | GET | List OVH credentials | | `/api/v1/credentials/ovh` | POST | Create an OVH credential | | `/api/v1/credentials/ovh/ssh-keys` | GET | List SSH key credentials | | `/api/v1/credentials/ovh/ssh-key` | POST | Create an SSH key credential | [API Reference →](/api-reference/introduction) ## Command Palette Direct Links to All Kubernetes Resources The Command Palette (`⌘+K` / `Ctrl+K`) now navigates directly to every Kubernetes resource type in your cluster not just Ankra pages. Type any resource kind and jump straight to it. **33 Kubernetes resource types** organized by category: Workloads (Pods, Deployments, StatefulSets, DaemonSets, ReplicaSets, Jobs, CronJobs, PodDisruptionBudgets, HorizontalPodAutoscalers), Networking (Services, Ingresses, Ingress Classes, Endpoints, NetworkPolicies, CSI resources), Configuration (ConfigMaps, Secrets, Namespaces, Events), Storage (PersistentVolumes, PVCs, Storage Classes, VolumeAttachments), RBAC (Roles, RoleBindings, ClusterRoles, ClusterRoleBindings, ServiceAccounts, LimitRanges), and more (CRDs, Helm Releases, Nodes). **New cluster pages**: Logs, Metrics, Resources, General Settings, and GitOps Settings are now accessible from the palette. **New actions**: Base64 Encode/Decode utilities, Keyboard Shortcuts reference, Documentation link, and Switch Organisation. [Command Palette →](/platform/command-palette) ## Log Viewer Redesign Rebuilt the Log Viewer for large clusters and high-volume streams. **Scalable Pod Loading**: Pods are fetched on-demand per namespace when you select a workload, replacing the previous 500-pod cap that caused "0 pods" for large clusters. **Accurate Matching**: Pod-to-workload matching now uses Kubernetes label selectors instead of name prefix heuristics. **Scroll Stability**: Scrolling up to investigate older logs now holds your position even under high-throughput streams. Auto-follow only re-engages on explicit user action. **Live Filtering**: Search and log level filters apply to incoming lines in real-time, not just existing logs. **Performance**: Batched rendering (150ms flush interval) with virtualized display handles tens of thousands of log lines without UI freezes. [Log Viewer Docs →](/platform/logs) ## Light Mode Full theme customization with Light, Dark, and System modes - the platform is now suitable for bright or dark developer caves. Set your preference from **Profile → Appearance** or use the sidebar theme toggle to cycle modes instantly. Your choice syncs across all devices. [User Profile →](/platform/user-profile) ## Billing & Subscription Management Stripe integration with vCPU-based metering, automated invoice generation, and subscription auto-provisioning for new organisations. The billing pipeline covers plan management, usage tracking, invoice history, and Stripe webhook handling. A billing analytics dashboard provides visibility into resource consumption and cost trends. ## Distributed Tracing OpenTelemetry tracing across the API, maintenance scheduler, and work scheduler services. Request-level observability with trace propagation, structured logging integration, and circuit breaker improvements provide end-to-end visibility into platform operations. ## Registry Performance & Reliability Registry listing, detail views, and sync operations significantly optimised. Cache invalidation after frontend changes, Harbor edge case handling, and backoff logic for failing registries improve reliability across all registry types. ## Database & Platform Performance Database index audit with unused index removal via pg\_stat\_statements, improved connection pool management, and reduced database pressure under load. Listing performance improvements across clusters, stacks, and AI insights result in faster page loads throughout the platform. ## Helm Charts Version Tracking New charts version comparison and a clusters tab showing which clusters run which chart versions, making it easier to track Helm chart drift across your fleet. # Hetzner Cloud Provisioning, AI Goes Agentic, Full Observability & Secrets at Scale Hetzner Cloud provisioning lands across the platform, AI goes agentic with 58 tools, full observability arrives with log streaming and pod terminals, and secrets management scales up with SOPS and variables. ## Hetzner Cloud Provision Clusters from Ankra Ankra now provisions and manages Hetzner Cloud clusters end-to-end. Create k3s clusters across five Hetzner locations (Falkenstein, Nuremberg, Helsinki, Ashburn, Hillsboro), scale workers, and upgrade Kubernetes all from the dashboard, CLI, or API. The full provisioning pipeline handles networking, SSH keys, bastion servers, control planes, workers, k3s installation, and Ankra Agent setup automatically. Deprovision in one click when you're done. [Hetzner Clusters Guide →](/guides/hetzner-clusters) ## Hetzner Cluster Provisioning in the Dashboard A guided wizard walks you through creating a Hetzner cluster select credentials, pick a location, choose server types (cost-optimized, regular, or dedicated vCPU), set control plane and worker counts, and launch. A live provisioning progress view tracks every step from network creation to Ankra Agent installation. Once running, scale workers and upgrade k3s versions directly from cluster settings. ## Hetzner CLI Commands Full Hetzner lifecycle from your terminal. `ankra cluster hetzner create` provisions a cluster with configurable network ranges, server types, and k3s versions. Scale workers with `ankra cluster hetzner scale`, upgrade Kubernetes with `ankra cluster hetzner upgrade`, and tear everything down with `ankra cluster hetzner deprovision`. Manage Hetzner API tokens and SSH keys via `ankra credentials hetzner` including automatic keypair generation. [CLI Reference →](/integrations/ankra-cli) ## Hetzner REST API Every Hetzner operation is available via the REST API with Bearer token authentication. Create and deprovision clusters, scale workers, upgrade k3s, and manage Hetzner credentials and SSH keys programmatically. Integrate Hetzner cluster provisioning into your CI/CD pipelines or custom tooling. [API Reference →](/api-reference/introduction) ## Sandbox Cluster Try Ankra Instantly No Kubernetes cluster? No problem. Spin up a sandbox cluster in one click and explore the full Ankra experience: pre-populated nodes, workloads, services, stacks, and live-looking metrics. It's read-only, always online, and requires zero setup. The fastest way to see what Ankra can do. [Sandbox Docs →](/guides/cluster-sandbox) ## AI Agentic Mode & 58 Tools The AI Assistant is now a fully autonomous agent. It reads your cluster state, chains up to 10 tool calls per response, and proposes infrastructure changes with a built-in confirmation system. 58 tools span Kubernetes read/write, stack management, and addon lifecycle. [Learn more →](/platform/ai-assistant) ## AI Incident Reports & Root Cause Analysis When an alert triggers, Ankra automatically generates a detailed AI incident report with root cause analysis, severity assessment, affected resources, and actionable recommendations. Reports are delivered to Slack, Teams, PagerDuty, Discord, and Opsgenie alongside alert notifications. [Configure Alerts →](/guides/alerts) | [AI Incidents →](/platform/ai-incidents) ## Alerting Built Into All Ankra Resources Alerts now monitor every resource type clusters, stacks, addons, manifests, and GitHub repositories. Define custom rules with AND/OR logic, set severity levels, and get notified via six built-in integrations plus generic webhooks. [Configure Alerts →](/guides/alerts) ## Log Explorer Stream logs in real-time from up to 20 pods simultaneously with full-text and regex search, auto-detected log levels, adjustable display settings, and export to clipboard or file. [Learn more →](/platform/logs) ## Terminal to Any Pod Open an interactive terminal directly into any running pod container from the dashboard. Choose your shell, select the target container, and debug issues without leaving the browser. ## Stack Cloning Clone any stack between clusters with automatic name conflict resolution, SOPS-encrypted value handling, and parent relationship preservation. Available in the dashboard and via the CLI. [Clone Stack Guide →](/guides/clone-stack) | [Clone Cluster Guide →](/guides/clone-cluster) ## SOPS Integration with ArgoCD End-to-end secret encryption using SOPS with AGE keys, fully integrated with ArgoCD. Encrypt specific YAML keys while keeping the rest readable. Automatic decryption during GitOps sync no manual steps. [SOPS Guide →](/guides/sops) ## Variables: Org, Cluster & Stack Levels Define reusable variables at three levels with automatic precedence resolution. Use `${{ ankra.variable_name }}` in manifests and Helm values. Mark variables as secrets for masked display in the UI. [Variables Guide →](/concepts/variables) ## Metrics Revamp Redesigned metrics with area charts for CPU and memory by node, network RX/TX rate charts, disk I/O, pod restarts by namespace, summary cards, and AI-powered health insights surfaced in dashboard widgets. [Cluster Metrics →](/platform/cluster-metrics) | [Prometheus Integration →](/integrations/prometheus) ## Multi-Select Delete for Kubernetes Resources Bulk select and delete Kubernetes resources across 20+ resource types with checkbox selection, confirmation dialog, sequential deletion with progress tracking, and per-item error reporting. ## CLI v0.1.125 & API Updates New SOPS encryption commands replace the old `ankra cluster sops` command. Granular encrypt/decrypt for manifests and addon values. Full REST API with Bearer token auth, alerts API with AI analysis endpoints, and interactive OpenAPI docs. [Ankra CLI →](/integrations/ankra-cli) | [API Reference →](/api-reference/introduction) # 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 stacks` List all stacks in the active cluster * `ankra get stacks ` View stack details with manifests and addons * `ankra clone ` Clone stacks between clusters * `ankra applyf stack.yaml` Apply stack configurations Perfect for CI/CD pipelines and automation. [Explore Stack Builder →](/concepts/stacks) ## Insight Metrics Real-time cluster metrics powered by Prometheus integration. **Resource Usage Cards**: At-a-glance CPU and memory utilization across your cluster with current values and totals. **Time Series Charts**: Interactive graphs for CPU by node, memory by node, disk I/O, and network traffic (RX/TX). **Pod Restarts**: Bar chart showing restart counts by namespace to quickly identify unstable workloads. **Configurable Time Ranges**: View metrics from 15 minutes to 7 days with automatic refresh intervals. **Node-Level Drill-Down**: Click any series to isolate and focus on specific nodes. ## Helm Charts & Registries Completely revamped Helm chart discovery and registry management. **Chart Explorer**: Browse, search, and filter Helm charts from all connected registries. View chart metadata, versions, and dependencies. **HTTP & OCI Registries**: Full support for both HTTP-based Helm repositories and OCI registries (GHCR, GAR, ECR, ACR, Docker Hub, Harbor). **Auto-Sync**: Registries sync automatically to keep chart catalogs up to date. Configure sync intervals per registry. **Credential Management**: Securely store and manage registry credentials with support for tokens, basic auth, and cloud provider authentication. [Explore Helm Charts →](/platform/helm-charts) | [Registry Setup →](/integrations/helm-registries) ## Alerting New alerting system to stay on top of cluster issues. **Slack Webhooks**: Send alerts directly to Slack channels via incoming webhooks. Configure per-cluster or organisation-wide. **Alert Rules**: Define custom alert conditions based on cluster events, resource states, and thresholds. **Event-Driven Notifications**: Get notified on deployments, failures, scaling events, and health changes. [Configure Alerts →](/guides/alerts) ## AI Assistant Enhancements The AI Assistant is now the centerpiece of the Ankra experience. **Page-Aware Context**: The AI automatically knows what you're looking at. Open a pod and it already has the logs, manifest, events, and related resources. No copy-pasting or explaining. **Incident Triangulation**: Root cause analysis across multiple data sources: * Container logs with error detection * Prometheus metrics and anomalies * Kubernetes manifests and configurations * Stack deployment history and changes * Resource relationships and dependencies **Stack Building**: Describe infrastructure in natural language and the AI helps you build it: * *"I need a monitoring stack with Prometheus and Grafana"* * AI recommends add-ons, suggests values, and explains dependencies * You add the components to your Stack based on the recommendations * Review and deploy with one click **Unified Context Layers**: The AI combines all context for comprehensive understanding: | Layer | What AI Sees | | --------- | --------------------------------------- | | Logs | Container stdout/stderr, error patterns | | Metrics | CPU, memory, network, custom metrics | | Manifests | Current and desired state, diffs | | Events | Kubernetes events, warnings, errors | | History | Deployment timeline, who changed what | **New Shortcut**: Press `⌘+J` (Mac) or `Ctrl+J` (Windows/Linux) from anywhere. **Claude Opus 4.5**: The AI Assistant now runs on Claude Opus 4.5 Anthropic's most capable model by default. No configuration needed. [Learn more →](/platform/ai-assistant) ## New Guides **Build a Monitoring Stack**: Step-by-step guide to deploy kube-prometheus-stack with Loki for logs. [Read the guide](/guides/monitoring-stack) **Cloudflare Tunnel**: Expose services without public IPs or open firewall ports. [Read the guide](/guides/cloudflare-tunnel) ## New Integrations **Prometheus**: Connect your Prometheus instance as a metrics data source. Powers Insight Metrics and AI analysis. [Learn more](/integrations/prometheus) **Helm Registries**: Expanded documentation for HTTP and OCI registries with provider-specific setup. [Learn more](/integrations/helm-registries) ## New Documentation **Kubernetes Resources**: Complete pages for Workloads, Networking, Storage, Configuration, and RBAC. **Command Palette Guide**: Full reference for `⌘+K` navigation, shortcuts, and commands. [Learn more](/platform/command-palette) ## Documentation Improvements **Restructured Navigation**: Reorganized into logical groups with AI Assistant prominently featured in Get Started. **Consistent Formatting**: Standardized formatting across all pages. # Supercharging Stack Builder & Workflows! Safety, speed, visibility & brand-new integrations-everything you need to build, manage, and share infra. ## Stack Builder **Safe Node Deletion**: Prevent new nodes linking to those being removed-no dangling edges or race conditions. **Drag-and-Drop Layout**: Manually reposition nodes, then snap them back into a tidy grid with "Reorder." **Reconcile Quick-Jump**: Click a resource's badge to dive directly into the underlying operation. **Unsaved-Changes Prompt**: Real-time draft indicators highlight pending edits-and you'll be warned before leaving. ## Agent & Import Flow **Upgrade Available**: Get notified when a new agent version is available-no more missing out on improvements. **Pending-Upgrade Fix**: Agents no longer stall in "pending-upgrade"-rollbacks are a thing of the past. ## AI & Automation **In-Context AI Chat**: AI Assistant now lives on every page-get guidance right where you work. It's like having a personal DevOps expert at your fingertips. **Chat History**: View past conversations in the AI Assistant sidebar-no more lost context. **Anthropic Models**: Use some of the most advanced AI models available today. Choose between: Claude 3.5 Haiku, Claude 3.7 Sonnet, Claude Sonnet 4 and Claude Opus 4. ## Resource & CRD Management **CRD Explorer**: Browse all CRDs in-app, with filters to zero in on exactly what you need. **IaC Source View**: Click "View Source" on any generated resource to inspect the GitHub-hosted files. ## Search & Shareability **Shareable URLs**: Bookmark or share any filtered list-teammates see exactly what you see. **Enter-Key Power-Up**: Press Enter in ⌘+K to immediately run searches or actions. ## Integrations & Ecosystem **Terraform Provider (Alpha)**: Define clusters, stacks, and add-ons as code-live on Terraform & OpenTofu. [Read Docs](https://docs.ankra.ai/integrations/terraform) **Monitoring Stack Walk-Through**: Step-by-step video guide with GitOps examples. [Watch Video](https://www.youtube.com/watch?v=__EQEh0GZAY\&t=4s) **GitOps Enhancements**: Bidirectional syncing & auto-cleanup of stale files. [Learn More](https://docs.ankra.ai/essentials/cluster-gitops-multiple) **Ankra CLI**: Scriptable imports, builds, and add-on management right in your terminal. [Get the CLI](https://docs.ankra.ai/integrations/ankra-cli) ## Usability & Productivity **Sidebar State Saver**: Hide or show the sidebar without losing your custom panel layout. **Download & Copy**: One-click download or copy of cluster add-on configs for backups and sharing. **Improved Error Messages**: Actionable hints (e.g. invalid URL format) instead of cryptic failures. **OCI-Backed Add-on Sources**: Support for OCI Helm charts now live-private & credential-based OCI coming next month. # 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 the `helm install ankra-agent` command from the import cluster on your laptop or on your Kubernetes clusters. **Expanded Resource Insights**: Live access to Kubernetes resources. **ARM & macOS Native Support**: Prebuilt binaries for Apple Silicon (M1/M2) and generic ARM64 servers. Easy helm install from the import cluster: `helm install ankra-agent`. ## Roadmap Preview: Kubernetes‑Native Integrations Upcoming support for streaming capabilities that will allow real‑time exploration of the Kubernetes environment: * Expand ArgoCD integration to simplify troubleshooting * Log streaming of pods * Creation of Kubernetes resources with add‑ons ## Cluster Add‑on Management **Add Multiple Add‑ons**: When you click add‑ons of an existing cluster, you can now add a stack of add‑ons in a single form. Just keep selecting add‑ons from the options. ## Bug Fixes & Improvements **General Fixes**: Resolved an issue where multi‑line strings were not being preserved. **Quality of Life Improvements**: General improvements in the UI for a better user experience. # Add-on Settings Source: https://docs.ankra.ai/concepts/addon-settings Configure sync policies, retry behaviour, health checks, and ignore rules for your add-ons. Add-on settings control how ArgoCD manages the lifecycle of your deployed add-ons. These settings apply to both standalone add-ons and add-ons within stacks. ## Overview Every add-on deployed through Ankra is backed by an ArgoCD Application. The settings page lets you fine-tune how ArgoCD synchronizes, monitors, and recovers your add-on. You can configure these settings from: * **Stack Builder** -- click any add-on and open the **Settings** tab * **Standalone Add-ons** -- open the add-on and click **Settings** Changes made in the Stack Builder are applied when you save the stack. Changes to standalone add-ons are applied to ArgoCD immediately. *** ## Settings Profiles Profiles are pre-configured bundles of settings optimized for common scenarios. Select a profile to quickly apply recommended values, or choose **Custom** to configure each setting individually. | Profile | Automated Sync | Auto Prune | Self Heal | Health Check | Revision Limit | Best For | | ----------------------- | :------------: | :--------: | :-------: | :----------: | :------------: | ------------------------------------------- | | **Default** | On | On | On | Off | 10 | Most add-ons | | **Development** | On | On | On | Off | 5 | Fast iteration, dev/staging clusters | | **Production Critical** | Off | Off | Off | On | 20 | Critical workloads requiring manual control | | **Stateful** | On | Off | On | Off | 10 | Databases, message queues, stateful apps | Changing any individual setting automatically switches the profile to **Custom**. *** ## Sync Policy The sync policy determines how ArgoCD responds to changes in your Git repository and drift in your cluster. ### Automated Sync When enabled, ArgoCD automatically syncs your add-on whenever changes are detected in Git. When disabled, you must trigger syncs manually. ### Auto Prune When enabled alongside Automated Sync, ArgoCD automatically deletes Kubernetes resources that are no longer defined in Git. This keeps your cluster clean but means removing a resource from your stack will delete it from the cluster. Auto Prune can delete resources that were removed from your Git repository. Make sure you intend to remove them before enabling this option. ### Self Heal When enabled alongside Automated Sync, ArgoCD automatically reverts any manual changes made directly to the cluster. If someone modifies a resource with `kubectl`, ArgoCD will detect the drift and restore the resource to match Git. *** ## Sync Options Sync options are flags that control specific ArgoCD behaviors during synchronization. You can select multiple options. | Option | Description | | --------------------------------- | ------------------------------------------------------------------------------------------------- | | **Create Namespace** | Automatically create the target namespace if it does not exist | | **Server-Side Apply** | Use Kubernetes server-side apply instead of client-side. Recommended for large resources and CRDs | | **Apply Out-of-Sync Only** | Only apply resources that are out of sync, skipping unchanged resources. Reduces sync time | | **Respect Ignore Differences** | Honor ignore difference rules during sync. Automatically enabled when ignore rules are present | | **Prune Propagation: Foreground** | Wait for dependent resources to be deleted before removing the parent | | **Prune Propagation: Background** | Delete the parent immediately and let Kubernetes garbage-collect dependents | | **Prune Propagation: Orphan** | Remove the parent but leave dependent resources in place | | **Prune Last** | Prune resources only after all other sync operations complete | | **Replace** | Use `kubectl replace` instead of `kubectl apply`. Useful when apply fails due to field conflicts | | **Fail on Shared Resource** | Fail the sync if a resource is already managed by another ArgoCD Application | **Server-Side Apply** and **Create Namespace** are enabled by default in most profiles. Server-Side Apply is recommended because it handles large objects and field conflicts better than client-side apply. *** ## Health & Revisions ### Strict Health Check When enabled, ArgoCD requires **all** resources created by the add-on to report a healthy status before considering the deployment successful. This is useful for production-critical add-ons where partial deployments are unacceptable. When disabled (default), ArgoCD considers the sync successful as soon as resources are applied, regardless of their health status. ### Revision History Limit Controls how many previous application revisions ArgoCD retains (1--100). Higher values consume more storage but make it easier to audit changes and understand deployment history. The default is **10**. *** ## Retry Policy The retry policy controls automatic retry behaviour when a sync operation fails. | Field | Description | Default | | ------------------ | ---------------------------------------------------- | ------- | | **Retry Limit** | Maximum number of retry attempts (0--100) | 5 | | **Backoff Factor** | Multiplier applied to delay between retries (1--10) | 2 | | **Initial Delay** | Wait time before the first retry (e.g. `5s`, `1m`) | 5s | | **Max Delay** | Maximum wait time between retries (e.g. `3m`, `10m`) | 3m | Retries use exponential backoff: each retry waits longer than the previous one, up to the max delay. For example, with the defaults, retries happen at approximately 5s, 10s, 20s, 40s, and 80s (capped at 3m). *** ## Sync Window Sync windows restrict when ArgoCD is allowed to synchronize your add-on. This is useful for enforcing change-management policies, such as only allowing deployments during business hours or maintenance windows. | Field | Description | Example | | ------------ | ---------------------------------------------- | ------------------------------------ | | **Schedule** | Cron expression defining when the window opens | `0 22 * * *` (daily at 10 PM) | | **Duration** | How long the window stays open | `1h`, `30m`, `2h` | | **Timezone** | Timezone for the cron schedule | `UTC`, `Europe/Berlin`, `US/Eastern` | When a sync window is active, ArgoCD will only sync during the defined window. Outside the window, changes accumulate in Git and are applied when the next window opens. *** ## Ignore Differences Ignore Differences lets you tell ArgoCD to skip specific fields when comparing the desired state (Git) with the live state (cluster). This prevents false "OutOfSync" reports caused by fields that are mutated at runtime by Kubernetes controllers, webhooks, or operators. ### Why Ignore Differences? ArgoCD continuously compares your Git repository with the live cluster state. When they differ, ArgoCD reports the resource as **OutOfSync**. However, some fields are legitimately modified after deployment: * **Webhook controllers** inject `caBundle` values into webhook configurations * **Kubernetes** assigns `clusterIP` to Services automatically * **Operators** update status fields and annotations on custom resources * **Controllers** like `kube-controller-manager` set default values on resources Without ignore rules, these runtime mutations cause constant OutOfSync status, triggering unnecessary syncs (with auto-sync) or masking real configuration drift. ### Resource Selectors Each ignore rule can be scoped to specific resources using optional selectors: | Field | Description | Example | | ------------- | ------------------------- | -------------------------------- | | **Kind** | Kubernetes resource kind | `ValidatingWebhookConfiguration` | | **Group** | API group of the resource | `admissionregistration.k8s.io` | | **Name** | Specific resource name | `istio-validator-istio-system` | | **Namespace** | Namespace of the resource | `istio-system` | All selectors are optional. Omitting a selector means the rule matches all values for that field. For example, a rule with only `Kind: Service` and no name or namespace applies to every Service in the add-on. ### Matching Methods Each rule must include at least one of the following methods to specify which fields to ignore. #### JSON Pointers JSON Pointers ([RFC 6901](https://datatracker.ietf.org/doc/html/rfc6901)) are path-based references into a JSON document. They use `/` as a separator and numeric indices for arrays. **Syntax:** `/path/to/field` or `/path/0/arrayElement` **Examples:** | Pointer | What it targets | | ------------------------------------------------------------------------- | ---------------------------------------------------- | | `/spec/clusterIP` | The `clusterIP` field on a Service | | `/webhooks/0/clientConfig/caBundle` | The `caBundle` of the first webhook | | `/metadata/annotations/kubectl.kubernetes.io~1last-applied-configuration` | An annotation (note: `/` in keys is escaped as `~1`) | | `/status` | The entire status subresource | Use JSON Pointers when you need to target a specific array index or a straightforward field path. They are simple and well-suited for most use cases. #### JQ Path Expressions JQ path expressions use the [jq](https://jqlang.github.io/jq/) query language syntax to target fields. They are more powerful than JSON Pointers and support wildcards and array iteration. **Syntax:** `.path.to.field` or `.path[0].arrayElement` **Examples:** | Expression | What it targets | | --------------------------------------------------------------------------- | ------------------------------------------------ | | `.spec.clusterIP` | The `clusterIP` field on a Service | | `.webhooks[0].clientConfig.caBundle` | The `caBundle` of the first webhook | | `.webhooks[].clientConfig.caBundle` | The `caBundle` of **all** webhooks (wildcard) | | `.metadata.annotations["kubectl.kubernetes.io/last-applied-configuration"]` | An annotation with special characters in the key | | `.status` | The entire status subresource | Use JQ Path Expressions when you need wildcards (e.g. `.webhooks[]` to match all array elements) or when targeting fields with special characters in their keys. #### Managed Fields Managers Instead of targeting specific fields, you can ignore all fields managed by a particular controller or process. Kubernetes tracks which controller "owns" each field through its [Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) mechanism. **Examples:** | Manager | What it covers | | ------------------------------------ | ------------------------------------------------------------------------------------- | | `kube-controller-manager` | Fields set by the Kubernetes controller manager (e.g. default values, status updates) | | `clusterrole-aggregation-controller` | Aggregated rules on ClusterRoles | | `cert-manager-cainjector` | CA bundle fields injected by cert-manager | Managed Fields Managers is the broadest matching method. It ignores **all** fields owned by that manager, which may include fields you want ArgoCD to track. Use it only when you trust the controller's mutations entirely. ### Common Examples Webhook controllers like cert-manager inject a `caBundle` into webhook configurations after deployment. This is one of the most common causes of false OutOfSync status. | Field | Value | | ---------------- | ----------------------------------- | | **Kind** | `ValidatingWebhookConfiguration` | | **Group** | `admissionregistration.k8s.io` | | **JSON Pointer** | `/webhooks/0/clientConfig/caBundle` | Or to cover all webhooks in the configuration using JQ: | Field | Value | | ---------------------- | ----------------------------------- | | **Kind** | `ValidatingWebhookConfiguration` | | **Group** | `admissionregistration.k8s.io` | | **JQ Path Expression** | `.webhooks[].clientConfig.caBundle` | This also applies to `MutatingWebhookConfiguration` resources. Kubernetes assigns `clusterIP` and `clusterIPs` automatically when a Service is created. These values are not in your Helm chart but will appear in the live resource. | Field | Value | | ----------------- | ------------------------------------- | | **Kind** | `Service` | | **JSON Pointers** | `/spec/clusterIP`, `/spec/clusterIPs` | When using ClusterRole aggregation, the `kube-controller-manager` merges rules from multiple ClusterRoles. The aggregated `rules` field will differ from what is defined in Git. | Field | Value | | -------------------------- | ------------------------------------ | | **Kind** | `ClusterRole` | | **Group** | `rbac.authorization.k8s.io` | | **Managed Fields Manager** | `clusterrole-aggregation-controller` | Operators and controllers frequently update the `.status` subresource on CRDs. Since status is managed by controllers and not by your Helm chart, these changes cause false diffs. | Field | Value | | ---------------------- | -------------------------------------------------- | | **Kind** | Your CRD kind (e.g. `Certificate`, `IngressRoute`) | | **JQ Path Expression** | `.status` | Some controllers add or modify annotations on resources. For example, `kubectl.kubernetes.io/last-applied-configuration` is added by client-side apply. | Field | Value | | ---------------- | ------------------------------------------------------------------------- | | **JSON Pointer** | `/metadata/annotations/kubectl.kubernetes.io~1last-applied-configuration` | Or with JQ (no escaping needed): | Field | Value | | ---------------------- | --------------------------------------------------------------------------- | | **JQ Path Expression** | `.metadata.annotations["kubectl.kubernetes.io/last-applied-configuration"]` | Kubernetes mutates `volumeClaimTemplates` on StatefulSets after creation, adding defaults like `storageClassName`, `volumeMode`, and `status`. These fields are not in your Helm chart but appear in the live resource. | Field | Value | | ---------------------- | ------------------------------ | | **Kind** | `StatefulSet` | | **Group** | `apps` | | **JQ Path Expression** | `.spec.volumeClaimTemplates[]` | For more targeted ignoring, you can narrow to specific subfields: | Field | Value | | ----------------- | ------------------------------------------------------------------------------------- | | **Kind** | `StatefulSet` | | **Group** | `apps` | | **JSON Pointers** | `/spec/volumeClaimTemplates/0/spec/volumeMode`, `/spec/volumeClaimTemplates/0/status` | The Kubernetes controller manager sets default values on many resources (e.g. default service account tokens, pod tolerations). Use a Managed Fields Manager rule to ignore all of them at once. | Field | Value | | -------------------------- | ------------------------- | | **Managed Fields Manager** | `kube-controller-manager` | This applies broadly, so only use it on resources where you want to ignore all controller-managed fields. ### Important Behaviors **Rules need a diff specifier.** Each ignore rule must include at least one JSON Pointer, JQ Path Expression, or Managed Fields Manager. Rules with only resource selectors (Kind, Group, Name, Namespace) and no diff specifier are silently ignored. **RespectIgnoreDifferences is automatic.** When you add ignore rules, the `RespectIgnoreDifferences=true` sync option is automatically enabled. You do not need to add it manually. **Custom profile.** Adding or modifying ignore rules automatically switches your settings profile to **Custom**. *** ## Related Learn about add-on architecture and deployment. Bundle add-ons into reusable stacks. Understand the GitOps workflow. Encrypt sensitive add-on values. # Add-ons Source: https://docs.ankra.ai/concepts/addons Manage and deploy Helm add-ons with GitOps-powered continuous delivery. Add-ons are Helm charts deployed through Ankra's GitOps pipeline. They provide a standardized way to extend your clusters with monitoring, networking, security, and custom applications, all managed through continuous delivery. ## What is an Add-on? An add-on is a packaged application or tool that extends the functionality of your Kubernetes cluster. Add-ons are distributed as Helm charts and can include anything from monitoring tools and ingress controllers to security solutions and custom integrations. An add-on could even be your own application, integrated into the Ankra ecosystem for easy deployment and management. *** ## Architecture Overview Understanding how add-ons flow from configuration to deployment helps you manage them effectively. ### GitOps Deployment Pipeline ```mermaid theme={null} flowchart LR Stack[Stack Builder] --> Git[Git Repository] Git --> ArgoCD[ArgoCD] ArgoCD --> Helm[Helm Release] Helm --> K8s[Kubernetes Resources] ``` **How it works:** 1. **Stack Builder**: You configure add-ons with values and dependencies 2. **Git Repository**: Configuration is committed as Helm values files 3. **ArgoCD**: Detects changes and initiates deployment 4. **Helm Release**: ArgoCD renders the Helm chart with your values 5. **Kubernetes Resources**: The rendered manifests are applied to your cluster ### Add-on Lifecycle States | State | Description | | ------------- | -------------------------------------------- | | **Pending** | Add-on is queued for deployment | | **Deploying** | ArgoCD is applying the Helm release | | **Synced** | All resources are deployed and healthy | | **Degraded** | Some resources are unhealthy | | **OutOfSync** | Git configuration differs from cluster state | | **Unknown** | Status cannot be determined | *** ## Resource Hierarchy Each add-on creates a hierarchy of Kubernetes resources. Understanding this hierarchy helps with troubleshooting and resource management. ### Typical Add-on Resource Structure ```mermaid theme={null} flowchart TD App[ArgoCD Application] --> NS[Namespace] App --> Deploy[Deployments] App --> SVC[Services] App --> CM[ConfigMaps] App --> Secret[Secrets] Deploy --> RS[ReplicaSets] RS --> Pod[Pods] SVC --> EP[Endpoints] ``` **Resource types commonly created by add-ons:** | Category | Resources | | ----------------- | ------------------------------------------- | | **Workloads** | Deployments, StatefulSets, DaemonSets, Jobs | | **Networking** | Services, Ingresses, NetworkPolicies | | **Configuration** | ConfigMaps, Secrets | | **Storage** | PersistentVolumeClaims | | **RBAC** | ServiceAccounts, Roles, RoleBindings | | **Custom** | CRDs and custom resources | Navigate to any installed add-on and open its [Resource Map](#resource-map) to see this hierarchy live for your cluster. *** ## Continuous Delivery Flow Add-ons in Ankra follow a GitOps continuous delivery model powered by ArgoCD. ### Sync Process You modify add-on values in the Stack Builder or update values in Git directly. Changes are committed to your connected Git repository. Ankra detects the change via webhook (or periodic polling). ArgoCD compares desired state (Git) with actual state (cluster) and applies differences. ArgoCD monitors resource health until all pods are running and endpoints are ready. ### Sync Strategies | Strategy | Behavior | | --------------- | --------------------------------------------------- | | **Auto-Sync** | Changes in Git automatically deploy to the cluster | | **Manual Sync** | Changes require explicit sync trigger | | **Self-Heal** | ArgoCD reverts manual cluster changes to match Git | | **Prune** | Resources removed from Git are deleted from cluster | *** ## Manage Add-on Sources An add-on source in Ankra is either a Helm repository URL or an OCI (Open Container Initiative) registry URL. These sources contain the Helm charts you want to use for deploying add-ons to your clusters. Helm charts are a standard way to package Kubernetes applications, making it easy to manage dependencies and versioning for complex workloads. By connecting both public and private Helm repositories or OCI registries, you can access a wide range of Kubernetes add-ons. This lets you integrate open-source tools, vendor solutions, or your own custom charts - all from a single interface. Managing sources centrally ensures your team always has access to the latest and most secure versions of your preferred add-ons. Setup steps live in one place: see [Registries](/guides/registries) for connecting a source, and [Create a Registry](/guides/create-a-registry) for hosting your own charts on GHCR. *** ## Stacks To deploy an add-on onto your cluster, add it to a stack. You can add multiple add-ons and manifests to build a **Stack**, which is a repeatable, reusable set of components for your Kubernetes environments. Stacks let you bundle everything your application or platform needs, from monitoring and logging to ingress controllers and security policies. You can version stacks, share them with your team, and deploy them to any cluster with a single action. This approach speeds up onboarding, reduces errors, and helps make sure every environment is production-ready. [Learn more about Stacks →](/concepts/stacks) *** ## Install Add-ons Add-ons in Ankra are installed through **Stacks**. This ensures your add-ons are bundled with their dependencies and can be managed as a cohesive unit. Go to the **Stacks** section in your cluster and click **Create Stack** (or edit an existing stack). In the Stack Builder, click **Add** and select **Add-on**. Browse or search for charts from your connected registries. Select the chart version and configure the values. Pin an exact chart version in production to avoid unexpected upgrades. You can use the AI Assistant (`⌘+J`) to help customize the configuration. Save your stack and deploy it to install the add-on on your cluster. Ankra handles versioning, dependency management, and cluster targeting for you. This makes it easy to standardize tooling and services across all your environments, ensuring consistency and reducing operational overhead. *** ## Encrypting Sensitive Values with SOPS When your add-on configuration contains sensitive data like passwords, API keys, or webhook URLs, use **SOPS** to encrypt them before storing in your GitOps repository. Edit an add-on within your stack by clicking on it in the Stack Builder. In the values edit view, click the **SOPS** button in the toolbar to enable encryption. SOPS will encrypt sensitive values (like `adminPassword` or `slack_api_url`) while keeping keys readable for easier Git diffs. Save your add-on configuration. The encrypted values will be stored safely in your GitOps repository and decrypted automatically when deployed. SOPS encryption requires initial setup. See [SOPS Encryption](/guides/sops) for configuration instructions. *** ## Operational Learnings with AGENTS.md Every add-on can carry an **AGENTS.md** - a markdown document of operational learnings (upgrade gotchas, safe rollout order, values that must stay pinned) that teammates and Ankra's AI build up over time. Edit it from the **AGENTS.md** tab on the add-on in the Stack Builder; editing it never triggers a redeploy. See [Teach Your Agents with AGENTS.md](/platform/agents-md). *** ## Manifests A **manifest** is a Kubernetes YAML file that defines resources or configuration, like namespaces, CRDs, or RBAC rules. In Ankra, manifests help you: * **Include manifests in stacks:** Make sure your clusters are ready for add-ons by setting up all prerequisites and custom resources first. * **Automate environment setup:** Create the foundational resources your add-ons and workloads need, so your stacks are fully self-contained and repeatable. Manifests are key for customizing clusters and making sure every deployment fits your team's needs. [Learn more about Manifests →](/concepts/manifests) *** ## Viewing Installed Add-ons Once deployed, you can monitor and manage add-ons from the Add-ons page. ### Add-ons List Navigate to your cluster → **Add-ons** to see all installed add-ons with: * **Name and Version**: The Helm chart name and deployed version * **Status**: Current sync and health status * **Namespace**: Where the add-on is deployed * **Last Updated**: When the add-on was last modified ### Add-on Details Click any add-on to view detailed information: | Tab | Description | | ---------------- | ------------------------------------------------------------------ | | **Overview** | Chart info, status, metadata, and ArgoCD application state | | **Resource Map** | Visual hierarchy of all Kubernetes resources created by the add-on | | **Values** | Current Helm values configuration | | **Events** | Recent events related to the add-on's resources | ### Resource Map The Resource Map provides a visual representation of all resources deployed by an add-on: * **Hierarchical View**: See parent-child relationships (e.g., Deployment → ReplicaSet → Pod) * **Quick Navigation**: Click any resource to view its details * **Status Indicators**: Identify unhealthy or pending resources at a glance * **Resource Types**: View all Kubernetes resource kinds in one place Use the Resource Map when troubleshooting to quickly identify which resources are failing and their dependencies. *** ## Updating Add-ons ### Changing Values 1. Navigate to your stack in the Stack Builder 2. Click the add-on you want to modify 3. Update the Helm values as needed 4. Save and deploy the stack ### Upgrading Chart Versions 1. Edit the stack containing the add-on 2. Click the add-on and select a new chart version 3. Review any breaking changes in the chart changelog 4. Save and deploy to upgrade Major version upgrades may include breaking changes. Review the chart's release notes and test in a non-production environment first. ### Rollback If an upgrade causes issues: 1. Edit the stack and revert to the previous chart version 2. Or use GitOps: revert the commit in your Git repository 3. ArgoCD will automatically sync to the previous state Add-on settings and Helm values are also readable and updatable through Ankra's AI and MCP clients, alongside sync, rollback, and uninstall - so routine add-on operations can run straight from chat or your editor. See the [MCP Tool Reference](/platform/mcp-tools#add-ons). *** ## Explore the Add-ons API Want to automate add-on management or integrate with your CI/CD workflows? Check out the [API Reference](/api-reference/introduction) for endpoints to list, install, and manage add-ons programmatically. *** ## Related Build stacks with multiple add-ons. Browse available Helm charts. Understand the GitOps workflow. Encrypt sensitive add-on values. # Applications Source: https://docs.ankra.ai/concepts/applications Point Ankra at an application's source repository and it generates the Dockerfile, Kubernetes manifests, and CI/CD to build and deploy it. Applications take you from source code to a deployable workload. Connect an application's Git repository and Ankra analyzes it, generates the packaging it's missing, and opens a pull request in your repository. Once merged, CI builds and publishes a container image that you can deploy to a cluster. **Closed beta.** Applications is in closed beta. The workflow is stable but the surface may still change, and it is enabled per organisation on request. [Contact support](/platform/support) to have it turned on for your organisation. Applications connect to **GitHub** repositories and use a [GitHub credential](/integrations/github). By default the generated CI/CD pipeline pushes the container image to your organisation's private Ankra registry; if you already run your own registry, [declare it](#using-your-own-registry) and Ankra publishes to and reads from it instead. *** ## How it works ```mermaid theme={null} flowchart LR Repo[Your app repo] -->|connect| Ankra[Ankra] Ankra -->|"analyze + generate (PR)"| PR[Pull request] PR -->|merge| CICD[CI/CD pipeline] CICD -->|push image| Registry[Private Ankra registry] Registry -->|deploy| Cluster[Application on cluster] ``` Provide a name and a GitHub credential, then pick the repository and a branch from the repository's own branch list - the default branch is preselected, and **Enter a different branch** lets you type one that does not exist yet. Ankra inspects the repository, detects the language and framework, and generates the artifacts it needs: a Dockerfile, Kubernetes manifests, and a CI/CD workflow. Review and merge the PR. Merging activates the CI/CD pipeline in your repository. CI builds and pushes the container image to the organisation's private Ankra registry. Ankra surfaces the image URL and scans the published image. Deploy the application onto a cluster. Ankra verifies that the image was published and tracks the rollout. *** ## What Ankra tracks For each application you see: * **State** and **analysis status** - where the application is in the connect/analyze/generate/build lifecycle, with an error message if something needs attention. * **Repository** - owner, name, branch, and URL. * **Components** - the repository's deployable apps. An ordinary repository has one; a monorepo has one per app. * **Artifacts** - the private container image URL and the latest published build, per component. * **Pull request** - a link to the generated PR. * **Jobs** - the underlying platform jobs for the application, so you can follow analysis and generation as it runs. ### Monorepos A repository that builds more than one deployable app is onboarded as a **monorepo**: Ankra records one component per app, and each component gets its own packaging and its own image. | Per component | Where it lives | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Dockerfile | `/Dockerfile` | | Kubernetes manifests | `.ankra/manifests/-*.yaml` | | Build workflow | `.github/workflows/-build-and-publish.yml`, with a `paths:` filter scoped to the component's directory so touching one app does not rebuild the others | | Container image | `//` | Ankra decides the components from, in order: the per-component workflows the repository already carries (so re-running analysis never renames a component and orphans the images it has published), the apps the analysis proposed, then the repository's structure - two or more Dockerfiles in subdirectories and no Dockerfile at the root, or a workspace marker (`nx.json`, `turbo.json`, `lerna.json`, `pnpm-workspace.yaml`, `go.work`) plus two or more subdirectories with their own dependency manifest. **A Dockerfile at the repository root always means a single app**, whatever else the repository contains. Build state, published images, 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. ### Using your own registry An application publishes to your organisation's private Ankra registry unless you say otherwise. If you already operate a registry - the same Harbor whose OCI charts Ankra indexes, for instance - declare it on the application and Ankra publishes there, reads the published tags back from there, and pulls from there. Declare it with `image_registry` when you create the application: ```json theme={null} { "name": "commerce", "app_repo_credential_name": "github", "app_repo_owner": "smartoptics-dwdm", "app_repo_name": "commerce", "image_registry": { "url": "oci://artifact.example.com/commerce-images", "credential_name": "example-harbor-pull", "pull_secret_name": "harbor-registry", "username_secret_name": "HARBOR_USERNAME", "password_secret_name": "HARBOR_PASSWORD" } } ``` | Field | Meaning | | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `url` | The registry project images publish to, as `oci:///`. A deeper path becomes a prefix every component's repository nests under. | | `credential_name` | An existing [registry credential](/integrations/helm-registries) of the organisation - the same credential resource your chart registries authenticate with. Ankra reads published tags and builds the cluster pull secret from it. | | `api_url` | Optional. The registry's management API base; defaults to `https://`, which is where a Harbor serves its own API. | | `pull_secret_name` | Optional. The `kubernetes.io/dockerconfigjson` Secret the generated manifests reference through `imagePullSecrets`. Defaults to `ankra-registry-pull`. | | `username_secret_name` / `password_secret_name` | Optional. The repository Actions secrets the build workflow logs in with. Default to `ANKRA_REGISTRY_USERNAME` / `ANKRA_REGISTRY_PASSWORD`. | | `manage_actions_secrets` | Optional, default `false`. See below. | **Ankra does not mint robots for a registry you operate.** With a declared registry, setup names the two Actions secrets the workflow reads and leaves them to you, rather than writing a credential Ankra happens to hold over a push robot you administer. Publish readiness reports whether those secrets exist and names them. Set `manage_actions_secrets: true` to have Ankra write the declared credential into them instead. On a monorepo, a component may declare its own `image_registry` to publish into a different project of the same registry - useful when each app has its own robot accounts and retention rules. A component's declaration wins over the application's; the application's applies to every component that declares none. Publish readiness, the deploy gate, image tag listings, container scanning, and preview demos all resolve the declared registry, so an application whose images live outside Ankra reports what is actually published rather than staying blocked on an artifact that was never going to appear in Ankra's own project. ### Security scanning Applications include code and container security insights, so vulnerabilities surface alongside the build rather than in a separate tool. On a monorepo, the image tags and the scanned image reference follow the component you select; code and IaC findings cover the whole repository, because that is where those scanners run. Pair this with [AI Insights](/platform/ai-insights) for proactive analysis. *** ## Preview demos Before you merge, you can spin up a **throwaway demo** of a pull request or branch build to see it running. Each demo is deployed into its own isolated namespace (`ankra-demo-pr-` or `ankra-demo-br-`) on the organisation's **staging cluster**, PodSecurity-hardened and quota-bounded, and is automatically torn down when its TTL expires - so it can never affect existing workloads. An admin sets the organisation's staging cluster under **AI** → **Settings** → **Workspaces**. Optionally set a **demo base domain** (with an ingress class and TLS secret) there too - this is what gives demos a public URL. Deploy a branch or PR demo from the application's **Demos** tab, from the CLI, or by asking the AI assistant. The demo pulls the image tag the PR/branch build pushed. When a public host is available, Ankra returns a **preview URL** you can open directly. Otherwise the demo stays reachable in-cluster (service DNS + a `kubectl port-forward` command). Two guides cover the two ways a demo starts: [branch demos](/guides/branch-demos) walks the launch dialog field by field, and [PR preview environments](/guides/pr-preview-environments) covers the automatic per-pull-request flow. ### The preview URL Ankra resolves the demo's public hostname automatically, and every surface (portal, CLI, MCP, and automatic PR previews) uses the same rule: 1. **An organisation demo base domain**, if configured, wins outright - the host is `.`, served with your configured ingress class and TLS secret. 2. **Otherwise, the staging cluster's own delegated DNS zone**, but only when that zone is active - giving `...ankra.cc`, a hostname the `external-dns` running on that cluster can resolve. 3. **Otherwise the demo stays in-cluster-only** - no ingress is created, and you reach it with the returned service DNS name and `kubectl port-forward`. A demo only gets a resolvable public URL when the organisation has a demo base domain configured **or** the staging cluster has an active Ankra DNS zone. Without either, the demo still deploys - it just stays in-cluster-only. ### Deploying a demo A demo deploys **every component** of the application by default. A single-app application runs its one image; a monorepo runs one pod per component — the frontend and the API of a two-app repository both come up, wired together, instead of half an application answering where the other half belonged. You can still deselect components or demo a single one. Open the application's **Demos** tab, pick a branch or enter a pull request number, and deploy. The tab shows active demos, the preview URL, and the remaining TTL. Each demo links to its own detail page - live provisioning progress read from the staging cluster, the namespace's bill of materials with manifests (grouped per component), Kubernetes events, and pod logs, plus the preview URL or port-forward command to reach it. On a monorepo the launch dialog lists every component with its own build status and tag, lets you include or exclude each, and marks the **web entry** — the component that owns the demo URL. ```bash theme={null} # Deploy a branch demo ankra application demo deploy --branch feature/login # Deploy a PR demo with an explicit TTL ankra application demo deploy --pr-number 42 --ttl-hours 8 # List active demos, then stop one ankra application demo list ankra application demo stop # Inspect a demo: record + provisioning steps, and a bounded log tail ankra application demo detail ankra application demo logs --tail 200 # Read or edit the saved demo defaults ankra application demo config get ankra application demo config set \ --database=true --env 'DATABASE_URL=${{ ankra.demo_database.url }}' \ --migrate-command 'pnpm run db:migrate' --database-extension vector # Dispatch the AI pre-setup mission for a failed demo ankra application demo fix ``` The deploy response includes `preview_url` when a public host was resolved. `config set` fetches the saved configuration first and applies only the flags you pass, so it never drops entries or dependency designations you did not name. Ask the AI assistant to demo a pull request, or call the `deploy_pr_demo` tool directly (it is allowed in **Ask** mode - the demo is isolated and self-expiring). The result carries the same `preview_url`. Tear down early with `demo_stop`. Opening a pull request on a connected application also deploys a preview automatically and posts the URL back as a PR status comment that updates in place - see the [PR preview environments guide](/guides/pr-preview-environments) for the comment lifecycle, requirements, and troubleshooting. ### Monorepo demos: every component, one URL A monorepo demo deploys each component as its own Deployment and Service inside the demo namespace, and the demo only reports **ready** once every component accepts connections: * **The web entry owns the demo URL.** Ankra picks the frontend-shaped component (a name or directory like `frontend`, `web`, `ui`, `portal`) as the entry serving `/` on the demo host; you can move the entry in the launch dialog or with `entry_component` on the API. * **API components share the host under a path.** The single API-shaped component (`api`, `backend`, `server`) is published under `/api` on the same demo host, routed straight to its Service — so a browser calling `/api/...` reaches the API even when the frontend's own proxy target was baked for another environment. Override per component with `ingress_path`. * **Components reach each other by name.** Every component's Service is named after it, so in-namespace URLs like `http://crm-api:8090` resolve. Env values can also use placeholders that resolve at deploy time: | Placeholder | Resolves to | | ----------------------------------------- | ------------------------------------------------ | | `${{ ankra.demo_component..url }}` | `http://:` inside the namespace | | `${{ ankra.demo_component..host }}` | The component's Service name | | `${{ ankra.demo_component..port }}` | The component's container port | The saved [migration command](#environment-variables-and-a-throwaway-database) runs once per deploy, inside the image of the component that owns the schema (the primary component - usually the backend). Demo environment defaults and the throwaway database are shared by every component of the demo. Existing demos and single-app applications are unaffected: a demo recorded before multi-component support (or of an application with one component) keeps exactly the previous single-pod shape. ### Environment variables and a throwaway database Most real applications need configuration to boot — a database name, an API key, an SMTP host. Demos support both **per-application defaults** and **per-launch overrides**, so any codebase can run as a demo without changes: * **Defaults** live behind the gear button on the **Demos** tab (*Demo settings*). Every demo of the application inherits them — manual launches, CLI/MCP deploys, and the automatic PR previews. * **Overrides** are set per launch in the *Environment & database* section of the launch dialog (or via the `env` argument of `deploy_pr_demo`). Overrides win by name. Values marked **secret** are stored as Ankra secret slots (Vault-backed) — the plaintext never persists and is mounted into the demo as a Kubernetes Secret at deploy time. **Need a database?** Toggle **Attach a throwaway Postgres** and an ephemeral Postgres is provisioned inside the demo namespace with a random per-demo password, destroyed together with the demo. Because every codebase names its configuration differently, nothing is injected automatically — reference these placeholders in your env *values* and they resolve when the demo starts: | Placeholder | Resolves to | | ------------------------------------- | ------------------------------------ | | `${{ ankra.demo_database.url }}` | Full `postgres://` connection string | | `${{ ankra.demo_database.host }}` | In-namespace service host | | `${{ ankra.demo_database.port }}` | `5432` | | `${{ ankra.demo_database.name }}` | Database name | | `${{ ankra.demo_database.user }}` | Database user | | `${{ ankra.demo_database.password }}` | The per-demo random password | The throwaway database is ephemeral by design: it starts empty on every deploy and is wiped with the namespace. The database runs a pgvector-capable Postgres, so migrations using `CREATE EXTENSION vector` work. `.url` and `.password` references are always delivered through a Kubernetes Secret, never as plain env text. **Migrations.** If your image does not run its own migrations on boot, set a **migration command** in the demo configuration (`migrate_command`) — for example `pnpm run db:migrate` or `alembic upgrade head`. It runs inside your application image (`sh -c`) as an init container, after the database accepts connections and with the same environment the app sees, so a fresh demo database provisions its schema before the first request. Because every deploy starts the database empty, the command re-runs on every deploy — write migrations to be idempotent (every standard migration tool is). **Extensions.** If your schema needs Postgres extensions beyond what migrations create themselves, list them in `database_extensions` (for example `["vector"]`) and the demo database creates them at initdb, before your migrations run. Ankra detects both automatically when it analyses a repository: a Postgres client dependency, an ORM configuration, or a composed database marks the application as database-needing, its referenced connection variables are wired to the `${{ ankra.demo_database.* }}` placeholders, and a recognised migration script becomes the migration command — so the first demo of a database-backed application works without any manual configuration. Detection only ever seeds an application that has no demo configuration yet; it never overwrites what you or the pre-setup agent saved. ### The demo container port The demo's readiness probe, Service, and preview route all target one container port, resolved in this order: the component's recorded port, the generated runtime Dockerfile's `EXPOSE`, the generated Deployment manifest's `containerPort`, the analysed `target_port` parameter, and only then the platform default. The launch dialog shows the resolved port and where it came from; a port you did not edit is left to the platform to resolve. When the resolved port is still wrong — stale analysis, a hand-edited Dockerfile — the platform corrects itself at runtime: a demo whose container runs cleanly but never accepts connections has its logs read for the port the server actually announces (`Accepting connections at…`, `Listening on…`, and the other common startup banners). If the evidence is unambiguous, the demo is repointed at the announced port on the fly, the correction is recorded on the application so the next launch resolves it statically, and the demo detail page shows the correction. Ambiguous evidence never auto-corrects; it flows into the failure message ("Nothing accepted connections on port 3000. The container's logs say it listens on port 8001.") and dispatches the pre-setup agent instead. ### Automatic pre-setup when a demo crashes An image that validates its environment on boot — refusing to start without a database URL, an auth secret, an API key — crash-loops when demoed with no configuration. Ankra now detects this and fixes it with an agent: 1. When a demo fails with a **startup crash** (CrashLoopBackOff or a container configuration error), a **failed migration command**, or a port-evidence timeout (the container announced a different port than the demo probed), Ankra dispatches a one-shot **pre-setup agent** for it automatically. The run appears on the **AI agents** page like any other mission. 2. The agent reads the crashed container's logs, works out which environment variables the application demands, and generates a **pre-setup**: missing database URLs become `${{ ankra.demo_database.* }}` references with the throwaway Postgres enabled, secrets get fresh random values, and mode flags get the value that avoids external side effects. 3. It saves the pre-setup as the application's demo defaults — so **every future demo inherits it** — and redeploys the failed demo to prove it boots. The agent can also set the migration command and database extensions when the logs show schema or `CREATE EXTENSION` failures. It never weakens the application's own validation, never reuses values found in logs, and merges with existing demo settings rather than replacing what you configured. Dispatch is bounded to one run per demo per day; image-pull failures and provisioning timeouts never dispatch (no environment can fix those). You can also trigger it on demand with `POST /org/applications/{application_id}/demos/{workspace_id}/fix`, or just ask the AI assistant to fix the failed demo — the chat has the same `get_demo_diagnostics`, `update_application_demo_config`, and `redeploy_demo` tools the mission uses. *** ## Managing applications | Action | What it does | | ------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Retry** | Re-run analysis and generation after fixing an issue (for example, adding the right credential or repository permissions) | | **Reconcile** | Re-evaluate the application against its repository and refresh its state | | **Delete** | Disconnect the application from Ankra | *** ## Prerequisites Add a [GitHub credential](/integrations/github) with access to the application's repository. The Ankra GitHub App needs permission to open pull requests, commit workflow files, and manage Actions secrets. Ankra installs the Ankra registry credentials on the repository automatically; for [your own registry](#using-your-own-registry) you set the login secrets yourself. Make sure you have a [cluster](/guides/import-cluster) with the [agent](/concepts/cluster-agent) connected to deploy onto. *** ## API Applications are available over the API for CLI and scripted use, under `/api/v1/org/applications` (bearer-token authenticated) - create, list, inspect, retry, reconcile, and delete. See the [API Reference](/api-reference/introduction) for endpoints and schemas. The same lifecycle is available through Ankra's AI and MCP clients - connect, deploy, retry, reconcile, and delete applications, and follow their CI workflow runs - see the [MCP Tool Reference](/platform/mcp-tools#applications). See the [CI/CD Pipeline guide](/guides/cicd-pipeline) for how the generated pipeline fits into GitOps. # Ankra Agent Source: https://docs.ankra.ai/concepts/cluster-agent Learn how the Ankra Agent connects your Kubernetes cluster to the platform. The Ankra Agent is a lightweight service that runs inside your Kubernetes cluster, enabling real-time communication with the Ankra platform. It provides secure, bidirectional connectivity for resource browsing, deployments, and cluster management. The agent ships as a single, statically compiled **Go binary** on the **2.x version track** (`2.0.x`). It is a drop-in replacement for earlier agents - the same Helm chart, values, install command, and behaviour - with a smaller memory and CPU footprint and faster startup. Existing clusters are upgraded automatically by the platform; there is nothing to change in your install command. The agent requires **cluster-admin** permissions to manage all Kubernetes resources and deploy add-ons. *** ## What the Agent Does Browse Deployments, Pods, Services, and 20+ resource types with live updates. View container logs in real-time directly from the Ankra dashboard. Deploy, upgrade, and manage Helm releases across your cluster, including history and rollback. Install stacks and add-ons using the native Helm engine (default) or ArgoCD. See [Deployment Engines](/concepts/deployment-engines). Proxy authenticated `kubectl` requests to the cluster API server - no inbound ports. See [Accessing Clusters with kubectl](/guides/kubeconfig). Optionally report the cluster's public egress IP so it appears on the [Dashboard](/platform/dashboard) world map. *** ## Installation When you import a cluster, Ankra generates a Helm install command with a unique token: ```bash theme={null} helm upgrade --install ankra-agent oci://ghcr.io/ankraio/ankra-agent/ankra-agent \ --namespace ankra \ --create-namespace \ --set config.token="YOUR_UNIQUE_TOKEN" ``` The agent will connect to the platform and your cluster will appear online within seconds. ### Verify Installation Check the agent is running: ```bash theme={null} kubectl get pods -n ankra ``` View agent logs: ```bash theme={null} kubectl logs -n ankra -l app.kubernetes.io/name=ankra-agent -f ``` *** ## Configuration Reference ### Required Settings | Parameter | Description | | ------------------ | ----------------------------------------------------- | | `config.token` | Authentication token (provided during cluster import) | | `config.ankra_url` | Platform URL (default: `https://platform.ankra.app`) | ### Using an Existing Secret For production environments, store the token in a Kubernetes secret: ```bash theme={null} kubectl create secret generic ankra-agent-secret \ --namespace ankra \ --from-literal=token=YOUR_UNIQUE_TOKEN ``` Then reference it in your Helm install: ```bash theme={null} helm upgrade --install ankra-agent oci://ghcr.io/ankraio/ankra-agent/ankra-agent \ --namespace ankra \ --set config.existing_secret_name=ankra-agent-secret \ --set config.secret_key=token ``` ### Performance Tuning For large clusters (1000+ resources), adjust these settings: | Parameter | Default | Description | | --------------------------- | ------- | ------------------------------------------------------------- | | `nats_worker_max_workers` | `15` | Worker threads for command processing | | `read_worker_count` | `5` | Concurrent worker slots for read jobs | | `write_worker_count` | `5` | Concurrent worker slots for write jobs (create/update/delete) | | `resources.limits.memory` | `512Mi` | Memory limit | | `resources.requests.memory` | `256Mi` | Memory request | | `replica_count` | `1` | Number of agent replicas | Example for large clusters: ```bash theme={null} helm upgrade --install ankra-agent oci://ghcr.io/ankraio/ankra-agent/ankra-agent \ --namespace ankra \ --set config.token="YOUR_TOKEN" \ --set nats_worker_max_workers=25 \ --set resources.limits.memory=1Gi \ --set resources.requests.memory=512Mi ``` ### Fleet world map (public IP reporting) To place an imported cluster on the [Dashboard](/platform/dashboard) world map when it has no recognisable cloud region, let the agent report its public egress IP on check-in: ```bash theme={null} helm upgrade --install ankra-agent oci://ghcr.io/ankraio/ankra-agent/ankra-agent \ --namespace ankra \ --set config.token="YOUR_TOKEN" \ --set public_ip.reporting_enabled=true ``` When enabled, the agent performs an outbound HTTP lookup (to `public_ip.lookup_url`, default `https://api.ipify.org`) and reports the result. Leave it **disabled** (the default) for air-gapped clusters or where egress IP lookups are undesirable. ### All Helm Values The complete value list - connection, workers, watch tuning, public IP reporting, image, security contexts, scheduling, and metrics - lives in the [Agent Helm Values reference](/reference/agent-helm-values). The agent runs as a **non-root** container by default (`runAsNonRoot: true`, UID/GID `1000`, `readOnlyRootFilesystem: true`, all Linux capabilities dropped, `seccompProfile: RuntimeDefault`). Because the root filesystem is read-only, the chart mounts writable `emptyDir` volumes for `/tmp`, `~/.cache`, and `~/.config` via `writable_volumes.enabled` (default `true`). Don't lower these security settings unless you are running a custom image. ### Advanced tuning via `extra_env` Less-common knobs are set as environment variables through `extra_env`: | Env var | Default | Description | | --------------------------------------------- | ------- | ------------------------------------------------------------------------------- | | `KUBERNETES_HTTP2_ENABLED` | `false` | Enable HTTP/2 to the API server (only if the path supports it cleanly) | | `KUBERNETES_REQUEST_MAX_ATTEMPTS` | `3` | List/get retry attempts on connection-terminated errors | | `KUBE_PROXY_UNARY_CONCURRENCY` | `64` | Max concurrent unary requests through the kubectl proxy | | `KUBE_PROXY_STREAM_CONCURRENCY` | `128` | Max concurrent streaming connections (watch/logs/exec) through the proxy | | `DYNAMIC_API_DISCOVERY_ENABLED` | `false` | Discover and watch additional API groups dynamically | | `RECONCILE_AUTO_HEAL_ENABLED` | `true` | Auto-heal native-engine releases stuck mid-operation | | `FORWARD_SERVICE_REQUEST_MAX_TIMEOUT_SECONDS` | `120` | Upper bound for platform-requested forwarded-request timeouts (e.g. Prometheus) | ```yaml theme={null} extra_env: - name: KUBERNETES_REQUEST_MAX_ATTEMPTS value: "5" ``` *** ## Architecture The agent uses a NATS-based architecture for real-time communication: ```mermaid theme={null} flowchart TB Portal[Ankra Portal] <-->|HTTPS| Platform[Ankra Platform] Platform <-->|NATS JetStream| Agent[Ankra Agent] Agent <-->|Kubernetes API| Cluster[Your Cluster] ``` **Key features:** * **Outbound connections only** - The agent initiates all connections, no inbound ports required * **Real-time streaming** - Resource data streams efficiently using pagination * **Automatic reconnection** - Handles network interruptions gracefully * **kubectl proxy** - Forwards authenticated `kubectl` requests (including `watch`, `logs -f`, and `exec`) from the platform to the cluster API server, so you can reach private clusters without inbound access. See [Accessing Clusters with kubectl](/guides/kubeconfig). * **Health monitoring** - Exposes `/livez` and `/readyz` endpoints on port 8080 *** ## Network Requirements The agent requires outbound connectivity to: | Endpoint | Port | Purpose | | -------------------- | ---- | ------------------------ | | `platform.ankra.app` | 443 | API communication | | `connect.ngs.global` | 4222 | NATS real-time streaming | No inbound ports need to be opened on your cluster. *** ## Upgrading the Agent New agent releases are published on the `2.0.x` version track. The platform rolls the fleet forward automatically to the latest published version, a few clusters at a time, so most clusters stay current without any action. You can still trigger an upgrade yourself at any time. ### From the Platform Click **Upgrade Agent** in the cluster settings. The agent will self-upgrade using Helm. ### Manually ```bash theme={null} helm upgrade ankra-agent oci://ghcr.io/ankraio/ankra-agent/ankra-agent \ --namespace ankra \ --reuse-values ``` Check the current agent version: ```bash theme={null} kubectl get deployment -n ankra ankra-agent -o jsonpath='{.spec.template.spec.containers[0].image}' ``` *** ## Troubleshooting ### Agent Not Connecting 1. **Check agent pods are running:** ```bash theme={null} kubectl get pods -n ankra ``` 2. **View agent logs:** ```bash theme={null} kubectl logs -n ankra -l app.kubernetes.io/name=ankra-agent --tail=100 ``` 3. **Verify network connectivity:** ```bash theme={null} kubectl run --rm -it --restart=Never debug --image=curlimages/curl -- \ curl -s https://platform.ankra.app/health ``` 4. **Check the token is set:** ```bash theme={null} kubectl get secret -n ankra ankra-agent -o jsonpath='{.data.token}' | base64 -d ``` ### Common Issues | Issue | Cause | Solution | | --------------------- | ------------------------------------ | ---------------------------------------------------------------------------------------- | | Cluster shows Offline | Agent not running or network blocked | Check pods and firewall rules | | Token invalid | Token expired or revoked | Go to Clusters → Your Cluster → Settings → Generate Command to get a new install command | | Connection refused | Outbound network blocked | Allow connections to `platform.ankra.app:443` | | Resources not loading | Agent memory limits too low | Increase `resources.limits.memory` | ### Health Checks The agent exposes health endpoints: ```bash theme={null} kubectl port-forward -n ankra svc/ankra-agent 8080:8080 curl http://localhost:8080/livez curl http://localhost:8080/readyz ``` *** ## Uninstalling To remove the agent from your cluster: ```bash theme={null} helm uninstall ankra-agent -n ankra kubectl delete namespace ankra ``` Uninstalling the agent will disconnect your cluster from Ankra. You'll need to re-import it to reconnect. *** ## Security ### RBAC Requirements The agent requires cluster-admin permissions to: * Browse all Kubernetes resources * Deploy Helm charts and manifests * Manage add-ons via the native Helm engine or ArgoCD * Stream pod logs and proxy authenticated `kubectl` requests The Helm chart creates a `ClusterRoleBinding` with the necessary permissions. ### Token Security * Tokens are unique per cluster * Tokens can be revoked by deleting the cluster from Ankra * Store tokens in Kubernetes secrets (not in Helm values) for production # Cluster States Source: https://docs.ankra.ai/concepts/cluster-states Understanding Ankra Kubernetes Cluster States ## What Are Cluster States? Cluster states in Ankra indicate whether the Ankra Agent running in your Kubernetes cluster is currently connected to the Ankra platform. This provides a simple, reliable signal of your cluster's availability for management and monitoring. Ankra supports two cluster states: * **Online:** The Ankra Agent in your cluster is connected to the Ankra platform. This means your cluster is reachable, healthy, and ready for management operations. * **Offline:** The Ankra Agent is not connected to the Ankra platform. This usually means your cluster is unreachable-possibly due to network issues, cluster shutdown, or maintenance. *** ## Cluster States Cluster is reachable and healthy.
  • Ankra Agent is connected to the platform.
  • Kubernetes API is accessible via the agent.
  • Ready for deployments, monitoring, and management operations.
  • All platform features are available.
 Cluster is not reachable.
  • Ankra Agent is disconnected from the platform.
  • May be due to network issues, cluster shutdown, or maintenance.
  • Cannot deploy stacks or view live resources.
  • Historical data and configuration remain available.
 *** ## Why Do Cluster States Matter? Instantly see which clusters are connected and available for management across your entire infrastructure. When online, deploy stacks, browse Kubernetes resources, view logs, and manage add-ons. Offline clusters preserve configuration but cannot be actively managed. Quickly identify connectivity issues. An offline state often indicates network problems, agent issues, or cluster maintenance. Use cluster states with alerts to get notified when clusters go offline unexpectedly. *** ## Viewing Cluster State You can view the current state of any cluster: 1. **Clusters List:** The main Clusters page shows Online/Offline status for all clusters 2. **Cluster Dashboard:** The cluster overview page displays connection status 3. **API:** Query cluster state programmatically via the Ankra API 4. **Alerts:** Configure alerts to notify you when clusters go offline *** ## Troubleshooting Offline Clusters If a cluster shows as **Offline**, check the following: Ensure the Kubernetes cluster is running and accessible. Try connecting with `kubectl` from your local machine. Verify the Ankra Agent pod is running in your cluster: ```bash theme={null} kubectl get pods -n ankra-system ``` Review agent logs for connection errors: ```bash theme={null} kubectl logs -n ankra-system -l app=ankra-agent ``` Ensure the agent can reach the Ankra platform. Check firewall rules and network policies that might block outbound connections. If running an older agent version, upgrade to the latest: * Go to cluster settings in Ankra * Click **Upgrade Agent** if an update is available *** ## Agent Connection The Ankra Agent maintains a persistent connection to the platform: * **Heartbeat:** The agent sends regular heartbeats to confirm connectivity * **Reconnection:** If connection is lost, the agent automatically attempts to reconnect * **Graceful Handling:** Temporary network issues don't immediately mark the cluster offline The agent uses outbound connections only, so no inbound firewall rules are required. It connects to `platform.ankra.app` on standard HTTPS ports. *** Still have questions? [Join our Slack community](https://join.slack.com/t/ankra-community/shared_invite/zt-3a5rem8f8-cUho4epX2MoLT83bFf~VSA) and we'll help out. # Deployment Engines Source: https://docs.ankra.ai/concepts/deployment-engines How Ankra deploys and reconciles addons on your clusters. ## Overview Ankra supports two deployment engines for managing addons on your clusters: * **Native (`ankra_native`)**: The Ankra agent uses the Helm CLI directly to install, upgrade, and reconcile chart-based addons. Releases are written to standard Helm storage (`helm.sh/release.v1` Secrets). * **ArgoCD (`argo_cd`)**: The Ankra agent talks to an ArgoCD installation in the cluster, which renders the chart and applies it via server-side apply. The engine is set per-addon, with a cluster-level default. New clusters created after the May 2026 release default to `ankra_native`. Existing clusters keep `argo_cd` until you opt in to migrate. ## Why migrate? The native engine reduces the dependency surface on your cluster: * No `argocd-server`, `argocd-application-controller`, `argocd-repo-server`, `argocd-redis`, `argocd-applicationset-controller`, `argocd-notifications-controller`, or `argocd-dex-server` (\~7 pods, 500-800 MB RAM reclaimed). * No JWT lifecycle. The agent's existing ServiceAccount is the only auth. * No NATS-proxied API round-trip for reading addon status; the agent pushes drift state to the control plane directly. You can also `helm list`, `helm history`, `helm rollback`, and `helm get manifest` directly against your cluster - first-class debuggability. ## Feature parity | Feature | ArgoCD | Native | | ------------------------------------------------------------------------------ | ----------------------------------- | ----------------------------------------------- | | Self-heal on drift | Yes | Yes (per-addon `sync_policy.self_heal`) | | Prune orphaned resources | Yes | Yes (`auto_prune` + post-apply orphan sweep) | | `ignoreDifferences` (jsonPointers / jqPathExpressions / managedFieldsManagers) | Yes | Yes | | Sync windows | Yes | Yes (cron-style schedule + duration + timezone) | | Custom retry policy | Yes | Yes | | `strict_health_check` | Yes (Healthy only, not Progressing) | Yes (Healthy only, not Progressing) | | `revision_history_limit` | Yes | Yes (`--history-max`) | | SOPS-encrypted values | Yes (helm-secrets) | Yes (direct `sops --decrypt`) | | GitHub repos | Yes | Yes (HTTPS Contents API) | | Bitbucket Cloud repos | Yes | Yes (HTTPS `2.0` Contents API, OAuth refresh) | | Bitbucket DC repos | Yes | Yes (HTTPS `1.0` raw API) | | GHCR via git token fallback | Yes | Yes | | Multi-source applications | Yes | Not yet (single-source only) | | ApplicationSet | Yes | Not used | ## Reconcile loop The native engine runs a periodic reconcile sweep on the agent. The platform schedules a `reconcile_native_releases` step every 60 seconds per cluster (via the `reconcile_addons` maintenance loop). Each sweep: 1. Recovers any release stuck in `pending-*` for more than 10 minutes: first attempts a fresh `helm upgrade --install --atomic`; if that fails, rolls back to the last `deployed` revision. 2. Detects drift against `helm get manifest` (live resources fetched in parallel; Helm-injected metadata stripped from both sides before diff). 3. If drift is detected and `sync_policy.self_heal=true`, marks the addon for update so the existing reconciler re-runs `helm upgrade --install`. 4. If `sync_policy.auto_prune=true`, deletes orphaned resources whose UID is no longer in the rendered manifest. 5. Publishes a NATS heartbeat to `agent.heartbeat.native_reconcile.{cluster_id}` with `last_sweep_at`, `sweep_duration_seconds`, and `addons_inspected`. The platform consumes those heartbeats and exposes `ankra_native_engine_reconcile_loop_lag_seconds{cluster_id}` for alerting. ## Sync windows Set `settings.sync_window.enabled=true` on the addon and provide a 5-field cron expression and duration. The agent will only run `create`/`update`/`self-heal` operations inside the configured window. Outside the window, jobs return immediately as `cancelled` with an "outside\_sync\_window" task message. ## Moving an add-on between namespaces The native engine supports relocating an add-on to a different namespace. When you change an add-on's target namespace, the agent installs the release into the new namespace and cleans up the resources left behind in the old one, so you don't end up with orphaned objects. As with any namespaced move, persistent data tied to the old namespace (for example, `PersistentVolumeClaim`s) is not automatically carried over - plan for data migration where relevant. ## Migration When ready to migrate an existing cluster: 1. Open the cluster's settings page in the portal. 2. Click **Migrate to native engine**. 3. Review the per-addon eligibility report. The preview surfaces: * **CRD coverage** - addons whose live resources include kinds the native engine does not yet have a health rule for are flagged. * **In-flight ArgoCD sync** - blocks migration until the sync settles. * **Single-source check** - multi-source `Application`s are not yet migratable. 4. Confirm; the migration runs per-addon, in parallel up to a small concurrency limit, and is resumable across control-plane restarts. Each per-addon migration uses `helm upgrade --install --take-ownership` to adopt the live resources into Helm storage. Resource UIDs do not change; no Pod is recreated; the only on-cluster mutation is to add Helm's `app.kubernetes.io/managed-by=Helm` label and the `meta.helm.sh/release-name` / `meta.helm.sh/release-namespace` annotations. The `Application` CR is deleted only after the helm release verifies as `deployed`. Per-addon rollback (back to ArgoCD) is supported until you explicitly decommission ArgoCD on the cluster. ## Decommissioning ArgoCD Once a cluster has zero remaining ArgoCD-managed addons, a **Decommission ArgoCD** button appears in the cluster settings. The decommission flow: * Migrates any remaining addons to the native engine and verifies they are healthy. * Clears the Ankra-managed ArgoCD user credentials and session token stored on the platform and forgets the `argo_user` resource. * Leaves the ArgoCD installation itself, the `argo_cd` resource, and any ArgoCD `Application` CRs you own untouched. This deliberately stops short of uninstalling ArgoCD: many teams continue to use the same ArgoCD instance outside of Ankra (for application delivery, GitOps of bespoke workloads, etc.). If you no longer need ArgoCD on the cluster, uninstall it yourself with the same tooling you originally used to install it (`kubectl delete -f install.yaml`, `helm uninstall argocd`, or the upstream `argocd uninstall` command), and clean up the leftover `accounts.ankra` / `policy.csv` entries from the `argocd-cm` and `argocd-rbac-cm` ConfigMaps if you keep the ArgoCD installation running. The migration of addons is **one-way**: changing the cluster default deployment engine back to ArgoCD after decommission is not supported. # GitOps Source: https://docs.ankra.ai/concepts/gitops Manage your clusters with GitOps using YAML files and include paths Ankra makes it easy to manage clusters using GitOps. Define your cluster's configuration, manifests, and add-ons in YAML files, store them in Git, and let Ankra handle the automation. *** ## What is GitOps? GitOps is a way to manage your Kubernetes infrastructure using Git as the single source of truth. With Ankra: * **Store configuration in Git** - Your cluster definitions, manifests, and add-ons live in your repository * **Automatic sync** - Ankra detects changes and applies them to your clusters * **Version control** - Track every change, roll back when needed, review via pull requests * **Team collaboration** - Multiple team members can update configurations safely *** ## How It Works Ankra uses **include paths** to let you split your configuration into multiple files or folders. This keeps your setup modular, maintainable, and easy to scale. *** ## Why Use Include Paths? Keep manifests and add-ons in separate files or folders for easy automation in your CI/CD pipelines. Update only what you need, and trigger deployments automatically. Organize resources by team, environment, or feature. Reuse the same manifests or add-ons across different stacks or clusters. Let different teams own and update their own YAML files without merge conflicts. Everyone works from the same Git repository. Easily add new resources or stacks by dropping new YAML files into the right folder - no need to edit a giant config file. *** ## Repository Structure Organize your Git repository with separate folders for manifests and add-ons: ``` my-repo/ manifests/ namespace.yaml namespace.AGENTS.md rbac.yaml addons/ ingress.yaml ingress.AGENTS.md monitoring.yaml import-cluster.yaml ``` The optional `AGENTS.md` sibling files hold per-manifest and per-add-on operational learnings for your team and Ankra's AI - see [Teach Your Agents with AGENTS.md](/platform/agents-md). *** ## Cluster Definition Example Your `import-cluster.yaml` references files using `include` paths: ```yaml theme={null} apiVersion: v1 kind: ImportCluster metadata: name: my-cluster spec: git_repository: provider: github credential_name: my-credential branch: main repository: my-org/my-repo stacks: - name: platform-stack manifests: - include: manifests/ addons: - include: addons/ ``` Ankra will automatically load and apply all YAML files from the `manifests/` and `addons/` folders. You can also include individual files for more control: ```yaml theme={null} manifests: - include: manifests/namespace.yaml - include: manifests/rbac.yaml ``` *** ## Single-File Cluster Definition For small or self-contained setups you can skip include paths and define everything inline in one file. Manifest and values content is embedded as base64: ```yaml theme={null} apiVersion: v1 kind: ImportCluster metadata: name: my-cluster description: Imported cluster with an inline stack spec: git_repository: provider: github credential_name: my-git-credential branch: main repository: my-org/my-gitops-repo stacks: - name: secrets manifests: - name: secrets-namespace manifest_base64: namespace: secrets parents: [] addons: - name: external-secrets chart_name: external-secrets chart_version: 0.10.5 registry_name: external-secrets registry_url: https://charts.external-secrets.io namespace: secrets configuration_type: standalone configuration: values_base64: parents: - name: secrets-namespace kind: manifest ``` Use `parents` to control deployment order - a resource only deploys after its parents succeed. Prefer include paths once a cluster definition grows beyond a couple of resources. Every field of this file - stacks, manifests, add-ons, applications, parents, and encrypted paths - is documented in the [ImportCluster YAML Schema](/reference/importcluster). *** ## How Ankra Syncs Your Cluster 1. You update or add YAML files in your Git repository 2. Ankra detects the change and automatically syncs your cluster 3. All included manifests and add-ons are applied in the order you specify ```mermaid theme={null} flowchart LR A[Git Push] --> B[Ankra Detects Change] B --> C[Parse Include Paths] C --> D[Apply Manifests] D --> E[Deploy Add-ons] E --> F[Cluster Updated] ``` *** ## Monitoring Sync Status Track the status of your GitOps syncs in the cluster settings. ### Sync Status Banner Navigate to your cluster → **Settings** → **GitOps** to see the current sync status: | Status | Description | | ------------------ | ----------------------------------------------------- | | **Synced** | All configurations are up-to-date with the repository | | **Syncing** | A sync is currently in progress | | **Error** | The last sync failed. Check error details below | | **Not Configured** | GitOps is not yet connected to a repository | ### Sync Progress During a sync, you'll see the progress through these phases: 1. **Fetching** - Pulling latest changes from Git 2. **Validating** - Checking YAML syntax and configuration 3. **Applying** - Deploying changes to the cluster 4. **Completed** - Sync finished successfully ### Manual Sync Click **Sync Now** to trigger an immediate sync from your Git repository. Use this when: * You want to apply changes without waiting for automatic detection * Webhook delivery failed * You need to force a refresh *** ## Sync History View a complete history of all GitOps syncs for your cluster. ### Accessing Sync History 1. Go to your cluster → **Settings** → **GitOps** 2. Scroll down to the **Sync History** table ### History Table Features The sync history table shows: | Column | Description | | ---------------- | ------------------------------------------------ | | **Status** | Success, Failed, or Running badge | | **Source** | How the sync was triggered (webhook or manual) | | **Commit** | The Git commit SHA with a link to view in GitHub | | **Started** | When the sync began (relative timestamp) | | **Triggered By** | Who or what initiated the sync | **Table Features:** * **Pagination**: Navigate through history (10 entries per page) * **Sorting**: Click column headers to sort by any field * **Commit Links**: Click the SHA to view the commit in GitHub ### Sync Metadata Each sync entry includes detailed metadata: * **Last Commit SHA**: The exact commit that was synced * **Sync Source**: `webhook` (automatic) or `manual` * **Timestamp**: When the sync occurred * **Retry Count**: Number of retry attempts (if any) * **IAC Files Link**: Direct link to view the configuration files in your repository *** ## Handling Sync Errors When a sync fails, Ankra provides detailed error information to help you fix issues quickly. ### Error Display Failed syncs show: * **Validation Errors**: Issues with YAML syntax or configuration * **Field-Level Guidance**: Specific fields that need attention * **Missing Fields**: Required fields that weren't provided * **Typo Detection**: Suggestions for misspelled field names ### Common Error Types YAML syntax issues or invalid configuration values. **Solution**: Check the error details for the specific field and fix the YAML in your repository. Required configuration fields weren't provided. **Solution**: The error shows which fields are missing with examples of expected values. A resource already exists or conflicts with another definition. **Solution**: Check for duplicate resource names or conflicting configurations. ### Retrying Failed Syncs 1. Fix the issues in your Git repository 2. Commit and push the changes 3. Click **Sync Now** or wait for automatic detection 4. Monitor the new sync in the history table *** ## Best Practices **Keep related resources together.** Group manifests and add-ons by environment, team, or feature. **Use clear folder names.** Make it obvious what each folder contains (e.g., `manifests/`, `addons/`, `prod/`, `dev/`). **Automate with CI/CD.** Trigger Ankra syncs on pull requests or merges to main. **Review changes in Git.** Use pull requests to review and approve updates to your cluster configuration. *** ## Troubleshooting If Ankra isn't syncing as expected: | Issue | Solution | | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sync not triggering | Check that Git credentials are valid and have repo access | | Files not found | Verify all `include` paths exist in the repository | | Invalid configuration | Ensure YAML files are syntactically correct | | Wrong branch | Confirm the branch name in your cluster definition matches | | Unsure which repository a cluster deploys from | Run `ankra cluster gitops status --cluster `. It reports the configured repository and branch, and `observed_source` - the repository the last successful sync actually read. If they disagree, `source_mismatch` is `true` | Use the Ankra WebUI to see sync status and any errors. The Operations page shows deployment history and helps identify issues. *** ## Global Helm Registries Ankra comes with a curated index of preloaded Helm charts that are ready to use out of the box. These registries power the add-on catalog in the Ankra platform. Want to add a Helm chart that would benefit the entire Ankra community? Submit a pull request to the **ankra-global-resources** repository. Your contribution will be available to all Ankra users. The [ankra-global-resources](https://github.com/ankraio/ankra-global-resources) repository contains: * **Helm Registries** - Preloaded chart repositories that appear in the Ankra add-on index * **Global Resources** - Platform-wide resource definitions ### Contributing a Helm Registry 1. Fork the [ankra-global-resources](https://github.com/ankraio/ankra-global-resources) repository 2. Add your Helm registry definition to the `helm_registries/` folder 3. Submit a pull request with a description of the charts and their use cases 4. Once merged, your charts will be available to all Ankra users When contributing, ensure the Helm charts are well-maintained, secure, and provide value to the broader Kubernetes community. *** ## Related * [Stacks](/concepts/stacks) - Learn about organizing resources into stacks * [Add-ons](/concepts/addons) - Install Helm charts as add-ons * [Manifests](/concepts/manifests) - Deploy raw Kubernetes manifests *** Still have questions? [Join our Slack community](https://join.slack.com/t/ankra-community/shared_invite/zt-3a5rem8f8-cUho4epX2MoLT83bFf~VSA) and we'll help out. # Manifests Source: https://docs.ankra.ai/concepts/manifests Use Kubernetes manifests to customize and automate your cluster setup in Ankra. Manifests are the foundation for customizing your Kubernetes clusters in Ankra. They allow you to define, automate, and standardize resources and configurations across all your environments. ## What is a Manifest? A **manifest** is a YAML file that describes Kubernetes resources such as namespaces, ConfigMaps, CRDs, RBAC rules, deployments, and more. Manifests are declarative: you specify the desired state, and Kubernetes makes sure your cluster matches it. *** ## Why Use Manifests in Ankra? Automatically create all the resources you need (namespaces, roles, CRDs, and more) as part of cluster setup or stack deployment. Use the same manifest on multiple clusters to make sure every environment is set up the same way. Use manifests to set up things like CRDs or service accounts before installing add-ons, so everything works smoothly. Keep manifests in your repository to track changes, roll back if needed, and support GitOps workflows. *** ## Creating Manifests Manifests in Ankra are created within **Stacks**. This ensures your manifests are bundled with related add-ons and can be deployed as a cohesive unit. Go to the **Stacks** section in your cluster and click **Create Stack** (or edit an existing stack). In the Stack Builder, click **Add** and select **Manifest**. You can:
  • Write your manifest YAML directly in the editor
  • Use the AI Assistant (`⌘+J`) to get manifest recommendations by describing what you need
 Arrange the order of resources if some depend on others. For example, ensure namespaces are created before deployments that use them. Save your stack and deploy it to apply the manifests to your cluster. Monitor the deployment in the **Operations** section. Use the AI Assistant to get recommendations for common manifests like namespaces, RBAC rules, ConfigMaps, and Secrets. Just press `⌘+J` and describe what you need, then copy the suggested YAML into your manifest. *** ## Example Manifest ```yaml theme={null} apiVersion: v1 kind: Namespace metadata: name: monitoring --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: monitoring name: monitoring-reader rules: - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list"] ``` *** ## Encrypting Secrets with SOPS When your manifests contain sensitive data like passwords, API keys, or credentials, use **SOPS** to encrypt them before storing in your GitOps repository. Edit a manifest within your stack by clicking on it in the Stack Builder. In the manifest edit view, click the **SOPS** button in the toolbar to enable encryption for this manifest. SOPS will encrypt the sensitive values (like `data` fields in Secrets) while keeping keys readable for easier Git diffs. Save your manifest. The encrypted values will be stored safely in your GitOps repository and decrypted automatically when deployed. SOPS encryption requires initial setup. See [SOPS Encryption](/guides/sops) for configuration instructions. *** ## Operational Learnings with AGENTS.md Every manifest can carry an **AGENTS.md** - a markdown document of operational learnings (upgrade gotchas, safe rollout order, fields that must stay pinned) that teammates and Ankra's AI build up over time. Edit it from the **AGENTS.md** tab on the manifest in the Stack Builder; editing it never triggers a redeploy. See [Teach Your Agents with AGENTS.md](/platform/agents-md). *** Manifests are a powerful way to automate, standardize, and scale your Kubernetes operations with Ankra. [Learn more about Stacks →](/concepts/stacks) *** ## Explore the Manifests API Want to automate manifest management or integrate with your CI/CD workflows? Check out the [API Reference](/api-reference/introduction) for endpoints to create, update, and apply manifests programmatically. # Organisations & User Management Source: https://docs.ankra.ai/concepts/organisations Manage your organisations, invite users, and control access in Ankra. Organisations in Ankra help you manage access, resources, and collaboration for your team. You can invite users, assign roles, and switch between organisations to keep your workspaces organized. ## Accessing Your Organisation Open your current organisation directly from anywhere in Ankra. 1. Click your profile icon in the menu at the bottom left of the Ankra platform. 2. Select **Organisation**. 3. You land straight on your current organisation's overview — members, stats, roles, audit log, billing, and settings are in the sidebar. ## Switching Organisations Switch between organisations to see the resources, stacks, and credentials for each one. * In the profile menu, hover **Switch organisation** to see every organisation you belong to. Your current organisation is marked with a check — click any other one to switch to it. * **All organisations** in that submenu opens the full list, including pending invitations, with a switch button per organisation. * You can also switch from the command palette with the **Switch Organisation** command. * When you switch, your active session updates to reference that organisation. You’ll see only the stacks, clusters, and credentials for the selected organisation. ## Inviting Users Invite teammates to your organisation by email and assign their role. * To add people, click **Add User** in the organisation view. * Enter the user’s email address to send an invitation. * You can assign one of two roles: * **Admin:** Can invite and remove users, and manage all organisation settings. * **Member:** Can use the platform but cannot invite others. ## Managing Users & Roles Control who has access to your organisation and what they can do. * **Admins** can invite new users, remove any user, and manage organisation settings. * **Members** can remove themselves from the organisation but cannot remove others or invite new users. * To remove a user, use the menu next to their name in the user list. ## Organisation Variables Define variables at the organisation level to share configuration values across all clusters and stacks. 1. Go to your organisation's **Settings** page 2. Click **Variables** in the settings menu 3. Add variables that apply organisation-wide Organisation variables are inherited by all clusters and stacks but can be overridden at the cluster or stack level for environment-specific values. [Learn more about Variables →](/concepts/variables) *** ## Best Practices Tips for keeping your organisations secure and well managed. * Use organisations to separate projects, teams, or environments. * Assign admin rights only to trusted team members. * Regularly review your organisation's user list to keep access up to date. * Define shared configuration as organisation variables to avoid duplication. *** > **Tip:** Switching organisations changes your view to only the resources, stacks, and credentials for that organisation. This helps keep your work organized and secure. *** # Stack Profiles Source: https://docs.ankra.ai/concepts/stack-profiles Capture a working stack as a reusable, versioned, parameterised template - then roll it out to any cluster. A Stack Profile is a reusable template captured from a real [stack](/concepts/stacks). Build a stack once, save it as a profile, and instantiate it on any cluster - with parameters filled in per environment. Profiles are versioned, so you can publish updates, diff versions, and see which deployments have drifted behind the latest. A profile is a **template**, not a running deployment. Instantiating a profile produces a stack draft on a target cluster, which you then review and commit like any other stack change. *** ## Why use profiles * **Standardise** a golden stack (monitoring, ingress, security baseline) and reuse it across clusters. * **Parameterise** the bits that differ per environment - domains, replica counts, sizes - instead of copy-pasting YAML. * **Version** changes with a changelog and channels, and **diff** any two versions. * **Track drift**: a profile shows how many instantiations are behind its latest version. *** ## Anatomy of a profile | Concept | Description | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Version** | An immutable snapshot of the stack spec. Versions increment as you publish updates and carry a `channel` (e.g. `stable`) and an optional changelog. | | **Parameters** | Typed inputs callers fill in at instantiation. Each parameter has a `type` (`string`, `number`, `boolean`, `enum`, or `secret`), and may be `required`, have a `default`, an `enum` list, or a validation `pattern`. | | **Visibility** | `organisation` (default) keeps the profile private to your org; `public` shares it more widely. Independently of visibility, a profile can be [shared with specific organisations](#share-with-specific-organisations). | | **Category & tags** | Metadata for organising and searching profiles. | | **Publisher** | The organisation that owns the profile. Publisher names, logos, and verified badges help you identify trusted profiles. Verified Ankra profiles appear first in profile results. | | **Drafts** | An editable working copy used to build or edit a profile before publishing a version. | Secret-typed parameters and other sensitive values are redacted when a profile is captured, so credentials are never baked into a shared template. *** ## Create a profile You can create a profile two ways: Capture a profile directly from a stack already running on a cluster. Optionally include addon configurations. This is the fastest path - build and validate the stack first, then snapshot it. Import a profile from exported IaC content, for sharing across organisations or storing in Git. In the portal, **Save as Profile** starts with the stack's existing name and description. Categories combine common options with values your organisation already uses, and tags are suggested as you type. Choose who can use the profile before saving: * **This organisation** keeps it private to members of your organisation. * **Public** makes it available to every organisation. * **Specific organisations** keeps it private and grants access to the organisation slugs you enter. Public and specific-organisation sharing require an organisation admin. Quick save publishes immediately. Save and customise opens the profile builder so you can review inputs before publishing. ```bash theme={null} # Capture from a cluster's stack POST /org/stack-profiles { "name": "platform-baseline", "description": "Shared platform services", "category": "platform", "tags": ["baseline", "production"], "visibility": "organisation", "share_organisation_slugs": ["partner-org"], "source_cluster_id": "...", "stack_name": "platform", "include_addon_configurations": true } ``` Organisation admins can upload a publisher logo under **Organisation Settings**. Profile cards fall back to the organisation's initials when no logo is configured. ### Build with drafts For more control, work in a draft: create a draft (optionally seeded from a cluster's stack), edit its spec and parameters, validate it, then publish it as a new version. `POST /org/stack-profiles/drafts` - optionally seeded from an existing profile or a source cluster stack. Update the draft's spec and parameters, then `POST /org/stack-profiles/drafts/{draft_id}/validate` to surface any issues before publishing. `POST /org/stack-profiles/drafts/{draft_id}/publish` with a channel and changelog. This creates the profile (or a new version of it). *** ## Instantiate a profile Instantiating turns a profile into a stack on a target cluster: Pick the profile and, optionally, a specific version. When no version is given, the profile's **current** version is used - the pinned version, which can be older than latest after a rollback. Supply values for the profile's parameters. Required parameters must be set; others fall back to their defaults. Instantiation creates a stack draft on the cluster (with the resolved addons and manifests). Review it. Commit the draft to deploy, exactly like any other [stack](/concepts/stacks) change. ### From the CLI The [Ankra CLI](/integrations/ankra-cli) can instantiate a profile directly. Inspect a profile's parameters first, then apply it to a cluster as a draft (or pass `--deploy` to deploy in one step): ```bash theme={null} # See the profile's versions and parameters ankra stack-profiles get # Create a draft on a cluster, binding parameters ankra stack-profiles apply --cluster production \ --set replicas=3 \ --set-env api_token=MONITORING_API_TOKEN # Or apply a specific version and deploy immediately ankra stack-profiles apply --cluster production --version 3 --deploy ``` For **secret** parameters use `--set-file ` or `--set-env ` rather than `--set` so the value never appears in your shell history or process list. *** ## Demo a profile before you deploy it Instantiating a profile puts it on a real cluster. When you only want to see what it deploys - to review a new version, to check a public profile before adopting it, or to show someone the stack running - launch it as a **demo** instead. A demo installs the profile into its own throwaway namespace on your organisation's staging cluster, quota-bounded and on a timer, and deletes itself when the timer runs out. Open the profile's **Demos** tab to launch one. See [Stack Profile Demos](/guides/stack-profile-demos). *** ## Share with specific organisations Making a profile `public` exposes it to everyone. When you want to share a golden stack with one partner, customer, or sibling organisation - and nobody else - share it directly instead: * Shared organisations can **list, view, diff, export, and instantiate** every version of the profile. They cannot edit, delete, or re-share it. * The profile keeps its `organisation` visibility; sharing is an explicit per-organisation grant. * The target organisation is identified by its **organisation slug** (found under organisation settings). Ask the other organisation for theirs. * Only **organisation admins** can grant or revoke shares, and a grant re-runs the plaintext-secret scan over every published version - a profile that still carries plaintext secrets cannot be shared. Grants and revokes are recorded in the audit log. * Revoking a share hides the profile from the other organisation again. Stacks they already deployed from it keep running - they just stop seeing profile updates. In the portal, open a profile you own and use **Share**. Via the API: ```bash theme={null} # Grant an organisation access POST /org/stack-profiles/{profile_id}/shares { "organisation_slug": "acme-corp" } # List grants / revoke one GET /org/stack-profiles/{profile_id}/shares DELETE /org/stack-profiles/{profile_id}/shares/{share_id} ``` Profiles shared **with** your organisation show up in your profile list marked "Shared with you". *** ## Versioning, diffing, and updates * **Save a new version** from an updated source stack, or by publishing an edited draft. * **Diff** any two versions to see what changed: `GET /org/stack-profiles/{profile_id}/diff?from_version=1&to_version=2`. * **Diff a draft** before publishing it, against the version it was opened from: `GET /org/stack-profiles/drafts/{draft_id}/diff`. The draft is redacted first, so the comparison shows what publishing would actually store rather than your working copy. A draft that will create a brand-new profile has no base, so everything in it reads as added. * **Update tracking**: a profile reports `outdated_instantiation_count` and `has_update_available` so you can find deployments that are behind and re-instantiate them on the newer version. * **Export IaC** for a version to store the template in Git or move it between organisations. *** ## API All endpoints are under `/org/stack-profiles` and require authentication; write operations require a CSRF header for browser-originated requests. | Method | Path | Purpose | | --------------------- | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | `GET` | `/org/stack-profiles` | List profiles (paginated) | | `POST` | `/org/stack-profiles` | Create a profile from a cluster's stack, with optional visibility and organisation shares | | `GET` | `/org/stack-profiles/metadata-suggestions` | List categories and tags already used by your organisation | | `POST` | `/org/stack-profiles/import` | Import a profile from IaC content | | `GET` | `/org/stack-profiles/{profile_id}` | Profile detail, versions, and update status | | `PATCH` | `/org/stack-profiles/{profile_id}` | Update metadata (name, description, category, tags, visibility; making a profile public requires the org admin role) | | `DELETE` | `/org/stack-profiles/{profile_id}` | Delete a profile | | `POST` | `/org/stack-profiles/{profile_id}/current-version` | Pin the current version (roll back / roll forward) | | `POST` | `/org/stack-profiles/{profile_id}/versions` | Save a new version from a source stack | | `GET` | `/org/stack-profiles/{profile_id}/versions/{version}` | Get a version's spec and parameters | | `GET` | `/org/stack-profiles/{profile_id}/versions/{version}/iac-export` | Export a version as IaC | | `GET` | `/org/stack-profiles/{profile_id}/diff` | Diff two versions | | `GET` | `/org/stack-profiles/{profile_id}/shares` | List the organisations a profile is shared with | | `POST` | `/org/stack-profiles/{profile_id}/shares` | Share the profile with an organisation by slug (org admin role required) | | `DELETE` | `/org/stack-profiles/{profile_id}/shares/{share_id}` | Revoke a share (org admin role required) | | `GET`/`POST` | `/org/stack-profiles/drafts` | List or create drafts | | `GET`/`POST`/`DELETE` | `/org/stack-profiles/drafts/{draft_id}` | Get, update, or delete a draft | | `POST` | `/org/stack-profiles/drafts/{draft_id}/validate` | Validate a draft | | `POST` | `/org/stack-profiles/drafts/{draft_id}/publish` | Publish a draft as a profile version | See [Stacks](/concepts/stacks) for the deploy/commit flow and the [API Reference](/api-reference/introduction) for full schemas. # Stacks Source: https://docs.ankra.ai/concepts/stacks Build, reuse, and automate Kubernetes environments with Stacks in Ankra. Stacks let you bundle add-ons and manifests into a reusable, versioned package. This makes it easy to deploy consistent Kubernetes environments at scale. ## What is a Stack? A **Stack** in Ankra is a collection of add-ons and manifests grouped together to define a complete Kubernetes environment. Stacks are reusable and can be versioned, shared, and deployed to any cluster. *** ## Build Stacks with AI Assistance The fastest way to plan a Stack is with the AI Assistant. Press `⌘+J` to open the chat and describe what you need: *"I need a monitoring stack with Prometheus, Grafana, and alerting for a production cluster"* The AI suggests add-ons, dependencies, and best-practice configurations based on your cluster. *"Set retention to 30 days and add PagerDuty integration"* - the AI provides updated configuration recommendations. Add the recommended components to the Stack Builder, configure based on the guidance, and deploy with one click. The AI knows your cluster's existing add-ons, resource limits, and Stack history - so recommendations are tailored, not generic. Beyond planning, Ankra's AI can manage the full Stack lifecycle: list, inspect, create, update, redeploy, clone, and delete Stacks. In chat every change is confirmation-gated; the same tools are available to MCP clients with the `mcp:write` scope - see the [MCP Tool Reference](/platform/mcp-tools#stacks). *** ## Why Use Stacks? Deploy the same stack to dev, staging, and production to ensure every environment is configured identically. New clusters or teams can be up and running in minutes by applying a pre-built stack. Update a stack and roll out changes to all clusters using it, reducing manual work and configuration drift. Share stacks across your organization to enforce standards and recommended configurations. *** ## Stack Builder Ankra provides a visual **Stack Builder** interface that makes it easy to compose and manage your stacks. ### Visual Interface The Stack Builder provides a drag-and-drop canvas where you can: * **Add Components:** Drag add-ons and manifests onto the canvas * **Define Dependencies:** Connect components to establish deployment order * **Configure Values:** Click any component to edit its configuration * **Preview Flow:** See how components will be deployed ### Creating a Stack Navigate to your cluster's **Stacks** section and click **Create Stack**. The Stack Builder canvas opens with an empty workspace. Click **+ Add** to browse available components: * **Add-ons:** Helm charts from your connected repositories * **Manifests:** Custom Kubernetes YAML resources Drag components onto the canvas or click to add them. Connect components to define deployment order. Ankra will deploy components in the correct sequence based on these connections. Example: Connect your namespace manifest to run before add-ons that depend on that namespace. Click any component to: * View and edit values files (for add-ons) * Modify manifest content * Set namespace and other metadata Click **Save** to store your stack. Then click **Deploy** to apply it to your cluster. *** ## Draft Stacks Ankra supports **draft stacks** for work-in-progress configurations: * **Auto-save:** Changes are saved automatically as you work * **Preview:** See what will be deployed before committing * **Validation:** Ankra validates your stack for common issues * **Publish:** When ready, publish the draft to make it deployable Draft stacks appear with a "Draft" badge in the stacks list. *** ## Stack Components ### Add-ons Add Helm charts to your stack: 1. Click **+ Add → Add-on** 2. Search or browse available charts 3. Select a chart version 4. Configure values (or use defaults) 5. Place on the canvas Each add-on shows: * Chart name and version * Repository source * Deployment status (after deploy) ### Manifests Add custom Kubernetes YAML: 1. Click **+ Add → Manifest** 2. Enter a name for the manifest 3. Paste or write your YAML content 4. Place on the canvas Manifests can contain any valid Kubernetes resources: * Namespaces * ConfigMaps and Secrets * Custom Resource Definitions (CRDs) * RBAC resources * Any other Kubernetes objects ### Variables Define stack-specific variables in the **Variables** tab: 1. Click the **Variables** tab in the Stack Builder 2. Click **Add Variable** to create a new entry 3. Enter a name and value 4. Click **Save Variables** Use variables in your manifests and add-on values with the syntax: ```yaml theme={null} apiVersion: v1 kind: ConfigMap metadata: name: app-config data: API_URL: ${{ ankra.api_endpoint }} LOG_LEVEL: ${{ ankra.log_level }} ``` Stack variables have the highest precedence. They override cluster and organisation variables with the same name. See [Variables](/concepts/variables) for the full precedence hierarchy. *** ## Dependency Management The Stack Builder lets you define deployment order through visual connections: ### Connecting Components 1. Hover over a component to see connection points 2. Click and drag from one component to another 3. The arrow indicates deployment order (source deploys before target) ### Dependency Rules * Components without dependencies deploy first (in parallel if possible) * Connected components wait for their dependencies to complete * Failed dependencies stop downstream deployments ### Example Flow ```mermaid theme={null} flowchart LR Namespace[Namespace] --> ConfigMap[ConfigMap] Namespace --> Deployment[Deployment] ConfigMap --> Deployment ``` In this example: 1. Namespace deploys first 2. ConfigMap deploys after namespace 3. Deployment deploys after both namespace and ConfigMap Always deploy namespace manifests before the add-ons and resources that live in them, and prefer several focused stacks (one concern each) over one giant stack. *** ## Stack Operations ### Editing a Stack 1. Go to **Stacks** and click on the stack 2. Click **Edit** to open the Stack Builder 3. Make changes and save 4. Re-deploy to apply changes ### Cloning a Stack (Within Cluster) 1. Click the stack's menu (⋯) 2. Select **Clone** 3. Edit the cloned stack as needed ### Cloning a Stack to Another Cluster You can clone a stack from one cluster to another to replicate configurations across environments: 1. Click the stack's menu (⋯) 2. Select **Clone to Cluster** 3. Choose the target cluster 4. Optionally rename the stack 5. Click **Clone Stack** The cloned stack is created as a draft in the target cluster, allowing you to review and configure secrets before deployment. Encrypted values (secrets) are not transferred during cross-cluster cloning for security reasons. You'll need to reconfigure them in the target cluster. [Learn more about cloning stacks →](/guides/clone-stack) ### Deleting Components 1. Select a component on the canvas 2. Press **Delete** or click the remove button 3. Connections to that component are automatically removed *** ## Example Stack Composition A typical production stack might include: | Component Type | Example | | -------------- | ------------------------ | | **Manifest** | Namespace definition | | **Manifest** | RBAC roles and bindings | | **Add-on** | Prometheus (monitoring) | | **Add-on** | Grafana (dashboards) | | **Add-on** | NGINX Ingress Controller | | **Add-on** | Cert-Manager (TLS) | | **Manifest** | Certificate resources | | **Manifest** | Ingress rules | *** ## GitOps Integration Stacks can be synced to a Git repository for version control and GitOps workflows: 1. Connect your GitHub repository in cluster settings 2. Stacks are exported as Helm values and manifests 3. Changes in Git can be synced back to Ankra 4. Full audit trail of all stack changes [Learn more about GitOps →](/concepts/gitops) *** ## Explore the Stacks API Want to automate stack management or integrate with your CI/CD workflows? Check out the [API Reference](/api-reference/introduction) for endpoints to create, update, and apply stacks programmatically. # Variables Source: https://docs.ankra.ai/concepts/variables Define reusable variables at organisation, cluster, and stack levels for flexible configuration management. Variables allow you to define reusable values that can be referenced across your stacks. Define them at the organisation, cluster, or stack level and use them in manifests and add-on configurations. ## Overview Ankra supports variables at three levels with a clear precedence hierarchy: ```mermaid theme={null} flowchart TD Org[Organisation Variables] --> Cluster[Cluster Variables] Cluster --> Stack[Stack Variables] Stack --> Final[Final Configuration] ``` **Precedence Order** (highest to lowest): 1. **Stack variables** - Variables defined for a specific stack (highest precedence) 2. **Cluster variables** - Variables defined for a specific cluster 3. **Organisation variables** - Variables defined for the entire organisation (lowest precedence) Lower-level variables override higher-level ones. A stack variable with the same name as a cluster or organisation variable will take precedence for that stack. *** ## Variable Syntax Reference variables in your stacks using the following syntax: ```yaml theme={null} ${{ ankra.variable_name }} ``` **Examples:** ```yaml theme={null} # In a manifest apiVersion: v1 kind: ConfigMap metadata: name: app-config namespace: default data: domain: ${{ ankra.domain_name }} api_url: https://${{ ankra.domain_name }}/api ``` ```yaml theme={null} # In Helm values ingress: enabled: true hosts: - host: ${{ ankra.domain_name }} ``` *** ## Organisation Variables Organisation variables apply to all clusters and stacks within your organisation. Use them for values that are consistent across your entire infrastructure. ### Creating Organisation Variables Go to **Organisation Settings** → **Variables**. Click **Add Variable** to open the creation form. Fill in the required fields: * **Variable Name**: Must start with a letter, containing only letters, numbers, and underscores (e.g., `domain_name`, `api_key`) * **Value**: The variable's value * **Description** (optional): A brief description for documentation * **Secret**: Check this box to mask the value in the UI Click **Create Variable** to save. ### Common Organisation Variables | Variable Name | Example Value | Use Case | | -------------- | -------------------- | ---------------------------- | | `domain_name` | `example.com` | Base domain for all services | | `registry_url` | `ghcr.io/myorg` | Container registry URL | | `environment` | `production` | Environment identifier | | `alert_email` | `alerts@example.com` | Notification email address | | `log_level` | `info` | Default logging level | *** ## Cluster Variables Cluster variables apply to all stacks deployed to a specific cluster. Use them for cluster-specific configurations that differ between environments. ### Creating Cluster Variables Go to your cluster → **Settings** → **Variables**. Click **Add Variable** to open the creation form. Fill in the required fields: * **Variable Name**: Must start with a letter, containing only letters, numbers, and underscores * **Value**: The variable's value * **Description** (optional): A brief description * **Secret**: Check this box to mask the value in the UI Click **Create Variable** to save. ### Common Cluster Variables | Variable Name | Example Value | Use Case | | ---------------- | ------------------ | -------------------------- | | `cluster_domain` | `prod.example.com` | Cluster-specific subdomain | | `storage_class` | `gp3` | Default storage class | | `node_selector` | `app=production` | Node selector labels | | `replica_count` | `3` | Default replica count | | `resource_quota` | `high` | Resource allocation tier | *** ## Stack Variables Stack variables are specific to a single stack and have the highest precedence. Use them for stack-specific configurations that should override cluster and organisation variables. ### Creating Stack Variables Navigate to your cluster → **Stacks** and open an existing stack or create a new one. Click the **Variables** tab in the Stack Builder. Click **Add Variable** to create a new variable entry. Fill in the fields: * **Variable Name**: Must start with a letter, containing only letters, numbers, and underscores * **Value**: The variable's value Click **Save Variables** to persist the changes. Stack variables are saved as part of the stack configuration. When you deploy the stack to GitOps, the variables are resolved before manifests are written. ### Common Stack Variables | Variable Name | Example Value | Use Case | | --------------- | ------------------ | ---------------------------- | | `app_version` | `v2.1.0` | Application version tag | | `replicas` | `5` | Stack-specific replica count | | `feature_flag` | `enabled` | Feature toggles | | `log_level` | `debug` | Stack-specific logging | | `custom_config` | `{"key": "value"}` | JSON configuration | ### When to Use Stack Variables Use stack variables when: * A specific stack needs values that differ from cluster defaults * You want to override cluster or organisation variables for one stack * You're testing different configurations on the same cluster * You need stack-specific feature flags or version tags *** ## Secret Variables Mark variables as secrets when they contain sensitive values like API keys, passwords, or tokens. Secret variables are masked in the UI but are still stored as-is on the server. For encrypted storage, use [SOPS encryption](/guides/sops) instead. ### Secret Variable Features * **Masked Display**: Values show as `••••••••` in the UI * **Reveal Option**: Click the eye icon to temporarily reveal the value * **Copy Protection**: Values can still be copied for use in configurations ### When to Use Secrets vs SOPS | Feature | Secret Variables | SOPS Encryption | | ---------------------- | ------------------ | ----------------------- | | **UI Masking** | Yes | N/A | | **Git Storage** | Plaintext | Encrypted | | **Runtime Decryption** | No | Yes | | **Best For** | UI-only protection | Full encryption at rest | Use secret variables for convenience in the UI. Use SOPS when you need values encrypted in your Git repository. *** ## Using Variables in Stacks ### In Manifests Reference variables anywhere in your Kubernetes manifests: ```yaml theme={null} apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: replicas: ${{ ankra.replica_count }} template: spec: containers: - name: app image: ${{ ankra.registry_url }}/myapp:latest env: - name: DOMAIN value: ${{ ankra.domain_name }} ``` ### In Add-on Values Use variables in Helm chart values: ```yaml theme={null} # Grafana add-on values grafana: adminPassword: ${{ ankra.grafana_password }} ingress: enabled: true hosts: - grafana.${{ ankra.cluster_domain }} ``` ### Variable Resolution When you deploy a stack, Ankra resolves variables in this order: 1. Check for a matching stack variable (highest priority) 2. If not found, check for a matching cluster variable 3. If not found, check for a matching organisation variable 4. If still not found, the literal `${{ ankra.variable_name }}` is left in place (which will likely cause deployment errors) This precedence allows you to define sensible defaults at the organisation level, environment-specific overrides at the cluster level, and stack-specific customizations when needed. *** ## Managing Variables ### Copying Variable Syntax Click the **Copy** icon next to any variable to copy its full syntax: ``` ${{ ankra.variable_name }} ``` This copies the ready-to-use syntax for pasting into your manifests. ### Deleting Variables Deleting a variable that is in use by stacks will cause deployment failures. Review stack usage before deleting. 1. Click the **Delete** (trash) icon next to the variable 2. The variable is immediately removed ### Variable Naming Rules Variable names must follow these rules: * Start with a letter (a-z, A-Z) * Contain only letters, numbers, and underscores * Be unique within their scope (organisation or cluster) **Valid names:** `domain_name`, `API_KEY`, `replica_count_v2` **Invalid names:** `123_name`, `my-variable`, `name with spaces` *** ## Managing variables via API and CLI Organisation and cluster variables have full CRUD over the API and the [Ankra CLI](/integrations/ankra-cli), so you can manage them from scripts and pipelines, not just the UI. (Stack variables are managed as part of the stack via the CLI's stack commands.) ### CLI ```bash theme={null} # Organisation scope - available to every cluster ankra org variables set DB_HOST db.example.com --description "Primary DB" ankra org variables list # Cluster scope - shadows org variables on that cluster ankra cluster variables set DB_HOST db.prod.example.com --cluster prod ``` `set` is an upsert, and values can be read from stdin with `-` so secrets can be piped in from a vault or password manager. See the [CLI reference](/integrations/ankra-cli) for the full command set. ### REST API Both scopes expose the same list/create/update/delete shape under `/api/v1/org/variables` (organisation) and `/api/v1/org/clusters/imported/{cluster_id}/variables` (cluster), bearer-token authenticated. See the [API Reference](/api-reference/introduction) for endpoints and schemas. *** ## AI Prompts Press `⌘+J` to open the AI Assistant and use these prompts: ``` I need to deploy the same stack to dev and prod clusters with different domain names. Help me set up variables. ``` ``` Review my stack and suggest which values should be converted to variables. ``` *** ## Related Build stacks that use variables. Encrypt sensitive values in Git. Configure organisation-level settings. Configure cluster-level settings and variables. # Getting Started Source: https://docs.ankra.ai/get-started/quickstart Set up Ankra end to end: try the live playground, import or provision a Kubernetes cluster, build and deploy a stack, wire up GitOps and CI/CD, then operate it with AI - from the web UI, the ankra CLI, an MCP-connected agent, or your pipelines. This guide walks you through setting up Ankra: trying it in the playground, connecting a cluster, building your stack, and using AI to manage your infrastructure. GitOps is optional - stacks deploy directly through the Ankra agent, and you can add a Git audit trail whenever you want it. This guide uses the web UI; every step also works from the [CLI](/integrations/ankra-cli), an [MCP-connected agent](/platform/mcp-server), or your [CI/CD pipelines](/guides/pipeline-agents) - step 5 wires those up. **What you need:** a Kubernetes cluster you can run `helm` against (EKS, GKE, AKS, k3s, minikube - anything), or nothing at all if you start in the playground. *** ## 0. Try the Playground (optional) No cluster handy? Start in the **playground**: a real, writable, ephemeral Kubernetes environment we provision for you in about two minutes. It comes with a starter stack already deploying, so you can watch a real deploy land, then use the AI to ship something yourself. On your first visit, choose **Try it in a live playground**. You can also start one later from **Clusters** → **Try Playground**. Everything works: deploy stacks, browse resources, break things, ask the AI to fix them. The playground is yours alone. The playground expires after a few days (you'll get a heads-up). Everything you learned works identically on your own cluster - importing one takes a single helm command. *** ## 1. Connect a Cluster Everything starts with a cluster. Import an existing one or provision a new managed cluster. Import any Kubernetes cluster - EKS, GKE, AKS, on-prem, k3s, minikube, or kind. Go to **Clusters** and click **Import Cluster**. Give it a name. Ankra generates a Helm command for your cluster. Run it wherever you have `kubectl` access: ```bash theme={null} helm upgrade --install ankra-agent oci://ghcr.io/ankraio/ankra-agent/ankra-agent \ --namespace ankra \ --create-namespace \ --set config.token="YOUR_UNIQUE_TOKEN" ``` The agent connects your cluster to the platform securely. It works behind firewalls, NATs, and private networks. Your cluster appears in the dashboard within seconds. You now have full visibility into workloads, resources, and events. Ankra provisions production-ready K3s clusters on Hetzner, OVHCloud, or UpCloud with automated networking, bastion hosts, and NAT gateways. Go to **Credentials** and add your cloud provider API key (Hetzner, OVH, or UpCloud). Don't have a Hetzner account? [Sign up for Hetzner Cloud](https://www.hetzner.com/cloud) to get started. Go to **Clusters** → **Create Cluster**. Select your provider and configure: * **Region** - choose a datacenter location * **Node sizing** - control plane and worker node types * **Networking** - private network range and subnet * **Kubernetes version** - pick a supported K3s version Ankra provisions the infrastructure, installs K3s, configures networking, and connects the agent. The cluster is fully yours - if you disconnect from Ankra, everything keeps running on your cloud account. You can also provision clusters from the CLI: `ankra cluster hetzner create`, `ankra cluster ovh create`. *** ## 2. Build Your Stack A **Stack** is a collection of Helm charts, manifests, and variables that define your Kubernetes environment. Build stacks visually or with AI assistance. Navigate to your cluster → **Stacks** → **Create Stack**. The visual canvas opens. Click **+ Add** to compose your stack: * **Add-ons** - Helm charts like Prometheus, Grafana, NGINX Ingress, cert-manager * **Manifests** - custom Kubernetes YAML (namespaces, RBAC, ConfigMaps, CRDs) Drag components onto the canvas and connect them to define deployment order. Press `⌘+J` and describe what you need: *"I need a monitoring stack with Prometheus, Grafana, and Loki for a production cluster with 30-day retention"* The AI recommends components, configurations, dependencies, and deployment order tailored to your cluster. Click any component to edit its values. Use [variables](/concepts/variables) with `${{ ankra.variable_name }}` for environment-specific configuration. Click **Create Stack** to save and deploy. Deploys go directly through the Ankra agent - no Git repository or extra credentials required. Stacks can be cloned across clusters - replicate a stack from dev to staging to production. See [Clone a Stack](/guides/clone-stack). *** ## 3. Connect GitOps (optional) Stacks deploy without Git. Connect a GitHub repository when you want version control, an audit trail, and CI/CD integration on top - every stack write is then also committed to your repository. This is where Ankra integrates with your existing CI/CD. Go to your cluster → **Settings** → **Integration**. Select a GitHub credential (or add one) and choose the repository where Ankra will store your cluster configuration. Ankra installs ArgoCD and the GitOps engine on your cluster automatically. Every stack you build is exported as Helm values and manifests to your repository under `clusters/{cluster-name}/`. Changes in either direction sync automatically. Your existing CI pipeline can now deploy through Ankra: 1. CI builds a container image and pushes to your registry 2. CI commits the new image tag to the GitOps repo 3. Ankra detects the change and deploys to your cluster ```mermaid theme={null} flowchart LR A[git push] --> B[CI builds image] B --> C[Update GitOps repo] C --> D[Ankra syncs cluster] ``` See the full walkthroughs for [GitHub Actions](/guides/cicd-pipeline) or [GitLab CI](/guides/gitlab-cicd-pipeline). For app repos, [Applications (closed beta)](/concepts/applications) generates the Dockerfile, Helm chart, and pipeline for you. Go to your cluster → **Settings** → **GitOps** to view sync status, history, and any errors. Every sync is tracked with commit SHA, trigger source, and timestamp. ### GitOps file format For advanced setups, define your clusters declaratively using `include` paths to keep configuration modular: ```yaml theme={null} apiVersion: v1 kind: ImportCluster metadata: name: my-cluster spec: git_repository: provider: github credential_name: my-credential branch: main repository: my-org/infra-gitops stacks: - name: platform-stack manifests: - include: manifests/ addons: - include: addons/ ``` Different teams can own different YAML files in the same repo - no merge conflicts, no monolithic configs. The full schema is in the [ImportCluster YAML reference](/reference/importcluster). *** ## 4. Manage with AI With your cluster connected and stacks deployed, Ankra's AI capabilities unlock powerful management and debugging workflows. ### Ask the AI anything Press `⌘+J` from anywhere in the platform. The AI is page-aware - it automatically knows what you're looking at. Three modes control how much it can do: **Ask** answers read-only, **Agentic** confirms each change before acting, and **Plan** lets you approve a plan once and watch it execute. | You're viewing | What the AI already knows | | -------------- | --------------------------------------------------------------------- | | A crashing pod | Its logs, events, manifest, resource usage, and parent deployment | | A deployment | All replicas, rollout status, associated services, and recent changes | | A stack | Installed add-ons, Helm values, deployment history, and dependencies | **Try these:** * *"Why is my pod crashing?"* * *"Scale this deployment to 5 replicas"* * *"What changed in the last hour that could cause 503 errors?"* * *"Create a Redis stack with persistence enabled"* ### Enable proactive AI Insights Navigate to **Organisation Settings** → **General** → toggle **Proactive AI Insights**. The AI continuously scans your clusters and surfaces issues with root cause analysis, remediation commands, and MTTR analytics before they become incidents. ### Set up alerts with AI analysis Configure [alert rules](/guides/alerts) on your cluster. When alerts trigger, Ankra's AI automatically collects cluster data and generates structured incident reports with root cause, affected resources, and recommended actions. *** ## 5. Take Ankra to Your Tools The same tool registry behind `⌘+J` is available outside the browser - to your terminal, your editor's AI agent, and your pipelines. **No browser automation required.** Install, sign in, and hand tasks to the AI from your terminal: ```bash theme={null} bash <(curl -sL https://github.com/ankraio/ankra-cli/releases/latest/download/install.sh) ankra login ankra chat "why is the payments pod crashing?" --cluster prod ankra chat "scale the api deployment to 5 replicas" --cluster prod --mode agent ``` `--mode ask` stays read-only (plus safe creations); `--mode agent` lets it act. For headless or CI use, set the `ANKRA_API_TOKEN` environment variable instead of `ankra login`. See the [Ankra CLI guide](/integrations/ankra-cli). Point any MCP client at Ankra's remote server and it gets the full tool surface (clusters, workloads, logs, stacks, provisioning) gated by `mcp:read` / `mcp:write` scopes. ```bash theme={null} # Claude Code - register once, then authenticate with /mcp claude mcp add --transport http ankra https://platform.ankra.app/api/v1/mcp ``` Then install Ankra's curated Agent Skills into your editor - `ankra skills install` for Cursor (default) or `ankra skills install --editor claude-code` for Claude Code. See the [MCP Server guide](/platform/mcp-server) for Claude desktop/web, Cursor, tokens, and OAuth, and the [MCP Tool Reference](/platform/mcp-tools) for every tool. Your pipelines deploy through the GitOps image-bump flow from step 3. Beyond deploys, any plain CI job becomes a **pipeline agent** by calling the CLI: ```yaml theme={null} - run: bash <(curl -sL https://github.com/ankraio/ankra-cli/releases/latest/download/install.sh) - env: ANKRA_API_TOKEN: ${{ secrets.ANKRA_API_TOKEN }} run: ankra chat --cluster prod -o json "Review this repo's cluster YAML against the live cluster" ``` See [Pipeline Agents](/guides/pipeline-agents) for PR review, deploy watching, and scheduled health checks, the [GitHub Actions](/guides/cicd-pipeline) and [GitLab CI](/guides/gitlab-cicd-pipeline) pipeline guides, or the [Terraform provider](/integrations/terraform) for infrastructure-as-code. *** ## What's Next Deploy Prometheus, Grafana, and Loki with AI assistance. PR review, deploy watching, and scheduled health checks from plain CI jobs. Connect Claude, Cursor, and other MCP clients with scoped access to 169 platform tools. Deep dive into AI-powered troubleshooting, stack building, and incident triangulation. Parameterise your stacks with organisation, cluster, and stack-level variables. Run Ankra's autonomous infrastructure agent from Slack, Discord, or Telegram. *** Still have questions? [Join our Slack community](https://join.slack.com/t/ankra-community/shared_invite/zt-3a5rem8f8-cUho4epX2MoLT83bFf~VSA) and we'll help out. # Azure Kubernetes Service (AKS) Source: https://docs.ankra.ai/guides/aks-clusters Provision, import, and operate Azure Kubernetes Service (AKS) clusters with Ankra - network plugins, SKU tiers, private clusters, node pools, upgrades, GitOps, and AI-assisted operations. [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/products/kubernetes-service) is Microsoft Azure's managed Kubernetes service. Azure runs the control plane; Ankra provisions the cluster, then manages everything on top - node pools, Kubernetes upgrades, addons, stacks, GitOps, and AI-assisted operations. This page covers AKS specifically. For the shared concepts across all managed providers - live options, discovery/import, and day-2 API patterns - see [Managed Kubernetes](/guides/managed-kubernetes). ## Why AKS with Ankra * **Network plugin and SKU tier** - choose `azure` or `kubenet` networking and the control-plane SKU tier that fits your uptime needs. * **Private clusters** - provision a private API endpoint when required. * **Live pricing and options** - locations, Kubernetes versions, and VM sizes are fetched live with your service principal, including spot and autoscaling where available. ## Prerequisites An **Azure service principal** stored in Ankra with **Contributor** on the target subscription. See [Azure Credentials](/platform/credentials/azure). GitOps is optional: connect a repository at creation and Ankra commits the cluster's stack definitions to Git. ## Creating an AKS cluster Go to **Clusters** → **Create Cluster** and pick Azure's **Cloud Managed** action. Select the Azure credential and a location (for example `westeurope`). Locations load live from Azure. Define one or more worker pools: name, VM size (with live pricing), count, labels, and autoscaling bounds. Pick a Kubernetes version or keep the default, choose the network plugin (`azure` or `kubenet`), the SKU tier (`Free`, `Standard`, or `Premium`), and whether the cluster is private. Optionally connect a Git repository, then create. Ankra runs AKS preflight checks, provisions the cluster, retrieves the kubeconfig, and installs the Ankra Agent. ```bash theme={null} ankra cluster managed create \ --provider aks \ --name my-aks-cluster \ --credential-id \ --location westeurope \ --node-pool-name workers \ --node-pool-size Standard_D2s_v5 \ --node-pool-count 2 ``` Network plugin, SKU tier, private-cluster, resource group, and node-pool autoscaling bounds are set from the portal or the API. ```bash theme={null} curl -X POST https://platform.ankra.app/org/clusters/managed/aks \ -H "Authorization: Bearer $ANKRA_API_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "name": "my-aks-cluster", "credential_id": "", "location": "westeurope", "kubernetes_version": "1.32.3", "node_pools": [ { "name": "workers", "size": "Standard_D2s_v5", "count": 2, "autoscaling": {"enabled": true, "min_count": 2, "max_count": 5} } ], "aks": {"network_plugin": "azure", "sku_tier": "Standard"} }' ``` ### AKS options | Field | Description | | --------------------- | -------------------------------- | | `aks.resource_group` | Target resource group | | `aks.network_plugin` | `azure` or `kubenet` | | `aks.private_cluster` | Provision a private API endpoint | | `aks.sku_tier` | `Free`, `Standard`, or `Premium` | AKS node-pool names are lowercase alphanumeric and at most 12 characters; cluster names are at most 63 characters. ## Day-2 operations Node pools, upgrades, and deletion work from the CLI, portal, or API. The CLI examples use `--provider aks`: ```bash theme={null} # scale a pool to a fixed count ankra cluster managed node-pool scale workers --provider aks --count 5 # upgrade the cluster ankra cluster managed upgrade --provider aks --version 1.32.3 # delete the cluster ankra cluster managed delete --provider aks ``` Autoscaling bounds are set with `ankra cluster managed node-pool update --provider aks --autoscaling --autoscaling-min 2 --autoscaling-max 8`, from the portal, or via the `PATCH .../node-pools/{name}` endpoint. See [Managed Kubernetes - day-2 operations](/guides/managed-kubernetes#day-2-operations) for the shared mechanics. ## Stopping and Starting AKS is the only managed provider with native cluster stop/start, and Ankra exposes it in the portal Danger Zone, CLI, API, and Ankra AI/MCP. Stopping deallocates the control plane and agent pools (Azure stops billing for compute) while keeping all configuration, and starting brings the same cluster back. In the portal, open **Settings** → **General** → **Danger Zone** and choose **Stop cluster**. When Azure finishes the operation, the same area offers **Start cluster**. ```bash theme={null} ankra cluster managed stop --provider aks ankra cluster managed start --provider aks ``` The API exposes the same asynchronous stop and start operations. You can also ask Ankra's AI or any MCP client to "stop my AKS cluster" or "start my AKS cluster"; write operations require confirmation. Both operations are asynchronous on Azure's side - the cluster shows `stopped` or `running` once Azure completes the transition. Other managed providers do not support stop/start; Ankra advertises the capability per provider as `supports_stop_start`. ## Importing an existing AKS cluster Already running AKS? Discover clusters in your subscription and adopt them into Ankra without touching them. Discovery and import run from the portal or API - see [Managed Kubernetes - importing existing clusters](/guides/managed-kubernetes#importing-existing-clusters). ## Related * [Managed Kubernetes overview](/guides/managed-kubernetes) * [Azure Credentials](/platform/credentials/azure) * [Cluster settings](/platform/cluster-settings) # Alerts Source: https://docs.ankra.ai/guides/alerts Monitor your clusters and resources with customizable alert rules Ankra Alerts help you stay informed about your cluster health, resource issues, and operational events with configurable notifications. ## What are Alerts? Alerts in Ankra let you define rules that automatically monitor your infrastructure and notify you when specific conditions are met. You can: * **Monitor Cluster Health:** Get notified when clusters go offline or agents disconnect * **Track Resource Status:** Watch for issues with GitOps repositories, add-ons, manifests, and stacks * **Configure Conditions:** Set up multiple conditions with AND/OR logic for precise alerting * **Receive Notifications:** Send alerts to any webhook-enabled service (Slack, Teams, PagerDuty, etc.) ### How Alerts Work ```mermaid theme={null} flowchart LR A[Resource State Change] --> B[Condition Evaluation] B --> C{Conditions Met?} C -->|Yes| D[Alert Triggered] C -->|No| E[No Action] D --> F[Webhook Notifications] D --> G[AI Incident Created] F --> H[Slack / Teams / PagerDuty] ``` *** ## Automatic AI Analysis Every time an alert triggers, Ankra automatically starts an AI-powered analysis to help you understand what went wrong. ```mermaid theme={null} flowchart LR A[Alert Triggers] --> B[AI Analysis Resource Created] B --> C[Analysis Job Scheduled] C --> D[Data Collection] D --> E[AI Analysis] E --> F[AI Incident Ready] ``` ### What Happens Behind the Scenes 1. **AI Analysis Resource** - When conditions are met, Ankra creates an AI Analysis resource to track the investigation 2. **Analysis Job** - A background job is scheduled to collect and analyze data 3. **Data Collection** - The job gathers: * Pod status and container states * Kubernetes events (warnings, errors) * Container logs (recent output) * Job results and error messages 4. **AI Analysis** - Ankra's AI processes the data to identify: * Root cause of the issue * Severity assessment * Affected resources * Recommended actions 5. **AI Incident** - Results are saved as an AI Incident for review View all AI Incidents in the **Alerts → AI Incidents** tab. Each incident includes the full analysis, affected resources, and an interactive checklist of recommended actions. *** ## Alerts Dashboard The Alerts page displays key metrics at a glance: | Metric | Description | | ------------------ | -------------------------------------------------- | | **Total Alerts** | Number of configured alert rules | | **Active** | Alerts currently enabled and monitoring | | **Rules** | Total number of individual rules across all alerts | | **Triggers (24h)** | How many times alerts fired in the last 24 hours | You can filter alerts by status (Active/Disabled) using the quick filter pills on the dashboard. *** ## Alert Structure An alert consists of rules, conditions, and webhook integrations: ```mermaid theme={null} flowchart TD subgraph alert [Alert] A[Name / Description / Enabled] end subgraph rules [Rules] R1[Resource Type / Clusters / Severity / Cooldown] end subgraph conditions [Conditions] C1[Condition 1] C2[Condition 2] end subgraph webhooks [Webhooks] W1[Slack] W2[PagerDuty] end alert --> rules rules --> conditions C1 -->|AND / OR| C2 alert --> webhooks ``` *** ## Creating Alert Rules Configure the basic alert settings: * **Alert Name:** A descriptive name (e.g., "Production Resources Down") * **Severity:** Choose Critical, Warning, or Info * **Cooldown:** Time in minutes before the alert can trigger again (prevents alert storms) * **Clusters:** Select "All Clusters" or choose specific clusters to monitor Select the resource type to monitor: Monitor overall cluster health including: * Cluster connectivity state * Agent status and availability Monitor specific resource types: * **GitOps** - GitHub repository sync status * **Addon** - Add-on deployment health * **Manifest** - Raw manifest deployments * **Stack** - Stack deployment status Define one or more conditions that trigger the alert. Multiple conditions can be combined using **AND** or **OR** logic. **For Cluster monitoring:** * **Cluster State:** Alert when cluster goes offline/online **For Cluster Resource monitoring:** * **Resource State:** Alert on state changes (up, down, creating, updating, stopping) * **Job Status:** Alert on job outcomes (failed, timeout, blocked, etc.) Select which destinations (webhooks) should receive notifications when this alert fires. You can configure destinations in the [Webhooks](/guides/webhooks) section. In addition to the alert's own destinations, org-wide **routing rules** (Alerting → Destinations → Routing rules) can match alert firings by severity and cluster - for example, "every critical firing also goes to PagerDuty". A destination that the alert already notifies directly is skipped by routing rules, so nothing is delivered twice. If you have set a [home channel](/guides/webhooks#home-channel), a critical or warning firing that no destination or routing rule handles falls back to the home so it is never missed. *** ## Condition Types Reference ### Cluster Conditions Use these when monitoring **Cluster** resource type: | Condition | Description | Values | | ----------------- | ---------------------------- | ------------------- | | **Cluster State** | Monitor cluster connectivity | `offline`, `online` | ### Cluster Resource Conditions Use these when monitoring **Cluster Resource** types (GitOps, Addon, Manifest, Stack): | Condition | Description | Values/Options | | ------------------ | ----------------------------- | ------------------------------------------------------------------------------------------ | | **Resource State** | Monitor resource health state | `all_up`, `up`, `creating`, `updating`, `stopping`, `down` | | **Job Status** | Monitor job execution status | `blocked`, `failed`, `pending`, `running`, `success`, `timeout`, `cancelling`, `cancelled` | ### Condition Operators For numeric threshold conditions, you can use these operators: | Operator | Description | | -------- | --------------------- | | `eq` | Equals | | `neq` | Not equals | | `gt` | Greater than | | `gte` | Greater than or equal | | `lt` | Less than | | `lte` | Less than or equal | *** ## Alert Severity Levels | Level | Description | Use Case | | ------------ | ------------------------- | --------------------------------------- | | **Critical** | Immediate action required | Production outages, service unavailable | | **Warning** | Attention needed soon | Resource pressure, degraded performance | | **Info** | Informational updates | Successful deployments, routine events | *** ## Viewing Alert History Each alert tracks its trigger history. From the alert detail page, you can: * **View Statistics:** Total triggers, last check time, last triggered time * **Review History:** See when alerts triggered and what conditions matched * **Analyze Patterns:** Identify recurring issues across your infrastructure Navigate to **Alerts → \[Alert Name] → View History** to access the full timeline. *** ## Related * [AI Incidents](/platform/ai-incidents) - AI-powered root cause analysis for triggered alerts * [Webhooks](/guides/webhooks) - Configure notification endpoints for alerts *** Still have questions? [Join our Slack community](https://join.slack.com/t/ankra-community/shared_invite/zt-3a5rem8f8-cUho4epX2MoLT83bFf~VSA) and we'll help out. # Audit Log Source: https://docs.ankra.ai/guides/audit-log Review the append-only record of every administrative change in your organisation - who did what, when, and from where. Every administrative change in Ankra is recorded in the organisation **Audit Log**. It is the platform's system of record for governance questions: who invited that member, who approved that deployment, who accepted that CVE as risk, and when. *** ## What is recorded Each entry captures: * **Who** - the actor (a member, or a token acting on their behalf) * **What** - the action and the resource it touched, with structured details of the change * **When** - the timestamp * **Where from** - the source IP Administrative changes across the platform write entries: invitations and role assignments, cluster-group edits, credential changes, cluster lifecycle operations, security disposition changes, and organisation settings edits. Entries are **append-only** - they cannot be edited or deleted - and they are written for every change regardless of who can view the log. *** ## Who can see it Viewing the audit log requires the audit read permission, held by **owners** and **admins** by default. It can also be granted to [custom roles](/guides/roles-and-access), so a compliance or security function can review the log without broader administrative access. *** ## Reading and filtering Open **Organisation → Settings → Audit Log**. From there you can: * **Search** entries by keyword * **Filter** by user, action type, cluster, resource type, and date range * **Expand** an entry to see the structured details of the change Every entry names the **cluster** it belongs to, and the name links straight to that cluster's own Audit tab. Organisation-level events - sign-ins, invitations, role changes - show no cluster. A cluster you have since deleted keeps its name in the trail, marked deleted: the record outlives the cluster, which is exactly what makes the deletion itself auditable. The cluster filter is carried in the page URL, so a view narrowed to one cluster can be bookmarked or shared as a link. *** ## Per-cluster view Each cluster carries its own slice of the trail: the **Audit** tab in cluster **Settings** shows only the manual actions performed on that cluster - lifecycle operations, scaling, node restarts, and stack changes - with the same permission gate and entry format. See [Cluster Settings → Audit](/platform/cluster-settings#audit). The two views are connected in both directions. From the organisation log, a row's cluster takes you into that cluster's tab; from the tab, **View in organisation audit log** takes you back to the full trail with that cluster preselected as the filter - the same entries, alongside the organisation-level events the tab leaves out. *** ## Exporting Export the current filtered view to CSV or JSON, from the portal or through the API for scheduled evidence jobs. The download honours the filters on screen, including the cluster filter, and the export rows carry the cluster alongside the actor and action. A cluster's **Audit** tab exports through the same path, so a per-cluster download and the organisation view filtered to that cluster contain the same entries. A single export returns up to 100,000 rows and signals truncation when more rows match. See [Audit Export](/security/audit-export) for the full column list, the API parameters, and how to forward the trail to a SIEM. *** ## Retention Audit entries are retained for **365 days**, after which older rows are removed by a background retention job. Entries inside the window are immutable. If your framework requires a longer trail, [export](/security/audit-export) on a schedule into storage you control - the platform is not intended to be your long-term system of record. *** ## Relationship to Git history Ankra gives you two complementary trails: * The **audit log** records platform actions - who signed in, assigned a role, approved a plan, or changed a disposition. * **Git history** records desired-state changes as attributed commits - exactly what changed in your cluster definitions and Stacks, and when it was deployed. Together they answer both "who did what in the platform" and "what actually changed in the cluster". For how commits are produced and attributed, see [GitOps](/concepts/gitops). *** ## Related Grant the audit read permission via custom roles. The attributed commit trail for desired-state changes. How the audit log fits the wider control set. Disposition changes that land in the audit log. # Branch Demos Source: https://docs.ankra.ai/guides/branch-demos Launch a throwaway demo of any branch build on your staging cluster - with environment variables, an optional Postgres, and an automatic teardown timer A branch demo runs a branch's already-built container images in their own isolated namespace on your organisation's staging cluster, and stops itself when the timer runs out. Use it to show work in progress, reproduce a bug against a specific build, or hand a reviewer a live URL instead of a screenshot. Pull requests get [previews automatically](/guides/pr-preview-environments). This guide covers the manual path: the **Launch a branch demo** dialog on an application's **Demos** tab, and its CLI and MCP equivalents. *** ## Prerequisites The branch must belong to a [connected application](/concepts/applications). Application setup adds the canonical build-and-publish workflow, which is what pushes the image a demo deploys. An admin sets it under **AI** → **Settings** → **Workspaces**. Every demo lands there. Without it, there is nowhere to launch. A demo deploys an image, it does not build one. Push the branch so the workflow publishes a tag for it. If nothing was ever published, the dialog offers [Fix the build](#no-built-image-for-this-branch). Without one, demos are served over the staging cluster's `*.ankra.cc` zone on plain HTTP, or stay in-cluster-only. See [the preview URL](/concepts/applications#the-preview-url). *** ## Launch a demo Open the application, go to the **Demos** tab, and choose **Launch demo**. ### Staging cluster capacity The panel at the top of the dialog reports the staging cluster's live headroom - nodes ready, CPU and memory in use, pod count, and how many demos are already running - and highlights a figure in amber once it passes 90% of capacity. It is informational: a busy cluster does not block the launch, but it tells you whether your pods will actually get scheduled. Each demo namespace carries its own hard `ResourceQuota`, so one demo can never exhaust the cluster: | Demo type | Pods | CPU limit | Memory limit | | ----------------------------------- | ---- | --------- | ------------ | | Single service | 5 | 2 | 2 Gi | | Full stack (stack profile attached) | 20 | 8 | 16 Gi | ### Branch Pick the branch to demo. The list marks the application's configured **build branch** and the repository **default** branch. As soon as you pick one, Ankra checks the registry for a matching image and reports the verdict inline: | Verdict | Meaning | | ------------------------------- | ---------------------------------------------------------------------------------------- | | ✅ **Build found** | The resolved image tag is shown and will be deployed. | | ⚠️ **No built image was found** | Nothing was published for this branch yet. See [below](#no-built-image-for-this-branch). | | ❌ An error message | The registry or the repository could not be read - the message names the cause. | ### Components (monorepos only) A single-app repository has nothing to choose. A monorepo shows every deployable component with its own build status and tag, and **all of them deploy by default** - each as its own pod in the one namespace, so a frontend and its API come up wired together instead of half an application answering where the other half belonged. * **Untick a component** to leave it out of this launch. At least one must stay ticked. * **The web entry** owns the demo's URL root. Ankra marks the component its heuristic picked; **set as entry** moves the badge to another one. * **Path badges** on the remaining components show where they are published under the same host, so in-cluster callers and the browser reach the same demo. The container port prefill follows the web entry, and the launch is blocked until every ticked component has an image (or you supply an [image tag override](#advanced-options), which applies to all of them). ### Stop automatically after (hours) The teardown timer. It is pre-filled with the organisation's default demo TTL and capped by your role's limit, which admins set per role (admin, operator, member) under **AI** → **Settings** → **Workspaces**. The field states your own ceiling. When the timer expires the namespace is deleted; nothing survives it. ### Environment and database Expand **Environment & database** to set variables for this launch only. **Add variable** adds a row - a name, a value, and a **Secret** checkbox. Values marked secret are stored as Vault-backed Ankra secret slots and mounted as a Kubernetes Secret at deploy time; the plaintext never persists in the application's configuration. Toggle **Attach a throwaway Postgres** and an ephemeral pgvector-capable Postgres is provisioned inside the demo namespace with a per-demo random password, then destroyed with it. Nothing is injected automatically, because every codebase names its configuration differently - reference the placeholders in your own variable *values* instead: | Placeholder | Resolves to | | ------------------------------------- | ------------------------------------ | | `${{ ankra.demo_database.url }}` | Full `postgres://` connection string | | `${{ ankra.demo_database.host }}` | In-namespace service host | | `${{ ankra.demo_database.port }}` | `5432` | | `${{ ankra.demo_database.name }}` | Database name | | `${{ ankra.demo_database.user }}` | Database user | | `${{ ankra.demo_database.password }}` | The per-demo random password | With the toggle on, the editor offers quick-add buttons for the common names (`DATABASE_URL` and friends) already wired to the right placeholder. Everything in this section applies to **this launch only**. To give every demo of the application the same configuration - manual launches, CLI and MCP deploys, and the automatic PR previews - set it once as the application's demo defaults behind the gear button on the **Demos** tab. Per-launch values win by name. Full reference: [environment variables and a throwaway database](/concepts/applications#environment-variables-and-a-throwaway-database). ### Advanced options | Field | Use it when | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Image tag override** | You want a specific tag rather than the one resolved from the branch build - an older build, or a tag pushed outside the standard workflow. It applies to every included component, so it also rescues a partially built branch. Leave empty to use the resolved tag. | | **Container port** | Your application listens on something other than the detected port. It is pre-filled from the web entry's build metadata and stops following it once you edit the field. | ### Full-stack demos When the application designates a **stack profile** for demos, the dialog says so before you launch. That launch also instantiates the profile as a demo-scoped Stack in the same namespace - dependencies, add-ons, and manifests included - and tears the whole thing down with the demo. The per-demo quota rises to the full-stack row in the table above. Configure the designation in the **Demos** tab settings. The **Demos** tab also names that profile and lists the profile's own live demos, each one linking straight to its details. A profile can be demoed on its own - the same stack, without an application in front of it - which is usually a cheaper way to look at it than launching a whole application demo. See [Stack Profile Demos](/guides/stack-profile-demos). *** ## Reach the running demo Launching drops you back on the **Demos** tab, which lists every active demo with its status, preview URL, and remaining TTL. Each demo has a detail page carrying live provisioning progress read from the staging cluster, the namespace's bill of materials, Kubernetes events, and pod logs. How you reach it depends on DNS: 1. **An organisation demo base domain**, if configured, wins outright: `.`, with your ingress class and TLS secret. 2. **Otherwise the staging cluster's delegated Ankra DNS zone**, when active: `...ankra.cc` over HTTP. 3. **Otherwise in-cluster only** - the demo still runs, and the detail page gives you the service DNS name and a ready-made `kubectl port-forward` command. The full resolution order is documented under [the preview URL](/concepts/applications#the-preview-url). *** ## From the CLI and the AI Assistant ```bash theme={null} # Deploy a branch demo ankra application demo deploy --branch feature/login # Override the teardown timer ankra application demo deploy --branch feature/login --ttl-hours 8 # List active demos, then stop one early ankra application demo list ankra application demo stop ``` The deploy response includes `preview_url` when a public host was resolved. Ask the AI Assistant to demo a branch, or call the `deploy_pr_demo` tool directly - it is allowed in **Ask** mode, because a demo is isolated and self-expiring. Pass `env` to set per-launch variables. Tear down early with `demo_stop`, and inspect a failed one with `get_demo_diagnostics`. *** ## No built image for this branch When the registry holds nothing for the branch, the dialog does not dead-end. It offers, in order of effort: * **Recent image tags** from the same repository as one-click chips - handy for demoing the last good build while a new one is still running. * **Fix the build**, which diagnoses why no image exists and applies the safe fixes it can: restarting a failed application setup, repairing publish readiness, or re-running the latest workflow so it can push to the registry. When the deterministic fixes cannot unblock it, Ankra dispatches an agent mission and links you to its run so you can watch the work. * **Open CI/CD**, which jumps straight to the application's pipeline runs. *** ## Stopping a demo A demo stops itself when its TTL expires - namespace deleted, quota released, database gone. Stop one early from the **Demos** tab, with `ankra application demo stop`, or with the `demo_stop` tool. There is nothing to clean up afterwards. Demo namespaces are ephemeral by design. The throwaway database starts empty on every deploy and is wiped with the namespace - run your migrations on boot and never point a demo at data you care about. *** ## Troubleshooting | Symptom | What to check | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Launch demo** is disabled | The dialog names the reason on hover: no branch picked, an unresolved image tag, a TTL beyond your role's cap, an invalid container port, or an incomplete environment variable. | | No branches are listed | The application's Git credential can no longer read the repository. Re-check it on the application's settings, then reopen the dialog. | | Deployed, but the pod crash-loops | The demo runs *your* image, so a boot crash is application-side. Read the pod logs on the demo's detail page. If the container refuses to start without configuration, Ankra dispatches a [pre-setup agent](/concepts/applications#automatic-pre-setup-when-a-demo-crashes) that works out the missing variables, saves them as the application's demo defaults, and redeploys. | | Pods stay `Pending` | The namespace quota or the cluster is full. Check the capacity panel and the demo's Kubernetes events, and stop demos you no longer need. | | The preview URL does not resolve | The staging cluster needs an active Ankra DNS zone, or the organisation needs a demo base domain. Without either, use the port-forward command on the detail page. | | An environment variable did not reach the container | Per-launch values win by name over the application defaults, and an empty value is still a value. Confirm the final set on the demo's detail page bill of materials. | *** ## Related * [Preview demos](/concepts/applications#preview-demos) - the concept, the namespace model, and the isolation guarantees * [PR preview environments](/guides/pr-preview-environments) - the automatic per-pull-request flow and its status comment * [Environment variables and a throwaway database](/concepts/applications#environment-variables-and-a-throwaway-database) - the defaults layer shared by every demo surface * [GitHub Actions CI/CD pipeline](/guides/cicd-pipeline) - the build that publishes the image a demo deploys # Application CI/CD with GitHub Actions Source: https://docs.ankra.ai/guides/cicd-pipeline Build application images and publish them to your private Ankra registry Ankra Applications generates a GitHub Actions pipeline that builds your source repository, scans the image, and publishes it to your organisation's private registry. The generated Kubernetes manifests already reference that image and the matching pull secret. The Ankra registry is private. Ankra provisions its project, GitHub Actions credentials, and Kubernetes pull credentials automatically. ## How it works ```mermaid theme={null} flowchart LR Repo[Application repository] -->|connect| Ankra Ankra -->|open setup PR| PR[Setup pull request] PR -->|merge| Actions[GitHub Actions] Actions -->|build and scan| Image[Container image] Image -->|push| Registry[Private Ankra registry] Registry -->|pull| Cluster[Kubernetes cluster] ``` Create an Application from a GitHub repository. Ankra analyses the source and prepares the missing Dockerfile, Kubernetes manifests, and workflow. The pull request adds `.github/workflows/build-and-publish.yml` and manifests under `.ankra/manifests/`. Monorepos get one scoped workflow per application. Merging the pull request runs the workflow. It tests the source, builds the image, pushes it to your organisation's project on `registry.ankra.cloud`, and scans it with Trivy. The workflow also runs on `pull_request`, where it tests, scans the source, and builds the image without pushing it - so an unmerged branch never puts artifacts in your registry. The image scan follows the push, so it runs on branch builds only. Deploy the Application to a cluster. Ankra checks that an image was published before starting the deployment. ## Registry authentication Ankra installs these encrypted GitHub Actions secrets on the application repository: | Secret | Purpose | | ------------------------- | --------------------------------------------------------- | | `ANKRA_REGISTRY_USERNAME` | Push robot username for the organisation registry project | | `ANKRA_REGISTRY_PASSWORD` | Push robot password | The generated workflow uses the secrets with `docker/login-action`. It does not use `GITHUB_TOKEN` package permissions and does not publish a public package. For Kubernetes pulls, Ankra creates an `ankra-registry-pull` Docker registry secret in each managed namespace. Generated Deployments include: ```yaml theme={null} spec: template: spec: imagePullSecrets: - name: ankra-registry-pull ``` The same pull credential is injected into short-lived Application preview environments. ### Your own registry An Application that [declares its own registry](/concepts/applications#using-your-own-registry) publishes there instead. The workflow logs in with the secret names the declaration gives (defaulting to the `ANKRA_REGISTRY_*` pair), the generated Deployments reference the pull Secret it names, and Ankra creates that Secret in the deploy namespace from the registry credential the declaration names. Ankra does not write the login secrets for a registry you operate - the robots there are yours to administer, and overwriting a push robot with the credential Ankra holds would deny every later build. Publish readiness reports whether the named secrets exist. Opt in with `manage_actions_secrets: true` if you want Ankra to write them. ## Existing applications Reconcile an Application after the registry cutover. Ankra updates its image URL, replaces a legacy build workflow or manifest with the private registry version, and restores missing repository secrets. You can inspect readiness in the Application's **CI/CD** tab or from the CLI: ```bash theme={null} ankra application publish-readiness ``` Readiness checks the organisation registry project, both repository secrets, the workflow login target, and whether an image has been published. ## Troubleshooting Open the Application's **CI/CD** tab. If Ankra cannot restore the repository secrets, approve the updated Ankra GitHub App **Secrets** permission and retry the fix. Registry projects are provisioned automatically. The background reconciler retries missed provisioning. If readiness remains blocked after a few minutes, contact support. Confirm that the workflow logs in to the host shown in the Application image URL and uses `ANKRA_REGISTRY_USERNAME` and `ANKRA_REGISTRY_PASSWORD`. Reconcile the Application to replace a legacy workflow. Reconcile the Application and check the target namespace for `ankra-registry-pull`. Ankra rotates and reapplies pull credentials automatically. Ankra blocks deployment until it can verify a published image in the organisation registry. Check the latest GitHub Actions run, then retry after the image push succeeds. ## Next steps Connect a repository and follow the Application lifecycle. Review the GitHub App permissions used by Ankra. Add read-only deployment and health reporting to your CI workflows. Encrypt other secrets stored in GitOps. # Clone a Cluster Source: https://docs.ankra.ai/guides/clone-cluster Duplicate cluster configurations using the Ankra CLI. Clone stack configurations from existing clusters or remote repositories. Perfect for replicating production setups to staging or dev environments. *** ## Prerequisites * [Ankra CLI](/integrations/ankra-cli) installed and configured * A cluster configuration file (YAML) *** ## Clone from a Local File Copy stacks from an existing cluster configuration: ```bash theme={null} ankra cluster clone existing-cluster.yaml new-cluster.yaml ``` *** ## Clone from GitHub Pull configurations directly from a repository: ```bash theme={null} ankra cluster clone https://github.com/user/repo/raw/main/cluster.yaml my-cluster.yaml ``` *** ## Clone Options | Flag | Description | | ---------------- | ----------------------------------------------- | | `--clean` | Replace all stacks in target (clean copy) | | `--force` | Override conflicts during merge | | `--copy-missing` | Copy missing files even from skipped stacks | | `--stack` | Clone only specific stacks by name (repeatable) | **Examples:** ```bash theme={null} # Clean copy - replace all stacks in target ankra cluster clone source.yaml target.yaml --clean # Force merge - override conflicts ankra cluster clone source.yaml target.yaml --force # Clone only specific stacks ankra cluster clone source.yaml target.yaml --stack "monitoring" --stack "networking" # Complete replacement with all files ankra cluster clone source.yaml target.yaml --clean --force --copy-missing ``` *** ## Example Workflow ```bash theme={null} ankra cluster clone https://github.com/ankraio/ankra-gitops-examples/raw/main/clusters/monitoring-stack/cluster.yaml ./my-cluster.yaml ``` ```bash theme={null} ankra cluster apply -f my-cluster.yaml ``` Edit the YAML file or use the UI to adjust values for your environment (resource limits, domains, replicas). *** ## Clone via UI You can clone stacks directly in the Ankra UI: **Clone a single stack:** 1. Navigate to **Stacks** in your cluster 2. Click the menu on any stack card 3. Select **Clone to Cluster** 4. Choose a target cluster and click **Clone Stack** **Clone multiple stacks at once:** 1. Navigate to **Stacks** in your cluster 2. Click the **Clone Stacks** button next to the search bar (or click a stack card's avatar to start selecting) 3. Select the stacks you want to clone - a floating action bar shows the count 4. Click **Clone to Cluster**, choose a target cluster, and confirm 5. All selected stacks are cloned as drafts to the target cluster For a full guide on multi-stack cloning, see [Clone Stacks Between Clusters](/guides/clone-stack#clone-multiple-stacks-at-once). *** ## Next Steps Full CLI command reference. Example cluster configurations to clone. # Clone Stacks Between Clusters & Organisations Source: https://docs.ankra.ai/guides/clone-stack Learn how to clone one or multiple stacks from one cluster to another - including across organisations - for consistent deployments across environments Cloning stacks allows you to replicate your infrastructure configurations across multiple clusters - even across different organisations. You can clone a single stack or select multiple stacks at once. Cloned stacks are created as drafts, giving you the opportunity to review and customize them before deployment.