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

# Creating a Microservice

> Define a containerized service from an image or a Helm chart, with a live XanoScript preview.

From **Test & Deploy → Microservices**, click **Add Microservice** (or use the inline create action next to the sidebar entry). A slide-in panel opens with the form on the left and a live preview on the right.

## The two-pane layout

The preview pane stacks two things:

* **Summary** — the resolved configuration: image, credential method and registry host, the generated pull-secret name, ports, resources, and the image-access verdict. This is what the form actually amounts to, read back to you in plain terms.
* **XanoScript** — the live script the form is producing, updating as you type.

**Hide XanoScript** collapses the preview back to the narrow form. The hosting panel widens automatically for the split view and restores its previous width when you close it.

<Tip>
  The **Load example** dropdown fills the form with a working echo-server preset — one for each deployment path (Docker image, Helm via OCI registry, Helm via `.tgz` URL, Helm via classic HTTP repo). It's the fastest way to see a real microservice deploy end to end before you wire up your own.
</Tip>

## Built-in deployments

Choose **Built-in** when you have a container image and want Xano to build the deployment for you.

<Steps>
  <Step>
    ### Name and describe the service

    The **Name** is what you'll see in the list, in release diffs, and in the function stack host picker. It is also sanitized into the XanoScript identifier and the container name — lowercased, with any run of non-alphanumeric characters collapsed to an underscore. `echo-docker` becomes `echo_docker`.

    The **Description** is optional and appears alongside the name in the list.
  </Step>

  <Step>
    ### Point at the image

    Enter the image reference the way you would pass it to `docker pull`:

    ```text Image theme={null}
    ealen/echo-server:latest
    ```

    If the image lives in a private registry, turn on the private-image toggle — see [Private registries](/enterprise/enterprise-features/microservices/workspace-microservices/private-registries).
  </Step>

  <Step>
    ### Add ports

    Ports are repeatable rows of two values:

    * **Service port** — the port Xano exposes the microservice on. This is the port you'll address from the function stack.
    * **Container port** — the port your application listens on inside the container. It defaults to the service port, so for the common case where they match you only fill in one field.

    Add a row for every port that needs to be reachable.
  </Step>

  <Step>
    ### Choose resources

    Pick a preset card, each labelled with its plain-language spec:

    | Preset  | CPU     | RAM      | Suited to                                           |
    | ------- | ------- | -------- | --------------------------------------------------- |
    | Tiny    | `100m`  | `128Mi`  | Lightweight sidecars and simple echo/proxy services |
    | Small   | `250m`  | `512Mi`  | Light APIs and small background workers             |
    | Medium  | `500m`  | `1024Mi` | Moderate workloads and typical web services         |
    | Large   | `1000m` | `2048Mi` | Heavier services handling sustained traffic         |
    | X-Large | `3500m` | `7168Mi` | Compute-intensive or memory-hungry containers       |

    **Custom** reveals CPU (millicore) and RAM (Mi) dropdowns instead. The presets and the dropdowns stay in sync in both directions — picking a preset sets the dropdowns, and choosing dropdown values that match a preset re-selects that card.

    <Note>
      `100m` is one tenth of a CPU core; `1000m` is one full core. `1024Mi` is one gibibyte. These are raw Kubernetes resource strings, which is why the UI shows the friendly form (`0.5 vCPU · 1 GB`) next to them.
    </Note>
  </Step>

  <Step>
    ### Set the tenant deploy mode

    **Auto** (the default) deploys the microservice into tenants as part of any release deploy that contains it. **Manual** still ships it with the release but does not deploy it there automatically.

    If you aren't using tenants, leave this on Auto — it has no effect.
  </Step>

  <Step>
    ### Test image access, then create

    Before creating, click **Test image access** to confirm Xano can actually pull the image. See [Testing image access](/enterprise/enterprise-features/microservices/workspace-microservices/private-registries#testing-image-access) for what each verdict means — the probe works for public images too, with no credentials entered.
  </Step>
</Steps>

## Helm deployments

Choose **Helm** to deploy a chart you already ship, rather than re-expressing it as an image, ports, and resources.

### The chart reference field

One field accepts every common way of naming a chart. Xano works out which form you've used:

<CodeGroup>
  ```text OCI registry theme={null}
  oci://us-docker.pkg.dev/xano-registry/public/echo-server
  ```

  ```text Direct .tgz URL theme={null}
  https://ealenn.github.io/charts/echo-server-0.5.0.tgz
  ```

  ```text Pre-added repo theme={null}
  my-repo/echo-server
  ```

  ```text Classic HTTP repo theme={null}
  https://ealenn.github.io/charts echo-server
  ```
</CodeGroup>

The classic HTTP repo form is the repository URL and the chart name separated by a space — the same two values `helm repo add` and `helm install` would take.

### Version

Pin the chart version in the **Version** field.

The field is hidden for a direct `.tgz` URL, because the version is already in the filename and a separate version has nothing to apply to. It also clears when you switch between reference forms, so a version left over from an OCI reference can't silently attach itself to a `.tgz` URL.

### Values

Chart values are supplied as YAML, exactly as you would pass them with `helm install -f`.

<Warning>
  Values YAML may contain secrets, so it is **masked server-side and never returned**. You can set it when you create the microservice, but you cannot read it back out or edit it from the UI afterward. Keep your source of truth for values outside Xano.
</Warning>

### The Helm preview

For a Helm microservice the XanoScript pane is a **read-only preview**. The create flow reads the chart configuration from the form fields directly rather than parsing the script, so the pane shows you what will be stored without being hand-editable.

## Authoring in XanoScript

For built-in microservices the form drives the script live, and the script is the thing that gets saved.

Two controls change who owns it:

* **Edit script directly** hands ownership to the script. From that point the form stops overwriting it, and saving routes through the script rather than the form fields. Use this for anything the form doesn't expose.
* **Sync from form** regenerates the script from the current form state, discarding hand edits.

<Note>
  While the script is a form-driven mirror, XanoScript validation is suppressed — the language service doesn't yet know the `microservice` type. Validation is re-enabled once you take the script over with **Edit script directly**.
</Note>

See the [XanoScript reference](/enterprise/enterprise-features/microservices/workspace-microservices/xanoscript-reference) for the full block syntax.


## Related topics

- [Microservices in the Workspace](/enterprise/enterprise-features/microservices/workspace-microservices.md)
- [Microservices](/enterprise/enterprise-features/microservices.md)
- [Ollama](/enterprise/enterprise-features/microservices/ollama.md)