Skip to main content
The main reason a microservice belongs to the workspace rather than the instance is that a workspace object can travel with a release. A microservice is now surfaced in release diffs and release contents alongside APIs, functions, and tables, and moves with a release like any other object.

​
Microservices in a release

When you build a release, any microservice in the workspace is included in the release contents, and changes to it show in the release diff. There is nothing to opt into — a containerized dependency is subject to the same publish and promotion path as the API that calls it, instead of being kept in step by hand.
This is what makes a container-dependent backend shippable to isolated tenants at all. Under the instance-level model, a microservice couldn’t reach tier 2 and tier 3 tenants, so any backend that depended on a container was unshippable to them.

​
Tenant deploy mode

Each microservice is Auto or Manual, set when you create it. Manual is for a service you want present in the tenant but rolled out on your own schedule — a change with a data migration behind it, say, or a service whose tenants need staggering.

​
Deploy failures are reported

A microservice failing to deploy in a tenant does not fail the release deploy. The release itself still lands. That is deliberate, but it used to make failures invisible. Tenant deploys now return a per-microservice reconcile result, and the deploy panel surfaces them:
  • A persistent warning block listing each failure by tenant, microservice, and reason.
  • A warning toast summarising the count.
  • On a partial failure the panel stays open so the list stays readable, and the tenant-list refresh is deferred until you close it — the results don’t vanish out from under you.
A release that reports microservice failures has still deployed. Your APIs, functions, and tables are live in the tenant; what’s missing is the container the affected microservice provides, so anything calling it will fail until you resolve the failure and redeploy.
Common reasons a tenant deploy fails when the workspace deploy succeeded:
  • Image or chart not pullable from the tenant’s context — most often expired credentials. This is the failure mode that makes short-lived AWS ECR tokens worth planning around.
  • Insufficient resources in the tenant’s namespace for the requested CPU/RAM.
  • A chart values problem that only manifests with the tenant’s configuration.

​
Tenant infrastructure panel

Infrastructure items in the Tenant Center — pods, deployments, services, persistent volume claims, ingresses, and jobs — now carry a scope of either tenant or microservice, so you can tell which resources belong to the tenant itself and which belong to a microservice you shipped. What each tenant tier sees: Detail views for an infrastructure item share one layout: a status pill, vitals chips, grouped definition rows, collapsed metadata, and a status-history timeline. See Tenant Center for the rest of the tenant management surface.