FreePBX UK is a UK business hosting service for FreePBX, operated by 20 Telecom Ltd. Customer instances run on individual DigitalOcean virtual machines in London and are supplied with FreePBX 17 and Asterisk 22 on Debian 12, created from a maintained hardened snapshot and handed over ready for the customer's FreePBX Initial Setup and ongoing configuration.

FreePBX UK is an Official FreePBX® Partner and holds the only licence from Sangoma to provide Official FreePBX® Hosting in the UK. The service is operated by 20 Telecom Ltd, with customer instances hosted on DigitalOcean infrastructure in London.

All standard FreePBX UK instances are hosted in DigitalOcean's London (LON1) data centre. Each instance receives its own public IPv4 address and a FreePBX UK hostname in the freepbxhosting.uk zone.

A new instance is supplied with FreePBX 17 and Asterisk 22 on Debian 12. Provisioning completes the hosting-side preparation before handoff, after which the customer completes FreePBX Initial Setup and configures the PBX for their own use.

There are four standard paid plans: Nano² at £15 per month with 2 GB RAM, 1 AMD vCPU, 50 GB NVMe storage and 2 TB transfer; Micro⁴ at £30 with 4 GB RAM, 2 AMD vCPUs, 80 GB and 4 TB; Macro⁸ at £60 with 8 GB RAM, 4 AMD vCPUs, 160 GB and 5 TB; and Mega¹⁶ at £120 with 16 GB RAM, 8 AMD vCPUs, 320 GB and 6 TB. Prices exclude VAT.

Size the plan around concurrent call load, extension count and the work the PBX will actually perform, including queues, conferences, call recording and heavier modules. Micro⁴ is the recommended starting point for most businesses; Nano² suits lighter deployments, while Macro⁸ and Mega¹⁶ add progressively more CPU, memory and storage headroom. Plans can be upgraded in place later if the workload grows.

Nano² is intended for small offices, test environments and low-volume deployments. It provides 2 GB RAM and one AMD vCPU and is suitable for at least 10 concurrent calls with a considerably higher number of extensions. It is also a sensible starting point when validating a migration before committing to a larger tier.

Micro⁴ is the recommended starting point for most businesses. Its 4 GB RAM and two AMD vCPUs give Asterisk room to process typical SME call volumes while the FreePBX web stack and background services run alongside. It is suitable for most deployments using standard modules, IVRs and queues.

Macro⁸ is intended for higher call volumes, busy queue environments and heavier module use. Its 8 GB RAM and four AMD vCPUs provide headroom for concurrent call recording, active conference bridges and resource-intensive modules running together. It is suited to contact centres and businesses with sustained inbound call traffic.

Mega¹⁶ is intended for large deployments, high concurrency or multi-tenant configurations. It provides 16 GB RAM, eight AMD vCPUs and 320 GB NVMe storage, making it suitable where FreePBX is carrying heavier IVR logic, substantial call recording, sustained workloads or serving as a core telephony platform across a larger organisation.

There is no minimum contract period. Paid hosting runs month to month, so you can cancel without a long-term commitment. The service remains active until the end of the current billing period, and unused time in that billing period is not refunded.

Yes. Powering off an instance stops the virtual machine but does not stop billing, because the DigitalOcean resources remain reserved for that service. Use Cancellation if you want billing to end; a powered-off instance can be started again from the customer portal.

The four standard plans use DigitalOcean AMD Basic Droplets with shared vCPUs rather than dedicated CPU. That suits the bursty nature of a typical PBX workload, where activity rises around calls and then falls back again. Dedicated-CPU options are available for workloads that need guaranteed sustained processor access.

Bespoke deployments can use DigitalOcean General Purpose, CPU-Optimised or Memory-Optimised Droplets in London rather than one of the four standard plans. Larger configurations can reach far beyond Mega¹⁶, and dedicated-CPU deployments can also be paired with a separate enterprise support agreement where defined response times and escalation paths are required.

