Skip to content

Scaling

Moved

The concrete sizing profiles (Small/Medium/Large/XL), the pipeline traffic light, and applying new worker/Postgres/Redis values now live under Admin → Maintenance → Resources → Performance — see Resources. This page remains as a conceptual guide: when is a bigger profile enough, when do you need more?

When to scale?

Signs that the current size no longer suffices:

  • The pipeline traffic light under Resources → Performance is yellow or red
  • The RAM distribution under Resources → RAM shows one service (usually the database) permanently close to the server limit
  • New check results visibly arrive delayed in the frontend

First reaction: pick a higher sizing profile (see Resources → Performance). That covers most cases without touching individual .env variables by hand.

Vertical vs. horizontal

Path Pro / con
Vertical — bigger sizing profile, more RAM/CPU on the server Simple (one click + container restart), no architecture change, eventually hardware-limited
Horizontal — multiple API containers, external database/Redis More complexity, but growth far beyond a single server

Recommendation: scale vertically first, up to the largest sensible server configuration (XL profile, 16 GB+ RAM). Only then think horizontally.

Externalizing (Postgres / Redis)

For very large setups it can make sense to take Postgres or Redis out of the compose stack and use a dedicated or managed service. Rough steps:

  1. Set up the external instance (same Postgres major version, TimescaleDB extension installed)
  2. Migrate the data (restore the built-in backup's dump into it)
  3. Switch the connection variable in .env to the external instance
  4. Remove the corresponding service from your own compose stack

This path isn't officially tested end-to-end — try it out on a test instance first, including a full restore drill.

Next