Your own Mumble server for the clan, set up the safe way

What your Mumble server actually asks for

Very little, as far as the official material goes: Mumble's documentation lists no processor or memory requirement for the server. The limits you will care about are set in one text file, /etc/mumble/mumble-server.ini on Debian 13 and current Ubuntu. Out of the box it lets 100 people connect at once (users=100) and caps what each of them may send at 558,000 bits per second (bandwidth=558000).

• Network: port 64738 by default. The server listens on it for TCP and for UDP, so your firewall has to let both through.
• Storage: a small SQLite database holding your channels, permissions and registered members. Back it up; it is the whole server.
• Bandwidth cap: per person, not for the whole server. Mumble's config page says each member's app picks the lower of its own setting and the server's, so the server value is a ceiling.

The server that fits

Most clans already rent a box for the game itself, and nothing stops the voice server living on it too. That is how our game server machines are meant to be used: a whole physical server with nobody else on it, a port not shared with any other customer at the access switch, and support by live chat, email or phone at any hour. If voice is the only job, the four-core micro server, racked in Bucharest and New York, is a real machine of its own; note that the smaller cartridges like it have power control rather than a full remote console.

Pick the site nearest where your members play: three cities in the US and two in Europe, all on the locations page. Once your order is approved, a server that is already racked takes about 30 minutes to reach you. Debian 13 and Ubuntu 24.04 are both on the one-click install list of the widest Linux server lines, and IPv6 comes at no charge if you want it, which matters for the firewall step below. Billing is month to month, so a clan that drifts apart is not stuck paying for a year.

Up and running in an evening

1. Connect over SSH, then turn the firewall on before the voice server exists, letting in nothing but SSH.
2. Check that ufw is filtering IPv6 as well. Ubuntu's ufw manual says a rule applies to both address types when IPv6 is enabled, and the package ships with IPV6=yes. If that line says no, ufw drops all IPv6 traffic except loopback, so members connecting over IPv6 cannot reach you. Set it to yes and reload ufw so every rule covers both address types.
3. Install the package with apt. It creates a service account called mumble-server and starts the server for you, still behind the closed firewall.
4. Edit the settings file (next sections), restart, then set your admin password with dpkg-reconfigure.
5. Only now open the door for your members. Leaving the protocol off ufw allow 64738 lets in TCP and UDP at once.

sudo apt update
sudo apt install ufw
sudo ufw allow 22/tcp
grep IPV6 /etc/default/ufw
sudo ufw enable
sudo apt install mumble-server
sudoedit /etc/mumble/mumble-server.ini
sudo systemctl restart mumble-server
sudo dpkg-reconfigure mumble-server
grep -E '^(ice|dbus|grpc) *=' /etc/mumble/mumble-server.ini
sudo ufw allow 64738

Using a different SSH port? Allow that port instead of 22 ahead of ufw enable; otherwise the firewall will shut you out of your own server.

The admin password nobody else should see

Mumble has an all-powerful account called SuperUser. The first time the server starts, it makes up a random password, 12 characters long, and logs it. Mumble's documentation names mumble-server.log as the place. From the source, we believe that on Ubuntu 24.04 or newer and on Debian 13, where systemd launches the server with -fg, the line ends up in the journal; sudo journalctl -u mumble-server shows it. Debian 12 keeps it in mumble-server.log under /var/log/mumble-server/. Treat that one as burned. Debian's own notes for the package point you to sudo dpkg-reconfigure mumble-server. It asks for a new password at a hidden prompt and hands it over on standard input.

Please don't use the shortcut you will find in old forum posts, where the password is typed straight after -supw on the command line. Anything typed that way can be read back from your shell history and, while it runs, from the process list.

Once you're in as SuperUser, register your own normal account, make it a member of Root's admin group, and use that from then on. Mumble's permissions guide explains that this group, which holds Write ACL on Root, can do everything.

Letting members in, keeping strangers out

You have two tools, and they work best together. A server password (serverpassword= in the file) is what a newcomer types to get in at all. Registration is how a member claims their name: their Mumble app already holds a certificate, and once they register, the server remembers it. In Mumble's source, the server password is asked of unregistered people only, so your regulars never need it again, and nobody else can show up under a registered member's name without that certificate.