Nano² includes 2 TB of outbound transfer per month, Micro⁴ 4 TB, Macro⁸ 5 TB and Mega¹⁶ 6 TB. Inbound transfer is not counted, and traffic between DigitalOcean resources in the same region does not consume the allowance; excess outbound transfer is passed through at DigitalOcean's standard overage rates.

Yes. A plan can be upgraded in place through my.freepbx.uk without reinstalling the PBX. DigitalOcean resizes the Droplet, the filesystem is expanded, and the existing configuration, recordings and data are preserved.

An in-place plan upgrade requires the Droplet to be powered off while DigitalOcean resizes it. DigitalOcean estimates roughly one minute per GB of used disk space; for a typical FreePBX UK instance, the complete resize and reboot usually takes around five to ten minutes. The existing PBX configuration, recordings and data remain on the same instance.

Not in place. Once the virtual disk has been expanded it cannot be reduced, so the supported route to a smaller plan is to back up the configuration, cancel the existing service and order a new instance on the lower tier.

Yes. A 7-day Free Trial is available and runs for seven complete days. The trial shares the Nano² hardened snapshot and remains available after those seven days until the fixed Day 8 termination deadline.

The trial runs for seven complete days from the Start Date. After those seven days have finished, the instance remains available until 17:00 UK local time on Day 8 unless it has already been upgraded. For example, a trial started at 09:00 on Monday completes its seven days at 09:00 the following Monday and, if left unupgraded, is terminated at 17:00 on Tuesday. At termination the instance and its associated snapshots are permanently deleted, and the deadline cannot be delayed, paused or overridden.

An Irreversible Upgrade specifically converts a 7-day Free Trial into paid hosting so the same instance can continue beyond the trial. Once completed, it cannot be returned to trial status. After conversion, the paid instance can still be upgraded in place from Nano² to Micro⁴, Macro⁸ or Mega¹⁶ as requirements grow. Paid plan upgrades preserve the existing instance and data, but cannot be reversed to a smaller plan because the disk size cannot be reduced.

Starting a 7-day Free Trial adds £18 credit to the FreePBX UK account. The credit is separate from the trial clock, so it does not extend the Day 8 deadline; keeping the trial instance still requires the Irreversible Upgrade to be completed before termination.

Yes. SysAdmin Pro is available with the 7-day Free Trial and is included with paid FreePBX UK hosting plans at no additional hosting charge, subject to activation. A qualifying Free Trial can receive the 30-day SysAdmin Pro trial licence. If the hosting trial is converted to paid hosting through the Irreversible Upgrade, the SysAdmin Pro licence is converted to the full 25-year licence before it expires, provided the account remains active and in good standing.

Email [email protected] from the registered account address with the FreePBX Deployment ID and request activation. The Deployment ID must be registered with a Sangoma portal account. FreePBX UK will check eligibility and apply a 30-day SysAdmin Pro trial licence within three working days. Free Trial instances can receive that licence before a hosting invoice has been paid. If the hosting trial is converted to paid hosting through the Irreversible Upgrade, the SysAdmin Pro licence is converted to the full 25-year licence before expiry, provided the account remains active and in good standing.

Every plan includes automated DigitalOcean backups taken daily and retained for seven days on a rolling basis. They are full-instance recovery points covering the operating system, FreePBX configuration, database and recordings. Available backup points can be viewed and restored from the customer portal.

Daily backups are automatic recovery points created by DigitalOcean on its schedule and retained on a seven-day rolling basis. Snapshots are manual, customer-controlled copies created when you choose, which makes them useful before a module update, dialplan change or other deliberate maintenance. Both cover the whole Droplet, but snapshots give you control over when the copy is taken and when it is deleted.

You can retain up to five snapshots for an instance, provided their combined DigitalOcean compressed billable size does not exceed that plan's included disk capacity. The allowance is a hard limit rather than a billable overage: if a new snapshot would exceed it, an existing snapshot must be removed first. Snapshots are deleted when the associated instance is terminated.

