FreePBX requirements: platform, workload and recovery planning

Start with a supported platform boundary

FreePBX 17 and the operating system beneath it are one support decision. The FreePBX download page and official installer repository still name Debian 12.x as the target, even though Debian now lists 13.7 as current stable and Debian 12 as oldstable. A newer Debian release is not automatically a FreePBX platform the project develops and tests. Record the installation path, Debian point release, architecture, repository sources, installer revision and update owner before sizing anything.

Debian moved Bookworm from regular support to LTS in July 2026 and states that LTS continues through June 30, 2028. That covers Debian's supported architectures and eligible packages, not every FreePBX module, Sangoma repository, Asterisk branch, commercial component or integration. Use debian-security-support and the current FreePBX advisories to identify separate coverage gaps; do not infer one combined support date.

The installer downloads packages while it runs; the FreePBX 17 FAQ says there is no supported offline installer or offline licence-update path. DNS, time, package mirrors, outbound access and maintenance-window policy therefore belong in the deployment design. Preserve the install log as evidence, but do not treat a completed script as proof that routes, trunks, media, backups or commercial modules work.

Size the work, not the extension count

Define busy-hour behavior as concurrent answered calls, new call attempts, queue offers, conferences, recordings, voicemail deposits, transcodes, encryption, reports and integration activity. An extension may be idle, while one call can create two PBX channels and additional Local, queue or bridge relationships. Extension count alone is not a CPU, memory or carrier-capacity model.

List the codec on each leg and whether Asterisk can pass it through or must translate it. Separate ordinary two-party calls from mixing, recording and speech-processing work. For a virtual machine, record reserved or contended CPU, memory, storage latency, clock behavior, snapshot policy and host-failure domain. For a physical host, record replacement ownership, remote-console access and power protection. Do not publish a calls-per-vCPU ratio unless it comes from a controlled workload on the exact design.

Give storage distinct owners and failure limits

Inventory configuration, the FreePBX database, AstDB, voicemail, call recordings, prompts, certificates, logs, CDR or CEL data, spool content and backup archives separately. Estimate growth from retention and real recording format rather than disk capacity alone. The filesystem holding recordings can have a different performance, access and retention policy from the database or operating system.

Define free-space and inode thresholds, database growth checks, log rotation, recording deletion, encryption, off-host replication and restore ownership. A hypervisor snapshot, a FreePBX backup and a copied recording tree preserve different things and have different consistency boundaries. A backup on the same storage pool is not protection from loss of that pool, and a successful archive is not a proven recovery point until an isolated restore is inspected.

Treat network management as a compatibility choice

Document management, phone, trunk, media, provisioning, DNS and time paths before assigning interfaces or firewall policy. FreePBX 17 can run on Debian systems configured through several network mechanisms, but Sangoma documents that the Sysadmin network page supports the traditional /etc/network/interfaces method; another valid Debian network manager may therefore leave the GUI unable to own that configuration and may produce a dashboard warning. Choose one owner and make out-of-band recovery possible.

Stable signaling reachability does not prove RTP, remote administration or provisioning. Record local networks, external addresses, NAT ownership, MTU, VLAN and QoS policy, name resolution, certificate names and clock source separately. A public address is not a security design; restrict management access and validate the exact remote-phone, carrier and emergency-service paths.

Decide on telephony hardware before installation

If the system will use Sangoma analog or digital cards, treat DAHDI, Wanpipe, the supported Debian kernel, PCIe placement, interrupt behavior, timing, power and cabling as one compatibility set. Sangoma documents that the default FreePBX 17 install script does not install DAHDI or Wanpipe and recommends the --dahdi path during a fresh installation when that hardware is planned. That path also constrains kernel update behavior because driver support does not necessarily follow Debian kernel updates immediately.

Do not transfer a currently documented kernel example into a permanent requirement. Recheck the live package repository and current DAHDI guidance at change time. Keep card recognition, driver load, span or port configuration, line supervision, caller identity, fax, emergency routing and accepted calls as separate evidence. A virtual SIP-only PBX should not acquire kernel holds merely by copying a hardware-oriented build recipe.

Turn the design into an acceptance envelope

Before production, record the exact software and module set, update channel, installed options, host resources, storage thresholds, network owners, licences and support route. Establish an off-host backup, an isolated restore procedure, monitoring and rollback triggers. Use authorized test destinations and exclude emergency numbers from routine load or route testing.

Validate a representative peak mix rather than a single quiet call: internal and trunk calls, expected codecs, queue or conference work, recordings, voicemail, reports, failover and maintenance recovery only where each is in scope. Observe CPU, memory, run queue, storage latency, database health, channel count and user-visible results together. Retain the workload definition and results with the design; margin without a repeatable workload is not capacity evidence. No host, installer, card, PBX, workload, storage system, backup or call was inspected or tested for this guide.