CMS Server Requirements

Use this checklist before purchasing server capacity or unpacking a CMS release. Hosted customers can use it to understand the infrastructure, but should follow the provisioning instructions for their hosting service.

Required components

Component	What to prepare
Application runtime	Node.js 24 is the runtime used by the bundled release Dockerfile. Follow any runtime requirement supplied with your specific release. Node.js 20 guidance in older docs is insufficient for the current dependency set.
Database	An accessible PostgreSQL database with a dedicated database owner able to apply core and module migrations. Do not use MySQL for the CMS.
Public address	A domain or subdomain you control, with DNS access
HTTPS	A reverse proxy or hosting ingress with a valid certificate
Persistent storage	Durable storage for the PostgreSQL data and CMS uploads; retain backups outside the application release
Process management	A service manager or hosting platform that starts the app after reboots and records startup failures
Network access	Outbound HTTPS to the BRAD licensing server and the external providers you configure

The release is a prebuilt application, not a static website or PHP package. The host must run a persistent application process and route web traffic to it. You need shell access or equivalent deployment controls for dependency installation and database migrations.

Capacity planning

Capacity depends on your users, enabled modules, upload volume, and real-time activity. Allow separate headroom for the application, PostgreSQL, Redis, and installation of native dependencies. Test representative activity before committing to a production workload; documentation examples are not a capacity guarantee.

Plan database connections as well as CPU and RAM. With clustering, each worker has its own database pool. For example, four workers with a pool limit of eight can consume up to 32 pooled connections, plus administrative and other application connections.

Redis and real-time features

A single-process installation can use the in-memory Socket.IO adapter. Multiple workers on one server can communicate through the application's internal cluster adapter, but production deployments with substantial real-time traffic should use Redis.

Set REDIS_URL for independent application processes, multiple replicas, or Passenger deployments so socket broadcasts can reach users connected to other processes. See production hosting.

Access and network checklist

• The application host can connect to PostgreSQL with the chosen credentials.
• The application user can write to the intended storage directories.
• The hostname resolves to the correct ingress, which serves HTTPS.
• The proxy can forward WebSocket connections to /socket.io.
• The CMS can make outbound HTTPS requests to https://www.brad.software.
• You can read logs, restart the process, and restore the database if deployment fails.

Use your final hostname for installation. Activating on a temporary hostname or different directory can require a license reissue when you move to production.