Domain Access controls whether the FreePBX UK hostname is proxied through Cloudflare or resolves directly to the instance. Cloudflare proxying is enabled by default; the customer portal can switch to direct access and back again, subject to automated safety checks and any operational restrictions needed to protect the platform.

The Reachability Checker runs an external check of the instance's configured web access from the customer portal. It checks the saved HTTP and HTTPS access points and reports whether they can be reached externally. It is an operational convenience and does not guarantee availability, security or correct configuration of the instance.

A pre-provisioned SMTP2GO integration is available for FreePBX-generated email such as voicemail, fax and system notifications. It is optional, not a requirement: you can use another SMTP relay instead if it supports a submission port available from the platform, such as 2525. The customer portal provides the SMTP2GO controls and credentials when you choose to use it.

The customer portal provides power on, graceful power off, reboot, Domain Access, Reachability Checker, SMTP2GO, browser console, rebuilds, snapshots, daily-backup restores, task history and resource graphs. Longer-running operations are tracked so you can see progress and confirm whether they completed successfully. Rebuild is destructive: it replaces the contents of the instance disk, so anything you need to keep should be preserved in a snapshot or backup first.

The hosting plan provides the FreePBX instance and its hosting platform, not a complete managed telephone service. SIP trunks, telephone numbers, handsets and ongoing PBX configuration are separate. Those services can be supplied by 20tele, or you can use third-party SIP trunk providers where you prefer.

New customers moving an existing FreePBX system can use Take Five: five hours of free migration support, valid for 12 months and deducted in 20-minute increments. It can cover moving the existing configuration, reconnecting extensions and trunks, checking IVRs and queues, and making test calls before the old PBX is retired. Mention Take Five when ordering or contact [email protected] before the migration.

FreePBX UK hosting is for UK-based commercial business use. Companies, organisations, sole traders and freelancers operating commercially can use the service; residential, personal, student and hobbyist use is excluded. The instance must be used to operate a telephone system for the customer's business or for a business operated by or on behalf of that organisation.

The customer is responsible for the configuration, operation and ongoing security of the FreePBX software from the Start Date. That includes firewall rules, SIP access controls, extensions, credentials, network exposure and connected endpoints. FreePBX UK provides the hosting platform and hardened provisioning standard, but unmanaged hosting does not include managed PBX security, fraud prevention or day-to-day PBX administration.

FreePBX UK hosting is an unmanaged PBX hosting service. FreePBX UK provides and maintains the virtual-machine hosting platform and delivers FreePBX/Asterisk pre-installed, but the customer remains responsible for PBX configuration, day-to-day operation and ongoing PBX security. Hands-on PBX work can be purchased separately under Paid Access or through other services.

Infrastructure monitoring covers the availability and resource behaviour of the virtual machine, not the customer's telephony activity. FreePBX UK does not monitor SIP traffic, calls, call routing, PBX configuration, fraud or the security state of the FreePBX software as part of the hosting service. An infrastructure alert therefore does not create an obligation to investigate what the PBX itself is doing.

The hosting agreement covers the hosted FreePBX instance, not telephony connectivity. Telephone numbers, SIP trunks, call routing and PSTN access are separate services. They can be obtained from a third party or through separate 20 Telecom services without becoming part of the FreePBX UK hosting agreement.

The my-XXXXXXXX.freepbxhosting.uk hostname is provided as a convenient way to reach the FreePBX web interface over HTTP or HTTPS. It is not a guaranteed or permanent service endpoint, does not form part of the core hosting Service, and may be modified, reassigned or withdrawn where reasonably required. It is not configured or supported for SIP signalling, RTP media or other real-time telephony traffic. SIP and RTP should use appropriate direct network access to the instance instead.

Cloudflare proxying can be disabled through Domain Access where that control is available in the customer portal. The change is subject to automated safety checks and operational restrictions, and FreePBX UK may refuse or reverse it where reasonably necessary to protect its infrastructure or third-party platforms. Switching to direct access does not make FreePBX UK responsible for the customer's PBX security.

