How Open WebUI speech-to-text and text-to-speech stay on your servers
Open WebUI can send transcription and speech requests to OpenAI-compatible servers that your organization runs, so voice in chat does not have to leave your network. Speech to text handles the input side: a user records a question, the audio is sent to your transcription server, and the returned text becomes the chat message. Text to speech handles the output side: the model's reply is sent to your speech server and played back to the user. Each direction is a separate setting, so you can run them on different servers or keep one of them on a cloud service if your policy allows that.
Both directions are configured in the Open WebUI admin settings and through environment variables, which is where the connection endpoint, API key and model or voice selection are set. The exact variable names and the menu locations change between releases, so confirm them in the Open WebUI documentation for the version you deploy before writing your configuration. Record the release number in your change ticket, because a later upgrade can rename a setting and leave voice silently pointed at a default engine. Also confirm which roles can open the audio settings, since changing the endpoint is effectively a change to where user voice data goes.
Keeping the audio path internal depends on more than the setting itself. The Open WebUI containers must be able to reach the transcription and speech servers over the network you intend, and those servers need their own capacity planning, TLS and access control. Store the API key for each server in your secrets manager or the platform's secret handling, not in a shared configuration file. Confirm how each speech server handles uploaded audio: whether it keeps recordings, writes them to disk, or includes them in request logs. Those answers determine your retention settings and what your data protection assessment needs to describe.
The main risk is a silent fallback. If an audio setting is left empty or reverts after an upgrade, requests may go to a default hosted engine instead of your server, and users will see no difference. Test this on purpose: record a short clip, confirm in your server logs that the transcription arrived at your endpoint, and then confirm that outbound traffic to external audio providers is blocked at the firewall or proxy. Repeat this check after every upgrade. Ask your implementation partner or internal team to document the expected endpoints, the owner of each speech server and the test that proves the path works.
What you need before connecting speech servers to Open WebUI
Five items shape a self-hosted voice setup: the Open WebUI version and install method, the speech servers and their API compatibility, network paths, TLS certificates, and the license position. Work through them in this order, because each one depends on the answer before it. Record the answers in your change ticket so platform, security and licensing owners review the same facts.
Open WebUI version and install method
Fix the Open WebUI version and install method first, since speech settings and configuration names can change between releases. The latest release line is v0.12.3, published on October 16, 2026. Official install methods are Docker, Docker Compose, Kubernetes with Helm, and pip install open-webui followed by open-webui serve. Read the release notes for every version you plan to run, and test any upgrade on a copy of your data before changing production.
Speech server API compatibility
Confirm that each transcription and speech server exposes endpoints compatible with the OpenAI audio API that Open WebUI calls. Check endpoint paths, model names, accepted audio formats, file size limits and response formats in the server documentation. Record which model handles transcription, which handles speech, and whether they run on separate hosts. Send a short test recording and a test sentence to each endpoint with a plain HTTP client before you add the connection in Open WebUI.
Network paths for users and services
Map two paths. The first runs from user browsers to Open WebUI, which carries microphone audio and spoken replies. The second runs from the Open WebUI container or pod to each speech endpoint, often inside a private network. Confirm DNS names, firewall rules, proxy settings and any egress policy that blocks outbound calls to cloud audio APIs. Check that reverse proxy body size and timeout limits at the load balancer or ingress allow longer recordings to upload and finish.
TLS certificates and trust
Issue certificates for the Open WebUI hostname and for every speech endpoint that uses HTTPS. Confirm that the certificate chain is trusted inside the Open WebUI container, pod or host, including any internal certificate authority, because a failed trust check often appears as a generic connection error. Browsers generally limit microphone access to secure origins, so the user-facing hostname needs valid HTTPS. Plan renewal for both sides and record which team owns each certificate.
License position above 50 users
Check the Open WebUI License before rollout. Since v0.6.6, Open WebUI code is distributed under this license, which includes a branding protection clause. That clause applies to deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written contributor permission. Count active users across the whole deployment, including people who never use voice. Enterprise pricing is not published, so ask Open WebUI enterprise sales for a quote based on your expected seat count.
Which speech server options fit an OpenAI-compatible setup
The core decision is whether speech-to-text and text-to-speech run on servers you operate or call a cloud audio API, and that choice determines which speech servers are worth evaluating at all. Open WebUI reads its audio settings for speech-to-text and text-to-speech from the Admin Panel, where you point it at an OpenAI-style base URL. A self-hosted transcription server or speech synthesis server that exposes compatible audio endpoints can fill that slot, so voice input and spoken replies stay inside your network. Decide first whether audio content may leave your environment at all, because that answer removes some options before any benchmarking starts.
Model choice drives most of the remaining trade-offs. A transcription server runs a speech recognition model, and a speech synthesis server runs a voice model, and each model has its own language coverage, accent handling, voice options and resource profile. Ask each candidate which languages and voices it supports in the configuration you will run, not only in its marketing material. Check how it handles your domain vocabulary, such as product names or clinical and legal terms, and whether it supports the languages your users actually speak in chat. Languages that your staff use daily should be tested with real recordings from your environment.
Latency and hardware capacity are the drivers most likely to change the user experience. Speech recognition and synthesis can run on GPUs for faster responses or on CPUs when volume is low and some delay is acceptable, but CPU-only operation can make voice replies feel slow for interactive use. Estimate concurrent audio requests from your user base, then ask each server vendor or project which accelerator and memory it needs for that load. Measure time to first word and time to complete transcription on your own hardware, because published figures rarely match your audio length, model size or concurrency.
Assign ownership before you deploy. Someone must track model and server releases, test them against your Open WebUI version, and decide when to upgrade. Speech models carry their own licenses, which may restrict commercial use, redistribution or use of generated voices, so have legal or compliance review the license of each model and voice you select. Record the license, the model version and the owner in your configuration register. Confirm these terms directly with each project, because licenses change between releases.
Request and response formats must be tested against the specific server, not assumed from the OpenAI API. Compatible servers differ in supported audio file types, maximum upload size, response formats, parameter names, voice identifiers and error payloads. Run a test matrix that sends the same recording and text through Open WebUI and the server directly, then confirm that transcripts, audio output and error messages behave as expected. Repeat the test after every server or Open WebUI upgrade, since a changed field name can silently break voice features for every user.
How to configure Open WebUI to use self-hosted speech endpoints
This sequence points Open WebUI's voice input and output at speech servers you run, then checks each stage so that transcription and synthesis stay on your network. It ends with access limited to approved groups and a log review that confirms no audio leaves for an external provider. Setting names and API paths should be confirmed against the Open WebUI documentation for the version you install.
Confirm network path to speech servers
The network engineer and the Open WebUI operator confirm that the speech servers are reachable from the Open WebUI runtime, not only from a workstation. Test from inside the Open WebUI container or pod, because container networking and DNS often differ from the host. Send a request to the OpenAI-compatible transcription and speech routes exposed by each server, and confirm the path names in the server's own documentation. Done when both routes return an expected HTTP status with valid authentication and the Open WebUI runtime resolves the server hostnames to internal addresses.
Set speech-to-text endpoint and key
The Open WebUI administrator enters the transcription endpoint base URL and API key in the admin settings for audio, or sets the equivalent environment variables at deployment. Confirm the exact setting names in the Open WebUI documentation for the installed version before editing anything, because names have changed between releases. Store the key in your secrets manager and inject it at runtime rather than pasting it into shared configuration files. Done when the settings save without error, persist after a restart of the Open WebUI service, and the speech-to-text status in the admin panel reports the configured server.
Set text-to-speech endpoint, key and voice
The administrator sets the speech synthesis endpoint, its key and a default voice using the same method chosen in the previous step. Confirm the voice identifiers the server exposes, since voice names are defined by the synthesis server and not by Open WebUI. Keep the key separate from the transcription key where the server supports it, so each service can be rotated on its own schedule. Done when a test synthesized clip is generated from a chat message, plays in the browser, and the audio file is produced by the internal server, which the server's own request log should show.
Select transcription and speech models
The administrator chooses the transcription model and the speech model that Open WebUI should request, using the model names each server publishes. Confirm that each selected model supports the languages your users need, since language coverage varies by model and should be checked with the model provider. Record the chosen names in your configuration documentation so that a future model change is reviewed. Done when a test transcription of a short recording with known wording returns text that a reviewer agrees is accurate for the language, and the server log shows the selected model name on that request.
Restrict voice features to approved groups
The Open WebUI administrator uses role-based access control and groups to decide which users can record voice input or use read-aloud output. Keep the default for new accounts set to deny voice features, then grant them to named groups that have a documented business need. Coordinate the group list with your identity team if sign-in is handled by SSO or SCIM provisioning. Done when a test account in an approved group can use the microphone and read-aloud controls, and a test account outside those groups sees neither control and receives a permission error if it calls the endpoints directly.
Verify no audio leaves your network
The security engineer reviews the Open WebUI logs and the host or cluster egress rules to confirm that audio requests only reach the internal speech servers. Block outbound traffic from the Open WebUI runtime to external audio providers at the firewall or network policy layer, then repeat a test transcription and a test synthesis. Record the results with timestamps and the block rules in your change record for the compliance evidence file. Done when the test requests succeed against the internal servers, the external provider requests fail or are absent from the logs, and the signed-off record names the reviewer and the date of the check.
Which audio settings map to which speech server fields
This table maps each audio setting in Open WebUI to the value your speech server must expose, and shows where each value is stored and who should change it. Read it before configuring anything, because a mismatch in one row often shows up as failed transcription or silent playback. Confirm the exact field labels against the Open WebUI version you run, since labels can change between releases.
| Open WebUI setting | Speech server value to match | Source and storage | Who owns changes |
|---|---|---|---|
| Base URL | Root address of the OpenAI-compatible speech endpoint, including any path prefix, reachable from the Open WebUI container or host | Entered in the admin audio settings for speech-to-text and text-to-speech | Platform team, changed only with a planned endpoint move |
| API key | Key the speech server accepts, or a documented placeholder if the server runs without authentication | Entered in admin settings and stored as a secret, so handle it like any service credential | Security or platform team, rotated under the key owner's process |
| Model name | Exact speech model identifier that the server has loaded and lists on its models endpoint | Typed in admin settings, checked against the server's model list after any change | Platform team, updated whenever the model is swapped and retested |
| Voice name | Voice identifier the text-to-speech server supports for the chosen model | Selected in admin settings, and the available list depends on the server build | Product owner picks the voice, platform team confirms server support |
| Supported audio formats | File types the server accepts for transcription, which should cover what your users' browsers record | Determined by the server build, so confirm accepted types in its documentation | Server owner documents formats, client team tests recordings from target browsers |
| Maximum upload size | Largest audio file the server accepts, and no smaller than the limit enforced by any proxy in the path | Set in Open WebUI and in any reverse proxy or gateway, where the smallest limit applies | Platform team owns app and proxy limits together and changes both in one request |
Keeping voice data inside your infrastructure
Voice input and output send recordings of people's speech through your infrastructure, so the controls around them matter as much as the choice of speech server. The cards below cover transport, credentials, access, data retention, logging and multi-replica state. Each one names a decision or check your team owns before users start speaking to the assistant.
Speech traffic on private networks and TLS
Place the speech-to-text and text-to-speech servers on a private subnet that only the Open WebUI instances can reach, so audio never crosses a public route. Serve the endpoints over TLS with certificates from your internal certificate authority, and confirm that Open WebUI validates the server certificate and does not skip verification. Check the path from every replica, including any reverse proxy placed in front of the speech servers.
Storing and rotating speech API keys
If the speech server requires an API key, treat it as a secret. Keep it in a secrets manager or the orchestrator's secret store, and out of compose files committed to version control. Give each environment its own key so a leak in staging does not expose production. Write rotation as a runbook step that updates Open WebUI and the speech server together, then confirm that the old key is rejected. Ask the server vendor how keys are issued and revoked.
Limiting voice features by group
Open WebUI's role-based access control works through groups and per-resource permissions, so voice input and read-aloud can be limited to specific groups. Decide which groups may send audio at all, and whether any group may use voice alongside sensitive knowledge collections. Review group membership after directory or SCIM sync changes, because a mapping error can widen access without anyone noticing. Test with a standard user account, not only an administrator account.
Retention of audio and transcripts
Uploaded audio and the transcripts derived from it can persist in the Open WebUI database and file storage, so retention is a design decision the team must make and document. Confirm where each artifact is written, how long it stays, and who can export it. Include backups and replicas in the review, because deleting a conversation may not remove copies held in backup sets. Test the deletion procedure on a sample conversation before users rely on voice.
Logs that exclude spoken content
Application, proxy and speech server logs can capture request bodies, error payloads or transcript text when debug logging is enabled. Set production log levels deliberately, and check that reverse proxies and the speech server do not log multipart audio bodies. Send logs to your central store with restricted access, and set their retention separately from chat data. Before go-live, speak a test phrase, then search every log sink for that phrase.
Replicas, shared storage and session revocation
Running several Open WebUI replicas requires PostgreSQL, Redis for shared sessions and websocket state, and shared file storage so uploaded audio and other files are reachable from every replica. Without Redis, signing out does not revoke tokens. They stay valid until they expire, by default after 4 weeks. Confirm the Redis deployment, the shared volume's access controls and encryption, and test sign-out from a second replica before accepting voice data.
How to test voice input and output before users rely on them
Test voice features as one chain before anyone depends on them: browser microphone capture, the transcription request to your speech server, the model response, and spoken output. Start with functional checks using short and long recordings, because a few seconds of speech and a ten-minute meeting exercise different limits in the upload path, the server and the browser. Test every language your staff and customers actually use, including accented speech and internal product names. For text-to-speech, check each voice you plan to expose, and confirm whether your speech server returns streamed audio or only full-file responses. Then test playback in each browser you support. Keep the audio samples and results so the same tests can be repeated after an upgrade.
Load checks should model concurrent users doing the mix of dictation and spoken replies that you expect in production, with several people running voice requests at the same moment. Agree the target concurrency and acceptable latency with the business owner before the run, and write them down as acceptance criteria. Increase load in steps while watching response times, error rates, and the speech server's queue and resource use. Test the deployment shape you will actually run. Open WebUI's scaling guidance requires PostgreSQL, Redis and shared file storage for multiple replicas, so a single container on a developer machine will not tell you much. Confirm whether your speech server handles requests in parallel or one at a time, because that determines whether adding Open WebUI replicas helps voice throughput at all.
Failure checks show what users experience when the speech server is down, slow or returning errors. Stop the server during an active voice session and confirm that Open WebUI displays a clear message, does not leave the chat waiting indefinitely, and recovers once the server returns. Add artificial latency to confirm that timeouts behave as configured and that one long transcription does not hold up other users. Then run access checks. Sign in as users from groups that should not have voice features and confirm that the microphone and read-aloud controls are hidden or disabled. Also send direct requests to the speech endpoints with a session or API key from an unauthorized account, and confirm that the request is refused. Confirm that the speech server URL and credentials are visible only to administrators. Repeat the access checks after every change to group permissions.
Agree on sign-off before testing begins and write the roles into the test plan. A typical split is that the platform owner signs off on functional and load results, the security team signs off on failure and access results, and the data protection or compliance owner confirms where audio and transcripts are stored and how long they are kept. Keep evidence that an internal or compliance reviewer can follow: the test plan and acceptance criteria, the Open WebUI and speech server versions, configuration exports with secrets removed, dated test results, load test reports, logs of refused access attempts, and a defect list showing fixes and retests. File these with the change record. DeployOpen can prepare this evidence and the test work behind it, but independent auditors and certification bodies decide whether controls meet a given requirement.
Why speech requests fail in Open WebUI and how to fix them
This table lists the failures teams most often hit when Open WebUI sends audio to a self-hosted speech server, with the likely cause, a way to confirm it and the fix. Work through the rows from the network path outward: reachability and trust first, then request contents, then load and storage. Most failures can be confirmed with one test request sent from the Open WebUI container or pod.
| Failure | Likely cause | How to confirm | Fix |
|---|---|---|---|
| Speech endpoint unreachable | The base URL points to localhost or a name the Open WebUI container or pod cannot resolve, or the speech server listens only on a host loopback interface. | Run curl against the models path from inside the Open WebUI container or pod. Look for connection refused or DNS errors in Open WebUI logs. | Use a service name or cluster DNS address that the container can reach, and bind the speech server to an interface that accepts that traffic. |
| Certificate trust errors | The speech server presents a certificate from an internal certificate authority that the Open WebUI image does not trust. | Search Open WebUI logs for TLS or SSL verification errors. Compare curl results from inside the container with and without the internal CA bundle. | Add the internal CA to the container trust store or mount a CA bundle into the container, restart Open WebUI and repeat the test request. |
| API key or model name mismatch | The key is rejected, or the configured model ID differs from the name the speech server reports. | Call the server's model list endpoint with the same key. Authentication failures appear as 401 responses in logs, and unknown model errors name the requested model. | Copy the exact model ID from the server's list into the audio settings and confirm the API key matches the server configuration. |
| Unsupported audio format or file size | The browser records a format the speech server cannot decode, or the clip exceeds the upload limit of the server or a reverse proxy in front of it. | Send the same file with curl to the transcription endpoint. Check server and proxy logs for decoding errors or 413 responses. | Convert audio to a format the server documents, shorten long recordings and raise the reverse proxy request body limit to match your tested clip size. |
| Timeouts while models load | The first request after a restart triggers loading a large model into memory, and the client or proxy gives up before loading finishes. | Time a first request after restart and a second request right after it. Look for gateway timeout (504) entries in proxy logs during the first call. | Load the model at startup or keep it resident, then raise client and proxy timeouts to values you have tested. Confirm the speech server's loading behavior before setting them. |
| Voice not found | The text-to-speech voice name is not available on the chosen server or model. | Call the speech endpoint directly with the voice name in the request. Compare it with the voice list in the server documentation. | Set the voice to one the server lists for the selected model, and retest after changing the model. |
| Missing audio in multi-replica deployments | Uploaded or generated audio is written to one replica's local disk, and a later request is served by a different replica. | Requests succeed on one replica and fail on another. Record which pod handled each request and check whether the file exists on that pod's disk. | Place the file storage Open WebUI uses for uploads on shared storage reachable from every replica, and confirm that generated audio follows the same path in your setup. |
Questions buyers ask before hiring help with Open WebUI speech
How much does hiring help with Open WebUI speech cost?
Cost is set by a fixed-scope quote written from an agreed scope, so no general price applies to every organization. DeployOpen does not publish a price list. The main cost drivers are the number of users and groups that need access, how many speech servers must be connected, how many languages must be tested, the identity and network work needed for sign-in and routing, and the depth of security and functional testing. One-time costs cover design, integration, configuration, testing and documentation. Recurring costs apply only if you add a retainer for upgrades, support or continuous testing. When you request a quote, ask for the deliverables, the assumptions about your environment, and which items are one-time and which recur.
How long does a self-hosted speech integration take to deliver?
Duration depends on the written scope, and no general timeline applies. The largest factors are how many speech servers must be connected, whether each one is already running and reachable, how quickly your identity and network teams approve access, and how many languages and user groups need testing. Work moves faster when speech server owners answer questions promptly and when the test plan is agreed early. Delays usually come from access requests, data handling sign-off, and configuration changes to speech servers after testing has started. Ask for a proposal that lists the dependencies on your side and ties each milestone to them.
Can our internal team set up Open WebUI speech without outside help?
Often yes, if the team has the skills and time to finish the work. The skills needed include container or Kubernetes operations, depending on your install method, familiarity with Open WebUI administration, experience running OpenAI-compatible transcription or speech servers, identity administration for single sign-on and group mapping, network and TLS configuration, and test design for voice input and output. Many teams underestimate the testing and documentation work. Consider a partner when your team lacks one of these skills, when the scope spans many speech servers or languages, or when deadlines compete with ongoing operations. A short skills review against the written scope will help you decide.
Does the Open WebUI license apply to our number of users?
It can. Since v0.6.6, Open WebUI code is distributed under the Open WebUI License, which includes a branding protection clause. The clause forbids altering or removing Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written contributor permission. Code through v0.6.5 remains under BSD-3-Clause. Count active users across the whole deployment, not only licensed seats, and have your legal or procurement team review the license text. Open WebUI enterprise licenses allow white-labeling and custom branding. Pricing is not published, so you contact its enterprise sales team with an expected seat count. DeployOpen does not provide license advice.
What must our organization provide for a speech integration project?
Three things are needed from your side before work starts. First, infrastructure access: cloud or data center accounts, service accounts, network paths between Open WebUI and each speech server, and test environments. Second, named speech server owners who can answer questions, confirm endpoints and approve configuration changes during testing. Third, sign-off on data handling: which audio is sent, whether it is stored or logged, retention periods, who can read transcripts, and where data may travel. You will also need an identity owner for single sign-on and group mapping, plus a change approval process for production. Agree on these owners and approvals in the written scope so that delays are visible early.
What should we check before sending employee audio to a speech server?
Confirm first that each speech server exposes the OpenAI-compatible transcription or speech API your version of Open WebUI expects, and that you have tested it with your models. Check where the server runs, how traffic is encrypted, which certificate authority Open WebUI trusts, and how the server authenticates requests. Ask the speech server owner how long it keeps audio, transcripts and logs, and whether those records can be deleted on request. Check whether Open WebUI itself stores uploaded audio or generated text, and who can see it by group. Test file size limits and timeouts with long recordings, and test every language your users need.
Does running several Open WebUI replicas change speech server work?
Yes, because the platform beneath the speech feature must support multiple replicas. The scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, Redis as a shared store for sessions, websocket connections and application state, and shared file storage so uploads stay reachable from every replica. It also warns that the default ChromaDB will crash in multi-process setups, so an external vector database is required. Without Redis, signing out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. Include sessions, uploads and voice requests across replicas in your test plan, and confirm each dependency in the written scope.
How DeployOpen scopes and delivers Open WebUI speech integrations
DeployOpen plans and implements Open WebUI speech features inside your own infrastructure, connecting the deployment to transcription and speech servers that expose OpenAI-compatible APIs and keeping audio processing on servers you run. Each engagement is fixed-scope, so the speech servers, audio data paths, user access rules and handover items are agreed in writing before build work begins.
How we scope
- The written scope names each speech server, its model, host location and the users allowed to record or listen.
- Scope records where audio is stored, how long transcripts are kept and which logs capture voice requests.
- Scope confirms the Open WebUI license terms that apply to your expected user count before build starts.
How we build
- Deploy the transcription and speech servers on your infrastructure and verify their OpenAI-compatible endpoints from the Open WebUI network.
- Configure Open WebUI audio settings for speech-to-text and text-to-speech, with model names and voices set per environment.
- For multiple replicas, add PostgreSQL, Redis and shared file storage so every instance handles voice sessions consistently.
How we hand over
- Test cases cover dictation, uploaded audio, spoken replies and failure behavior when a speech server is unavailable.
- Written runbooks describe configuration, model updates, log locations and steps for restarting speech services.
- Handover includes a record of the agreed scope, access settings and the open items your team owns.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Open WebUI version upgrades, speech server model changes and monitoring of voice request errors.
- Upgrade planning reviews release notes and license changes before each Open WebUI version moves into production.
