Scaling and resources
Regions, instances, CPU, memory, storage and health checks.
Regions
An app runs in every region you select under Runtime settings → Regions, and production and preview can use different regions. Teral currently runs in one region, eu-central-1, with more planned.
Instances
Instances sets a range per region, such as 1 – 3. Teral always keeps the minimum running and adds instances up to the maximum when average CPU use stays high. When load drops, it removes them again after about a minute, down to the minimum.
Setting the minimum and maximum to the same number turns autoscaling off. Requests are spread across all healthy instances in a region at random, so there's no session affinity: store sessions outside the instance.
With one instance, a restart or a failing host makes the app unavailable for a moment. For production, run at least two.
CPU and memory
CPU is the most an instance can use, from 1/4 vCPU to 16 vCPU. Memory is the most an instance can hold, from 256 MiB to 32 GiB. An instance that goes over its memory is restarted. Watch the deployment's memory chart when you pick a size.
The largest size you can choose depends on your plan, see Settings → Limits in your workspace.
Storage
Without storage, everything an instance writes to its filesystem, including /tmp, shares 128 MiB.
Storage adds a disk of 512 MiB up to 50 GiB to each instance, mounted at /data. Your app can find the path in TERAL_EPHEMERAL_DISK_PATH. Each instance gets its own disk, which starts empty and is deleted when the instance stops. Use it for scratch work such as processing uploads, not for data you need to keep. Keep that in a database or object storage.
Health checks
A health check is an HTTP endpoint Teral calls on every instance. In the dashboard you set the method (GET or POST), the path, such as /health, and the interval, such as 30s, 2m or 1h. The API also lets you set the rest:
| Setting | Default |
|---|---|
| Interval between checks | 10 seconds |
| Timeout per check | 5 seconds |
| Failed checks in a row before a restart | 3 |
| Delay before the first check | 0 seconds |
Teral uses it in two ways:
- A new deployment only becomes ready once its instances pass the check.
- An instance that keeps failing stops getting traffic and is restarted.
Any 2xx response passes. Keep the endpoint simple: if it checks your database and the database has a hiccup, every instance fails at once and the whole app goes down. Without a health check, Teral treats an instance as healthy while its process runs.
Shutdown
When Teral replaces or removes an instance, it sends SIGTERM. Finish in-flight requests and exit within 30 seconds. After that the process is killed.