The hosting service must not be relied upon as the customer's means of reaching emergency services such as 999 or 112. FreePBX UK does not provide or guarantee emergency calling, so the customer must maintain appropriate and reliable emergency-calling arrangements independently of the hosted PBX.

Support Hours are Monday to Friday, 09:00 to 18:00 UK time, GMT or BST as applicable, excluding UK bank holidays in England, Scotland and Wales. Some separately booked Paid Access sessions have wider published availability.

A Critical Issue is a complete and sustained loss of connectivity to the underlying virtual machine at the infrastructure level. It does not include FreePBX configuration, SIP connectivity, call routing, call quality or other telephony functionality.

Restricted support is included with every hosting plan at no additional charge. Requests are submitted through the customer portal, are handled at low priority with a target response of four business hours during Support Hours, and cover Critical Issues, Major Service Outage reports and general billing queries. Phone, email and WhatsApp support are not included at this tier.

Full Access is the optional £9 per month or £90 per year support subscription, plus VAT. It adds high-priority handling, phone, email and WhatsApp contact during Support Hours, a dedicated Support Number protected by a four-digit PIN, and a one-hour response SLA for valid requests relating to the hosting Service. It does not turn unmanaged hosting into a managed PBX service.

The SLA is a response-time commitment, not a promise that the underlying problem will be fixed within one hour. A valid Service-related request submitted during Support Hours must receive a response within one hour. If that response deadline is missed, the customer's monthly Full Access fee can be credited in full on request, limited to one credit per calendar month.

Paid Access can be booked by customers on any support tier for hands-on technical work under the customer's direction. A one-hour block costs £75 plus VAT and is deducted in 20-minute increments; a five-hour block costs £250 plus VAT on the same basis; and a full day of eight consecutive hours costs £300 plus VAT. Sessions are paid in advance.

Standard Paid Access can be booked Monday to Friday from 06:00 to 23:00 UK time, excluding UK bank holidays and the annual Christmas closure, subject to engineer availability and advance booking. Pre-purchased credits last for 12 months from purchase. They are non-refundable except in exceptional circumstances at FreePBX UK's discretion.

Restricted and Full Access support cover the hosting Service, not hands-on operation of the customer's telephone system. PBX configuration, SIP providers, call routing, call quality, dialplan development, third-party integrations, fraud prevention and other telephony work remain outside those tiers. That work can instead be undertaken under Paid Access, where assistance is provided under the customer's direction and control.

FreePBX UK closes for five consecutive days over Christmas and New Year, typically from 29 December to 2 January inclusive. During the closure all customers temporarily receive Restricted support; the exact dates are published at least 30 days in advance. Infrastructure failover systems continue to operate throughout the closure.

Paid hosting runs month to month and is billed on the anniversary of the Start Date. Prices are exclusive of VAT, which is added at the prevailing UK rate where applicable. Cancelling does not end the instance immediately: the paid service continues until the end of the current billing period.

Payment is due within seven days of the invoice date and direct debit is the preferred payment method. If an invoice becomes overdue, administration charges may be added at £3 after one day, £4 after eight days and £5 after 22 days, capped at £12 per invoice. Amounts still outstanding more than 21 days after the invoice date may also accrue daily interest at 5% per year above the Bank of England base rate.

Hosting and support prices are reviewed annually and may change from 1st April. Increases do not apply part-way through an active hosting subscription or annual support billing period, and at least 30 days' notice is given by email and through my.freepbx.uk. Annual increases are capped at CPI plus 3.9%, with limited catch-up for years in which no increase was applied, up to a maximum of three consecutive years.

Non-payment may lead to suspension of the Service. Where possible, access is restored after all outstanding charges and any applicable late or reconnection fees are paid, but suspension does not remove the customer's obligation to pay charges due under the Agreement.

FreePBX UK may suspend a service immediately and without prior notice where the information available at the time indicates that suspension is necessary to protect the integrity, stability or security of its infrastructure or a third-party platform. The customer must then be notified as soon as reasonably practicable.

