FreePBX module administration and updates

Inventory before contacting a repository

Record FreePBX, Debian, Asterisk, repository channel and every installed module's version, status and signature state. A GUI module update is different from an operating-system update, an Asterisk engine change and a commercial licence action. Preserve the current notices and available-update list before changing anything.

Sangoma's Module Admin overview explicitly says the module updates the PBX GUI and does not update Asterisk. The public GUI walkthrough is labelled for version 13, so use it for concepts rather than promising the same buttons on FreePBX 17. The installed Module Admin screen and fwconsole ma --help output are the controlling interface evidence for the exact host.

Separate read-only discovery from mutation

Use Module Admin normally or the documented fwconsole ma family for the installed release. list, info, showupgrades, checkdepends and reversedepends can establish the proposed set and dependency direction before an update. Repository selection, edge channels and commercial entitlement remain separate choices; do not expose a production PBX to a different channel just to make an update appear.

The -f option skips dependency and status checks. Do not use it as a generic retry. upgradeall, enableall, installall, delete and deleteall have intentionally broad or destructive scope; their existence in help output is not a recommendation. Capture the exact command, target modules and preview evidence in the change record.

Prepare a recoverable, bounded change

Create a verified backup and keep a usable copy outside the PBX's failure domain. Record custom code, locally signed modules and integrations that may not be recoverable from a repository. Check disk space, maintenance access and the alternate route for critical incoming calls. A backup file is not rollback evidence until its target version and restore path are known.

Select the smallest intended module set. Review release notes, reverse dependencies, required versions, licence state and signature status. Treat an unsigned or altered-module notice as integrity evidence, not an ordinary update reminder. The module-signature investigation separates authorized local code, changed published files and the content-replacing refreshsignatures operation.

Apply, reload and accept as separate states

Download, install, enable or upgrade only the approved modules, then preserve the transaction result and final module list. Applying or reloading configuration is a distinct operation: a downloaded package is not installed, an installed module is not necessarily enabled, and an enabled version is not proof that its generated configuration loaded cleanly. Reboot only when the exact change or documented maintenance procedure requires it.

Check FreePBX notices, service health, Asterisk logs, running module versions and registration state after reload. Exercise internal calls, incoming and outgoing carrier calls, IVR digits, voicemail, one representative remote endpoint and any workflow owned by the changed module. An idle dashboard is not call acceptance.

Roll back from compatible evidence

A module may migrate database schema or generated configuration, making an arbitrary package downgrade unsafe. Use the module's supported rollback path or restore the verified system backup into a compatible FreePBX, Debian, Asterisk and module environment. Do not combine forced downgrades, recursive ownership changes and signature suppression into one untraceable recovery attempt.

Keep the failed-change logs, exact versions, dependency output, repository channel, signature status, reload result and call-test result. Define the rollback trigger before the window and close it only when the PBX and representative workflows meet the recorded acceptance criteria. No module, PBX or call workflow was tested for this guide.

Update the restore owner before importing an archive

The 2026 FreePBX restore advisories direct administrators to update Backup & Restore before use. Record its installed version, signature and repository channel, update it through the supported module owner, and confirm the loaded result before importing. Do not uninstall or reinstall the module while its restore transaction is running.

Module state is part of restore evidence

A restore depends on the target module that owns each archived item. The missing settings or files diagnostic checks installed, enabled, signed and licensed state plus the module handler before anyone forces a package or edits generated output.

Verify the installed API module before trusting a schema

For an integration, record the PBX API module version, signature, dependencies and active modules before using the OAuth and GraphQL workflow. Repository metadata and generated examples do not prove the served schema.

Preserve Dynamic Routes support and repository status

Before installing or updating Dynamic Routes, record that its current documentation places it in the Unsupported repository and the community-supported module family. Verify version, signature and change ownership before using the bounded routing workflow.

Treat the Dashboard as a versioned signed module

The System Dashboard guide records installed module version, signature and provider hooks before interpreting cards. Repository version and changelog evidence do not establish the package installed on a selected PBX.

Migrate custom dialplan at its supported owner

The VALID_EXTEN migration guide preserves generator ownership and avoids editing FreePBX-generated output that a reload can overwrite.