Capacity and sizing

Areca is sized for a small agency: a few dozen client sites, one CMS process and one PostgreSQL database. This page lists the limits the project designs for, the benchmark results behind them, and the settings you can tune. Read it before you choose a server size, and again before you add clients.

Supported envelopeCopy Anchor Link

These are the targets the instance is designed and measured against. They are not hard limits, with two exceptions noted in the table.

The 20 MiB upload limit is the only hard limit a user can hit in normal work. The log caps protect the database and the publish screen.

Benchmark resultsCopy Anchor Link

The project ships a benchmark that seeds a synthetic instance and measures the application code. It does not measure HTTP, network or object storage, so treat the numbers as the cost of the code itself.

The reference dataset has 50 sites across 5 clients. The largest site has 2,000 entries, each with rich text, embedded images and references, and 5 revisions per entry. The largest client has 10,000 assets. Each site keeps 3 retained publications, and the largest site keeps 10.

The reference run used an Apple M4 (10 cores, 16 GB), macOS, Node 24.21 and PostgreSQL 17.11 in a local container, so database latency was close to zero. Your numbers will differ on a remote database.

The snapshot build dropped from about 6 seconds to about 0.5 seconds because the build now loads asset details in batches instead of one query per row. The asset usage check is still a full scan of the client's content, so it remains slow for a referenced asset.

Memory for the largest snapshot build was measured at about 175 to 205 MB of heap growth and a process peak of about 700 to 830 MB resident memory.

The table sizes in the reference dataset were about 20 MB for entries, 31 MB for revisions, 66 MB for publications and 4 MB for assets. The largest site's snapshot is about 22 MB of JSON.

Run the benchmark yourselfCopy Anchor Link

Run the benchmark against a throwaway PostgreSQL database, never against a live instance. The tool refuses to run unless ARECA_BENCHMARK=1 is set and the database name contains bench or test.

docker run -d --name areca-bench-pg -e POSTGRES_USER=bench -e POSTGRES_PASSWORD=bench \
  -e POSTGRES_DB=areca_bench -p 55444:5432 postgres:17-alpine

cd apps/cms
export DATABASE_URL=postgres://bench:bench@localhost:55444/areca_bench
pnpm db:migrate
ARECA_BENCHMARK=1 pnpm bench --keep --json /tmp/bench.json
ARECA_BENCHMARK=1 pnpm bench --skip-seed --keep

docker rm -f areca-bench-pg

The first bench run seeds the data and measures. The --skip-seed run measures again in a fresh process, which gives cleaner memory numbers. Useful flags:

Sizing guidanceCopy Anchor Link

Start from the envelope above and size for your largest site, not your average one.

• CPU. The benchmark ran on a laptop-class CPU. A small server with two or more modern cores is enough for the envelope. Build work runs in the same process as the server, so a slow snapshot build can slow page responses briefly.

• Memory. Plan for about 1 GB for the CMS container at the largest target site. The measured peak was 700 to 830 MB resident memory, and the snapshot is built in memory as one object. If you see out-of-memory restarts, give the container more memory and, if needed, raise Node's heap limit with the standard --max-old-space-size flag set through NODE_OPTIONS. The Compose file does not pass NODE_OPTIONS, so add it to the CMS service. Areca does not document or test a specific heap value.

• Uploads. Each upload is held in memory while it is parsed, stored and processed. A file of 20 MiB can use tens of megabytes of memory, so several concurrent uploads of large files can use hundreds of megabytes. Ask editors to upload large media one at a time.

• Database storage. Storage grows in three places, and none of them is pruned automatically:

  • Every save adds a revision. There is no revision limit.
  • Every release keeps a full copy of the snapshot. A largest-site snapshot is about 22 MB of JSON, and each retained release adds another copy.
  • Deleted content is kept in archives. See asset retention.

  Plan disk space for revisions and retained releases, and watch the size of the database over time.

• Object storage. Uploaded files are stored in your S3-compatible bucket and served through the CMS. Traffic to uploaded files goes through the CMS process, so put a CDN in front of /api/assets/file/* if your sites serve many images. See storage and email.

• Database connections. The CMS uses one connection pool per process. Areca does not expose a setting for the pool size, so it uses the node-postgres default of 10 connections. Make sure your PostgreSQL max_connections setting allows for that, plus connections from your own tools.

Tuning settingsCopy Anchor Link

These settings are read from the environment. Changing one needs a restart of the CMS. The full list is in configuration. This table shows the ones that affect capacity.

Raise WORKER_CONCURRENCY only when several clients publish at the same time and jobs for different sites wait in the queue. Each extra job runs a build, which uses CPU and memory. The value is a limit per process, so it does not change how much work one site can run at once. Only one job runs per site at a time.

Raise DB_STATEMENT_TIMEOUT_MS only if a legitimate operation regularly runs longer than 15 seconds. A longer limit hides slow queries instead of fixing them.

Replica stanceCopy Anchor Link

Run one CMS replica. The capacity envelope is built for a single process, and the project does not yet document a supported way to run several.

The publish worker and scheduler run in the same process as the server, and the readiness check reports worker state for each process. The worker and scheduler are designed for a single process, and the project has not tested several CMS processes against one database. Use one CMS container, and keep the restart policy on so the container comes back after a crash.

If you need more capacity, scale up the one container before you add replicas. If you still need more than one, open an issue with the project first, so the change can be designed rather than guessed.

When to plan for moreCopy Anchor Link

Change the setup, or talk to the project, when you see these signs:

RelatedCopy Anchor Link

• Operations for health checks, metrics and worker behaviour.
• Configuration for every environment variable.
• Upgrading before you change the image.
• Asset retention for how stored files and history grow.