Resource Sizes & Health Checks

Resource Sizes

Every service runs at one of three sizes. Each size has a guaranteed baseline and a burst limit the service can use when the node has spare capacity.

Size	Guaranteed	Burst limit	Good for
Small	25m CPU, 64Mi RAM	500m CPU, 512Mi RAM	Frontends and light APIs
Medium	50m CPU, 128Mi RAM	1 CPU, 1Gi RAM	APIs with database queries
Large	100m CPU, 256Mi RAM	2 CPU, 2Gi RAM	Heavy workloads and workers

A service that goes over its memory limit is OOMKilled and restarted automatically. If that happens regularly, move it to a larger size.

Sizes by Plan

• Free and Starter: Small
• Growth: Small and Medium
• Scale: Small, Medium, and Large

Choosing a size your plan doesn't include is refused with a message saying so. See When You Hit a Plan Limit.

Changing a Service's Size

Edit the service from the tenant's Services tab, choose a new size, and save. The new size applies on the next rollout.

Health Checks

A health check tells Staxa when a new deployment is ready to receive traffic. Each service has one of three types:

• HTTP request: Staxa sends a GET request to a path you choose (it must start with /) and expects a 2xx or 3xx response. The port defaults to the service port, or you can set another one.
• TCP connect: Staxa only checks that the port accepts connections. No HTTP request is made. Useful for non-HTTP services.
• None: No readiness probe. The service is considered ready as soon as its container starts. Use this for workers and consumers that never listen on a port.

If a deployment never becomes ready, check that the path returns a success status and that your app is listening on the right port. Build and runtime logs are on the tenant detail page.