MikoPBX: a self-hosted Asterisk phone system with a web interface

A whole phone system in one bootable image

MikoPBX is described as a free open-source PBX for small business, built on Asterisk 22, PHP 8.4 and Phalcon 5, and the project description spells out what that means in practice: it ships as a compact Linux distribution with all necessary services pre-configured, among them Asterisk, Nginx, PHP-FPM, Redis and Fail2Ban.

That packaging decision is the product. A PBX is not an application you install next to your other software, it is a system with SIP signalling, RTP media paths, dialplans, queues, recording storage and firewall rules, and each of those has its own configuration surface. MikoPBX collapses that into an appliance: an ISO that boots, a web interface that configures it, and a set of services that were already wired together when you logged in.

The project opens its documentation with an ASCII rendering of the name, which is a good signal about who it is written for:

88b           d88  88  88                     88888888ba   88888888ba  8b        d8
88`8b       d8'88      88                     88      ,8P  88      ,8P   `8b  d8'
88 `8b     d8' 88  88  88   ,d8   ,adPPYba,   88aaaaaa8P'  88aaaaaa8P'     Y88P
88   `8b d8'   88  88  8888[     8b       d8  88           88      `8b   ,8P  Y8,

The stack underneath is modern rather than legacy. The feature list names the latest PJSIP stack and Asterisk 22 LTS, PHP 8.4 with the Phalcon framework, Nginx and Redis, dual-stack IPv4 and IPv6 networking, and both x86_64 and ARM64 architectures. The web interface is available in 26 languages, translated by the community through Weblate.

The licence is GPL-3.0, the primary language is PHP, and the repository is the mikopbx/Core one, with the homepage at www.mikopbx.com and a Russian-language site and readme alongside the English one.

The project positions itself as free for the core: the readme says all core business functionality is free forever, while extensions in the marketplace come in both paid and free flavours.

Installing it, and the deployment paths multiply fast

The installation section is where the project is at its most useful, because it covers every way a small business might already own a server.

For bare metal there are two routes, a live USB installation and a bootable USB installation. For a virtual machine, you download the latest ISO and boot it in your hypervisor, and the table lists seven of them: VMware ESXi, VMware Workstation Pro, VMware Fusion for Mac, VirtualBox, Hyper-V, Proxmox as a VM, Proxmox as an LXC container, and UTM on Apple Silicon. The presence of both Proxmox rows and the UTM row tells you that containers and ARM are first-class targets rather than afterthoughts.

Docker has its own three-step path: prerequisites for Docker installation, running MikoPBX in a container, and running it with Docker Compose.

Then the cloud table, which lists AWS EC2 with an AWS Marketplace listing, Google Cloud with a GCP Marketplace listing, Microsoft Azure, DigitalOcean, Vultr, Alibaba Cloud and Hetzner Cloud. The feature list adds Yandex Cloud and VK Cloud to the auto-provisioning list, so the set of providers the project can provision itself into is wider than the deployment guides.

After installation you open the web interface and log in with the default credentials, username admin and password admin, then follow the Quick Start guide. The documentation for all of this lives at docs.mikopbx.com with per-language paths, and there is an English site and a Russian one.

The first thing to do after that login is change the password, and the documentation does not say so explicitly, so it is worth saying here.

What the web interface actually covers for a small office

The feature list in the readme is the closest thing to a capabilities statement, and it maps onto what a small business actually asks a phone system to do.

Call recording is there. Conference calls are there. Voicemail is there. Call transfers and pickup are there. Call queues are there. IVR menus are there. Inbound and outbound call rules are there, along with a holidays and night-time call switcher, which is the feature that decides where after-hours calls go.

Then there is custom call-flow programming, which is the item that separates a PBX from a consumer answering service. You write the logic rather than pick from a menu of templates.

Around the telephony there is a marketplace with paid and free extensions, and the description says you can write any module you think of and distribute it to your users through the built-in marketplace. That is a plugin ecosystem rather than a fixed feature set, and it is the reason the system can serve a small office and a larger one with the same core.

Two more things in the list are about access control rather than telephony: Fail2Ban with an iptables firewall, and WebAuthn and passkey authentication for the interface itself. For a box that is exposed to the internet and is holding your call recordings, those two lines are the security posture of the whole product, and there is a SECURITY.md file in the repository alongside the AGENTS.md, CLAUDE.md and CODE_OF_CONDUCT.md.

The REST API is the part that makes it composable

The REST API is where MikoPBX stops being an appliance and becomes something you can build on.

The feature list credits it with 259 or more endpoints and JWT authentication. That number is the point. An appliance with a web interface is something an administrator configures by hand, and an appliance with 259 endpoints and a token-based API is something a script, a billing system or a CRM can talk to.

The API design choice worth noting is that it sits alongside the web interface rather than under it, and the marketplace means the endpoints can be extended by extensions. A vertical integration for a particular vertical, written as a marketplace module, extends both the API surface and the interface without a fork of the core.

