Service

Every Service Template requires a DNS-compatible name with a maximum length of 60 characters. Because the name is used as the service's address on the private network, it must follow DNS naming rules:

• Only lowercase letters (a–z), digits (0–9), and hyphens (-).
• Must start with a letter.
• Cannot end with a hyphen.

The service name is how services address each other on the private network. Within any Environment, all Services are allowed to communicate with each other with no firewall restrictions. No communication between Services is allowed across Environments.

See the Ingress network and Internal load balancing sections for more information on network flows.

Each Service Template release is versioned using the major.minor.patch format. Every time you release a new version you can choose how to increment the version based on your organisation's versioning policy.

A Service can be exposed to the internet using ingress rules. You configure which ports receive external traffic and how requests are routed to your container. Internet ingress is supported on ports 80 (HTTP) and 443 (HTTPS). If no mapping is defined for port 80, traffic is automatically redirected to port 443.

You can map external ingress to your own domain name by configuring a custom DNS during service deployment — for example, pointing app.mydomain.com to your Service's public endpoint.

enableIngress — A boolean flag that turns ingress on or off for the Service. When disabled, the Service is only reachable from other Services within the same Environment over the private network.

ingressConfig.rules — A list of routing rules that control how external traffic reaches your containers. Each rule has the following properties:

Example — The following rule exposes the Service at https://<rootdomain>/auth/realms/app and forwards traffic to internal load-balanced port 80:

{
  "path": "/auth/realms/app",
  "pathType": "Prefix",
  "ingressPort": 443,
  "internalLoadBalancerPort": 80,
  "matchType": "PathPrefix"
}

RAM

• Request — The amount of RAM (in MB) allocated to the Service at startup. If the Service needs additional memory it will be allocated up to the Limit.
• Limit — The maximum amount of RAM that can be allocated. If the Service attempts to use memory beyond this value it will be OOM-killed and restarted.

If no request is specified, the full limit is allocated. In a Dev environment, where many services typically run on resource-constrained machines with very little load, a default request of 200 MB is set automatically. This allows developers to run a large number of lightly loaded services on their developer machines.

CPU

• Request — The minimum number of millicores (1/1000th of a CPU core) guaranteed to the Service at startup.
• Limit — The maximum number of millicores the Service can consume. If the Service attempts to use CPU beyond this value it will be throttled.

As with RAM, if no CPU request is specified, the full limit is allocated. In Dev environments, a default request of 20 millicores is applied to allow a large number of services to share limited compute resources.

Probes are periodic health checks that the platform performs against your Service to determine whether it is starting correctly, ready to accept traffic, and still running. Three probe types are available:

Startup Probe

The startup probe checks whether your application has finished initializing. Until the startup probe succeeds, the liveness and readiness probes are disabled. This is useful for Services that have a slow startup — it prevents the liveness probe from killing the container before the application is ready.

Readiness Probe

The readiness probe determines whether the Service instance is ready to accept traffic. When the probe fails, the instance is removed from the internal load balancer and stops receiving requests from both ingress and other Services in the Environment. Once the probe succeeds again, traffic is restored.

The readiness probe is critical for safe production upgrades. During a rolling upgrade, the platform upgrades instances in batches of 25%. It waits for each batch's readiness probes to pass before proceeding to the next batch. Without a readiness probe, the platform has no way to verify that newly upgraded instances are healthy — if a bad update is pushed, it will roll through every batch unchecked and bring down the entire Service. Always configure a readiness probe in production.

Liveness Probe

The liveness probe checks whether the Service instance is still running. If the probe fails for a sustained period, the platform kills and restarts the container. This helps recover from deadlocks or other states where the process is alive but unable to make progress.

Probe Configuration Fields

When you enable high availability, multiple replicas of your Service are deployed across different availability zones. This makes your Service resilient to an AZ failure.

Replica scaling can be manual or automatic. With manual scaling you specify the exact number of replicas to deploy. With autoscaling you set a minimum and maximum replica count and ModStack scales up or down based on load. The currently supported autoscaling metric is CPU utilisation. Support for additional scaling metrics is planned for a future release.

Each Service Template supports up to 10 configuration sets. A configuration set is a file — a properties file, a YAML file, or any other format — that you specify along with the path where it should be mounted inside the container. This is your primary way of providing runtime configuration to a Service.

Secrets work similarly to configuration sets. You can specify multiple secrets, each as a file that is mounted at a specified path inside the container. Secret values are stored encrypted and are never exposed in logs, build outputs, or the dashboard UI.