The customer is responsible for use of the hosted PBX and for charges arising from unauthorised access, fraud or misuse. That responsibility includes the PBX configuration, firewall and SIP access rules, extensions, credentials, network exposure and connected endpoints. FreePBX UK infrastructure monitoring is not a fraud-monitoring service.

The Acceptable Use terms prohibit unlawful activity, abusive or obscene material, infringement of third-party rights, unsolicited communications, fraudulent activity, non-compliant automated or predictive dialling, disruptive resource abuse and attempts to bypass FreePBX UK security controls. They also prohibit specified categories such as illegal content, terrorism or extremism, trafficking, exploitation and certain adult or premium-rate services.

Resale or third-party access requires prior written consent from FreePBX UK, and that consent will not be unreasonably withheld. Without consent, the Service and instance are for the named customer's use and must not be transferred, shared or made available to another party.

Direct external SSH is disabled by default and may be enabled on request, subject to a security review at FreePBX UK's discretion. This is separate from the browser-based console available through the customer portal.

The master SSH key exists solely so FreePBX UK can perform virtual-machine maintenance and infrastructure support when access is required. That access is described as limited and reactive, not continuous monitoring. The key and other FreePBX UK security controls must not be removed, disabled or circumvented; doing so is a material breach that may result in immediate termination without refund.

The customer retains ownership of the data stored on the instance. FreePBX UK will not access, inspect or disclose that data except where necessary to deliver or maintain the service, or where disclosure is required by law. Both parties remain responsible for their own obligations under the UK GDPR and Data Protection Act 2018.

Daily backups and customer snapshots are recovery features, not a guaranteed disaster-recovery service. A backup may not be recoverable in every circumstance, so customers should keep independent copies of critical configuration and data. Self-service restoration is available through the customer portal where the relevant control is present; assistance from FreePBX UK may be chargeable.

Cancellation can be requested at any time from the Product Details page, but the paid instance remains active until the end of the current billing period and no refund is given for the unused portion. At termination the instance and associated data are permanently removed, and associated snapshots are deleted, so anything that must be retained needs to be exported before the service ends.

Subject to liabilities that cannot lawfully be excluded, FreePBX UK's total liability under or in connection with the Agreement is capped at the hosting charges paid in the three months immediately before the event giving rise to the claim. The Agreement also excludes specified business losses, indirect or consequential loss, and failures caused by circumstances beyond FreePBX UK's reasonable control.

A SysAdmin Pro licence is tied to the Deployment ID on which it was activated and does not transfer automatically to a different Deployment ID. If a replacement or changed instance has a new Deployment ID, the customer must submit a new activation request and meet the eligibility requirements again.

FreePBX UK depends on third-party services from DigitalOcean, Sangoma and SMTP2GO. A failure of a third-party platform can therefore affect the hosting service or an optional feature, and the Agreement excludes liability for failure or delay caused by circumstances beyond FreePBX UK's reasonable control, including third-party platform or service failure. DigitalOcean provides the underlying infrastructure, Sangoma provides FreePBX and its commercial module ecosystem, and SMTP2GO is an optional email-delivery convenience rather than a core telephony service.

A new instance is created from the maintained hardened snapshot assigned to that service, then a separate automated provisioning process personalises and validates the clone. The process applies host-specific hardening and identities, takes the instance through clean boot cycles, verifies the finished service state, reports the result and removes temporary provisioning material before handoff.

Post-order provisioning takes around seven minutes and is automated. During that time the new clone is personalised, hardened, taken through its boot sequence, given instance-specific credentials and identities, checked, reported and cleaned before it is handed over for FreePBX Initial Setup.

A maintained hardened snapshot is the tested base image used to create new customer instances. It already contains the prepared Debian, FreePBX and plan-specific baseline, so a new order does not begin with an untouched operating-system image. FreePBX UK maintains that image as a rolling lineage, then performs separate customer-specific provisioning on each clone.

