Skip to main content
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.
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.

​
Built-in deployments

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

​
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.
2

​
Point at the image

Enter the image reference the way you would pass it to docker pull:
Image
If the image lives in a private registry, turn on the private-image toggle — see Private registries.
3

​
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.
4

​
Choose resources

Pick a preset card, each labelled with its plain-language spec: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.
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.
5

​
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.
6

​
Test image access, then create

Before creating, click Test image access to confirm Xano can actually pull the image. See Testing image access for what each verdict means — the probe works for public images too, with no credentials entered.

​
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:
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.
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.

​
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.
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.
See the XanoScript reference for the full block syntax.