Deploy and Host a Speech API on Railway

Speech to text and text to speech behind one OpenAI-compatible address, running on CPU, with the models kept on a volume so they are downloaded once rather than on every deploy.

Point any OpenAI client at it: /v1/audio/transcriptions for recognition, /v1/audio/speech for synthesis.

About Hosting a Speech API

Nine templates in the catalogue offer some piece of this. The most installed has 73 deployments at a 64% success rate; the only healthy one has 14. That many attempts with nothing working is a demand signal by itself.

Three things go wrong, and they are always the same three. The models are re-downloaded on every deploy because nothing persists them, so the first request after each deploy stalls for minutes. The API is left open on a public domain, so anyone who finds the URL runs models on your CPU. And only half the pair ships — recognition without synthesis, or the reverse — so you end up running two services that cannot share a cache.

This template is Speaches pinned to an exact release, with a volume for the model cache, an API key that is enforced on every route, and both halves of the pair on one endpoint.

Common Use Cases

• Transcribe voice messages and calls without paying per minute and without sending recordings to a third party.
• Give a bot a voice. Kokoro produces natural speech from the same service that does the listening.
• Feed an agent audio. Anything that already speaks the OpenAI audio API works by changing the base URL.

Dependencies for Speech API Hosting

Deployment Dependencies

• Speaches, pinned to ghcr.io/speaches-ai/speaches:0.9.0-rc.3-cpu
• A volume for the model cache — Whisper and Kokoro weights
• Verification script and notes

Implementation Details

• The image is the upstream one, pinned. No wrapper sits in the deployment path; the repository above carries the verification script and the notes, not a rebuilt image.
• API_KEY is generated and enforced. Without it every route is open, and a speech service on a public domain is a free GPU-less transcription farm for whoever finds it.
• The bundled web UI is off by default. It is not behind the API key, so leaving it on would undo the line above. Turn it on with ENABLE_UI when the service is not public.
• The model cache is a volume at /home/ubuntu/.cache/huggingface/hub. This is the difference between a first request that answers and one that downloads gigabytes.
• RAILWAY_RUN_UID=0 — the image runs as ubuntu, the volume is mounted as root, and without this the cache directory is read-only. The failure is silent: the service starts, and every model download fails.
• PORT matches UVICORN_PORT. A domain generated without a target port routes by PORT; when the two disagree the public address answers 502 while the container is perfectly healthy.

The repository carries scripts/verify-speech.sh, which will not pass unless a synthesised sentence comes back as the same sentence from the transcriber. One round trip covers both models, both endpoints and a writable volume — nothing about it can succeed by accident. This template was published only after that script passed against a deployment created from the template itself.

What to expect on CPU: faster-whisper-small runs two to three times faster than real time — good for recordings, not for live captioning. Because a volume belongs to a single replica, this service scales up rather than out.

Why Deploy a Speech API on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying a speech API on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.