Skip to main content
AI workspaces are short-lived workloads Ankra’s AI runs for you: code-search workspaces, agent and subagent pods, and time-limited PR demos of your applications. They all run on a staging cluster you designate, never on your production clusters. Configure everything under AI → Settings → Workspaces.

​
Staging Cluster

Pick one of your connected clusters as the staging cluster. Its agent must be online for workspaces to start - the page shows the agent status for the saved cluster. The same card sets the default AI mode new integrations start in (for example Ask, which allows read-only operations plus low-risk creates) - individual Slack, Teams, and Git connections can override it.

​
Custom Ankra Domain

Every hostname Ankra generates for the organisation - its delegated DNS zone, each cluster’s domain, and the preview URLs built from them - nests under a root domain. That root is ankra.cc unless you register your own in the Custom Ankra domain field on this page. The domain must be a bare domain you own, delegated to Ankra’s nameservers before you save; the write is refused otherwise and names the nameservers to point at. Registering a domain creates one subzone in it - <org_short_id>.<domain> - and Ankra works only inside that subzone. Records already published at the apex or under any other name are never read, written or deleted, so a domain that already serves your production hostnames is safe to register on that count. Changing the domain is refused while cluster domains or DNS records still live under the old root, and the refusal lists exactly which ones. It also separates the records you clear yourself from the ones the platform publishes and re-asserts, naming what to remove instead - deleting a reconciled record only lasts until the lane that owns it runs again. See the preview URL for the full switch procedure and what a switch does and does not touch, and ankra org domain get|set for the CLI equivalent.

​
Preview Domain

PR demos can get a public URL. Point a wildcard DNS zone at the staging cluster’s ingress, then set the preview domain, ingress class, and TLS secret here. Without a preview domain, demos stay in-cluster only.
The Preview domain and the Custom Ankra domain above it are different settings with very different blast radius. The preview domain decides only where demos are published: Ankra writes nothing in that zone, and changing it is one field write with no blockers. The custom Ankra domain re-roots every hostname Ankra generates, and the switch is refused while cluster domains or DNS records still live under the old root. If you only want demos on your own domain, the preview domain is the one you want.

​
DNS on your own preview domain

Publishing the records is the one prerequisite, and there are two ways to meet it. Ankra mints each demo a hostname under the preview domain, but the external-dns credential it provisions for a cluster is scoped to that cluster’s own Ankra subzone and nothing else, so on its own the platform creates no record on your domain. Declare the domain as a custom DNS zone (ankra org dns credentials create, then ankra org custom-dns-zones add --zone <preview domain> --credential <name>; see serving a zone in your own DNS account from every cluster). Ankra then runs a second external-dns on every cluster with your credential, and each preview host is published as its Ingress lands - the same way the Ankra subzone works. The preview domain also becomes every cluster’s cluster domain: ${{ ankra.cluster_domain }} in stacks and profiles, Ankra AI’s hostname advice, the deploy wizard’s default hostname and ankra cluster domain all report it instead of the generated Ankra domain. This is the route for a domain that lives in your own DNS account and so cannot be registered as the Custom Ankra domain. Or point a wildcard at the staging cluster. A wildcard *.<preview domain> pointing at the staging cluster’s ingress address covers every demo without further work. Per-host records do not: each demo gets a fresh hostname nobody has published yet. The wildcard reaches only the staging cluster, so it does not make the preview domain the cluster domain elsewhere. Without either, a demo still deploys and still reports ready, and its URL does not load. The certificate goes the same way, because an HTTP-01 challenge is answered over the hostname being certified: if the name does not resolve, Let’s Encrypt cannot reach the solver and no certificate is ever issued. So an unpublished preview domain costs you the URL and the TLS together. The settings screen and ankra org ai-environment get say so when the domain answers nothing and no custom DNS zone covers it, naming both routes and the cluster’s ingress address to point a wildcard at. On the Ankra subzone none of this applies: the platform provisions the zone and the in-cluster external-dns publishes each preview record itself.

​
TLS on your own preview domain

Demos get a certificate on both paths. Ankra requests one per preview hostname from the staging cluster’s letsencrypt-prod ClusterIssuer, the one the cloud networking stack installs, and the preview URL is https. Setting a preview domain does not change that. Each demo’s hostname is concrete when Ankra writes the ingress and it resolves publicly, so an HTTP-01 challenge answers for it exactly as it does on the Ankra subzone. No wildcard certificate is involved, and none is needed.
A wildcard would in fact be hard to obtain: ACME issues wildcards only through DNS-01, and the ClusterIssuer the networking stack installs is HTTP-01 only. Per-preview certificates avoid the question entirely.
Two fields change the default: The two are alternatives, and setting both is refused: cert-manager issues into whichever secret the ingress names, so a certificate ordered alongside your own would be written straight over it. Ankra only requests a certificate when the staging cluster actually carries an ACME HTTP-01 ClusterIssuer. On a cluster without one, demo ingresses carry no TLS and previews are served over plain http - claiming TLS against a certificate nothing will issue would be worse. The settings screen and ankra org ai-environment get both say so when that is the case, so it is never something you discover by opening a preview. Naming a certificate issuer without a preview domain is refused: on the Ankra subzone Ankra picks the issuer itself, from the networking stack it can verify. From the CLI:
Only the flags you pass are written; pass one with an empty value to clear that field. See PR preview environments for the full flow from pull request to running demo.

​
Time-to-Live

Workspaces clean themselves up:
  • Workspace TTL - how long code-search and agent workspaces live.
  • Demo TTL - the default lifetime of a PR demo.
  • Per-role caps - the longest a member of each role (admins and owners, operators, members) can keep a demo running.

​
Active Workspaces

The bottom of the page lists every running workspace and PR demo with its cluster, namespace, and expiry. Admins can terminate any of them; the workspace’s namespace on the staging cluster is deleted shortly after.

​
Permissions

Changing the staging cluster, custom Ankra domain, preview domain, or TTLs requires organisation admin. All members can see the active workspace list.