TeamSpeak 6 Server Beta: Docker Setup and Hosting Limits

What the TeamSpeak 6 Server Beta Provides

This repository distributes the beta version of the TeamSpeak 6 Server, intended for early access, testing, and feedback before the stable release. The server is for organizations and communities that want to operate their own voice service rather than rent an official server through TeamSpeak Communities. The README identifies gaming, education and training, internal business communication, and informal communication among friends and family as use cases.

The project addresses the operational side of voice communication: accepting client connections, providing a server process, exposing network services, storing server data, and offering configuration for administrators. It is not a desktop voice client. The README directs users who want the TeamSpeak 6 Client to the TeamSpeak downloads page, while this repository focuses on the self-hosted server files.

The beta status matters when choosing it. The README says the dedicated server is still under active development and is not fully feature-complete. New features may be unstable or change during the beta. Administrators should therefore treat this as an evaluation target rather than assuming that its behavior will match the eventual stable release.

How TeamSpeak 6 Server Configuration and Data Flow Work

The README documents three configuration paths. Command-line arguments apply options when the process starts, which is useful for temporary changes and scripted launches. Environment variables suit Docker deployments and can keep startup arguments shorter. A persistent YAML configuration is recommended for a longer-lived server, and the README says a default file can be generated with `--write-config-file`.

The documented settings include voice and file-transfer ports, database connections, IP bindings, and logging. The server supports both SQLite and MariaDB. Docker examples place persistent server data in `/var/tsserver`, mounted from the `teamspeak-data` volume. The Compose example maps UDP port `9987` for voice and TCP port `30033` for file transfer. It also includes a commented TCP mapping for port `10080`, identified as the Web Query service.

A Prometheus metrics endpoint and ServerQuery guest access are listed as available. The README says both are covered in `CONFIG.md`, so those details should be checked there before exposing them to a network. The visible architecture is a server process configured through arguments, environment variables, or YAML, with its state persisted through a file-backed Docker volume or the server's native data directory. The repository listing includes `CONFIG.md`, `compose/`, and license documentation, but the README does not describe internal modules or a client protocol data path.

Docker Installation and First Launch

The README recommends Docker as the easiest starting point and provides a `docker run` example. The command names the container, publishes the documented voice and file-transfer ports, accepts the license through `TSSERVER_LICENSE_ACCEPTED`, and stores data in a named volume. The expected result is a running container whose logs can be inspected for setup information, including the ServerAdmin privilege key.

docker run -d \
  --name teamspeak-server \
  -p 9987:9987/udp \
  -p 30033:30033 \
  -e TSSERVER_LICENSE_ACCEPTED=accept \
  -v teamspeak-data:/var/tsserver/ \
  teamspeaksystems/teamspeak6-server:latest

After the container starts, follow its logs. The README specifically points to this command when checking for the ServerAdmin privilege key:

docker logs -f teamspeak-server

The Compose route is more suitable when the container should restart unless stopped. The following is the minimal configuration shown in the README. The volume keeps server data separate from the container filesystem.

services:
  teamspeak:
    image: teamspeaksystems/teamspeak6-server:latest
    container_name: teamspeak-server
    restart: unless-stopped
    ports:
      - "9987:9987/udp"
      - "30033:30033/tcp"
      # - "10080:10080/tcp"
    environment:
      - TSSERVER_LICENSE_ACCEPTED=accept
    volumes:
      - teamspeak-data:/var/tsserver

volumes:
  teamspeak-data:
    name: teamspeak-data

Create this as `docker-compose.yaml` in the project directory, then start it with the Compose file named by your installation. The README also refers to ready-made files in `compose/`, including `example-compose-mariadb.yaml`. Do not delete `teamspeak-data` unless permanent data removal is intended.

Native Linux and Windows First Runs

Docker is recommended, but the repository also supports running the server binary directly. The README gives separate commands for Linux and Windows. On Linux, make the downloaded `tsserver` file executable, then start it with license acceptance. On Windows, open Command Prompt or PowerShell in the extracted server directory and run the executable with the same acceptance flag.

On Linux, the documented sequence is:

chmod +x tsserver

./tsserver --accept-license

On Windows, use:

tsserver.exe --accept-license

These commands start the server, but the README does not provide a separate initial client configuration sequence or a documented post-start administrator command. It does document `--help` for the complete option list and `--write-config-file` for generating a default YAML file. Those flags are the documented starting points for discovering configuration without inventing additional command-line options.

Beta Limits, Licensing, and Upgrade Costs

The beta includes a 32-slot license that the README says will be renewed every two months during the beta and evaluation period. It also states that licensing and pricing have not been finalized. A larger license cannot currently be obtained or added for TeamSpeak 6. This makes capacity planning unusually concrete: a deployment that expects more than 32 concurrent slots cannot assume that a larger beta license is available.

The server uses a custom license that GitHub cannot classify, so the repository contains `LICENSE.md` and that file is the relevant source for its terms. The README also states that TeamSpeak 3 Server licenses are not compatible with TeamSpeak 6 Servers and that no migration path currently exists between the versions. This is a product boundary, not merely a configuration difference. A current TeamSpeak 3 operator cannot treat a TS3 license or an assumed migration workflow as a valid TS6 deployment plan.

The repository was last pushed on 2026-09-22, and the latest listed release is `v6.0.0-beta13.1`, dated 2026-09-22. The release history also includes `v6.0.0-beta13` on 2026-09-17 and `v6.0.0-beta12.1` on 2026-07-28. This supports ongoing repository activity at that point, but it does not remove the beta risk stated in the README. Upgrade planning should account for changing beta features, changing licensing terms, and the absence of a documented TS3 migration path.

When a Native Server or Another Voice Platform Is the Better Fit

Choose the native binary route when the host does not use Docker or when the operator wants direct process control on Linux or Windows. Choose Compose when restart behavior, named storage, and a repeatable service definition matter. Choose SQLite for the simple volume-based example, or investigate the MariaDB Compose configuration when a separate database is required. The README confirms both database choices, but it does not provide enough detail here to compare their operational trade-offs.

A hosted TeamSpeak 6 service is the documented alternative when self-hosting is unwanted. The README links to TeamSpeak Communities and describes renting official servers as the easier route. That approach changes the responsibility boundary: the operator does not run the server process or manage its Docker volume, but the repository does not specify the hosted plan's license capacity, pricing, configuration access, or operational limits, so those details cannot be compared from the available documentation.

The TS6 server is the wrong choice for an organization that requires TeamSpeak 3 continuity, a confirmed migration procedure, or a larger beta license today. It is also unsuitable when the organization cannot accept unstable features or incomplete self-hosted server functionality. In those cases, the decision should be based on the licensing and migration constraints documented by the project, not on an assumption that TeamSpeak 6 is a drop-in replacement.

Editorial conclusion

Adopt this repository for evaluating TeamSpeak 6 in a controlled test environment or for a small self-hosted deployment that accepts beta behavior and a 32-slot license. Do not select it when a stable production service, a larger license, or migration from TeamSpeak 3 is required. Verify the executable source, port requirements, persistent volume, database choice, and current license terms before moving real users onto the server.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. teamspeak/teamspeak6-server on GitHub