Micro⁴, Macro⁸ and Mega¹⁶ each have their own hardened snapshot. Nano² and the 7-day Free Trial share the Nano² snapshot, with plan-specific preparation such as swap sizing maintained in the appropriate image.

A replacement snapshot is created at least monthly, and sooner when a defect is identified or developments in Debian, FreePBX, DigitalOcean or related platform components require a change. The current image remains the known-good baseline while its replacement is prepared and tested.

No. The normal process is a rolling lineage: the most recent tested hardened snapshot is used to create a temporary maintenance Droplet, which is updated, checked, sanitised and captured as the next snapshot. The process does not routinely start again from a fresh FreePBX installation.

The original foundation was a fresh Debian 12 Droplet with FreePBX 17 and Asterisk 22 installed using IN1CLICK 1.3.3 by 20tele.com. IN1CLICK performed the initial operating-system, architecture, resource, hostname, APT, network, mirror, installation, GUI, Apache and self-cleanup checks. That foundation then entered the maintained hardened-snapshot cycle; current refreshes do not routinely reinstall FreePBX from scratch.

Debian packages and installed FreePBX modules are brought fully up to date. FreePBX ownership and configuration are normalised, the platform is restarted, and health checks are performed before the image is accepted for further preparation.

The maintenance instance is checked for a pending reboot requirement. If a reboot is required, it is performed at that point and the health checks are repeated; if no reboot is required, the process continues without an unnecessary extra reboot.

Before a replacement image is accepted, Asterisk must answer, the FreePBX module state must be healthy and the PM2-managed FreePBX services must be in the expected state. If an update required a reboot, those checks are repeated after the reboot. A snapshot is not captured simply because the operating system has finished updating.

The image is prepared with the en_GB.UTF-8 locale and the Europe/London operating-system timezone. Later provisioning also aligns FreePBX and PHP with Europe/London so BST and GMT handling is consistent across the stack.

It means the instance is not handed over as a generic Debian server with FreePBX merely installed on top. The base snapshot is updated, health-checked and sanitised, then each customer clone receives its own hostname, credentials, API signing keys and local TLS identity. Root password SSH is disabled in favour of key authentication, Debian security-only unattended updates are configured, the core service stack is checked after the final reboot, and temporary provisioning material is removed before handoff. It does not turn the service into managed PBX security: ongoing PBX configuration and security remain the customer's responsibility.

The maintained snapshot carries plan-appropriate swap: 1 GB for Nano², 2 GB for Micro⁴, 4 GB for Macro⁸ and 8 GB for Mega¹⁶. The swap file is rebuilt for the target plan and enabled permanently.

The maintained image is prepared to allow the FreePBX UK console service through the FreePBX firewall. This means the browser-based portal console can reach the PBX without requiring the customer to add a manual firewall exception after deployment.

The maintenance system is sanitised before shutdown. Mail data, cloud-init instance state, root Bash history, system and Asterisk logs, temporary files and journal history are removed, and old FreePBX notification records are cleared so customer clones do not inherit stale operational history.

After preparation and sanitisation, the filesystem is synced and the maintenance instance is shut down cleanly. The reusable image is then captured from that clean state and stored ready for customer provisioning.

FreePBX itself is open source; FreePBX UK's hosting automation is not. The public Provisioning page explains what happens, the checks performed and the standard the finished instance must meet, while the exact hardening routines, validation rules and internal automation remain private. The public No Trace check gives customers an independent way to verify the clean handoff.

Yes. Customer provisioning is an automated process that normally takes around seven minutes and does not depend on an engineer manually configuring each server. The automation personalises the clone, rotates instance-specific credentials and identities, performs clean reboot cycles, checks the finished service state, sends the provisioning report and removes temporary setup material before handoff.

Boot 1 establishes the customer instance's basic operating environment and first layer of hardening. It fixes the network and DNS behaviour, assigns the unique FreePBX UK hostname, disables root password SSH, configures the temporary provisioning mail relay, installs needrestart, enables Debian security-only unattended updates, registers the post-boot provisioning services and then performs a clean reboot. Boot 2 begins from that hardened first-boot state.

