Self-Hosted Text-to-Speech with Coqui TTS in 2026

Self-hosted text-to-speech is useful anywhere speech output meets privacy, cost, or customization requirements. Internal training content, assistive tools, kiosk systems, accessibility features, and automated voice workflows all become easier to control when synthesis happens on infrastructure you manage. Coqui TTS has been one of the most visible open-source projects in this space, and it still works well in 2026 — but only if you know which version of it to run.

First, the honest part: Coqui the company is gone

Coqui AI, the startup behind the project, shut down in early 2024, and the original coqui-ai/TTS repository on GitHub is archived. Nobody is merging fixes there, and its dependencies drift further out of date every year. If a tutorial tells you to pip install TTS from the original project, it is pointing you at abandonware.

The good news is that the code did not die with the company. The actively maintained path today is the community fork kept alive by the Idiap Research Institute, published as the coqui-tts package (repository: idiap/coqui-ai-TTS). It keeps the same models, the same CLI, and the same demo server, with dependency updates and bug fixes that the archived repo will never get.

Two practical consequences before you deploy anything:

• Install the fork, not the original. pip install coqui-tts, or use the fork's Docker images. Same API, maintained code.
• Check model licenses. The flagship XTTS-v2 voice-cloning model ships under the Coqui Public Model License, which restricts commercial use. Architecture names such as VITS or Tacotron do not establish commercial rights. Verify the exact checkpoint, training-data and voice terms, and any required speaker permission before using a model in a business service.

If your needs are simple — alerts, kiosk prompts, accessibility audio on modest hardware — also look at Piper before committing. It is lighter, runs comfortably on a Raspberry Pi or the smallest VPS tier, and its ONNX voices start fast. Coqui earns its keep when you want higher-quality voices, multilingual output, or a framework you can experiment inside.

A minimal deployment with Docker

The fork ships a demo server that is good enough for internal use behind a reverse proxy. Here is a working docker-compose.yml for a CPU-only host:

services:
  coqui-tts:
    image: ghcr.io/idiap/coqui-tts-cpu:latest
    command: python3 TTS/server/server.py --model_name tts_models/en/ljspeech/vits
    ports:
      - "127.0.0.1:5002:5002"
    volumes:
      - tts-models:/root/.local/share/tts
    restart: unless-stopped

volumes:
  tts-models:

A few things worth knowing about this file:

• The server listens on port 5002. Binding it to 127.0.0.1 keeps it off the public internet; put nginx or Caddy in front with authentication if other machines need it.
• The named volume caches downloaded models under /root/.local/share/tts. Without it, every container rebuild re-downloads hundreds of megabytes.
• tts_models/en/ljspeech/vits is a solid single-speaker English default that runs fine on CPU. Swap in tts_models/en/vctk/vits for a multi-speaker model, or list everything with docker compose exec coqui-tts tts --list_models.

First run:

docker compose up -d
docker compose logs -f coqui-tts   # wait for the model download to finish
curl "http://127.0.0.1:5002/api/tts?text=Hello%20from%20my%20own%20server" -o hello.wav

The first start is slow because the model downloads and loads into memory; after that, measure synthesis latency and memory use on the intended host with realistic text lengths. A model family name or VPS specification alone does not establish usable latency. XTTS-v2 is a different animal — it wants a GPU, and whether that is worth it depends on the same tradeoffs covered in our CPU versus GPU inference comparison.

The gotcha: the bundled server processes one request at a time. It has no queue, no concurrency, and no back-pressure. Two simultaneous requests means one of them waits, and a very long text blocks everything behind it. For anything beyond light internal use, put a small job queue in front and treat the TTS container as a single worker you can scale horizontally — one container per concurrent stream. The general patterns in our production Docker Compose guide (resource limits, health checks, restart policies) all apply here.

From demo to dependable service

For many self-hosted users, the practical question is not whether Coqui TTS can produce speech at all. It is how to turn it into a dependable internal service. A demo that reads a sentence is easy. A production service that accepts requests, manages model files, normalizes audio output, and avoids overloading the host is a different job.

A sensible architecture is fairly small:

• an internal API or queue receives text input
• a TTS worker (the container above) loads a chosen model and synthesizes audio
• FFmpeg optionally normalizes format, bitrate, or sample rate
• the resulting audio is stored or streamed to the client

This works for most business use cases. You do not need an elaborate ML platform to generate useful speech. You do, however, need to think about latency. Loading a model for every request is inefficient — keep the worker warm. Long text can block shorter urgent requests, so split sentences before they hit the worker. If multiple voices are supported, memory use grows with each loaded model, so decide up front how many you really need.

Model selection should follow the task. If you are generating short prompts for internal apps, low latency may matter more than highly natural speech. If you are producing podcast-like narration or accessibility audio for end users, voice quality becomes more important. Coqui's flexibility is helpful here, but it also means you should benchmark on your real hardware before committing to a model family.

One operational pattern is to separate synthesis from delivery. Generate a WAV master first, then transcode with FFmpeg to MP3 or Opus for distribution. This keeps your synthesis pipeline stable while giving downstream applications the format they actually need.

Voice cloning deserves special caution. The technical capability exists in XTTS, but beyond the license restrictions already mentioned, organizations should consider legal, ethical, and consent boundaries before using any cloned or highly imitative voice. Self-hosting does not remove those concerns. It only changes where the processing happens.

From a systems perspective, text handling is where practical issues appear. You may need normalization for abbreviations, numbers, dates, or punctuation — without it, generated speech sounds awkward even when the model is solid. A useful deployment checklist:

• choose one default voice and one output format first
• benchmark startup time and synthesis speed on your real hardware
• define text length limits and queue behavior
• normalize pronunciation for common internal terms where needed
• store only the audio and logs you actually need

Security is straightforward but often ignored. TTS services can be abused for bulk generation or fed sensitive text. Put authentication in front of the API, log access, and decide whether requests are retained. If the tool is connected to private documents or chat systems, treat the text input as sensitive data.

Monitoring matters from day one. Track request volume, average synthesis time, failure rate, and queue depth. Those numbers tell you whether the service is ready for real use or still behaving like a fragile experiment. The most natural-sounding model is not helpful if it stalls during busy periods or fails silently when downstream applications expect audio back.

Is Coqui still the right choice?

In practice, the maintained Coqui fork is a good fit for teams that want an open, adaptable speech layer with better-than-basic voices, and who are comfortable running a Python service that the original company no longer stands behind. Piper is the better pick when you want something small, fast, and boring in the best sense. Either way, start with one voice, one format, and one narrow workflow, and expand once the pipeline is reliable. And if you are building out a private audio stack, TTS pairs naturally with speech-to-text — a self-hosted Whisper setup covers the other direction of the same pipeline.