Deploy Ollama with GPU and Open WebUI on Ubuntu 24.04: Secure, Optimize, and Update

Overview

This guide shows how to deploy Ollama with GPU acceleration on Ubuntu 24.04 and connect it to Open WebUI for a friendly chat interface. You will set up drivers, install Ollama, run Open WebUI in Docker, lock down network access, and tune performance. The result is a secure, fast, and maintainable local AI stack suitable for developers, helpdesk teams, and privacy-focused environments.

Prerequisites

You need an Ubuntu 24.04 server (or desktop) with at least 16 GB RAM, a modern CPU, and optionally an NVIDIA GPU (Turing or newer recommended). You also need sudo access and an open outbound internet connection to fetch packages and models.

1) Update the system

sudo apt update && sudo apt -y upgrade && sudo reboot

2) Install NVIDIA drivers (GPU users)

If you have an NVIDIA GPU, install the proprietary driver and CUDA runtime to enable acceleration. Ubuntu’s repo provides a good default.

sudo ubuntu-drivers autoinstall

sudo reboot

Verify the driver is working:

nvidia-smi

If you see your GPU and driver version, you are ready. CPU-only users can skip this section; Ollama will fall back to CPU automatically.

3) Install Ollama

Ollama provides a simple installer that configures a systemd service and the command-line client.

curl -fsSL https://ollama.com/install.sh | sh

After installation, the service runs on localhost port 11434 by default. Confirm status:

systemctl status ollama

Pull a model to test the pipeline. Llama 3 is a popular general-purpose model:

ollama pull llama3

Run a quick prompt:

ollama run llama3 "Write one sentence about Ubuntu 24.04."

4) Harden Ollama’s listener

By default, Ollama listens on 127.0.0.1. Keep it that way to avoid exposing the API publicly. Confirm the binding:

ss -ltnp | grep 11434

If you ever need to force it, create a systemd override and set the environment variable.

sudo systemctl edit ollama

Add the following lines, then save:

[Service]
Environment=OLLAMA_HOST=127.0.0.1:11434

sudo systemctl daemon-reload && sudo systemctl restart ollama

5) Install Docker and run Open WebUI

Open WebUI is a lightweight, modern web front end that can connect to a local Ollama. Install Docker, then run Open WebUI as a container.

sudo apt -y install docker.io

sudo systemctl enable --now docker

Run Open WebUI and publish it on port 3000. The extra host mapping allows the container to talk to Ollama on the host’s 127.0.0.1.

sudo docker run -d --name openwebui --restart=unless-stopped -p 3000:8080 --add-host=host.docker.internal:host-gateway -e OLLAMA_BASE_URL=http://host.docker.internal:11434 ghcr.io/open-webui/open-webui:main

Open your browser and visit http://server-ip:3000. On first launch, create an admin user. In Settings, confirm the Ollama endpoint is http://host.docker.internal:11434.

6) Add HTTPS with Nginx (recommended)

Protect logins and prompts with TLS. Point a DNS record (e.g., ai.example.com) to your server, then install Nginx and Certbot.

sudo apt -y install nginx certbot python3-certbot-nginx

Create a basic reverse proxy for Open WebUI on port 3000:

sudo bash -c 'cat >/etc/nginx/sites-available/openwebui.conf<<EOF
server {
server_name ai.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
EOF'

sudo ln -s /etc/nginx/sites-available/openwebui.conf /etc/nginx/sites-enabled/

sudo nginx -t && sudo systemctl reload nginx

Issue a free certificate:

sudo certbot --nginx -d ai.example.com --redirect

7) Lock down the firewall

Use UFW to allow only SSH and HTTPS. Do not expose port 11434 (Ollama) or 3000 (Open WebUI) directly to the internet.

sudo apt -y install ufw

sudo ufw default deny incoming

sudo ufw allow OpenSSH

sudo ufw allow 443/tcp

sudo ufw enable

8) Performance tuning

If you have a GPU, enable the VRAM cache to improve response times and reduce recomputation. Create an environment file for Ollama.

sudo mkdir -p /etc/ollama

echo 'OLLAMA_KV_CACHE_SIZE=4GB' | sudo tee /etc/ollama/environment

Bind the environment file via systemd:

sudo systemctl edit ollama

Add:

[Service]
EnvironmentFile=/etc/ollama/environment

sudo systemctl daemon-reload && sudo systemctl restart ollama

Other useful variables: OLLAMA_NUM_PARALLEL to control concurrent requests, OLLAMA_FLASH_ATTENTION=1 on supported GPUs, and OMP_NUM_THREADS for CPU-bound workloads. For large models, ensure enough disk space under ~/.ollama/models.

9) Backups and persistence

Models live in ~/.ollama/models and Open WebUI stores its data in the container by default. To persist Open WebUI settings, mount a host directory:

sudo mkdir -p /opt/openwebui-data

sudo docker rm -f openwebui

sudo docker run -d --name openwebui --restart=unless-stopped -p 3000:8080 --add-host=host.docker.internal:host-gateway -e OLLAMA_BASE_URL=http://host.docker.internal:11434 -v /opt/openwebui-data:/app/backend/data ghcr.io/open-webui/open-webui:main

