Mopidy Discourse

Multiple Mopidy Instances/SoundCards | One Server

I’ve been researching this issue for a few days and am struggling to find centralized documentation on how to do this. I have read this thread, and this thread, which has been the most helpful thus far but haven’t found a straightforward, clear answer on how to achieve this.

Cliff notes version of what I’m looking for:

-I have a server running ProxMox
-I have an instance of Debian installed in a VM running on this server
-I want to run multiple instances of Mopidy on the Debian VM and tie each instance to a discrete USB soundcard
-Let’s assume that all the issues of getting the VM up and running and passing the USB soundcards through to the VM is not an issue as I’ve got all of that up and running and can list each card by typing “$ aplay -l” into the terminal

My questions are:

  1. How do I get multiple instances of the Mopidy client to run on this single Debian install?
  2. What .conf files or directories would need to be edited to create multiple Mopidy instances and tie them to separate, discrete USB sound cards?

More detailed version:

– The Basic Idea –
I’m trying to setup a multi-zone Mopidy install on a singular server. My plan is to control each zone by using Iris as the front-end from our phones. I’ll tie each Mopidy instance to each zone and go into the “Settings” menu of Iris to change servers (which will be named for their corresponding zones throughout the house) and control the audio stream to each zone from there.

There will be 7 separate zones (Bathrooms, Bedrooms, Garage, Basement, Outside…etc) that Id’ like to control individual streams to. My kids like music in their rooms, I want it in the garage or basement if I’m working. Bathroom for ambiance and so on. I’ve been able to get this to work with no issues with a combination of several VMs and raspberry pis with individual Mopidy installs before, but I because of an issue with the server handling audio streams between more than 2 VM’s have to rethink the setup.

– The Hardware –
I have a server that will be running a basic Debian installation. That server has 7 USB sound cards connected. Each soundcard has been passed through to the VM and is up and running in the Debian installation (they can all be seen by typing “aplay -l” in the terminal).

Each USB soundcard will feed a 12-channel amplifier that’s mounted in the server rack by the server itself with speaker cable runs to in-wall and in-ceiling speakers throughout the house and outdoor speakers on the back patio.

– The Problem –
I can install one instance of Mopidy, control it via Iris and sync it with Spotify, but I can’t sort out how to get other instances of Mopidy to work on the same Debian installation, despite reading the other threads where people have tried to do something similar to this setup (some of which have had success, but never documented how).

As mentioned above, I have set up something similar to this before where I had several raspberry pi’s and the server each running their own single instance of Mopidy and it worked well. I was able to control each of them via a single Iris front end, play a different stream to each of them, etc. I’d like to be able to consolidate and expand that setup by using these USB sound cards to feed multiple zones from a single Debian install rather than having a raspberry pi for each zone.

I’m learning as I go here…I’m technical enough to get myself into trouble, but will need some 101 explanations (as you can tell).

I’m grateful for your help!


I‘d like to bump this, have the same situation with one server supposed to host multiple audio zones. Looking for exactly this solution.
Could you solve this?
Really looking for some pointers.


1 Like

I suppose you could run multiple Docker containers. Each one could have access to a different soundcard and use different ports. I haven’t tried it.

1 Like

Thanks jjok. This is exactly how I ended up solving this problem.

I have multiple dockers. One for each “zone” that I put together in a combined .yml file and ran through Docker Compose.

Each instance is tied to it’s own sound card and has it’s own MAC/IP address that I point the Mopidy server back to.

I’m happy to help if anyone has questions. It was quite the learning process for me, but aside from a few minor glitches, it’s been working very well.


wow, having a Docker layer just for that seems quite excessive.
Is there no other way? The docs suggest that multiple instances should work, is nobody running such a configuration?

Thanks for a response, Cheers

People seem to enjoy the extra complexity of docker but you are entirely correct, there’s no need for it and multiple instances will work fine if you point each one to it’s own config file.

I agree 100%, but I received no support for my use case, so I went with Docker instead.

I was able to get a few instances of Mopidy on one Debian install to work at one point during my trials, but was getting issues with sound being distorted as I played to more than one zone. Again, with no answers to my initial post, I had to go with a solution that worked, and Docker, well…just worked.

Hey kingosticks. Thank you for this software. It’s FANTASTIC!

Can you answer my questions from my OP? I would love to get this running without Docker, but as stated above (I think we replied at the same time) have not been able to.

My main questions from the OP were:

  1. How do I get multiple instances of the Mopidy client to run on this single Debian install?
  2. What .conf files or directories would need to be edited to create multiple Mopidy instances and tie them to separate, discrete USB sound cards?