Cloud network management is disabled so future boots do not overwrite the intended network configuration. DNS resolvers are set directly using Cloudflare and Google IPv4 and IPv6 resolvers, and cloud-init network management is locked out through the provisioning configuration.

Each instance receives a unique hostname under freepbxhosting.uk during provisioning. It is used for system identification, reverse DNS and mail headers, and it becomes part of the instance-specific local TLS identity created later in the provisioning sequence. The hostname is intended for web access, not SIP or RTP traffic.

Root password login is disabled and SSH accepts key authentication only. The inherited root password is replaced with a 32-byte cryptographic random string that nobody knows, so password-based root SSH is not the access model.

Debian security patches are configured to apply automatically, while general Debian updates, FreePBX and Asterisk are excluded from that unattended process and remain under customer control. The needrestart utility is also installed so the customer can see which running services are using outdated libraries after a manual apt upgrade.

Provisioning needs a reliable outbound path to send the final provisioning report, so a temporary SMTP2GO relay is configured on port 2525 with TLS and SASL authentication. The relay credentials and temporary mail configuration are removed during final cleanup.

Boot 2 turns the clean snapshot clone into a customer-specific PBX. After FreePBX has stabilised, the platform restarts and reloads FreePBX, replaces the inherited AMI and ARI credentials, randomises the FreePBX database password, rotates FreePBX-managed module secrets, regenerates the API OAuth signing keypair and local TLS identity, aligns FreePBX and PHP with Europe/London, rebuilds the generated configuration and then reboots into the final validation stage.

The primary AMI and ARI credentials are replaced so the clone does not retain the snapshot's values. AMI receives a new 15-character alphanumeric username and 30-character alphanumeric password, and ARI receives its own independently generated 15-character username and 30-character password. FreePBX-managed AMI secrets are rotated as part of the same clone-specific rebuild.

The freepbxuser database password is randomised and written back into /etc/freepbx.conf. The new password is applied in MariaDB and immediately tested with a live database connection; provisioning stops instead of continuing if that authentication test fails.

The inherited API OAuth private and public signing keys are removed and regenerated for the cloned PBX. Provisioning records whether regeneration succeeded so the final acceptance checks can confirm that the new instance has its own API signing identity.

The local Certificate Manager CA and default certificate are regenerated for the new PBX hostname. Certificate metadata and the web-server integration files are refreshed so the clone does not retain the snapshot server's local TLS identity.

You receive a clean FreePBX 17 instance with Asterisk 22 on Debian 12, created from the current hardened snapshot for that service. The instance has its own AMI, ARI, database, API OAuth and local TLS identities; root SSH is key-only; the core FreePBX service stack has been checked after the final reboot; the OS, FreePBX and PHP use Europe/London; and temporary provisioning scripts, relay credentials, cloud instance data and setup traces have been removed. It is then ready for your FreePBX Initial Setup and ongoing self-management.

Boot 3 is the acceptance stage. The reporting service first waits for Asterisk to answer, then checks Asterisk, MariaDB, Apache, Fail2Ban, the FreePBX firewall, Postfix, RestApps and UCP. It also confirms that the API OAuth keypair and local TLS identity were regenerated for this clone before the final report and cleanup run.

FreePBX UK receives a provisioning report containing service health, clone-hardening results and the Boot 2 and Boot 3 timeline. Cleanup then removes temporary SMTP credentials, cloud-init instance data, provisioning scripts, systemd units, mail traces, Bash history and transient provisioning markers.

Run the public No Trace command shown on the Provisioning page as root on a fresh instance. It checks that provisioning scripts and services, cloud-init instance data, temporary mail credentials and provisioning references have gone; it also checks the timezone, scans the filesystem and journal, confirms the expected boot history and verifies that Asterisk, MariaDB, Apache and Fail2Ban are running. It is deliberately customer-runnable so the clean handoff can be independently checked rather than merely asserted.