Skip to content

Getting Started

DomeNinchen edited this page Oct 21, 2026 · 8 revisions

Getting Started

Getting the containers running takes about two minutes — the README's Quick Start has the exact commands. Starting from a fresh server? Install on Debian 13 walks through everything from the first login, Docker included.

Connecting it to your TeamSpeak server is the part that actually trips people up, and how you do it depends on where that server lives. Pick your situation:

TeamSpeak on the same machine Both run on one host — a home server or a single VPS
TeamSpeak elsewhere, or rented Another machine of yours, or a server from a TeamSpeak host

Both walk you through the whole thing. The rest of this page explains the two concepts worth understanding first, so those steps make sense rather than being copied blindly.

What WebQuery is, and why it has to be on

TeamSpeak servers are administered through a query interface — a text protocol that does everything the GUI client can't, including everything this manager does.

TeamSpeak 6 offers it in two forms:

  • WebQuery — over HTTP, authenticated with an API key. This is what the manager needs, and it is off by default
  • SSH ServerQuery — over SSH, authenticated with a username and password. Optional here, see below

The old raw/telnet ServerQuery on port 10011 is neither used nor supported.

Because WebQuery is off out of the box, enabling it is the first real step of either setup guide — and on a rented server it may be something only your host can do.

There is one exception: the music bots need no WebQuery. They connect as ordinary TeamSpeak clients, so a connection added without an API key still runs them — and offers only the pages that don't need WebQuery. That is meant for rented servers whose host gives out no query access; see Setup: elsewhere or rented.

Why SSH is optional, and what you lose without it

Three things need SSH:

  • bot flows triggered by server events or by a chat command — a client joining, leaving or moving between channels, or a message written in a channel;
  • live events in the Query Console;
  • the Files page, the Icons page and the icon picker, because WebQuery has no file-transfer commands.

Everything else runs over WebQuery alone: the permission editor, groups, clients, channels, bans, the rest of the Query Console, music bots (including their own !play-style chat commands), video streaming, and bot flows triggered by schedules or webhooks.

The reason is structural rather than arbitrary. WebQuery is request/response: the manager can ask questions and issue commands, but the server has no way to push an event back over it, and it has no file-transfer commands at all. Subscribing to events needs a connection that stays open, which is what SSH ServerQuery provides.

So if you never want event-driven automation, a live event feed or a file browser, you can skip SSH entirely and nothing else is diminished.

One thing works without SSH but is better with it: the Connection Journal. With an SSH login it listens to the server's live events and misses no join, however short, and every leave comes with the reason TeamSpeak gave. Without one it asks the server who is there every 15 seconds, so a visit shorter than that is not seen and a leave has no reason.

What the API key actually is

WebQuery does not use a password. It uses an API key, and that key carries full server administration rights.

A self-hosted server prints one for serveradmin exactly once — on its very first startup ever, in a log block titled "Server Query Admin Account created". Miss it and you generate a new one with apikeyadd; there is no way to read the original back.

Store it like a root password. The manager encrypts it at rest (see ENCRYPTION_KEY in Configuration) and never sends it back to your browser, which is also why credential fields appear blank when you edit a connection later — they show (unchanged) and keep what is stored if you leave them empty.

After the connection works

  1. Create your admin account at /setup — there are no default credentials by design
  2. Add users if others need access, with the role that fits: Viewer, Bot Operator or Music Operator, each scoped to the servers you assign. See Users and Roles
  3. Consider a Bot Identity (Settings → Connections → Bot Identity) before building bot flows, so automated actions appear under their own name in TeamSpeak's logs instead of sharing yours
  4. Enable two-factor authentication under Settings → Account if this installation is reachable from the internet

New to TeamSpeak's permission system? Permissions explains the five layers and which one wins — that is where most administration time gets lost.


v0.10, last edited 21.10.2026

Getting started

Home
Getting Started
Install on Debian 13
Setup: same machine
Setup: elsewhere / rented
Users and Roles

Using the app

Dashboard
Virtual Servers and Instance
Channels
Clients
Client Database
Permissions
Server and Channel Groups
Moderation
Tokens and Passwords
Files
Icons
Bot Flows
Music Bots
Server Widgets
Server Maintenance
Server Logs
Query Console
Connection Journal
Change Log
Themes and Appearance

Running it

Administration
Configuration
Deployment
Privacy and Hosting

When something is odd

Tips and Pitfalls
Troubleshooting

Contributing

Development

Repository · Changelog

Clone this wiki locally