By default every visitor may register themselves (the Register Self permission is granted to everyone on the Root channel). So the routine for a new recruit is simple: share the server password once, they join, they click register. Tell members to back up their certificate, since it is their login.

database=/var/lib/mumble-server/mumble-server.sqlite
serverpassword=pick-a-long-random-one
welcometext="Welcome in. Please register your name."
users=100
bandwidth=558000
sslCert=/etc/mumble/fullchain.pem
sslKey=/etc/mumble/privkey.pem
;ice="tcp -h 127.0.0.1 -p 6502"
;dbus=session

Choose the database= path first and the admin password second, because a fresh database file comes with a fresh SuperUser. The settings file holds your server password in plain text; the package keeps it readable only by root and the mumble-server group (mode 0640), and sudoedit keeps it that way.

A certificate that stops the warning pop-up

If you skip sslCert and sslKey, the server makes its own self-signed certificate, and every member's app will show a warning that it failed verification and ask whether to accept it anyway. Our suggestion to avoid that: get a certificate from a public certificate authority for the hostname your members connect to, copy it and its key into /etc/mumble/ readable by the mumble-server group, and restart. If your authority uses an intermediate certificate, bundle it into the same file or point sslCA at it. Each time the certificate renews, put fresh copies of both files in /etc/mumble/, then either restart the service or signal it: sudo systemctl kill --signal=SIGUSR1 mumble-server makes it re-read the certificate settings. Don't count on systemctl reload: the service file that Debian 13 and Ubuntu 24.04 ship defines no reload action.

Doors that should stay shut

Mumble can be remote-controlled through three interfaces, and a clan server needs none of them. Ice is the powerful one: Mumble's configuration page warns that, with no secrets set, anyone who can reach its port gets full admin rights over every virtual server. Debian's package switches it off; upstream leaves it on, but only on 127.0.0.1 port 6502. If a web panel ever needs it, keep it on 127.0.0.1, set icesecretwrite, and never open 6502 in the firewall. Mumble's scripting documentation marks gRPC as unreleased, and the settings file that ships has no line for it at all. D-Bus is marked obsolete: keep the ;dbus= line with its semicolon in front.

A quick check that nothing is switched on by accident: the grep line in the setup commands should come back empty. And remember the firewall: the server binds every address the machine has unless you set host=, so ufw needs IPV6=yes for the 64738 rule to cover your IPv6 address as well as IPv4; with IPV6=no, members on IPv6 are simply refused.

Keeping it healthy

• Copy the SQLite file and the settings file to another computer regularly; stop the service first for a clean copy.
• Install updates through apt. Debian 13 ships version 1.5.735 and Ubuntu 24.04 ships 1.5.517, while Mumble's own latest release is 1.5.939.
• Hosting a LAN night where everyone shares one address? The built-in autoban (10 connections in 120 seconds earns a 300-second ban) can trip; the settings file offers autobanSuccessfulConnections=false for that.
• Want to hide your member count from strangers? allowping=false stops the server answering the pings that reveal it, though you must keep it on if you ever want a public listing.
• Prefer TeamSpeak? Our TeamSpeak workload page walks through TeamSpeak's licence and the ports it uses.

Questions people ask

Is Mumble free to run on my own server?

Yes. Mumble is free and open source, and the server package comes straight from Debian or Ubuntu's own repositories. Your only cost is the machine it runs on.

Murmur or mumble-server: which one do I install?

They are the same program. Debian's package notes treat the three names (murmur, murmurd and mumble-server) as one and the same server binary. On current releases you install the package called mumble-server.

My friends can't connect. What should I check first?

Make sure the firewall lets TCP and UDP through on 64738, on IPv6 and IPv4 alike when your machine has an IPv6 address too. Then look at the server's own log with journalctl -u mumble-server for a reason, such as a wrong server password or a name already registered to someone else's certificate.

Can I list my server publicly for anyone to find?

You can, but not with a server password. Mumble's public list requires the password to be empty, pings answered (allowping on), a valid certificate (or the server's self-made one) and the register settings filled in. For a private clan server, leave registerPassword blank and nothing is published.

Will voice quality suffer if lots of us talk at once?

Each member's upload is capped by the server's bandwidth setting, 558,000 bits per second unless you change it. What the server sends out grows with the number of people in a channel, which is our own reasoning rather than a documented figure, and is one reason an unmetered port suits voice.