The codebase conventions are documented in the same list: a modern codebase written to PSR standards and the Airbnb JavaScript style. The repository carries a phpstan.neon for static analysis, a composer.json, and an AGENTS.md and CLAUDE.md at the top level, which is the shape of a project where automated tooling is expected to work on it.

There is also a .oss-scanner directory and a SECURITY.md, which together suggest that the dependency surface is scanned as part of the workflow rather than reviewed by hand.

The sizing table is the honest part of the documentation

The requirements section is a table of concurrent calls against CPU, RAM and storage, and it is more useful than most project sizing guides because it is small.

For 5 to 10 concurrent calls it asks for 1 GHz x86-64 or ARM64 with 1 to 2 cores, 2 GB of RAM, and 1 GB for the system plus 50 GB for recordings.

Up to 25 concurrent calls, and the numbers move to a 3 GHz x86-64 or ARM64 with the same 2 GB of RAM and the same storage.

From 25 calls upward, it asks for dual CPU at 3 GHz on x86-64, 4 GB or more of RAM, and the same 1 GB plus 50 GB of storage.

Two things stand out. The RAM figure barely moves between the first two tiers, so memory is not the axis that scales with call volume in this design. And the storage figure does not move at all, because the recording allocation of 50 GB is a flat figure rather than a per-call one, which tells you the sizing here assumes a recording retention policy you set rather than unlimited capture.

The architecture rows are a reminder that ARM is a real target rather than a port. The listing gives x86-64 or ARM64 for the first two tiers and x86-64 only for the dual CPU tier, so a Raspberry Pi class deployment is in scope for small call volumes and the larger tier is not.

The project documentation links to a fuller system requirements page, and the compact table in the readme is the short form of it.

A dev branch with dev tags, and what that means for deployment

The release history deserves a note because it is unusual and it changes how you should install this.

The most recent releases are 2026.6.7-dev from 2026-10-12, 2026.6.6-dev from 2026-10-10 and 2026.6.4-dev from 2026-10-09. Every one is a dev build, the default branch is develop, and the last push to the repository was on 2026-10-19, a week after the newest tag.

So there is no numbered stable release line in the usual sense. The version scheme is a date plus a sequence with a dev suffix, which is a development cadence rather than a release train. If you want a stable box you have to pin to a specific image or ISO and freeze it, because pulling the latest means pulling a development build.

The badges at the top of the readme are consistent with that: a code quality workflow on the develop branch, a last-commit badge for develop, and a release badge pointing at the latest release page.

The repository tree is also consistent with a project that builds its own distribution. There is a resources/ directory for what goes into the image, a src/ directory for the application, plus sessions/ and sites/ directories, a tools/ directory for the build tooling, a config.json, a docs/ directory, a tests/ directory, and composer.json. Building the ISO and the container images from this tree is part of the workflow rather than a downstream packaging exercise.

Where MikoPBX is the wrong tool

The first limit is the licensing of the telephony itself. Asterisk is the engine and it carries its own GPL obligations, and a commercial PBX vendor's real cost is not the licence fee but the compliance, the SIP interconnect relationships and the support contract. MikoPBX makes the software free and leaves all of that with you. For a business that has one person responsible for IT, that can be a win. For a business that needs a number to ring when their main PBX fails, it is not, and the project does not position itself as a carrier-grade alternative.

The second is that the whole thing is a server, not a service. Asterisk 22 with PJSIP, Fail2Ban, an iptables firewall and a web interface is a box on the internet with your call recordings on it, and that is an operational responsibility, not a feature set.

The third is the dev branch. A developer tagged build as the normal release channel is fine for a project you follow closely and pin carefully, and it is a different proposition for a business that installs the latest ISO each quarter. There is no stable channel here to point at.

The fourth is the plugin marketplace as a dependency risk. The core is free forever, but the features a particular office needs may live in a paid extension, and then the cost model changes anyway, and you are trusting a third party's module inside a system that handles calls.

The fifth is that the project is largely one organisation's product, with GPL-3.0 licensing, a develop branch and a Weblate translation flow driven by the maintainers. The community translation model is a strength for the interface, but the roadmap is not a community roadmap.

And the sixth is the plainest one. The default credentials are admin and admin. For a box that will be reachable from the internet, that is the first thing you have to change, and the documentation does not put it in bold.

Editorial conclusion

MikoPBX is worth trying for a small business or a home lab that wants a working phone system this afternoon rather than a telephony platform project, because the ISO boots with Asterisk, the web interface, the REST API and the marketplace already wired together, and because the free core covers recording, queues, IVR, voicemail and call routing, which is most of what a small office needs. It is the wrong choice if you need carrier-grade reliability, and it is the wrong choice if nobody will maintain it. Before you install it, check the three things the documentation is explicit about: that the default web credentials are username admin and password admin, and that you change them before the box is reachable from anywhere; that the storage requirement is 1 GB for the system plus 50 GB for recordings, so the recordings are the disk you actually provision for; and that the release line you get is a dev build, with 2026.6.7-dev as the most recent tag on the develop branch, so you are running a development version rather than a numbered stable release.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mikopbx/Core on GitHub
3. Project website
4. README
5. Releases