Skip to main content
A workspace microservice is stored as a XanoScript microservice block. The Add Microservice form writes it for you and keeps it in sync as you fill the form, so you never have to write it by hand — but the script is the stored definition, it is what appears in release diffs, and Edit script directly hands it to you.
The XanoScript language service does not yet know the microservice type, so editor validation is suppressed while the script is a form-driven mirror, and re-enabled once you take it over with Edit script directly.

Built-in deployment

With a private image, a pull_secret line is added naming the microservice-owned secret Xano provisions:

Helm deployment

Multi-line chart values are rendered as a triple-quoted block:

Reference

Top level

The block is opened with microservice followed by an identifier. The identifier is the microservice name sanitized: lowercased, with each run of non-alphanumeric characters collapsed to a single underscore, and leading and trailing underscores stripped. A microservice named Echo Docker yields the identifier echo_docker.
string
Optional. Shown next to the name in the microservices list. Omitted from the script entirely when blank.
string
default:"builtin"
"helm" for a bring-your-own-chart microservice. Omitted for the built-in type, which is the default.
string
default:"auto"
"auto" or "manual". Both ship the microservice with a tenant release; "manual" does not deploy it in the tenant automatically. See Releases and tenants.

deployment

Present for the built-in type. Holds one or more container blocks, each opened with container followed by an identifier — for a single-container microservice this matches the microservice identifier.
string
required
The container image, as you would pass it to docker pull.
string
The pull secret for a private image. Xano provisions a microservice-owned secret named <identifier>-pull; this line is emitted only when private-registry credentials are configured. See Private registries.
array
required
An array of port objects. servicePort is the port Xano exposes and the one you address from the function stack; containerPort is what the application listens on inside the container, defaulting to servicePort.
object
required
CPU and RAM allocation as raw Kubernetes resource strings — CPU in millicores, RAM in mebibytes.
The form’s presets map to 100m/128Mi (Tiny), 250m/512Mi (Small), 500m/1024Mi (Medium), 1000m/2048Mi (Large), and 3500m/7168Mi (X-Large).

chart

Present when kind = "helm", in place of deployment.
string
required
The chart reference, in any of the four supported forms.
string
The chart version. Omitted for a direct .tgz URL, where the version is already in the filename.
string
Chart values as YAML, equivalent to helm install -f. A single-line value is a plain quoted string; multi-line values use a triple-quoted block, with the content lines and the closing quotes indented one level deeper than the values = line.
values is readable by anyone with access to the workspace: it is part of the microservice’s XanoScript, so it comes back when you read the microservice and you can edit it in place. Do not put a secret here directly. Reference a workspace environment variable as ${env.NAME} instead, inside single quotes in the YAML (apiKey: '${env.STRIPE_KEY}'), with a value on one line (see Creating a microservice). It is resolved only when the microservice deploys.