ActiveManage Docs ← Back to activemanage.co.uk

Hosting the API Server

The API server is the HTTP service that handles every API request. In most ActiveManage deployments it runs in the same PHP-FPM process pool as the web UI. For very high-load deployments you can split it onto dedicated infrastructure.

Topology diagram showing load balancer fronting two PHP-FPM pools — one for web UI, one for /api/* requests — both reading/writing the shared MySQL cluster and Redis cache

Default Setup

A single PHP-FPM pool serves both / (web UI) and /api (REST). Nginx routes by path. This is the simplest topology and fine up to roughly 500 requests/second.

Splitting the API onto a Dedicated Pool

  1. Provision a second PHP-FPM pool with its own worker count, memory limit and timeout.
  2. Update Nginx to send location /api to the new pool.
  3. Optionally use a separate FPM config with tighter PHP memory limits — API requests are usually smaller than full-page renders.
  4. Health-check both pools independently; the platform exposes /healthz on each.

Why Split?

  • Different resource profiles: Web requests render full pages; API requests are typically smaller and faster. Different worker counts make sense.
  • Stability isolation: A surge of API traffic doesn't crowd out interactive users.
  • Independent scaling: Add API capacity without doubling web capacity.
  • Auditing and logging: Separate log files make analysis cleaner.

Worked Examples

  • Small SaaS: Single combined pool, 16 workers, 2GB total memory. Sufficient until ~200 concurrent users.
  • Growing mid-market: Split into web (24 workers) and api (16 workers). Each scaled independently per usage.
  • Marketplace at scale: Dedicated API hosts, autoscaled by Kubernetes based on request rate. Web tier separately scaled by page-views.