The TeamSpeak 6 server is still in beta. The newest release on the official repository is v6.0.0-beta12.1, published 28 July 2026, and no stable version has shipped. It runs fine for a community that can tolerate the occasional restart, ships as a 57 MB Docker image, and comes with a 32-slot beta licence that TeamSpeak renews roughly every two months. What it does not do is take over from your TeamSpeak 3 server: TS3 licences are not valid on TS6, and TeamSpeak states there is currently no migration path between the two.
That last sentence is the entire decision.
Run TS6 beta or stay on TS3?
Run the TS6 beta if your server is a gaming community or a group of friends, your channel tree is small enough to rebuild by hand in an evening, and nobody loses anything if the process dies at 2am and comes back three minutes later. The beta has been moving quickly — beta12.1 exists specifically because beta12 shipped a startup crash — which is a good sign about the pace and a bad sign about stability.
Stay on TeamSpeak 3 if you are running anything with obligations attached: a paid community, an esports org, a server with hundreds of permission-tuned channels, or anything where "we rebuilt the channel tree from memory" is not an acceptable sentence. There is no exporter that carries your channels, groups and permissions across, so the migration cost is manual and it is paid twice — once now to the beta, and again later when the stable server arrives with, presumably, an actual migration tool.
Worth knowing for the in-between case: TeamSpeak has said publicly that the TeamSpeak 6 client can connect to a TeamSpeak 3 server. If your goal was simply to let members use the new client, you may not need a new server at all.
Self-hosting the TS6 beta with Docker
Docker is the method the project itself recommends, and it is the one worth using — the alternative is a bare binary you chmod and babysit under a systemd unit you wrote yourself.
services:
teamspeak6:
image: teamspeaksystems/teamspeak6-server:latest
container_name: ts6
restart: unless-stopped
environment:
TSSERVER_LICENSE_ACCEPTED: accept
ports:
- "9987:9987/udp" # voice
- "30033:30033/tcp" # file transfer
- "10080:10080/tcp" # web query (optional)
volumes:
- ts6-data:/var/tsserver/
volumes:
ts6-data:
Four things in that file are load-bearing:
TSSERVER_LICENSE_ACCEPTED=accept is mandatory. Without it the server refuses to start. On a bare binary the equivalent is the --accept-license flag. If your container exits immediately after pull, this is the first thing to check.
9987 must be UDP. Voice does not work over TCP, and a Docker port mapping without the /udp suffix silently publishes TCP instead. The symptom is a server that appears online in the client list and then times out on connect — the single most common self-hosting failure, and it looks like a firewall problem when it is a one-word typo.
Everything durable lives in /var/tsserver/. One named volume there covers the database, the licence state and uploaded files. Leave it out and every container recreate hands you a brand-new empty server with a new admin token.
10080 is optional and should stay closed unless you need it. Web query is an administrative interface; there is no reason to publish it to the internet on a community voice server.
On first start the server prints an admin token to the log once and never again. Capture it immediately:
docker logs ts6 2>&1 | grep -i tokenResource footprint and what to cap it at
A TeamSpeak server is not a heavy process. The image is 57 MB and idle memory sits in the low tens of megabytes; the load is per-connected-client and it is mostly network, not CPU. Capping it is still worth doing, because a voice server is exactly the kind of long-lived process that nobody looks at for six months.
256 MB of memory and half a CPU core is a comfortable ceiling for a 32-slot beta licence. In Compose that is deploy.resources.limits; on the command line it is --memory=256m --cpus=0.5. The point is not to save resources — it is that a capped container degrades alone instead of taking the web server on the same box with it.
The port and firewall checklist
| Port | Protocol | Purpose | Open to the internet? |
|---|---|---|---|
| 9987 | UDP | Voice | Yes — required |
| 30033 | TCP | File transfer | Only if members share files |
| 10080 | TCP | Web query (admin) | No |
Two things that trip people up beyond the firewall itself. Cloudflare will not help you here — the orange cloud proxies HTTP and HTTPS, not UDP voice traffic, so the DNS record for a TeamSpeak server must be grey-clouded and pointed straight at the host. And if you are behind NAT at home, 9987/UDP has to be forwarded on the router as well; the container port mapping only gets the packet from the host to the container.
What TeamSpeak 3 still gives you
The TS3 server remains the production answer, and it is the one most panels and one-click catalogues still ship. A typical deployment exposes 9987/UDP for voice, 10011/TCP for ServerQuery and 30033/TCP for file transfer, and it will run comfortably inside a 128 MB memory cap. Its permission system is deep, well documented and, crucially, has fifteen years of community answers behind it — when something breaks at midnight, somebody has already posted the fix.
If you are deciding today: put the TS6 beta on a subdomain and a second port range, invite ten people to hammer it, and keep the TS3 server exactly where it is. That costs you one container and tells you more than any changelog.
Running it next to your websites
Voice servers usually end up on the same VPS as a website, and that is fine as long as the two cannot starve each other. The parts that matter: a memory and CPU ceiling on the container, a named volume so a recreate does not wipe the channel tree, and a restart policy so a reboot brings it back without you.
Panels with container management handle this from one screen — in Panelica, TeamSpeak is one of the ready-made application templates, deployed with its UDP and TCP ports already mapped correctly and a 128 MB floor suggested, with the resource caps editable afterwards without touching a Compose file. There is nothing there you cannot do with the YAML above; the difference is that the UDP suffix and the volume path are already right, which is where most self-hosted voice servers actually die.
Frequently asked questions
Is the TeamSpeak 6 server released?
Not as a stable version. As of 4 August 2026 the newest published release is v6.0.0-beta12.1, dated 28 July 2026, and the project describes the self-hosted server files as still under active development and not feature-complete.
Can I move my TeamSpeak 3 server to TeamSpeak 6?
No. TeamSpeak states that TS3 server licences are not compatible with TS6 servers and that there is currently no migration path between the two versions. A TS6 server starts empty.
How many slots does the TeamSpeak 6 beta server have?
The beta ships with a 32-slot licence that is renewed roughly every two months for the duration of the beta and evaluation period.
Which ports does a TeamSpeak server need?
TeamSpeak 6: 9987/UDP for voice, 30033/TCP for file transfer, and optionally 10080/TCP for web query. TeamSpeak 3: 9987/UDP, 30033/TCP and 10011/TCP for ServerQuery. Voice will not work if 9987 is published as TCP.
Can I host a TeamSpeak server for free?
The server software is free to run yourself, including the beta's 32-slot licence — what you pay for is the machine. A small VPS is enough; the process is light and the constraint is bandwidth and latency, not CPU.
Why does my TeamSpeak container start and immediately exit?
Almost always the missing licence acceptance. The TS6 image requires TSSERVER_LICENSE_ACCEPTED=accept in the environment, or --accept-license when running the binary directly. Check docker logs for the licence message before looking anywhere else.