A practical route for a 24/7 Indian music stream is to run AzuraCast on a Linux VPS, then use its Liquidsoap AutoDJ and Icecast-KH components to schedule and deliver the station. You upload music, create playlists, configure the station, and let the VPS run the broadcast instead of keeping a home computer switched on.
That deployment only solves playback and distribution. It does not give you permission to broadcast commercial recordings or musical works, so investigate the rights for your catalogue and intended internet use before you put the station online.
Decide what the station is allowed to broadcast
Start with the catalogue, not the server. Write down what you plan to play, where the recordings came from, where listeners will be located, and whether the stream is personal, promotional, monetised or connected to a business. Those details affect which rights holders you need to contact.
For a radio-style internet stream, treat the musical or literary work and the sound recording as separate clearance questions. A song may involve rights in the composition and lyrics, while a label or another owner may control the particular recording you want to play. Permission for one does not automatically prove permission for the other.
IPRS identifies “Internet Non Interactive” as a licensing category. Its guidance says platforms using repertoire represented by IPRS need a licence or a royalty arrangement for its author members. Read the current IPRS licensing information and ask how the category applies to your exact station, catalogue, territory and business model.
Do the same with sound-recording rights. PPL India's tariff page states that its standard licence covers on-ground use and “DOES NOT permit any non-physical / digital usage”. That means you should not assume that a licence for music played in a shop, venue or office covers an internet stream. PPL also directs radio broadcasting enquiries to its licensing team, so ask specifically about internet-only streaming and the recordings in your proposed catalogue through its official licensing information.
Other rights holders may be relevant, including labels, independent artists, publishers and collecting societies outside your planned repertoire. If you use devotional music, regional releases, film songs, remixes or recordings supplied by a third party, retain the agreements and invoices that explain what you are allowed to do. Do not rely on a file being easy to download as evidence that it is licensed.
Create a simple rights spreadsheet before uploading anything. Useful columns include track title, artist, recording owner, composition owner, source, permitted use, territory, start and end date, and evidence of permission. If a track is unclear, leave it out of the AutoDJ library until the rights holder answers.
A working station can still receive a takedown, claim or complaint if its music permissions are incomplete. Software installation does not clear music rights, and an Indian terrestrial or venue licence should not be treated as an internet-streaming licence without written confirmation.
Choose a Linux VPS for AzuraCast
AzuraCast is server-based software designed for a VPS or another suitable server. For a small station, a single Linux VPS is a straightforward starting point because the operating system, application and media library stay under one account and can be managed remotely.
Choose the provider and location by looking at the practical path between the machine and your listeners. Consider the VPS region, network and bandwidth policies, any egress charges, support quality, available snapshots, backup options, allowed ports and the provider's recovery process. A location near a large part of your audience may reduce network distance, but it does not remove the need to monitor the station.
AzuraCast documents one-click options for providers including Linode by Akamai, Vultr and DigitalOcean, as well as manual installation. That is a deployment convenience rather than an endorsement of one provider. Provider plans, regions and terms change, so compare the current offerings directly before ordering.
Use a fresh, minimal Linux host compatible with Docker. Avoid placing unrelated websites, databases or experimental applications on the same VPS until you understand their resource use. A music station needs predictable access to memory, CPU, disk and network ports, and another application can make a quiet failure difficult to diagnose.
You will need administrator or sudo access for installation and maintenance. Keep the root password and AzuraCast administrator credentials private, use strong unique credentials, and restrict access to the administration interface where your hosting setup allows it. The public player can be available to listeners without making the management account public.
A domain or subdomain is useful even when the VPS provider gives you an IP address. It gives listeners a stable address and supports HTTPS for the administration interface. Plan the DNS record before enabling certificates, and check that the name points to the VPS as required by AzuraCast's SSL and HTTPS documentation.
If your aim is a YouTube visual stream rather than an internet radio endpoint, the operating model is different. For an uploaded video that should keep running after your computer is off, StreamNeo removes the need to maintain a VPS and AutoDJ installation for that particular YouTube workflow; it does not replace the music-rights checks for the file.
Check resources without mistaking them for capacity
AzuraCast lists a minimum of a 64-bit x86 or ARM64 CPU, 2 GB of RAM and at least 20 GB of disk. It recommends 4 CPU cores, 4 GB of RAM and at least 40 GB of disk for hobby use across a few stations. These figures are software requirements and recommendations, not a promise about how many listeners a VPS can serve.
The actual load depends on the size of the media library, the number of stations, stream formats, transcoding work, administration tasks, backups and listener traffic. A station that appears quiet can still run short of disk space if recordings, logs or backups grow without a plan. A larger audience can put more pressure on network transfer and the streaming frontend than the AutoDJ alone suggests.
| Planning point | What to use it for | What it does not tell you |
|---|---|---|
| 64-bit x86 or ARM64 CPU | Checking the basic architecture | Listener capacity or guaranteed performance |
| 2 GB RAM | AzuraCast's stated minimum | That every station will be comfortable at this level |
| 20 GB disk | AzuraCast's stated minimum storage | How much music, backup history or logs you can retain |
| 4 CPU cores and 4 GB RAM | AzuraCast's hobby recommendation for a few stations | A maximum audience or a service-level guarantee |
| 40 GB or more disk | AzuraCast's hobby recommendation | Permanent room for an expanding library |
Use the minimum as a compatibility check, not as your default purchase if you can avoid it. For a first hobby station, the recommended resource level gives you more room to observe the application and keep a useful media library, but it still needs measurement. Review CPU, RAM, disk and network activity after the station has run through busy and quiet periods.
Keep music storage separate in your thinking from backup storage. If the VPS has 40 GB of disk, that space is not all available for tracks. The operating system, Docker data, AzuraCast files, logs, artwork and temporary files also need room. A backup stored on the same disk will not help much if that disk fails.
If the audience or catalogue grows, change one variable at a time where possible. Remove unused audio, adjust stream formats, move backups elsewhere or resize the VPS based on observed pressure. Do not claim that the published resource recommendation guarantees a particular number of simultaneous listeners, because AzuraCast does not present it that way.
Install AzuraCast with the recommended Docker method
AzuraCast recommends Docker for most installations. It packages the application and its supporting services into a managed installation, which is more repeatable than assembling every component by hand. Follow the current AzuraCast Docker installation guide rather than copying an old command from a forum post.
Begin with the fresh minimal VPS, connect through SSH, and confirm that you have the administrator or sudo access the guide requires. Read the prerequisites and supported operating-system notes on the official page first. AzuraCast also documents unattended installation commands suitable for cloud-init, which can be useful when provisioning a new machine, but you should still understand what the installation is doing before you use automation.
Do not paste commands into a production host without checking their current source and target. Installation instructions can change as software versions, dependencies and supported platforms change. Keep a private record of the installation date, VPS details, domain name and the version information shown by the application.
When the installer completes, open the web interface, create the administrator account and finish the initial settings. Create a station with a clear name and short identifier. Keep the stream name and public description accurate: if the station plays a limited catalogue, does not broadcast continuously during maintenance, or has a particular regional focus, say so plainly.
Before adding audio, make sure each file has passed your rights check. Upload only the tracks and station material that you can use for the planned stream. Treat downloaded playlists, ripped recordings and files supplied by friends as unverified until you know their permission status.
Set a domain or subdomain to the VPS and configure HTTPS according to AzuraCast's current instructions. The SSL guide says a domain is required for Let's Encrypt. HTTPS protects logins and makes the administration address less exposed to casual interception, but it does not make the music catalogue licensed.
Keep credentials out of shared documents and screenshots. If more than one person manages the station, use separate accounts where the software supports them and remove access when someone stops working on the project. This is a small operational habit that matters once the station is no longer a one-person experiment.
Configure Liquidsoap AutoDJ and Icecast-KH
AzuraCast includes Liquidsoap for automated playback and Icecast-KH as the broadcasting frontend. The useful division is simple: your playlists and scheduling decide what should play, Liquidsoap prepares the continuous programme, and Icecast-KH exposes the stream to listeners through its mount point.
Create a small test library first. Add a few cleared tracks, a station ident or spoken announcement if you have permission to use it, and enough material to observe transitions. Do not upload the complete catalogue before you know that the station is delivering the correct audio and that your playlist rules behave as intended.
In the station interface, create playlists and assign their schedules. Decide whether your main music list should be random, ordered or weighted, then add separate categories for announcements, devotional material, regional language blocks or other programming you have planned. Scheduling rules should match the clock and timezone you intend to use. Check daylight-saving behaviour if your audience or collaborators are outside India.
Review the AutoDJ settings for silence handling, track transitions, replay rules and metadata. A station that technically stays connected can still feel broken if it plays long silence, repeats one song, displays the wrong title or changes between items abruptly. Listen through the public player rather than judging only from the administration screen.
Icecast-KH provides the listener-facing stream. Confirm the public mount point, codec and stream metadata, then open the player from a separate network. If it only works while logged into the VPS or web panel, it is not ready for listeners. Test both the player page and the direct stream address that you expect third-party players to use.
Keep the audio configuration modest at first. Every additional format or transcoded output creates more work for the system and another endpoint to test. Add alternatives only when you have a clear listener need. Record the final mount point, station name and metadata settings in your operating notes so another person can restore the setup.
For questions about the wider YouTube workflow, the guide to starting a YouTube 24/7 live stream with a cloud service in India covers a different distribution path. Do not confuse a YouTube live broadcast with an Icecast internet-radio stream: they have different endpoints, controls and rights considerations.
Test the station before calling it continuous
Run a controlled test before announcing the station. Start the AutoDJ, open the public player from a device outside the VPS network, and listen long enough to hear several transitions. Check that the title, artist and artwork are sensible, that the stream starts without manual intervention, and that the player recovers after a short connection interruption.
Test the things that tend to fail overnight. Restart the browser, close the administration session, reboot the VPS during a planned test window, and check whether the station starts again as expected. Confirm that the media library is still mounted, the public URL resolves, and the playlist does not stop when one file is damaged or missing.
Keep a short test record with the date, station name, public URL, files used and any corrective action. This is more useful than relying on memory when a listener reports silence several days later. If you find a bad file, remove it from the active playlist and keep the original somewhere separate until you understand the problem.
Separate the server test from the rights test. A clean audio transition proves that the software can play the file; it does not prove that you may broadcast it. Keep a clear “approved for stream” collection and make AutoDJ use that collection rather than a general downloads folder.
You can also check how the station behaves from mobile data and from a different broadband connection. This may reveal DNS, firewall or network-path problems that are invisible when you test from the same machine used to administer the VPS. It will not prove that every listener can connect, but it gives you a more realistic first check.
Monitor, back up and maintain the VPS
A 24/7 station is an operating routine, not just an installation. Check that the process is running, the public mount point responds, the disk has free space, memory is not continually exhausted, and the stream is producing current metadata. A simple daily check is better than discovering after several days that AutoDJ stopped at the first unavailable file.
Set an alert for the failures you can act on: an unreachable player, a full disk, sustained high resource use, or a VPS that cannot be reached. Decide who receives each alert and what the first response is. If nobody is available to investigate, the station is not truly unattended even if the application is automated.
Back up the station media, configuration and any rights records. Keep at least one copy away from the VPS. A snapshot can help with a machine-level recovery, but it is not a substitute for a separate copy of important music metadata, playlists and permissions. Test restoring a small part of the backup before assuming it works.
Plan updates during a low-listener period. AzuraCast's update guidance recommends backing up and warns that stations will be briefly offline during updates. Tell regular listeners if maintenance will interrupt the stream, and record the change so you know whether a later fault began before or after the update.
A single VPS can fail, lose network access or require maintenance. Do not describe one as guaranteed 24/7 uptime. If your audience or distribution needs justify it, investigate a relay or a second recovery path. AzuraCast documents a remote relay option for distributing a stream or handling a larger volume of incoming traffic, but whether it is necessary depends on your audience, budget and architecture.
For YouTube-specific interruptions, the guide to fixing a 24/7 YouTube stream that keeps disconnecting deals with a different failure path. If the station is also used to feed YouTube, monitor the YouTube ingest separately from the Icecast player rather than assuming that one healthy endpoint proves the other is healthy.
Review Indian music and recording permissions
Before launch, send a written description of the proposed service to the relevant rights organisations and owners. Include that it is an internet, non-interactive stream; the countries where it will be available; whether listeners can choose tracks; whether the station is commercial or monetised; the catalogue and languages involved; and whether you will also distribute the programme on YouTube or another platform.
Ask IPRS about the musical and literary works in its repertoire and the Internet Non Interactive category. Ask PPL about the sound recordings in your intended catalogue and the licence needed for internet streaming. If a recording is controlled by a label, independent artist or another organisation, contact that owner as well. Request the response in writing and retain it with the track records.
Do not assume that a PPL on-ground licence covers digital use. PPL's own wording rules that out for its standard tariff. Also do not assume that an Indian radio broadcast permission automatically covers internet simulcasting. The exact answer depends on the rights, repertoire, use, territory and commercial arrangement.
You may see PPL describe a large repertoire covering several Indian languages. That is a statement about its stated library, not proof that every song you want is represented or cleared for your stream. Check each recording and territory rather than treating a repertoire claim as blanket permission.
If a rights holder has not answered, use music that you have created, commissioned with suitable written rights, or obtained from a source whose terms clearly allow this exact use. Keep attribution requirements where applicable. A rights spreadsheet should be reviewed whenever you add a new album, language block, remix or programme segment.
The guide to avoiding copyright claims on a YouTube radio station livestream is useful for understanding the platform side of the problem, but platform advice is not a replacement for permission from the underlying rights holders. Check current official guidance before launch and whenever the format changes.
Once the station passes both tests, announce it with an honest schedule and contact address. Tell listeners what the station plays and when planned maintenance may occur. Keep monitoring it after launch, because a permission record, a healthy VPS and a working player each address a different part of the job.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Can AzuraCast itself provide permission to play Indian film songs?
No. AzuraCast provides station management, automated playback and streaming components, but it does not grant music rights. Check the musical-work and sound-recording permissions separately with IPRS, PPL and any other relevant rights holders.
Is 2 GB of RAM enough for a 24/7 station?
AzuraCast lists 2 GB as a minimum, while its hobby recommendation is 4 CPU cores, 4 GB of RAM and at least 40 GB of disk for a few stations. Neither figure guarantees a listener capacity, so measure the actual station and allow room for its library, backups and stream workload.
Do I need a domain name for AzuraCast?
A domain or subdomain is strongly useful for a stable public address and HTTPS. AzuraCast's SSL guidance says a domain is required for Let's Encrypt, so point the DNS record to the VPS before requesting that certificate.
Can one VPS guarantee that the station never stops?
No. A VPS can fail, lose network access or need maintenance, and the application can encounter a file, storage or configuration problem. Use monitoring, separate backups, planned updates and a recovery path, then describe the station as continuously operated rather than promising uninterrupted uptime.