Running a local model is easy on a laptop with unified memory or a GPU sitting idle. Running it on a server, reachable from anywhere, behind a real login and a real domain, is a different chore normally it means wiring Ollama and a chat UI together yourself, then bolting on a reverse proxy for HTTPS by hand. This is the version where that's two templates and a domain field.
The one honest caveat first
Templates automate the software. They don't change what the hardware can do. A $5 VPS runs Ollama fine for small models on CPU, but anything you'd actually want to chat with at a reasonable speed needs either a lot of RAM or a GPU-backed instance from a provider that offers one. Pick the server size for the model you actually want to run, not the cheapest box on the list this is the one step in this guide that isn't a template away.
Step 1: Get a server ready
Servers → Add Server, connect over SSH, then run Bootstrap from the server card. It installs Docker, sets up the firewall, and starts a reverse proxy the same foundation every app on DeployOS runs on top of, model-serving included.
Step 2: Deploy Ollama
Templates, find Ollama, pick your server, and deploy. DeployOS generates the correct container configuration, wires it into the network, and runs it behind the reverse proxy like any other app no manually exposing a port and hoping nothing else on the server collides with it.
Once it's up, pull a model the normal Ollama way (its API is unchanged DeployOS just gives it a home). Check the app's Logs tab if a pull seems stuck; that's the fastest way to see download progress or an out-of-memory error without SSHing in yourself.
Step 3: Deploy Open WebUI on top
Back in Templates, deploy Open WebUI to the same server. Point it at your Ollama instance's internal address (both containers share DeployOS's edge network, so they can reach each other by service name without any of it being exposed publicly) and it gives you a ChatGPT-style interface conversation history, multiple models, file uploads in front of the model you're already running.
Step 4: Put it behind your own domain
Add an A record for a domain (or subdomain chat.yourdomain.com works well here) pointing at the server, set it as Open WebUI's custom domain, and redeploy. A Let's Encrypt certificate is requested automatically the first time HTTPS traffic hits it. Open WebUI's own account system handles login from there, so this doesn't need to sit behind a VPN to be safe to leave running.
Step 5: Watch it like any other app
Once deployed, both containers show up on your Applications list logs, restarts, and live CPU/RAM metrics work exactly like they do for any other app. That last part matters more here than usual: model inference is the thing most likely to actually use the RAM and CPU you provisioned the server for, so keeping an eye on the metrics tab is worth doing in the first few days.
Why self-host this at all
The honest reason isn't that a self-hosted model beats a frontier API on quality for most tasks it doesn't. It's that the data never leaves a server you control, there's no per-token bill that scales with usage, and once it's running, it keeps running whether or not a provider changes its pricing or rate limits next quarter. If that tradeoff fits what you're building, this is the whole setup no compose file, no manually chained reverse proxy, no certbot cron job.