Why AzuraCast Does Not Behave Like a Normal PHP App

Most PHP applications you install on a Managed Cloud Shared Hosting account are request-driven: a visitor hits a URL, PHP runs, a response comes back, and the process exits. AzuraCast is a fundamentally different animal. It is a radio automation platform that ships as a full Docker stack, and its background layer is built around long-running daemons rather than short PHP requests. The web dashboard you see is only the visible surface. Underneath it, AzuraCast expects to run Liquidsoap for audio playout, Icecast or SHOUTcast for listener connections, a MariaDB server, a Redis instance for its message bus, a Supervisor process manager, and a set of persistent PHP worker processes that consume queued jobs continuously.

That last group is the part people mean when they ask about "cron and background tasks." AzuraCast does have a scheduler, but it is not a single crontab line that fires a maintenance script every fifteen minutes the way Blesta or WordPress does. It uses a Symfony-based console application (bin/console) combined with a message queue backed by Redis. Jobs like media reprocessing, podcast feed imports, listener analytics rollups, automated playlist scheduling, backup runs, and "now playing" notifications are all pushed onto queues and picked up by resident worker processes that never exit. Supervisor keeps those workers alive and restarts them when they crash. There is a cron component too, driven internally, that enqueues the periodic sync tasks: the near-real-time task that runs every few seconds to update now-playing data, plus one-minute, five-minute, and hourly cycles.

This design is deliberate and works beautifully on a dedicated VPS where you own the whole machine. It collides head-on with the constraints of an unprivileged hosting account. On LiteSpeed with CloudLinux, your PHP processes are killed when the request ends or when they exceed the LVE and CPU limits assigned to your user. You cannot install Docker, you cannot start Liquidsoap or Icecast, you cannot register a Supervisor service, and you cannot run a PHP process that stays resident for hours consuming a Redis queue. Understanding this before you touch a single setting saves a great deal of frustration, because a large part of "troubleshooting AzuraCast background tasks" on shared hosting is really about recognizing which pieces can exist here at all.

Mapping the Task Layer Against Your Account's Limits

Walk through each background component and check it against what an unprivileged account actually permits. The audio engine, Liquidsoap, is a compiled binary that opens network sockets and holds them open to stream to listeners. That is a persistent daemon and a listening service on non-HTTP ports, both of which are outside the scope of a shared account. Icecast and SHOUTcast are the same story: they bind to ports and serve continuous streams. Nothing in cPanel Jupiter or DirectAdmin Evolution exposes a way to run those, and even if you smuggled a binary into your home directory, the process manager would terminate it and firewall rules would block the ports.

The Redis message bus is the next problem. AzuraCast's queue workers connect to Redis and block, waiting for jobs. Some hosting plans expose a per-user Redis via the cPanel interface, but that only gives you a key-value store; it does not give you a way to run the resident worker that drains it. A queue with no worker simply fills up and the tasks never execute. The internal cron scheduler that enqueues periodic sync jobs is itself normally launched by Supervisor inside the container, so without Supervisor the enqueue side is also missing.

You might reasonably ask whether you can replace Supervisor with the cron system your panel exposes. cPanel's Cron Jobs tool and DirectAdmin's cron feature can run a command on a schedule, and the smallest interval both offer is one minute. In principle you could add an entry like this to trigger the sync task:

* * * * * /usr/local/bin/php /home/USER/azuracast/bin/console azuracast:sync:run >/dev/null 2>&1

Even setting aside the fact that AzuraCast is not designed to be run outside its container, this only addresses the enqueue side. The command pushes jobs onto Redis, but there is still no permanent worker to consume them, and the one-minute floor cannot satisfy the near-real-time now-playing task that needs to run every few seconds. You would also be invoking the Symfony console with your account's PHP CLI, which under CloudLinux inherits your max_execution_time, memory ceiling, and CPU throttling from the LVE. The realistic conclusion is that the core streaming and queue architecture of AzuraCast cannot be hosted on a shared plan. That is not a limitation to fix; it is a signpost pointing at the correct platform.

Diagnosing Task Failures With the Tools You Actually Have"

If you have inherited an environment where someone attempted this and jobs are not firing, work through the evidence available to an unprivileged user. Start in File Manager and look for the application's log output. A container install writes to its own /var/azuracast/www_tmp and storage/logs paths, but a manual attempt under your home directory will typically drop errors into the PHP error_log alongside the script that ran, or into the path defined by your .user.ini. Set an explicit target so you can find it:

; place in the AzuraCast web root, e.g. /home/USER/public_html/.user.ini
log_errors = On
error_log = /home/USER/logs/azuracast_php_errors.log
memory_limit = 256M
max_execution_time = 60

Give LiteSpeed up to five minutes to recycle the PHP handler after editing .user.ini, then trigger the console command manually from a cron entry and read the log. Common entries you will see are fatal errors about a missing Redis connection, exceptions about being unable to spawn Liquidsoap, or permission errors writing to storage. Each of these confirms the same root cause rather than a fixable bug.

Check your PHP build in the panel as well. Under cPanel's MultiPHP Manager or the Select PHP Version / PHP Selector interface (DirectAdmin exposes the same CloudLinux tool), AzuraCast expects a modern PHP 8.2 or newer runtime with extensions like redis, intl, gd, and pdo_mysql enabled. Toggle those in the Extensions tab and confirm they load with a small phpinfo() file. If redis is absent and your plan offers no Redis instance, the queue layer has nowhere to connect, which is often the true reason "scheduled tasks stopped." Use phpMyAdmin only to verify the application database is intact and reachable; the tasks that populate listener history and now-playing rows write there, so an empty history table with a healthy schema is another sign the workers never ran.

The honest engineering answer is that AzuraCast belongs on a VPS or dedicated instance where you have root, Docker, and the ability to run Supervisor, Redis, and Liquidsoap as persistent services. If email notifications from the platform are your concern rather than the streaming engine, the same SMTP and queue-worker principles that apply to other Laravel and Symfony apps are worth reviewing in our guide on Pterodactyl email delivery and queue workers. For AzuraCast itself, migrate the stack to a plan that permits background daemons, and reserve your shared account for the static sites and standard PHP apps it was built to serve.