Host your own AI API on a VPS — server with API endpoint illustration

How to Host Your Own AI API on a VPS

There’s a specific dread that hits when your AI app starts getting traction: the API bill. What started as a few cents a day in testing quietly becomes a line item you flinch at every month. Then come the rate limits, the surprise model deprecations that break your app overnight, and the nagging feeling that your users’ prompts are training someone else’s model. When you host your own AI API on a VPS, all of that changes. Your endpoints, your keys, your rate limits, your data never leaving your server. An OpenAI-compatible API running on a $20–40/month VPS can serve real traffic for a fraction of what per-token pricing costs at scale — and nothing goes down because a provider changed their pricing page. This guide walks through the two practical ways to do it, the VPS specs that actually matter, a full step-by-step setup with auth and HTTPS, and the honest cost math. Table of Contents Why Host Your Own AI API? The Real Reasons Pick Your Approach: Ollama vs LiteLLM vs Custom FastAPI VPS Specs That Matter for an AI API How to Host Your Own AI API on a VPS: Step-by-Step Cost Math: Self-Hosted vs Pay-Per-Token (Honest Numbers) Security Checklist: Don’t Skip This Common Mistakes That Bite Self-Hosted API Owners FAQ Conclusion Why Host Your Own AI API? The Real Reasons Most tutorials frame self-hosting as a cost hack. It can be, but the deeper reasons are control and predictability: Fixed costs. Per-token pricing is wonderful at zero traffic and brutal at scale. A VPS costs the same whether you serve 10 requests or 10,000. If you can predict your traffic, you can beat the API bill. Your data stays yours. User prompts, internal documents, proprietary workflows — none of it transits a third-party API. For internal tools, client work, or anything regulated, this alone justifies the setup. No rate-limit roulette. Your concurrency limit is your server’s capacity, not a tier a provider assigned you. No 429s at the worst moment. No surprise deprecations. When a hosted provider sunsets the model your app depends on, you rewrite or scramble. Your own API runs the same weights until you decide to change them. Drop-in compatibility. Modern open models serve an OpenAI-compatible endpoint, so your existing code usually changes one line: the base URL. The honest caveat: you become the ops team. Uptime, updates, and scaling are your problem. If your app makes three API calls a week, just pay per token — self-hosting is for steady, real traffic. New to servers entirely? Read our VPS hosting primer first. Pick Your Approach: Ollama vs LiteLLM vs Custom FastAPI There are three serious ways to serve an AI API from a VPS, and the right one depends on what you’re actually building: Approach What it is Best for Biggest weakness Ollama’s built-in server Ollama exposes an OpenAI-compatible API out of the box on port 11434 Single-model chat/completion APIs, personal projects, internal tools One model family per setup; minimal auth and rate-limiting built in LiteLLM proxy Open-source gateway that unifies 100+ providers and local models behind one OpenAI-compatible endpoint Mixing self-hosted + paid APIs, multiple keys, usage tracking, fallbacks Another service to run and secure Custom FastAPI wrapper Your own Python service in front of a local model (llama.cpp, vLLM, transformers) Custom logic: RAG, tool use, validation, bespoke billing You’re building and maintaining real software My recommendation: start with Ollama’s server, graduate to LiteLLM when you need keys and routing. Ollama gets you a working, OpenAI-compatible API in minutes. LiteLLM becomes worth it the day you want per-user API keys, spend tracking, or to route cheap requests to your VPS and overflow to a paid provider. A custom FastAPI wrapper only earns its keep when your API needs logic that isn’t just “talk to a model.” If serving models is your main goal, pair this guide with our deep dive on running AI models on a VPS for the model-selection side. VPS Specs That Matter for an AI API An API server’s specs are driven by the model, not the API layer. The web server part is trivially light — it’s inference that eats RAM. Quantized open models (4-bit) are the sweet spot for VPS hosting: Tier Workload RAM CPU Disk Approx. cost Starter 1–3B models, dev/test API, low concurrency 8 GB 2–4 vCPU 100 GB SSD $10–20/mo Sweet spot 7–8B models (Llama 3.1 8B, Qwen 2.5 7B), small production API 16 GB 4–6 vCPU 200 GB NVMe $20–40/mo Serious 13–14B models, higher concurrency, embeddings + chat together 32–64 GB 8–12 vCPU 400+ GB NVMe $50–100/mo GPU Fast responses, 30B+ models, real-time feel 16–32 GB 4–8 vCPU + NVIDIA GPU 200+ GB NVMe $80–300+/mo Concurrency is the hidden spec. A 7B model on CPU might take 5–10 seconds per response with one user; with five simultaneous users, requests queue and everyone waits. If your API will see real concurrent traffic, either size up, add a GPU, or be honest about expected wait times. Our roundup of cheap VPS plans that don’t sacrifice performance covers good CPU tiers, and server location matters too — put the VPS near your users, because API latency is user-facing latency. How to Host Your Own AI API on a VPS: Step-by-Step This assumes a fresh Ubuntu 22.04 or 24.04 VPS. First run through our new VPS setup checklist — firewall, SSH keys, updates — then work as a non-root user with sudo. Step 1 — Install Ollama and pull a model curl -fsSL https://ollama.com/install.sh | sh ollama pull llama3.1:8b For an API, pick a model with strong instruction-following in its size class — Llama 3.1 8B and Qwen 2.5 7B are the safe defaults in 2026. Download once; the weights live on your disk and never phone home. Step 2 — Make Ollama listen beyond localhost By default Ollama binds to 127.0.0.1, which is fine for local testing. For a real API you want it reachable through your reverse proxy — but never expose port

