Skip to main content
Quick SummaryMicroservices are now a first-class workspace object, found under Test & Deploy → Microservices in the workspace sidebar. You define a containerized service — a container image, or your own Helm chart — deploy it into the workspace, watch the rollout, read logs, inspect pods, call it from the function stack, and ship it with tenant releases, all without leaving the workspace.
Workspace microservices are an Enterprise capability and are being enabled customer by customer. If you don’t see Microservices in your workspace sidebar, contact your Xano representative.

​
Workspace microservices vs. instance microservices

Xano has always supported instance-level microservices, configured from the instance selection screen. That feature is unchanged and remains available. Workspace microservices are a second, separate place a microservice can live — and the two now appear together in the host list when you call one from the function stack. Nothing about the instance-level feature is deprecated by this. If you have a container that serves the whole instance and never needs to travel with a release, it can stay where it is.

​
Why it lives in the workspace

Instance-level microservices were configured from the instance selection screen rather than the workspace, which meant the person building the backend and the person deploying the service it calls were working in two different places. A microservice was also outside the workspace’s own model of what a backend is: it wasn’t something you could see in a release diff, so it didn’t move with a release the way an API, function, or table does. Teams shipping to tenants had to deploy the service separately and keep it in step by hand — and tier 2 and tier 3 tenants couldn’t be reached at all. A workspace microservice is a workspace object like everything else. It is defined in XanoScript, edited in the same editor, included in release contents and diffs, and deployed to tenants with the release that contains it. Everything you would otherwise leave the product to check — rollout state, container logs, pod health, why an image won’t pull — is on the detail page, and image access can be verified before you deploy rather than diagnosed from a failed rollout.

​
Core concepts

A microservice is one of two shapes.Built-in is the declarative case: you give it an image, one or more ports, and a CPU/RAM allocation, and Xano builds the Kubernetes objects for you.Helm brings your own chart. If your platform team already ships this application as a chart, you point at the chart rather than re-expressing it in a narrower form. The chart reference field accepts every common form — an oci:// reference, a direct .tgz URL, a pre-added repo/chart, or a classic HTTP repo URL paired with a chart name.
Every microservice carries a live status, shown as a badge on the list page and in the detail header:A disabled microservice is excluded from the function stack host list, because there is no running Service to call.
Each microservice is set to Auto (the default) or Manual.Both modes ship the microservice with a tenant release. The difference is what happens on the far side: Auto deploys it into the tenant as part of the release deploy, and Manual does not — it arrives with the release, and you deploy it yourself.
A workspace microservice is stored as XanoScript, the same language the rest of your workspace is defined in. The create form writes the script for you and keeps it in sync as you fill the form; you can also take the script over and hand-edit it. See the XanoScript reference.

​
The microservices list

Test & Deploy → Microservices lists every microservice in the workspace with:
  • Name and description
  • Status — the live badge described above
  • Tenant deploy — Auto or Manual
  • Last deployed — the timestamp of the most recent successful deploy
If the workspace has none yet, an empty state offers Add your first microservice.

​
Where to go next

Creating a microservice

The Add panel: built-in vs. Helm, ports, resources, live XanoScript preview.

Private registries

Docker, Google Artifact Registry, and AWS ECR credentials, plus the image-access probe.

Deploying and monitoring

Rollout stages, logs, pods, restart, undeploy, and delete.

Calling from the function stack

Address a workspace microservice from an API, function, or task.

Releases and tenants

How microservices travel with a release and what happens when a tenant deploy fails.

XanoScript reference

The full microservice block, for both deployment types.