One user, external API inference and light chat history.
external AI API setup
How to Run Open WebUI on a VPS with External AI API
Deploy Open WebUI without local model inference and connect it to an OpenAI-compatible provider.
Open WebUI does not need a GPU if you use a remote OpenAI-compatible API. The VPS hosts the interface, users, chats and configuration; the model provider handles inference. That makes the setup cheaper and easier to maintain, but the API key, request privacy and endpoint security deserve as much attention as the container itself.
A small VPS can give you a private, always-available AI interface without paying for idle GPU hardware. This is the practical choice when you want your own domain, users and chat history but are comfortable paying a model provider per request. Local models trade API dependence for much higher memory and GPU requirements.
No GPU requiredThe VPS hosts the interface and data. The external provider handles model inference and API billing.
External API and local model are different purchases
External API
Lower VPS cost and simpler operations. You still pay per request and send prompts to the selected provider.
Local model
More privacy and control, but model size, quantization and GPU VRAM determine the server you need.
VPS requirements
Buy for the workload, not the install command
Several users, HTTPS proxy, updates and routine backups.
RAG, many users or local inference. GPU VRAM must fit the selected model.
Request flow to keep in your head
BrowserHTTPSOpen WebUIOpenAI-compatible APIModel provider
Before touching the server
- Ubuntu VPS with Docker
- A provider endpoint that implements the OpenAI-compatible API
- An API key and model name from that provider
- A domain with HTTPS for any non-local deployment
Deploy the interface first
01
Create persistent storage
Open WebUI stores its application data under /app/backend/data. Use a named volume or a host directory so recreating the container does not erase users and conversations.
docker volume create open-webui
docker pull ghcr.io/open-webui/open-webui:main02
Start the interface
Publish the service only to localhost if a reverse proxy will handle HTTPS. The rolling main tag is convenient for testing; pin a tested version for a production change window.
docker run -d --name open-webui --restart always \
-p 127.0.0.1:3000:8080 \
-v open-webui:/app/backend/data \
ghcr.io/open-webui/open-webui:mainConnect the provider without leaking the key
Add the external provider
Open Admin Settings, then Connections, and add the provider's base URL and API key. Use the URL format documented by the provider; some expect /v1 and some supply it in their example. Do not paste a master key into a public client-side app.
Keep public
Only the HTTPS interface, protected by a strong owner account.
Keep private
Port 3000, provider keys, admin endpoints and raw container logs.
Test model discovery, then persistence
01
Put HTTPS and access control in front
Use a reverse proxy or private VPN, enable a strong owner account and avoid exposing port 3000 directly. Keep the upstream bound to localhost and allow only 80/443 through the firewall.
02
Test model discovery and usage
Confirm that the model list loads, send a short test prompt, then inspect container logs for connection errors. Set provider-side spend limits and remove unused connections when the test is finished.
Common mistakes that cause real downtime
- Buying a GPU plan even though every prompt goes to an external API
- Publishing port 3000 directly and skipping HTTPS or account controls
- Using the rolling main tag in production without pinning and testing an update
- Losing users and chat history because /app/backend/data was not persisted
- Using an unrestricted provider key without a project budget or rotation plan
Before inviting users
The container survives a restart with data intact
The provider connection can list models and complete a test request
Port 3000 is not publicly exposed
The API key is stored only in the admin connection and provider vault
Next step
Keep the deployment moving
Sources and further reading
- Open WebUI official quick start
- Open WebUI: connect an OpenAI-compatible provider
- Open WebUI: connection troubleshooting
- Open WebUI API endpoints
Commands assume a fresh Ubuntu server. Replace domains, users, database names and provider-specific values before running them. VPS sizing is a practical starting point, not a guarantee: monitor the real workload and resize when CPU, memory, disk or network headroom becomes tight.