Back up ~/.ollama and /opt/openwebui-data with your usual backup tool (rsync, restic, Borg, or your enterprise solution). Exclude temporary caches if space is limited.

10) Updating and troubleshooting

Update Ollama:

curl -fsSL https://ollama.com/install.sh | sh

Update Open WebUI:

sudo docker pull ghcr.io/open-webui/open-webui:main && sudo docker restart openwebui

If the GPU is not used, verify nvidia-smi shows utilization during prompts and check logs:

journalctl -u ollama -f

If Open WebUI cannot reach Ollama, confirm the extra host mapping is present and that curl http://host.docker.internal:11434 from inside the container returns JSON.

11) Optional: Zero-trust exposure

If you need remote access, consider exposing Open WebUI through a zero-trust tunnel (Tailscale Funnel, Cloudflare Tunnel, or Nginx with client certificates) instead of opening raw ports. This keeps the Ollama API private while giving you secure, audited access from anywhere.

Conclusion

You now have a production-ready local AI stack: Ollama for efficient model serving, Open WebUI for a clean interface, TLS for security, and sensible defaults to keep the API private. With regular updates and simple tuning, this setup is fast, safe, and easy to maintain on Ubuntu 24.04.

How to Set Up Real-Time File Synchronization on Linux Using Syncthing

Introduction

In the fast-paced world of IT, keeping files synchronized across multiple devices is crucial for productivity and data integrity. Real-time file synchronization allows users to automatically update files in different locations without manual intervention. One of the most reliable and user-friendly open-source tools for this purpose is Syncthing. In this tutorial, you will learn how to install, configure, and use Syncthing for seamless file synchronization on Linux systems.

What is Syncthing?

Syncthing is a free, decentralized, peer-to-peer file synchronization tool that works across multiple platforms, including Linux, Windows, and macOS. Unlike cloud-based services, Syncthing stores your data only on your devices, ensuring privacy and security. It uses robust encryption to protect your data during transfer and does not require any third-party servers.

Step 1: Installing Syncthing on Linux

To get started, first update your system’s package list. For Debian-based distributions (like Ubuntu), open a terminal and run:

sudo apt update

Next, install Syncthing using the following command:

sudo apt install syncthing

For other distributions, such as Fedora or Arch Linux, you can use your native package manager. For example, on Fedora:

sudo dnf install syncthing

Alternatively, you can download the latest release from the Syncthing official website for manual installation.

Step 2: Starting and Enabling Syncthing

Once installed, you can start Syncthing using your terminal:

syncthing

By default, Syncthing launches a web-based GUI at http://localhost:8384. For continuous background operation, it’s recommended to set up Syncthing as a systemd service:

systemctl --user enable syncthing
systemctl --user start syncthing

This ensures that Syncthing automatically starts on user login.

Step 3: Initial Configuration

Open your browser and navigate to http://localhost:8384. The user interface is intuitive, allowing you to configure folders and devices easily. To sync a folder, click “Add Folder,” choose a folder path, and assign a label. Each folder receives a unique “Folder ID” used for sharing with other devices.

To connect another device, install Syncthing on that device as well, then exchange Device IDs. Add the Device ID in the “Remote Devices” section of the web GUI. Accept the folder share on both devices to start synchronization.

Step 4: Managing Synchronization and Troubleshooting

Syncthing synchronizes files in real-time, meaning changes are detected and propagated instantly. You can monitor synchronization status, transfer speed, and recent activity from the web GUI. If you encounter connectivity issues, ensure that both devices can communicate over the network and that firewalls allow Syncthing’s ports (default: 22000/tcp, 21027/udp).

For advanced setups, you can tweak options such as versioning, ignore patterns, and resource limits. Syncthing also supports relay servers if direct connections are not possible, increasing flexibility for remote synchronization.

Conclusion

Real-time file synchronization with Syncthing offers an efficient, secure, and decentralized solution for keeping your files consistent across multiple Linux devices. Its open-source nature and ease of use make it ideal for individuals, teams, and businesses seeking control over their data. With the steps above, you can quickly set up Syncthing and enjoy hassle-free file synchronization on your Linux systems.

Popular Posts

Install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Install Ollama + Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Install a Local AI Chatbot on Ubuntu 24.04 with Ollama and Open WebUI (Step-by-Step)

Trending Now

Recovering from Btrfs Boot Failures Using GUI Tools on Fedora

By the end of this guide the reader will be able to identify a Btrfs‑based Fedora installation, boot from a live USB, list and restore snapshots using the graphical utilities btrfs‑assistant and snapper, and verify that the system returns to a functional state without resorting to the command line. Understanding the Btrfs Layout Used by Fedora Fedora Workstation and Fedora KDE install the root filesystem as a single Btrfs partition that contains two default sub‑volumes. One sub‑volume holds the traditional “/” hierarchy, while the second is dedicated to /var/lib/machines . The latter exists to keep container images out of snapshot operations; it remains empty on systems that do not run virtual machines. Because Btrfs stores data in sub‑volumes rather than separate partitions, a snapshot captures the state of an entire sub‑volume at a point in time. The installer (Anaconda) automatically registers these sub‑volumes with the snapper service. Snapper maintains a series of read‑only ...