Why we built an unofficial Docker image for the 3CX SBC

A 3CX Session Border Controller sits on the network where the desk phones are. It gathers up the signalling and the audio and carries them through the 3CX tunnel to a PBX somewhere else. That sidesteps the usual NAT and firewall arguments and gives the PBX one managed route into the building.

3CX currently suggests using one once a site has more than ten phones. Below that a supported router phone is often simpler, and someone working alone can usually just use the desktop or mobile app.

Whatever you choose has to be up whenever people want to make a call, normally on a fixed local address. That is what makes deployment and updates an operational question rather than a technical preference. If the SBC is down, that office cannot phone anyone.

3CX documents Windows, Debian and Raspberry Pi. Docker is not on the list. If you were already running a small Linux box at each site with everything else in containers, the SBC was the one service you had to treat differently from all the rest.

The image closes that specific gap. Its configuration lives with everything else for that site, hosts pull a known tag, and the same setup works on ordinary server hardware or on a small ARM board in a cupboard.

That is a narrow audience, which is exactly why open source was the right home for it. It never needed to become a company. It needed to be maintained code that other people could read, use and improve.

The Debian package assumes a normal machine with systemd running. Dragging an entire init system into the image would have made it much harder to reason about what happens when something crashes. The build unpacks the package, takes the SBC binary out and runs it directly as the container’s main process.

Setup happens through a PBX address and an authentication key. The entrypoint does what the binary expects, and the configuration stays in step with the 3CX management console. If you need a setting the generated file does not cover, you can mount an extra config file read-only.

It runs with host networking, because the SBC handles live audio and wants straightforward access to the network it is sitting on. That is the practical choice, but it does mean giving up the isolation a container normally gives you, and you should know that before you deploy it.

A container only helps if new upstream releases actually turn into new images. The repository builds automatically when a compatible 3CX release appears, and publishes both fixed version tags and moving major and minor ones.

Installing every new image the moment it appears would be a bad idea, because restarting the SBC drops calls that are in progress. So updates go through a deliberately scoped Watchtower setup rather than treating unattended replacement as harmless housekeeping.

That split is the part worth copying: automate finding, building and packaging, and keep the restart under human control. Continuous delivery does not have to mean continuous interruption.

This is an Apyos open-source project, not an official 3CX image or a supported way to install anything. It repackages software that 3CX controls, which means a change on their side can break the build even when nothing in the container has changed.

For most businesses, and certainly anywhere the phones are how customers reach you, the official Debian, Windows or Raspberry Pi install is the sensible choice. It follows the vendor’s documentation and puts support staff somewhere familiar.

The container makes sense for people who are comfortable with host networking, will notice when the process dies, test updates before rolling them out, and get enough out of consistent container operations to accept owning the unsupported edge. Saying that plainly makes the project more useful, not less.

The best small open-source projects tend to live in the gap between what a vendor supports and something people genuinely need that is too niche for the vendor to bother with. The problem is concrete, the surface is small, and you can prove it works without building a community around it.

It has picked up stars and forks from people who recognised the missing deployment immediately. That is not because it is clever. It is because a handful of operators no longer have to solve the same packaging problem separately.

Which is also the test: not every gap should become a product. Sometimes the right answer is maintained code, honest trade-offs and documentation good enough for the next person to decide whether it fits.