Thank you again!

  1. What do you mean by “the Mopidy client” here. Do you mean you want multiple Mopidy servers running on the same machine?

  2. If you are running Mopidy as a service you can read about the config file. If you look at /lib/systemd/system/mopidy.service you can see the config file is specified there:

ExecStart=/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf

And it’s also specified in /usr/sbin/mopidyctl:


If I was doing this I would create a new empty config file for each instance that overides stuff in my shared config at /etc/mopidy/mopidy.conf. I would then use a systemd template that lets me have a service for each instance which uses its own config file in addition to the share config.

Custom systemd units should live in /etc/systemd/system

sudo cp /lib/systemd/system/mopidy.service /etc/systemd/system/mopidy@.service
sudo nano /etc/systemd/system/mopidy@.service

Modify the ExecStart setting in /etc/systemd/system/mopidy@.service so it also reads an instance config file:

ExecStart=/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf:/etc/mopidy/mopidy-%i.conf

Create an empty config file for each instance:

sudo touch /etc/mopidy/mopidy-one.conf /etc/mopidy/mopidy-two.conf

Copy the important per-instance config to each new config file:

cache_dir = /var/cache/mopidy-one
data_dir = /var/lib/mopidy-one

output = alsasink card=some_card_for_this_instance

username = some_other_username
password = blahblah

port = 6681

port = 6601

Make the directories:

sudo mkdir /var/cache/mopidy-one /var/lib/mopidy-one /var/cache/mopidy-two /var/lib/mopidy-two
sudo chown mopidy:audio /var/cache/mopidy-* /var/lib/mopidy-*

Enable and start the services:

sudo systemctl enable mopidy@one mopidy@two
sudo systemctl start mopidy@one mopidy@two

But this does leave mopidyctl not doing the right thing, it’s still hard-coded to use /etc/mopidy/mopidy.conf. I don’t have a neat way around this, I’d probably just copy it for each instance and edit the config variable:

sudo cp /usr/sbin/mopidyctl /usr/sbin/mopidyctl-one
sudo nano /usr/sbin/mopidyctl-one



And then use sudo mopidyctl-one config etc .

OK, so maybe neater approach is to make just one copy of /usr/sbin/mopidyctl

sudo cp /usr/sbin/mopidyctl /usr/sbin/mopidyctl-x

and edit the CONFIG_FILES variable in /usr/sbin/mopidyctl-x:

CONFIG_FILES="/usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf:/etc/mopidy/mopidy-$1.conf"; shift

So you can then call sudo mopidyctl-x one config and sudo mopidyctl-x one deps.

thanks for sharing this detailed info, very valuable clues, appreciated. Will go ahead and try it once some time is at hand.


Hi Kingosticks,

I am looking to build multiroom audio system using mopidy. I have mopidy and snapserver installed and running using video multiroom guide. However, this only play the sound on a machine with snap client using output = audioresample ! audio/x-raw,rate=48000,channels=2,format=S16LE ! audioconvert ! wavenc ! filesink location=/tmp/snapfifo in the config.conf, not on the server. When I change audio to output = autoaudiosink This will play audio on to raspberry pi.

My issue is I like to play audio on a raspberry pi as well as an option to cast audio on other machine with mopidy and snapclient installed.

I followed this instructions and changed the audio settings to one mopidy instance, lets say core to autoaudiosink and another instance mopidy-one to output = audioresample ! audio/x-raw,rate=48000,channels=2,format=S16LE ! audioconvert ! wavenc ! filesink location=/tmp/snapfifo.

Mopidy installed with “autoaudiosink” giving me error “Mopidy: websocket closed”. Other instance are running fine and cast audio on other machine with mopidy and snapclient installed.

I am novice and learning by following guides on the web so any suggestions are welcome. my configuration is same as posted in your comments above.

Two instances seems unnecessary. I’d have just one instance of Mopidy configured with a fifo output to your snapserver. Then I’d run snapclient on both the server and the client.


Thanks very much. i can confirm this is working as intended both on the server and client simultaneously. appreciate your time and sharing knowledge.

Did anyone get this multiple instances method working ?

I can confirm that by following most of the above but essentially duplicating 2 config instances of mopidy plus having both instances start seperately in the terminal, I can access the 2 databases off the same raspberry PI using Iris.
Iris has the ability to consult numerous databases in the same settings interface. That does not work for me but using the 2 ports in the URL in seperate web browser pages, accesses the 2 instances.
The only problem is that snapcast cannot play 2 files cleanly at the same time, but that is not a problem for me.