How to Host Your Own AI API on a VPS Read More »

Server running AI apps with Docker containers on a VPS

How to Run AI Apps with Docker on a VPS

Leave a Comment / Tutorials / admin

There’s a special kind of pain only AI developers know: it works on your machine, you deploy it to the server, and it explodes. Wrong CUDA version. A Python package that compiled fine locally but refuses on the VPS. A model file that was supposed to be there and isn’t. You fix one thing, break two more, and by midnight you’re rebuilding an environment you built last week. When you run AI apps with Docker on a VPS, that whole class of problem disappears. The app, its dependencies, its CUDA libraries, and its config all live inside a container that behaves identically on your laptop and your server. Build once, pull on the VPS, and it runs. This guide covers why Docker fits AI workloads, the VPS specs that matter, full setup with GPU passthrough, a real docker-compose stack, and the security and cost realities nobody mentions upfront. Why Docker for AI Apps? (The Honest Pitch) AI apps are dependency nightmares. A typical stack pulls in PyTorch or llama.cpp, a specific CUDA toolkit, tokenizers, model weights in the tens of gigabytes, and a dozen pinned Python packages. On a bare server, one careless pip install and two projects start fighting over CUDA libraries. Docker fixes this with boring, reliable isolation: The tradeoff: a learning curve, plus a sharp edge or two in GPU setup (covered below). For AI apps, it isn’t close. New to servers? Our VPS hosting primer covers the fundamentals first. VPS Specs That Matter for AI-in-Docker Docker itself is light — your specs are driven entirely by what the AI app does inside the container. A chatbot UI sipping from an API needs almost nothing; a local 8B-parameter LLM needs serious RAM; fast inference needs a GPU. For CPU-only AI apps (API-backed chatbots, embedding pipelines, small models), RAM is king, then CPU cores, then disk: Tier Workload RAM CPU Disk Approx. cost Starter Chatbot UI, API proxies, n8n automations, small embedding jobs 4 GB 2 vCPU 80 GB SSD $6–12/mo Sweet spot Ollama with 7–8B models, RAG pipelines, Open WebUI + vector DB 16 GB 4–6 vCPU 200 GB NVMe $20–40/mo Heavy CPU 13B+ models on CPU, batch embedding, multiple AI services 32–64 GB 8–12 vCPU 400+ GB NVMe $50–100/mo GPU Fast local inference, image generation, fine-tuning 16–32 GB 4–8 vCPU 200+ GB NVMe $80–300+/mo Local LLMs are RAM-hungry in a way that surprises people: a 7B model in 4-bit quantization needs ~6–8 GB just for weights, plus server and OS overhead. That’s why the sweet spot starts at 16 GB. If serving models is your real goal, read our guide to running AI models on a VPS alongside this one. Start CPU-only, measure whether inference speed is actually your bottleneck, then pay the GPU tax — our roundup of cheap VPS options that don’t sacrifice performance covers the CPU tiers above. And budget 2x the disk you think you need: AI images run 5–10 GB, model weights 5–50 GB, and Docker’s build cache quietly eats the rest. Docker vs Bare Metal vs Virtualenv: Which Should You Pick? Approach Best for Biggest strength Biggest weakness Docker Most AI apps: chatbots, RAG, model servers, multi-service stacks Reproducible, isolated, one-command deploys Learning curve; overkill for single tiny scripts Bare metal Max-performance single workloads, squeezing every token/sec from one model Zero container overhead, simplest debugging Dependency conflicts; messy uninstalls Virtualenv Quick experiments, single Python scripts Zero setup, familiar Doesn’t isolate system deps (CUDA!); not reproducible across machines If the app has more than one moving part, or you ever want to run it on a second machine, use Docker. A single API-calling script? Virtualenv is fine. An Ollama server plus a web UI plus a vector database? That’s Docker’s home turf. Bare metal only wins when you’re chasing the last 2–3% of performance on one dedicated workload. How to Run AI Apps with Docker on a VPS: Step-by-Step Setup This assumes a fresh Ubuntu 22.04 or 24.04 VPS. If you haven’t hardened a fresh box yet, run through our new VPS setup checklist first — firewall, SSH keys, updates — then follow along as a non-root user with sudo. Step 1 — Install Docker and the Compose plugin Skip the distro’s outdated Docker package and use Docker’s official repository. Details change over time, so I’ll point you at Docker’s official Ubuntu install docs as the canonical reference — the short version: Then allow Docker without sudo (log out and back in after): Step 2 — GPU support: the NVIDIA Container Toolkit (GPU servers only) Skip this on a CPU-only VPS. With an NVIDIA GPU on the server, this is what makes it visible inside containers: The moment of truth — verify the GPU is reachable from inside a container: If your GPU appears in the output, passthrough works. If not, check troubleshooting first — it’s almost always a driver/toolkit version mismatch, not a Docker problem. Step 3 — Your first AI container: Ollama Ollama is the perfect first container: a real AI workload in one command. This pulls the image, starts the server, and keeps it running: Two deliberate choices: -p 127.0.0.1:11434:11434 binds the API to localhost only — never internet-exposed (see security) — and -v ollama-data:/root/.ollama keeps models in a named volume so they survive restarts. On a GPU server, add –gpus all and Ollama uses it automatically. That pull downloads ~4.7 GB — your first taste of why disk space matters. You’re now running a local LLM in a container on a VPS. Everything next makes this robust and multi-service. A Real Stack: Ollama + Open WebUI with Docker Compose Single containers are toys; real AI apps are stacks. The setup I run myself: Ollama serving models plus Open WebUI as a ChatGPT-style interface, wired together with Docker Compose. One YAML file, one command: The services talk over Docker’s internal network via service names (http://ollama:11434) — no host networking hacks. Both ports bind to 127.0.0.1 only; reach the UI through an SSH tunnel or reverse proxy. The

How to Run AI Apps with Docker on a VPS Read More »

AI coding agent running on a VPS — laptop connected to a server with an AI assistant

How to Run AI Coding Agents on a VPS

Leave a Comment / Tutorials / admin

There’s a moment every developer has with an AI coding agent. You’re on your laptop at a café, you ask it to refactor an old module, and then… your fan starts screaming, your battery starts melting, and you realize the agent has been spinning for ten minutes while your whole machine crawls. I love these tools, but running them on the machine you actually work on is asking for pain. When you run AI coding agents on a VPS, all of that goes away. The agent lives on a server with dedicated resources, it keeps working when you close your laptop, and you can hand it a task at midnight and wake up to a pull request. In this guide I’ll walk you through why it works so well, the specs that actually matter, which agents to pick, a step-by-step setup, the security rules you absolutely shouldn’t skip, and what it really costs. Why Run AI Coding Agents on a VPS Instead of Your Laptop? AI coding agents — tools like Claude Code, Aider, and OpenHands — aren’t like a chatbot in a browser tab. They read your whole codebase, run tests, execute shell commands, install dependencies, and sometimes spin up services. That behavior has real consequences for the machine they run on: If you’re new to the concept, our primer on what VPS hosting is explains the basics — but the short version is: a virtual private server is your own slice of a powerful machine in a datacenter, and it’s the ideal home for an AI agent. The Specs That Actually Matter (And the Ones That Don’t) Here’s the first thing to understand: most AI coding agents don’t do the heavy AI lifting on your server. The big language model runs in the cloud (Anthropic, OpenAI, whoever powers your agent), and your VPS is doing the “hands” work — reading files, running git, executing tests, managing processes. That changes the spec calculus completely. The spec that matters most is RAM, then CPU cores, then disk speed. A GPU is almost never necessary — unless you’re also running a local model on the same box (see our guide to running AI models on a VPS if that’s your plan). Here’s a realistic breakdown: Use case RAM CPU Disk Approx. cost Light — one agent, small repos, occasional sessions 4 GB 2 vCPU 60 GB SSD $6–12/mo Standard — daily driver, medium repos, parallel agents 8 GB 4 vCPU 120 GB NVMe $15–25/mo Heavy — big monorepos, test suites, multiple agents + services 16–32 GB 6–8 vCPU 200+ GB NVMe $30–60/mo Honest opinion: start at 8 GB RAM / 4 vCPU. It’s the sweet spot where agents feel snappy, you can run two sessions at once, and you’re not paying for capacity you’ll never touch. You can always resize a VPS in minutes — every provider lets you scale up without rebuilding. Our breakdown of cheap VPS options that don’t sacrifice performance is a good place to hunt for that tier. One more spec note: location matters more than people think. Every keystroke round-trips between you and the agent, so pick a datacenter near you. A 200ms difference in latency is the difference between an agent that feels alive and one that feels laggy. We covered the full decision in our VPS server location guide. Pick Your Agent: Claude Code vs Aider vs OpenHands The agent landscape moves fast, but three options cover nearly everyone’s needs right now. Here’s the honest comparison: Agent Best for How it runs Model cost model Claude Code Terminal-first developers who want the smartest agent available CLI on your server, you connect over SSH API usage or subscription Aider Pair-programming style, works with many models, great git integration CLI, pairs nicely with tmux for persistence Bring your own API key (pay per use) OpenHands A full agent “workspace” with web UI, sandboxed execution Docker container with browser-based interface Bring your own API key My take: if you’re already comfortable in a terminal, start with Claude Code or Aider — they’re the fastest to get running and the easiest to reason about. OpenHands is genuinely impressive, but it’s a heavier lift (Docker, more RAM) and shines when you want a self-contained agent environment with a GUI. There’s no wrong answer here; you can run all three on the same VPS. A quick word on model costs, because nobody warns you about this: the VPS is the cheap part. API usage for a heavy agent session can run anywhere from a few cents to a few dollars, and an enthusiastic weekend of agent-driven refactoring can surprise you. Set a spending alert on your API account on day one. Seriously. Step-by-Step: Setting Up Your VPS for AI Coding Agents This walkthrough assumes a fresh Ubuntu 22.04/24.04 server. If you haven’t hardened a fresh box yet, run through our new VPS setup checklist first — it takes ten minutes and saves you from the classic mistakes. 1. Create a dedicated agent user Never run agents as root. Create a locked-down user whose damage radius is limited to its own home directory: 2. Install the essentials tmux is non-negotiable. It keeps your agent session alive when SSH drops. Start every agent inside a tmux session and you’ll never lose work to a flaky connection again. 3. Install your agent For Claude Code (npm-based): For Aider (pip-based): For OpenHands (Docker): Then open http://your-server-ip:3000 in a browser (lock this down — more on that in the security section). The Aider documentation is genuinely excellent if you want to go deeper on configuration. 4. Clone your repos and set up SSH keys Generate a deploy key on the VPS (never copy your personal SSH private key onto a server): 5. Connect and go SSH in, attach to your tmux session (tmux attach -t claude), and start giving the agent tasks. From here on, your laptop is just a window into a machine that never sleeps. Lock It Down: Security Rules You Shouldn’t

How to Run AI Coding Agents on a VPS Read More »

Server rack with glowing GPU cards for a self-hosted AI image generator

How to Self-Host an AI Image Generator on a Server

Leave a Comment / Tutorials / admin

Paying $30 a month for an AI image subscription feels fine — right up until you hit the generation cap in week two, lose the style you spent hours dialing in, or find your private prompts sitting on someone else’s server. There’s a better way, and it’s not as hard as it sounds: self-host an AI image generator on your own server, and you get unlimited generations, total privacy, and full control over the models and styles you use. I’ve watched the self-hosted AI wave go from “Linux wizardry only” to something any determined beginner can pull off in an afternoon. In this guide, I’ll walk you through everything — the GPU hardware you actually need, your two setup options (home server vs GPU VPS), a step-by-step install of the Stable Diffusion web UI, a Docker alternative, how to lock it down, and what it really costs. By the end, you’ll have your own image generator running at an address you control. Why Self-Host an AI Image Generator Instead of Paying Monthly? Midjourney, DALL-E, and the rest are genuinely great products. But subscriptions come with strings attached that bother more people than you’d think: When you self-host an AI image generator, none of these apply. It’s your GPU, your models, your rules. And once the hardware is in place, the running cost is nearly flat — generate 10 images or 10,000, the bill barely moves. The honest caveat: self-hosting trades money for a bit of your time. If you generate fewer than ~200 images a month and don’t care about privacy, a subscription is simpler. If you’re past that — or you care about privacy and control — self-hosting wins by a mile. The Hardware Reality: Image Generation Needs a GPU Here’s the one non-negotiable part. Language models can run fine on CPU (as we covered in our guide to running AI models on a VPS), but image diffusion models are a different animal. They live and die by GPU VRAM. A regular CPU-only VPS will take 20+ minutes per image — that’s not usable. The good news: you don’t need a $3,000 card. Here’s what different VRAM levels realistically buy you in 2026: VRAM Example GPUs What you can run 8 GB RTX 3060 / 4060 SD 1.5 at 512×512, workable but slow on larger models; needs –medvram flags 12 GB RTX 3060 12GB / 4070 The sweet spot — SD 1.5, SDXL, most checkpoints run comfortably 16 GB RTX 4080 / 5080 SDXL comfortably, Flux.1 dev at reduced settings, faster batch generation 24 GB RTX 3090 / 4090 Everything including Flux.1 dev at full quality, training LoRAs, multi-model setups Two rules of thumb I tell everyone: never go below 8 GB VRAM, and 12 GB is where the frustration stops. Also budget 50–100 GB of SSD — checkpoints, VAEs, and LoRAs pile up faster than you’d expect. System RAM matters less; 16 GB is plenty for a dedicated box. Your Two Setup Options: Home Server vs GPU VPS There are two realistic ways to host your own image generator. Neither is “better” in the abstract — it depends on your situation. Home server / your own PC GPU VPS Upfront cost GPU purchase ($300–$1,500+) $0 — you rent by the month Monthly cost Electricity (~$10–30) $40–$150+ depending on GPU tier Always-on access Only if you leave it running (and your ISP allows inbound connections) Yes — data center power, static IP, reachable from anywhere Setup difficulty Moderate — you own the hardware stack Moderate — same software, but remote access plumbing Best for Heavy daily use, privacy purists, tinkerers Trying it out, remote teams, no hardware budget, access from anywhere A quick word on the GPU VPS route: regular VPS plans (like the ones we cover in our guide to the best VPS for AI agents) don’t include GPUs — you need a dedicated GPU VPS or a GPU cloud instance. They’re pricier than CPU servers, but you skip the hardware purchase entirely. If you’re testing the waters, a month of a GPU VPS is the cheapest way to find out whether self-hosting fits your workflow. The rest of this guide uses Ubuntu 22.04/24.04, which is what nearly every GPU VPS ships with and what the installation tooling expects. Installing the Stable Diffusion Web UI (AUTOMATIC1111), Step by Step The Stable Diffusion web UI by AUTOMATIC1111 is the most popular way to self-host an AI image generator. It’s a browser-based interface with txt2img, img2img, inpainting, upscaling, LoRA support, and a huge extension ecosystem — 165,000+ GitHub stars don’t lie. Here’s the full install on a fresh Ubuntu server with an NVIDIA GPU. Step 1: Prepare the server SSH into your machine and install the prerequisites: You’ll also need the NVIDIA driver and CUDA toolkit installed for your GPU — your GPU VPS provider usually offers an image with these pre-installed (pick it, it saves an hour). Verify with nvidia-smi; if it shows your GPU, you’re good. Step 2: Download and launch the web UI That first run takes a while — it builds a Python virtual environment, downloads PyTorch, and fetches the default Stable Diffusion checkpoint (~4 GB). Go make coffee. On a 12 GB card, expect 10–20 minutes on the first launch. Step 3: Access it safely By default the UI binds to 127.0.0.1:7860 — localhost only, which is actually the safe default. On a remote VPS, the cleanest way in is an SSH tunnel from your own computer: Then open http://127.0.0.1:7860 in your browser. You’re now talking to your own image generator, tunneled through encrypted SSH. (More on proper public access with authentication in the security section below.) Step 4: Generate your first image Type a prompt in the txt2img tab — something like “a cozy mountain cabin at dusk, warm light in windows, photorealistic” — pick 512×512 or 768×768, hit Generate. On a 12 GB card, a 20-step image takes roughly 10–30 seconds. Try the negative prompt field too (blurry, low quality, watermark) —

How to Self-Host an AI Image Generator on a Server Read More »

host an ai chatbot on a vps 24/7 - chatbot on server at night

How to Host an AI Chatbot on a VPS 24/7 (2026)

Leave a Comment / Tutorials / admin

Here is a scenario I see all the time. Someone builds a genuinely good AI chatbot — trained on their business docs, wired into their website — and then hosts it on their laptop. It works beautifully. Until they close the lid. Or the Wi-Fi drops. Or Windows decides 3 AM is the perfect time for an update. And just like that, the chatbot is down. Visitors get a dead widget. Leads go nowhere. The fix is simple: put the chatbot on a VPS that never sleeps. A small virtual server, running 24/7, serving your AI to the world while you do literally anything else. This guide shows you exactly how to host an AI chatbot on a VPS 24/7 — the model, the setup, the auto-restart plumbing, the web interface, and the security bits most tutorials skip. No fluff, just the working path. What “24/7” Actually Means (Be Honest With Yourself) Before we touch a terminal, let us define the target. “24/7” does not mean your chatbot literally never goes down — even Google has outages. It means three things: That is the bar. Everything in this guide exists to clear it. And the honest truth? Getting there takes about an hour, and most of that is waiting for downloads. What You Will Need Nothing exotic. Here is the full shopping list: A quantized 7B or 8B model may run on a CPU VPS, but throughput depends on CPU generation, memory bandwidth, context length, quantization and concurrency. The figures here are planning estimates, not measured benchmarks. Run a representative load test before promising response times or choosing a production plan. Step 1: Set Up Your VPS SSH into your fresh server. First, the boring-but-critical basics — updates, a firewall, and a non-root user. I know, I know, you want to get to the AI part. But an AI chatbot with an open port and a weak root password will be crypto-mining for a stranger by Thursday. Our VPS security guide goes deeper; here is the minimum: That gives you a patched server with only SSH, HTTP, and HTTPS reachable. If you have not done the rest of the new-server checklist (SSH keys, automatic updates), do it now — future-you will be grateful. Step 2: Install Ollama and Pull a Model Ollama is the easiest way to run open models on a server. One install command, one command per model, and you have an API serving completions. If you want the full background on how self-hosting models works, our complete guide to running AI models on a VPS covers it in depth. That downloads Meta’s Llama 3.1 8B — smart enough for customer support, FAQs, and document Q&A, small enough (~5 GB) to live comfortably in 8 GB of RAM. Want something else? ollama pull qwen2.5:7b is excellent for multilingual chat; mistral:7b is fast and sharp in English. Quick sanity check that it works: If it answers, your model is alive. Now let us make sure it stays alive. Step 3: Make It Survive Reboots (systemd) This is the step most tutorials skip — and it is the entire difference between “a chatbot” and “a chatbot that runs 24/7.” Ollama installs a systemd service by default on most setups, but let us verify and harden it, because silent failures here are how you get the 4 AM outage. enable is the magic word — it means “start this automatically on every boot.” Now add a safety net: if the process crashes, systemd should restart it instead of giving up. Create an override: Five lines, and your model now restarts itself within 5 seconds of any crash, and comes back after every reboot. That is 90% of “24/7” right there. Step 4: Give It a Web Interface (Open WebUI) Ollama alone is an API — great for developers, useless for visitors. Open WebUI is a polished ChatGPT-style interface that talks to Ollama. Your visitors get a familiar chat window; you get user accounts, chat history, and admin controls. Install Docker, then run it: Two details worth noticing. –restart unless-stopped means the web UI also comes back after reboots — same 24/7 principle, applied to every layer. And the data volume (-v open-webui:/app/backend/data) means user accounts and chat history survive container updates. I have seen people skip the volume, update the container, and lose everything. Do not be those people. Access the loopback-only interface with an SSH tunnel (ssh -L 3000:127.0.0.1:3000 user@your-server-ip), then visit http://localhost:3000 — you should see the Open WebUI signup page. Create your admin account (the first account becomes admin automatically). But do not stop here: right now it is HTTP on a raw IP. Let us fix that. Step 5: Put It Behind a Domain With Free HTTPS Nobody trusts a chatbot on http://203.0.113.42:3000. Point a DNS A-record for chat.yourdomain.com at your server’s IP, then install Caddy — a web server that gets free Let’s Encrypt certificates automatically, with roughly four lines of config: Then edit /etc/caddy/Caddyfile: That is genuinely all of it. Caddy fetches the certificate, renews it forever, and proxies visitors to Open WebUI over HTTPS. No certbot cron jobs, no manual renewals, no expiry panic. If you prefer Nginx, our Nginx on Ubuntu guide covers the manual route — but for a chatbot, Caddy’s simplicity wins. Step 6: Monitoring and Auto-Recovery You now have a chatbot that restarts itself and serves over HTTPS. The last piece of 24/7 is knowing — because “it restarted itself” is only comforting if you can verify it. 1. Free external uptime monitoring. Sign up for UptimeRobot’s free plan (50 monitors, plenty) and add https://chat.yourdomain.com. It pings every 5 minutes and emails you the moment the site stops responding. This is non-negotiable — it is the difference between finding out from a monitor in 5 minutes and finding out from an angry customer in 5 days. 2. Watch disk space. Chat logs and Docker images grow quietly. A full disk kills everything at once. Add a weekly check to

How to Host an AI Chatbot on a VPS 24/7 (2026) Read More »