MULTILARM // ANSWERS

How Do I Run Scheduled Audio Without Docker?

One service, one config file, no container runtime · 6 min read

Last updated 2026-09-23

If you have gone looking for software that plays music and announcements on a schedule, you have probably found that the well-known options now ship as container stacks. AzuraCast installs a Docker environment. LibreTime's supported path is Docker Compose. Both work, and for a server you administer daily that is a perfectly sensible way to ship software.

For a machine that sits in a cupboard in a school, a factory or a mosque, it is often the wrong shape, and it is worth being specific about why rather than just being against it.

What does Docker actually cost you here?

Four things, in roughly the order they bite:

• A second system to know. When audio stops at 08:55 on a Monday, the person who can get to the machine is the caretaker or the site manager. "Check the service is running" is a thing they can be taught. "Exec into the container and check the logs of the other container" is not.
• Disk and update churn. Images, layers and volumes on an SD card, plus a container runtime that updates on its own schedule alongside everything else.
• Another layer between the software and the hardware. A USB relay board, a serial port, a GPIO pin and an audio device all have to be passed through deliberately. Each is one more thing to get wrong, and each fails in a way that looks like the software's fault.
• A dependency you did not choose. Your audio software's uptime is now partly the container runtime's uptime.

None of that makes Docker bad. It makes it a poor fit for an appliance.

What does the alternative look like?

One service. Multilarm installs as an ordinary Windows service or a systemd unit, reads one XML config file, and writes its logs beside it. There is no container runtime, no database server to install, no message broker, no reverse proxy to configure, and no web stack to keep patched. On a Raspberry Pi it is a .deb, or a ready-made card image you flash and boot.

The practical difference shows up on the bad day. Restarting it is restarting one service. Backing it up is copying a folder. Moving it to a replacement machine is copying that folder onto the new one. Reading what happened at 08:55 is opening a text file.

Does that mean it is less capable?

It means it is a different product. A scheduled music rotation with separation rules, dayparting, jingles, a play log you can export for a licensing return, recording and listen-again, neural text-to-speech that works with the internet unplugged, bells through a relay board, zone announcements and a hardware emergency button - that is all there, in the one service.

What is not there is public internet streaming: no Icecast source, no HLS. If you need listeners outside the building, you need one of the container stacks, or a separate machine running one. That is a real trade and it is better to know it now than after the purchase order.

What about the database?

There is not one. Playlists, the library index, rotation settings, dayparts and listener counts are JSON files next to the config, and each of them is optional - a device that has none of them behaves exactly as it did before those features existed. Nothing to install, nothing to tune, nothing that needs a nightly dump. If you delete one, you lose that feature's settings and nothing else.

How do I try it without committing?

Install it on any Windows machine or a spare Pi, point it at a folder of audio, and give it a schedule. It runs entirely offline, so nothing has to be opened to the internet to see whether it does what you need. The cloud dashboard is an option you switch on, not a dependency you accept.

Frequently asked questions