> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xano.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Microservices in the Workspace

> Define, deploy, and ship containerized services as first-class workspace objects.

<Info>
  **Quick Summary**

  Microservices 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.
</Info>

<Note>
  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.
</Note>

## Workspace microservices vs. instance microservices

Xano has always supported [instance-level microservices](/enterprise/enterprise-features/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.

|                                  | Instance microservices                           | Workspace microservices                           |
| -------------------------------- | ------------------------------------------------ | ------------------------------------------------- |
| Where you configure it           | Instance Settings → Microservices                | Workspace sidebar → Test & Deploy → Microservices |
| How it's defined                 | Deployment form (image, ports, volumes, configs) | XanoScript, authored from a form or by hand       |
| Packaging                        | Container image                                  | Container image **or** your own Helm chart        |
| Appears in release diffs         | No                                               | Yes                                               |
| Ships to tenants                 | No                                               | Yes, with the release that contains it            |
| Callable from the function stack | Yes                                              | Yes                                               |

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

<AccordionGroup>
  <Accordion title="Deployment type: built-in or Helm">
    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.
  </Accordion>

  <Accordion title="Status">
    Every microservice carries a live status, shown as a badge on the list page and in the detail header:

    | Status      | Meaning                                                |
    | ----------- | ------------------------------------------------------ |
    | `pending`   | Defined but never deployed                             |
    | `deploying` | A rollout is in progress                               |
    | `ok`        | Running and ready                                      |
    | `error`     | The deployment is missing, or a pod hit a hard failure |
    | `disabled`  | Turned off — nothing is running                        |

    A `disabled` microservice is excluded from the function stack host list, because there is no running Service to call.
  </Accordion>

  <Accordion title="Tenant deploy mode">
    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.
  </Accordion>

  <Accordion title="XanoScript">
    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](/enterprise/enterprise-features/microservices/workspace-microservices/xanoscript-reference).
  </Accordion>
</AccordionGroup>

## 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

<Columns cols={2}>
  <Card title="Creating a microservice" icon="plus" href="/enterprise/enterprise-features/microservices/workspace-microservices/creating-a-microservice">
    The Add panel: built-in vs. Helm, ports, resources, live XanoScript preview.
  </Card>

  <Card title="Private registries" icon="key" href="/enterprise/enterprise-features/microservices/workspace-microservices/private-registries">
    Docker, Google Artifact Registry, and AWS ECR credentials, plus the image-access probe.
  </Card>

  <Card title="Deploying and monitoring" icon="chart-line" href="/enterprise/enterprise-features/microservices/workspace-microservices/deploying-and-monitoring">
    Rollout stages, logs, pods, restart, undeploy, and delete.
  </Card>

  <Card title="Calling from the function stack" icon="code" href="/enterprise/enterprise-features/microservices/workspace-microservices/calling-from-the-function-stack">
    Address a workspace microservice from an API, function, or task.
  </Card>

  <Card title="Releases and tenants" icon="building" href="/enterprise/enterprise-features/microservices/workspace-microservices/releases-and-tenants">
    How microservices travel with a release and what happens when a tenant deploy fails.
  </Card>

  <Card title="XanoScript reference" icon="file-code" href="/enterprise/enterprise-features/microservices/workspace-microservices/xanoscript-reference">
    The full `microservice` block, for both deployment types.
  </Card>
</Columns>


## Related topics

- [Microservices](/enterprise/enterprise-features/microservices.md)
- [Ollama](/enterprise/enterprise-features/microservices/ollama.md)
- [Calling from the Function Stack](/enterprise/enterprise-features/microservices/workspace-microservices/calling-from-the-function-stack.md)