DEV Community: Vultr

Installing GPT4All, an Open-Source Chatbot Application for Running LLMs

Sanskriti Harmukh — Thu, 03 Sep 2026 17:20:17 +0000

GPT4All is an open-source graphical desktop application for running large language models (LLMs) locally. It supports most desktop operating systems — macOS, Windows, and Linux — so you can run LLMs without an active internet connection, and it supports GGUF format models from sources including Hugging Face while also integrating with API-based providers like Groq, OpenAI, and Mistral. This guide covers installing GPT4All, downloading and running models, chatting with local documents, and enabling the built-in API server behind a reverse proxy. By the end, you'll have GPT4All installed with a local model running, a documents-aware RAG chat set up, and a remotely reachable API server secured with HTTPS.

Prerequisites

Access to a GPU-enabled or CPU-powered computer running Windows, macOS, or an Ubuntu (with GUI) based Linux server as a non-root user with sudo privileges.
A domain A record created for your domain name, pointing to the workstation's IP address, using your DNS provider's dashboard. This guide uses the gpt4all.example.com domain for demonstration purposes.

1. Install GPT4All

You can install GPT4All on Windows, macOS, or Linux.

Install GPT4All on Linux

GPT4All is available only for Ubuntu and Debian-based desktop workstations. You can install it using the latest installation binary or Flatpak. The steps below download and install the latest installation binary on an Ubuntu 24.04 desktop workstation.

1. Log in to your Ubuntu desktop workstation using VNC, NoMachine, or a remote desktop client, then open a new terminal (or press CTRL + ALT + T).

2. Download the latest GPT4All .run installation binary for Linux from the official website:

$ wget https://gpt4all.io/installers/gpt4all-installer-linux.run

3. Enable execute permissions on the downloaded file:

$ chmod +x gpt4all-installer-linux.run

4. Execute the file to open the GPT4All installation wizard (you need a full desktop environment to run the application):

$ ./gpt4all-installer-linux.run

5. Click Next >, verify the installation path, select all components, accept the license, and click Install to complete the wizard, then click Finish to close the installer.

6. List the GPT4All installation directory and verify all application files are available:

$ ls ~/gpt4all

Output:

bin             InstallationLog.txt  Licenses             network.xml  share
components.xml  installer.dat        maintenancetool      plugins
gpt4all-32.png  installerResources   maintenancetool.dat  qml
gpt4all-48.png  lib                  maintenancetool.ini  resources

7. List your Desktop path and verify a GPT4All.desktop file is available:

$ ls ~/Desktop

Output:

GPT4All.desktop

8. Create an applications directory for your user:

$ mkdir -p ~/.local/share/applications

9. Move the GPT4All.desktop file into it:

$ mv ~/Desktop/GPT4All.desktop ~/.local/share/applications/

10. Open your applications menu, search for GPT4All, and click the icon to launch the chat interface.

Install GPT4All on Windows

GPT4All supports x86 and ARM-based processors for Windows, with a single installer supporting CPU or GPU builds.

1. Download the latest GPT4All .exe installation binary from the official website.

2. Open the downloaded .exe file to launch the installer, click Next, verify the installation path, select the components to install, accept the license, keep the default start menu shortcut, and click Install.

3. Monitor the installation process, click Finish to close the installer, then open the Windows start menu, search for GPT4All, and open it from the list of installed applications.

Install GPT4All on Mac

Follow these steps to install GPT4All on a Mac with an M-series processor.

1. Download the latest GPT4All .dmg installation binary from the official website.

2. Open the downloaded installer package and double-click the gpt4all-installer-darwin file to open the installation wizard.

3. Click Next > on the Installation Folder page (you can keep the default path), click Next > again to review the single component (gpt4all), accept the License Agreement, and click Install.

4. Monitor the installation process, click Finish, then open the Launchpad and search for GPT4All to launch the chat interface.

2. Configure GPT4All to Run LLMs

GPT4All does not include any models by default. You download models from the built-in GPT4All repository or external sources such as Hugging Face, including distilled, instruct, reasoning, uncensored, and censored variants.

1. Open GPT4All from your applications menu and click Models on the main navigation menu.

2. Click Add Model to explore the Explore Models page, which offers:

GPT4All: Models hosted in the built-in GPT4All repository, tested and compatible with the application.
Remote Providers: Links to remote model providers, including Groq, OpenAI, and Mistral, which require an internet connection for inference.
Hugging Face: GGUF format models hosted on Hugging Face, searchable by keyword.

3. Scroll or search for a specific model, such as Llama3.2 1B Instruct, and verify its requirements:

File Size: The total size of the model files, which must fit in your available free space.
RAM Required: The total memory needed to run the model within GPT4All.
Parameters: The model's total parameter count.
Quant: The quantization type, indicating how the model's weights are compressed to reduce memory usage and improve inference speed.
Type: The model's architecture or base model family.

4. Click Download, then click Models on the navigation menu and verify the model is downloaded and available.

3. Chat with LLMs Locally

Downloaded models are available on the Chats tab. All chats are private and local to your workstation.

1. Click Chats on the main navigation menu, click Select a Model, and choose a model.

2. Enter a prompt in the Send a message field and press Enter to start the chat.

3. Monitor the token count and model response rate, and verify the response matches your prompt.

4. Enter another prompt to continue chatting with context from the original prompt, and use Delete, Edit, or New Chat in the history pane to manage conversations.

4. Reference Local Documents Using RAG

GPT4All supports Retrieval-Augmented Generation (RAG) by default through the LocalDocs menu option, letting you upload documents and chat with an LLM using them to improve response quality.

1. Click Settings, select LocalDocs, and verify the list of supported file extensions.

2. Click the Embeddings Device option and select CUDA if available to use your GPU for embedding local documents.

3. Click LocalDocs on the main navigation menu, then click Add Doc Collection to create a new collection.

4. Enter a collection name, click Browse to select the path containing your documents, and click Create Collection to scan them.

5. Verify the embeddings count and the model in use (nomic-embed-text-v1.5 by default), and monitor progress for each document.

6. Click Chats, start a new chat, and click LocalDocs in the top-right to select your documents collection for RAG.

5. Download and Use GGUF-Format Models

GGUF (GPT-Generated Unified Format) stores, loads, and infers large language models efficiently, optimized for memory usage and fast loading. You can download .gguf models from platforms like Hugging Face and manually add them to GPT4All.

1. Open a web browser and visit Hugging Face to search for a model — for example, Mistral GGUF.

2. Select a model from the list, such as mistralai/Devstral-Small-2507_gguf, click Files and Versions, and select a quantization version — for instance, Devstral-Small-2507-Q4_K_M.gguf — noting its file size.

3. Open a new terminal window and check available disk space:

$ df -h

4. Download the file from your browser, then navigate to your Downloads folder in the terminal:

$ cd ~/Downloads

5. Move the downloaded .gguf file to the GPT4All models directory:

$ mv Devstral-Small-2507-Q4_K_M.gguf ~/.local/share/nomic.ai/GPT4All/

6. List the directory and verify the available .gguf model files:

$ ls ~/.local/share/nomic.ai/GPT4All/

Output:

Devstral-Small-2507-Q4_K_M.gguf  Llama-3.2-1B-Instruct-Q4_0.gguf  localdocs_v3.db  test_write.txt

7. Close and reopen GPT4All to load the newly added model, then navigate to the Models tab to verify it's available.

8. Navigate to Chats, click New Chat, select the new model, and enter a prompt such as write a short story about a robot learning to code, with a focus on arrays, then press Enter to generate a response.

6. Enable the GPT4All API Server

GPT4All includes a built-in API server for interacting with models over REST endpoints, letting you integrate GPT4All into existing applications.

1. Click Settings, navigate to the Advanced section, and click Enable Local API Server.

2. Note the default API Server Port, then open a new terminal window and send a GET request to list all available models:

$ curl http://localhost:4891/v1/models

3. Send a GET request for a specific model's details (replace Devstral-Small-2507-Q4_K_M.gguf with a model available on your server):

$ curl http://localhost:4891/v1/models/Devstral-Small-2507-Q4_K_M.gguf

4. Send a POST request to generate a text completion:

$ curl -X POST http://localhost:4891/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Devstral-Small-2507-Q4_K_M.gguf",
    "prompt": "What is the sum of 8, 5, and negative 200?",
    "max_tokens": 500
  }'

The API returns a JSON response with the completion and a few other details.

Configure Nginx as a Reverse Proxy to Forward API Requests on Linux

GPT4All listens for API requests on the 127.0.0.1 localhost address, which limits connections to your local system. Installing Nginx as a reverse proxy enables secure network connections to the API server by forwarding requests to the localhost address.

1. Update the APT package index:

$ sudo apt update

2. Install Nginx:

$ sudo apt install nginx -y

3. Create a new virtual host configuration file:

$ sudo nano /etc/nginx/sites-available/gpt4all.conf

4. Add the following configuration, replacing gpt4all.example.com with your domain name:

server {
    listen 80;
    server_name gpt4all.example.com;

    location / {
        proxy_pass http://127.0.0.1:4891;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Save the file and exit. This forwards all connection requests from the gpt4all.example.com domain to the GPT4All API server on port 4891.

5. Enable the site by linking it to sites-enabled:

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

6. Remove the default Nginx virtual host configuration:

$ sudo rm /etc/nginx/sites-enabled/default

7. Test the Nginx configuration for syntax errors:

$ sudo nginx -t

Output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

8. Restart Nginx to apply the changes:

$ sudo systemctl restart nginx

9. Allow network connections to Nginx through the firewall and reload it:

$ sudo ufw allow "Nginx Full"
$ sudo ufw reload

10. Install Certbot to generate a Let's Encrypt certificate:

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

11. Generate a certificate for your domain (replace admin@example.com with your email address):

$ sudo certbot --nginx -d gpt4all.example.com -m admin@example.com --agree-tos

12. Restart Nginx to apply the certificate changes:

$ sudo systemctl restart nginx

Send API Requests to the GPT4All API Server

With the reverse proxy in place, GPT4All accepts remote API requests forwarded to the localhost API server port.

1. Send a GET request to list all available models using your domain:

$ curl https://gpt4all.example.com/v1/models

2. Send a GET request for a specific model's details:

$ curl https://gpt4all.example.com/v1/models/Qwen2-1.5B-Instruct

Troubleshooting

GPT4All won't open on Windows: The firewall may block connections to the application. Open Windows Settings → Privacy & Security → Windows Security → Firewall and Network Protection → Allow an app through firewall → Change Settings → Allow another app, then browse to the chat binary in C:\Users\<your-user>\gpt4all\bin, add it, enable private and public connections, and save.
GPT4All missing from the Linux applications menu: Move the GPT4All.desktop file from your Desktop path to ~/.local/share/applications to enable it in your applications list.
Error loading shared libraries on Linux: On a minimal Linux install you may see errors like error while loading shared libraries: libxkbcommon.so.0: cannot open shared object file, meaning required graphical libraries are missing. Install a full desktop environment:
```
$ sudo apt install ubuntu-desktop -y
```
Reboot after installation and re-run the installer.
Model fails to load or crashes the application: This usually means your system lacks enough RAM. Check the model's RAM Required value on the Models tab and use models that fit your available memory.

Next Steps

Explore remote model providers like Groq, OpenAI, and Mistral from within GPT4All's Models page for cloud-backed inference.
Build a LocalDocs collection from your own notes, PDFs, or spreadsheets to try RAG-based question answering.
Wire the GPT4All API server into an existing application using the OpenAI-compatible /v1/completions and /v1/models endpoints.
Automate certificate renewal for your reverse proxy and monitor the API server for production use.

For the full guide with additional tips, visit the original article on Vultr Docs.

Deploying Inference Using NVIDIA Dynamo and vLLM

Sanskriti Harmukh — Thu, 03 Sep 2026 17:19:26 +0000

NVIDIA Dynamo is an open-source, high-throughput, low-latency inference framework for deploying large-scale generative AI and reasoning models across multi-node, multi-GPU environments. It boosts LLM inference efficiency and reduces time-to-first-token (TTFT) through intelligent resource management, dynamic GPU allocation, and distributed orchestration, and it supports disaggregated serving — separating prompt processing (prefill) and response generation (decode) across different GPUs so each phase can be optimized independently. Dynamo integrates with backends including vLLM, SGLang, and NVIDIA TensorRT-LLM. This guide deploys NVIDIA Dynamo with the vLLM backend, covering infrastructure setup, container deployment, and two serving patterns: aggregated serving for single-GPU configurations and disaggregated serving for multi-GPU setups with independent prefill and decode workers. By the end, you'll have a running Dynamo + vLLM deployment serving chat completion requests in both aggregated and disaggregated configurations.

Prerequisites

Access to a GPU-enabled server with NVIDIA GPUs installed and the NVIDIA Container Toolkit configured, using a non-root user with sudo privileges.
- 1 GPU minimum for aggregated serving.
- 4 GPUs for disaggregated serving.
Docker Engine and Docker Compose installed.
A Hugging Face account with an access token generated for gated models like Llama.

Key Components

NVIDIA Dynamo is the orchestration layer, managing GPU resources, routing requests, and coordinating between workers. It includes a frontend service that receives inference requests, a smart router that directs traffic based on KV cache awareness, and a GPU planner that dynamically adjusts resource allocation.
vLLM is the inference backend that executes model computations on GPUs. Prefill workers process incoming prompts and generate initial tokens, while decode workers handle sequential token generation. The vLLM backend integrates with Dynamo through metrics reporting and KV cache event publishing.
etcd provides distributed service discovery so Dynamo components can locate and communicate with each other, maintaining a registry of active workers and their capabilities.
NATS handles message passing between components, particularly KV cache events — prefill workers publish KV cache information through NATS so the router can make intelligent request-placement decisions.
NIXL (NVIDIA Inter-GPU Exchange Library) manages efficient data transfer between GPUs during disaggregated serving, letting prefill workers transfer KV cache data to decode workers with minimal latency.

1. Clone the Dynamo Repository

NVIDIA Dynamo provides deployment scripts, container utilities, and orchestration modules required to run inference workloads.

1. Clone the repository:

$ git clone https://github.com/ai-dynamo/dynamo.git

2. Navigate to the repository directory:

$ cd dynamo

3. Switch to the latest stable release:

$ git checkout release/0.9.0

Visit the Dynamo releases page to find the latest stable release version.

2. Start Infrastructure Services

Dynamo's distributed architecture relies on etcd for worker registry and service discovery, and NATS for KV cache event propagation between prefill and decode workers. The Docker Compose configuration launches both with exposed ports for client connections (etcd: 2379-2380, NATS: 4222, 6222, 8222). These services must run continuously for Dynamo to coordinate worker resources and route inference requests.

1. Start the infrastructure services:

$ docker compose -f deploy/docker-compose.yml up -d

2. Verify the services are running:

$ docker compose -f deploy/docker-compose.yml ps

The output displays the running etcd and NATS containers:

NAME                   IMAGE                      COMMAND                  SERVICE       CREATED         STATUS         PORTS
deploy-etcd-server-1   bitnamilegacy/etcd:3.6.1   "/opt/bitnami/script…"   etcd-server   6 seconds ago   Up 6 seconds   0.0.0.0:2379-2380->2379-2380/tcp, [::]:2379-2380->2379-2380/tcp
deploy-nats-server-1   nats:2.11.4                "/nats-server -c /et…"   nats-server   6 seconds ago   Up 6 seconds   0.0.0.0:4222->4222/tcp, [::]:4222->4222/tcp, 0.0.0.0:6222->6222/tcp, [::]:6222->6222/tcp, 0.0.0.0:8222->8222/tcp, [::]:8222->8222/tcp

3. Verify CUDA Version and Pull the Container Image

The vLLM container requires a CUDA version match between the host driver and container runtime to prevent GPU kernel incompatibilities.

1. Check the installed CUDA version:

$ nvidia-smi

The output displays the CUDA version in the top-right corner of the table:

+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.95.05              Driver Version: 580.95.05      CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
....

2. Pull the vLLM container image from NGC, matching the image tag to your system's CUDA version:

For CUDA 13.x:

$ docker pull nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.9.0-cuda13

For CUDA 12.x:

$ docker pull nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.9.0

Visit the NVIDIA NGC Catalog to view all available image tags and CUDA versions.

3. (Optional) Build the container from source instead of pulling the pre-built image:

$ ./container/build.sh --framework VLLM

This creates an image named dynamo:latest-vllm. If you use this locally built image, replace nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.9.0-cuda13 with dynamo:latest-vllm in all subsequent commands.

4. Configure Hugging Face Cache Permissions

The container runs as UID 1000 and requires write access to the Hugging Face cache directory for model downloads. Incorrect permissions prevent the container from accessing cached model weights, causing worker initialization failures.

1. Create the cache directory if it does not exist:

$ mkdir -p container/.cache/huggingface

2. Set ownership to the container user (UID 1000):

$ sudo chown -R 1000:1000 container/.cache/huggingface

3. Set appropriate permissions:

$ sudo chmod -R 775 container/.cache/huggingface

5. Deploy Aggregated Serving

Aggregated serving combines prefill and decode phases on a single worker, eliminating inter-GPU KV cache transfers and reducing request latency. This suits single-GPU environments or workloads prioritizing response time over throughput.

1. Export your Hugging Face token to avoid rate limitations when downloading large models (replace YOUR_HF_TOKEN with your actual token):

$ export HF_TOKEN=YOUR_HF_TOKEN

2. Run the vLLM container with GPU access and workspace mounting, using the image tag that matches your CUDA version:

$ ./container/run.sh -it --framework VLLM --mount-workspace --image nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.9.0-cuda13 -e HF_TOKEN=$HF_TOKEN

3. Inside the container, create a custom launch script for aggregated serving with the NVIDIA Nemotron model:

$ cat << 'EOF' > ~/nemotron_agg.sh
#!/bin/bash

set -e
trap 'echo Cleaning up...; kill 0' EXIT

# Set deterministic hash for KV event IDs
export PYTHONHASHSEED=0

# Model configuration - use command line argument or default
MODEL="${1:-nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1}"

echo "Starting Dynamo Frontend..."
python -m dynamo.frontend &

echo "Starting vLLM Worker with model: $MODEL"
DYN_SYSTEM_PORT=${DYN_SYSTEM_PORT:-8081} \
    python -m dynamo.vllm \
    --model "$MODEL" \
    --trust-remote-code \
    --enforce-eager \
    --connector none
EOF

4. Make the script executable:

$ chmod +x ~/nemotron_agg.sh

5. Run the aggregated serving script:

$ ~/nemotron_agg.sh

This starts a frontend service on port 8000 and a vLLM worker that loads the specified model (defaults to NVIDIA Nemotron Nano 4B). To deploy the larger NVIDIA Nemotron Super 49B model instead, pass the model name as an argument:

$ ~/nemotron_agg.sh "nvidia/Llama-3_3-Nemotron-Super-49B-v1_5"

The 49B model requires high-memory GPUs such as B200 or GB200 class devices. Ensure sufficient VRAM and consider tensor parallelism for production deployments.

6. Open a new terminal session on your server (outside the container) and test with a chat completion request:

$ curl -X POST http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
      "model": "nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1",
      "messages": [{"role": "user", "content": "Hello! Tell me about AI."}],
      "max_tokens": 100
    }'

The output displays the model's chat response in JSON format.

6. Deploy Disaggregated Serving

Disaggregated serving assigns prefill and decode phases to separate GPU workers, enabling independent scaling and optimization of each phase. Prefill workers process incoming prompts and transfer KV cache data to decode workers via NIXL. This maximizes throughput by letting multiple decode workers share prefill resources, improving GPU utilization across the cluster.

1. Exit the container if you are still inside from the previous section — press Ctrl+C to terminate the running process, then Ctrl+D to exit.

2. Export your Hugging Face token (replace YOUR_HF_TOKEN with your actual token):

$ export HF_TOKEN=YOUR_HF_TOKEN

3. Run the container with the image tag that matches your CUDA version:

$ ./container/run.sh -it --framework VLLM --mount-workspace --image nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.9.0-cuda13 -e HF_TOKEN=$HF_TOKEN

4. Inside the container, create a custom launch script for disaggregated serving with the NVIDIA Nemotron model:

$ cat << 'EOF' > ~/nemotron_disagg.sh
#!/bin/bash

# Kill any existing processes
pkill -f "dynamo.frontend"
pkill -f "dynamo.vllm"
sleep 2

# Set deterministic hash for KV event IDs
export PYTHONHASHSEED=0

# Model configuration - use command line argument or default
MODEL="${1:-nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1}"

echo "Starting Dynamo Frontend..."
python -m dynamo.frontend &

echo "Starting Decode Workers with model: $MODEL"
# Decode Worker 1 - Uses GPU 0
CUDA_VISIBLE_DEVICES=0 python3 -m dynamo.vllm \
    --model "$MODEL" \
    --trust-remote-code \
    --is-decode-worker \
    --max-model-len 2048 &

# Decode Worker 2 - Uses GPU 1
VLLM_NIXL_SIDE_CHANNEL_PORT=20097 \
CUDA_VISIBLE_DEVICES=1 python3 -m dynamo.vllm \
    --model "$MODEL" \
    --trust-remote-code \
    --is-decode-worker \
    --max-model-len 2048 &

echo "Starting Prefill Workers with model: $MODEL"
# Prefill Worker 1 - Uses GPU 2
CUDA_VISIBLE_DEVICES=2 python3 -m dynamo.vllm \
    --model "$MODEL" \
    --trust-remote-code \
    --is-prefill-worker \
    --max-model-len 2048 \
    --kv-events-config '{"publisher":"zmq","topic":"kv-events","endpoint":"tcp://*:20082","enable_kv_cache_events":true}' &

# Prefill Worker 2 - Uses GPU 3
VLLM_NIXL_SIDE_CHANNEL_PORT=20099 \
CUDA_VISIBLE_DEVICES=3 python3 -m dynamo.vllm \
    --model "$MODEL" \
    --trust-remote-code \
    --is-prefill-worker \
    --max-model-len 2048 \
    --kv-events-config '{"publisher":"zmq","topic":"kv-events","endpoint":"tcp://*:20083","enable_kv_cache_events":true}' &

echo "All services starting... waiting for initialization..."
sleep 30

echo "Deployment ready!"

# Keep script running
wait
EOF

5. Make the script executable:

$ chmod +x ~/nemotron_disagg.sh

6. Run the disaggregated serving script:

$ ~/nemotron_disagg.sh

This starts the frontend service on port 8000, two decode workers on GPUs 0 and 1, and two prefill workers on GPUs 2 and 3 with the specified model (defaults to NVIDIA Nemotron Nano 4B). To deploy the larger NVIDIA Nemotron Super 49B model instead, pass the model name as an argument:

$ ~/nemotron_disagg.sh "nvidia/Llama-3_3-Nemotron-Super-49B-v1_5"

The 49B model requires high-memory GPUs such as B200 or GB200 class devices. Ensure sufficient VRAM and consider tensor parallelism for production deployments.

7. Open a new terminal session on your server (outside the container) and test with multiple sequential requests to observe worker distribution:

$ for i in {1..5}; do
    echo "Request $i:"
    curl -s http://localhost:8000/v1/chat/completions \
      -H "Content-Type: application/json" \
      -d "{
        \"model\": \"nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1\",
        \"messages\": [{\"role\": \"user\", \"content\": \"Test request $i\"}],
        \"max_tokens\": 10
      }" | jq '.id'
    sleep 1
  done

Each request returns a unique ID, and the logs inside the container show which workers process each request.

8. Test with concurrent requests to verify load distribution:

$ for i in {1..10}; do
    curl -s http://localhost:8000/v1/chat/completions \
      -H "Content-Type: application/json" \
      -d "{
        \"model\": \"nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1\",
        \"messages\": [{\"role\": \"user\", \"content\": \"Concurrent test $i\"}],
        \"max_tokens\": 20
      }" &
  done
  wait
  echo "All requests completed"

Dynamo's router distributes the requests across available prefill and decode workers.

Next Steps

Explore KV-aware routing and speculative decoding in the official NVIDIA Dynamo documentation.
Scale the disaggregated deployment to more GPUs or nodes for higher throughput.
Deploy Dynamo on a Kubernetes cluster for production-grade orchestration and autoscaling.
Benchmark aggregated vs. disaggregated serving for your specific model and traffic pattern to choose the right architecture.

For the full guide with additional tips, visit the original article on Vultr Docs.

Deploying a FastAPI Application with Gunicorn and Nginx on Ubuntu 24.04

Sanskriti Harmukh — Thu, 03 Sep 2026 17:18:55 +0000

FastAPI is a modern Python web framework for building high-performance APIs and web applications. It supports asynchronous programming with async/await for handling many simultaneous client connections efficiently, is built on the ASGI standard while remaining compatible with WSGI deployments, and ships with automatic, interactive API documentation via Swagger UI. This guide deploys a FastAPI application using Gunicorn as the application server (with a Uvicorn worker class for ASGI support) and Nginx as a reverse proxy on Ubuntu 24.04, then secures it with a free SSL certificate. By the end, you'll have a FastAPI app running as a systemd-managed Gunicorn service behind Nginx, reachable over HTTPS on your own domain.

Prerequisites: an Ubuntu 24.04 server with non-root sudo access, and a domain A record pointed at the server's IP address with your DNS provider (e.g. fastapi.example.com).

1. Set Up the FastAPI Application

1. Navigate to your home directory:

$ cd ~

2. Create a project directory:

$ mkdir fastapi_demo

3. Move into it:

$ cd fastapi_demo

4. Update the APT package index:

$ sudo apt update

5. Install python3-venv:

$ sudo apt install -y python3-venv

6. Create a virtual environment:

$ python3 -m venv venv

7. Activate it:

$ source venv/bin/activate

8. Install FastAPI with all optional dependencies:

$ pip install fastapi[all] wheel

9. Add the following application code (e.g. to app.py):

from fastapi import FastAPI
app = FastAPI()

@app.get("/")
async def home():
    return {"message": "Hello World"}

Save and close the file.

10. Start a temporary dev server with Uvicorn:

$ uvicorn app:app

11. In a new terminal session, test it:

$ curl http://localhost:8000

Output:

{"message": "Hello World"}

2. Deploy FastAPI Using Gunicorn

Gunicorn is a Python WSGI HTTP server for UNIX systems. It manages your FastAPI application process(es) and supports ASGI through a Uvicorn worker class.

1. Install Gunicorn:

$ pip install gunicorn

2. Start a temporary Gunicorn server with the Uvicorn worker:

$ gunicorn app:app -k uvicorn.workers.UvicornWorker

3. In another session, test it:

$ curl http://localhost:8000

Output:

{"message": "Hello World"}

4. Create a Gunicorn config file:

$ nano gunicorn_conf.py

5. Add the following, adjusting the paths for your setup:

from multiprocessing import cpu_count

# Socket path
bind = 'unix:/home/linuxuser/fastapi_demo/gunicorn.sock'

# Worker options
workers = cpu_count() + 1
worker_class = 'uvicorn.workers.UvicornWorker'

# Logging options
loglevel = 'debug'
accesslog = '/home/linuxuser/fastapi_demo/access_log'
errorlog = '/home/linuxuser/fastapi_demo/error_log'

Save and close the file.

6. Create the systemd unit file:

$ sudo nano /etc/systemd/system/fastapi_demo.service

7. Add the following:

[Unit]
Description=Gunicorn Daemon for FastAPI Demo Application
After=network.target

[Service]
User=linuxuser
Group=www-data
WorkingDirectory=/home/linuxuser/fastapi_demo
ExecStart=/home/linuxuser/fastapi_demo/venv/bin/gunicorn -c /home/linuxuser/fastapi_demo/gunicorn_conf.py app:app

[Install]
WantedBy=multi-user.target

Save and close the file.

8. Reload the systemd daemon:

$ sudo systemctl daemon-reload

9. Enable and start the service:

$ sudo systemctl enable --now fastapi_demo

Output:

Created symlink /etc/systemd/system/multi-user.target.wants/fastapi_demo.service → /etc/systemd/system/fastapi_demo.service.

10. Check its status:

$ sudo systemctl status fastapi_demo

11. Test the socket directly:

$ curl --unix-socket /home/linuxuser/fastapi_demo/gunicorn.sock http://localhost

Output:

{"message":"Hello World"}

3. Set Up Nginx as a Reverse Proxy

Nginx forwards client requests to Gunicorn, serves the app on standard HTTP/HTTPS ports, and can terminate SSL for you.

1. Install Nginx:

$ sudo apt install -y nginx

2. Create a virtual host config file:

$ sudo nano /etc/nginx/sites-available/fastapi_demo

3. Add the following, replacing fastapi.example.com with your actual domain:

server {
    listen 80;
    server_name fastapi.example.com;

    location / {
        proxy_pass http://unix:/home/linuxuser/fastapi_demo/gunicorn.sock;
        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;

        # Optional: Handle WebSocket connections
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeout settings
        proxy_connect_timeout 60s;
        proxy_read_timeout 120s;
    }
}

Save and close the file.

4. Symlink it into sites-enabled/ to activate it:

$ sudo ln -s /etc/nginx/sites-available/fastapi_demo /etc/nginx/sites-enabled/

5. Check the Nginx config syntax:

$ sudo nginx -t

Output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

6. Reload Nginx to apply the change:

$ sudo systemctl reload nginx

7. Allow HTTP/HTTPS through the firewall:

$ sudo ufw allow 'Nginx Full'

8. Verify the firewall rules:

$ sudo ufw status

4. Secure Nginx with an SSL Certificate

Use Certbot to get a free SSL certificate from Let's Encrypt and encrypt traffic to your FastAPI app.

1. Install Certbot and its Nginx plugin:

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

2. Request and install a certificate:

$ sudo certbot --nginx -d fastapi.example.com

Certbot updates your Nginx configuration automatically. When prompted, enter your email address and agree to the terms of service.

3. Confirm HTTPS works by visiting:

https://fastapi.example.com

4. Test automatic renewal:

$ sudo certbot renew --dry-run

If no errors appear, the certificate will renew automatically every 90 days.

Next Steps

Add structured logging and application monitoring around the Gunicorn service
Move secrets and environment-specific config out of source files and into environment variables
Tune the number of Gunicorn workers as traffic grows, or add a caching layer in front of the app
Set up log rotation for the Gunicorn access/error logs defined in gunicorn_conf.py

For the full guide with additional tips, visit the original article on Vultr Docs.

Installing Longhorn on Kubernetes

Sanskriti Harmukh — Thu, 03 Sep 2026 17:18:31 +0000

Longhorn is an open-source, lightweight distributed block storage system for Kubernetes that provides persistent, highly available storage for stateful applications running in a cluster. It runs a CSI driver, an instance manager on every node, a storage engine that replicates data and creates snapshots/backups, and a web UI for managing volumes. This guide walks through installing Longhorn on a Kubernetes cluster, creating ReadWriteOnce (RWO) and ReadWriteMany (RWX) StorageClasses, provisioning and testing PVCs with sample pods, exposing the Longhorn UI externally through an Nginx Ingress controller, and configuring volume backups to S3-compatible object storage. By the end, you'll have Longhorn running as your cluster's distributed storage layer, with tested RWO and RWX volumes, a browser-accessible dashboard, and automated backups to external object storage.

Prerequisites: a Kubernetes cluster with at least 3 nodes (4 vCPUs each), S3-compatible object storage with a bucket (e.g. longhorn) for volume backups, a Linux management workstation with SSH access as a non-root sudo user, and kubectl installed and configured to reach your cluster.

1. Install Longhorn on Kubernetes

You can install Longhorn with Helm or kubectl. The steps below use kubectl with a pinned release manifest.

1. Download the latest Longhorn release manifest:

$ wget https://github.com/longhorn/longhorn/releases/download/v1.6.1/longhorn.yaml

This downloads Longhorn v1.6.1 — check the GitHub repository for the latest version before deploying.

2. Verify the file downloaded:

$ ls

Output:

longhorn.yaml

3. Deploy Longhorn to your cluster:

$ kubectl apply -f longhorn.yaml

A successful install creates CRDs, RBAC roles, services (longhorn-backend, longhorn-frontend, etc.), a longhorn-manager DaemonSet, and longhorn-driver-deployer/longhorn-ui deployments.

4. Verify all Longhorn resources are running in the new longhorn-system namespace:

$ kubectl get all -n longhorn-system

Example output:

NAME                                                    READY   STATUS    RESTARTS      AGE
pod/csi-attacher-57689cc84b-tlzpb                       1/1     Running   0             73s
pod/longhorn-csi-plugin-lp562                           3/3     Running   1 (15s ago)   73s
pod/longhorn-ui-655b65f7f9-lgllp                        1/1     Running   0             98s

NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/longhorn-admission-webhook    ClusterIP   10.100.203.235   <none>        9502/TCP   103s
service/longhorn-backend              ClusterIP   10.110.4.220     <none>        9500/TCP   104s

NAME                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/engine-image-ei-5cefaf2b   3         3         3       3            3           <none>          84s
daemonset.apps/longhorn-csi-plugin        3         3         3       3            3           <none>          74s
daemonset.apps/longhorn-manager           3         3         3       3            3           <none>          100s

5. Install the Longhorn NFS package to enable ReadWriteMany (RWX) volumes:

$ kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.6.1/deploy/prerequisite/longhorn-nfs-installation.yaml

6. Confirm the NFS installation pods are running:

$ kubectl get pods | grep longhorn-nfs-installation

Output:

longhorn-nfs-installation-2kd6d   1/1     Running   0          43s
longhorn-nfs-installation-52kgg   1/1     Running   0          43s
longhorn-nfs-installation-qsst9   1/1     Running   0          43s

2. Create Longhorn Storage Classes

Longhorn ships with a default longhorn StorageClass, but you'll typically create dedicated classes per access mode so PVCs can target the right one.

ReadWriteOnce (RWO) StorageClass

RWO mounts a volume with read-write access on a single pod at a time — suitable for workloads like databases that need consistent writes to a single writer.

1. Create the StorageClass file:

$ nano rwo-storageclass.yaml

2. Add the following configuration:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-prod
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  fromBackup: ""
  fsType: "ext4"
reclaimPolicy: Retain

This creates an expandable StorageClass longhorn-prod with a Retain reclaim policy so the volume survives PVC deletion. Key fields:

provisioner — driver.longhorn.io routes provisioning through the Longhorn engine. A cloud block-storage CSI driver value here instead would create volumes that Longhorn can't manage.
allowVolumeExpansion — lets you grow a volume's capacity later (e.g. 10Gi → 20Gi).
numberOfReplicas — number of Longhorn volume replicas spread across nodes.
staleReplicaTimeout — marks a replica dormant after this many idle minutes.
fromBackup — restores the volume from a backup source (e.g. your object storage bucket).
fsType — filesystem format for the volume.
reclaimPolicy — Delete or Retain behavior when the bound PVC/PV is removed.

3. Apply the StorageClass:

$ kubectl apply -f rwo-storageclass.yaml

4. Verify it's available:

$ kubectl get storageclass

Output:

NAME                                PROVISIONER           RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
longhorn (default)                  driver.longhorn.io    Delete          Immediate           true                   35m
longhorn-prod                       driver.longhorn.io    Retain          Immediate           true                   4s
standard                            block.csi.example.com Delete          Immediate           true                   46m

(The standard row is just an example of a cluster's pre-existing default StorageClass — run kubectl get storageclass on your own cluster and substitute the real name/provisioner it shows.)

ReadWriteMany (RWX) StorageClass

RWX lets multiple pods mount the same volume with read-write access simultaneously.

1. Create the StorageClass file:

$ nano rwx-storageclass.yaml

2. Add the following configuration:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-rwx
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fromBackup: ""
  fsType: "ext4"
  nfsOptions: "vers=4.2,noresvport,softerr,timeo=600,retrans=5,rw,hard"
reclaimPolicy: Retain

This creates the RWX StorageClass longhorn-rwx, which uses Longhorn's NFS share-manager pods to support simultaneous multi-pod read-write access. nfsOptions is the main addition that enables the extra NFS mount options RWX volumes need.

3. Apply the StorageClass:

$ kubectl apply -f rwx-storageclass.yaml

4. Verify it's available:

$ kubectl get storageclass

Output:

NAME                                PROVISIONER           RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
longhorn (default)                  driver.longhorn.io    Delete          Immediate           true                   36m
longhorn-prod                      driver.longhorn.io    Retain          Immediate           true                   46s
longhorn-rwx                        driver.longhorn.io    Retain          Immediate           true                   9s
standard                            block.csi.example.com Delete          Immediate           true                   47m

3. Create Persistent Volume Claims (PVCs)

Longhorn dynamically provisions a volume whenever a PVC references one of its StorageClasses.

ReadWriteOnce (RWO) PVC

1. Create the PVC file:

$ nano rwo-pvc.yaml

2. Add the following configuration:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-rwo
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-prod
  resources:
    requests:
      storage: 10Gi

This creates a PVC test-rwo referencing the longhorn-prod StorageClass, which provisions a 10Gi Longhorn volume once mounted.

3. Apply the PVC:

$ kubectl apply -f rwo-pvc.yaml

4. Verify it's Bound:

$ kubectl get pvc

Output:

NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    VOLUMEATTRIBUTESCLASS   AGE
test-rwo   Bound    pvc-4026f8d2-873c-429b-8068-208b26a75692   10Gi       RWO            longhorn-prod   <unset>                 4s

5. Verify the underlying PV:

$ kubectl get pv

Output:

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS    VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-4026f8d2-873c-429b-8068-208b26a75692   10Gi       RWO            Retain           Bound    default/test-rwo   longhorn-prod   <unset>                          8s

Only a single pod can mount and write to this volume at a time.

ReadWriteMany (RWX) PVC

1. Create the PVC file:

$ nano rwx-pvc.yaml

2. Add the following configuration:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwx-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: longhorn-rwx
  resources:
    requests:
      storage: 20Gi

This creates a PVC rwx-pvc referencing longhorn-rwx, provisioning a 20Gi volume that multiple pods can mount simultaneously.

3. Apply the PVC:

$ kubectl apply -f rwx-pvc.yaml

4. Verify both PVCs are Bound:

$ kubectl get pvc

Output:

NAME       STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    VOLUMEATTRIBUTESCLASS   AGE
rwx-pvc    Bound    pvc-509f254e-255d-4aee-bdc1-8c10c6cc49f5   20Gi       RWX            longhorn-rwx    <unset>                 7s
test-rwo   Bound    pvc-4026f8d2-873c-429b-8068-208b26a75692   10Gi       RWO            longhorn-prod   <unset>                 3m10s

5. Verify the PVs:

$ kubectl get pv

Output:

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS    VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-4026f8d2-873c-429b-8068-208b26a75692   10Gi       RWO            Retain           Bound    default/test-rwo   longhorn-prod   <unset>                          3m31s
pvc-509f254e-255d-4aee-bdc1-8c10c6cc49f5   20Gi       RWX            Retain           Bound    default/rwx-pvc    longhorn-rwx    <unset>                          28s

All pods that mount rwx-pvc can read and write to it at the same time.

4. Test the PVCs

ReadWriteOnce (RWO)

1. Create an Nginx pod that mounts the RWO PVC:

$ nano nginx-rwo-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-webserver
spec:
  containers:
  - name: rwo-container
    image: nginx:latest
    volumeMounts:
    - name: rwo-volume
      mountPath: /data
  volumes:
  - name: rwo-volume
    persistentVolumeClaim:
      claimName: test-rwo

2. Apply it:

$ kubectl apply -f nginx-rwo-pod.yaml

3. Verify the pod is running:

$ kubectl get pods

Output:

NAME                              READY   STATUS    RESTARTS   AGE
nginx-webserver                   1/1     Running   0          41s

4. Open a shell in the pod:

$ kubectl exec -it nginx-webserver -- /bin/bash

root@nginx-webserver:/#

5. Write a test page to the mounted volume:

$ echo "<html><body><h1> Hello World! Nginx Writes to the RWO Longhorn Volume </h1></body></html>" > /usr/share/nginx/html/index.html

6. Confirm Nginx serves it:

$ curl 127.0.0.1

<html><body><h1> Hello World! Nginx Writes to the RWO Longhorn Volume </h1></body></html>

Only this one pod can write to the volume at a time — others could mount it read-only, but not write concurrently.

7. Exit the pod:

$ exit

ReadWriteMany (RWX)

RWX is suited to workloads with separate reader/writer processes needing shared storage.

1. Create a backend pod that writes to the shared volume:

$ nano log-backend.yaml

apiVersion: v1
kind: Pod
metadata:
  name: log-writer
spec:
  containers:
  - name: log-writer-container
    image: busybox:latest
    command: ["/bin/sh", "-c", "while true; do echo $(date) >> /var/log/app.log; sleep 1; done"]
    volumeMounts:
    - name: shared-storage
      mountPath: /var/log
  volumes:
  - name: shared-storage
    persistentVolumeClaim:
      claimName: rwx-pvc

2. Create a second pod that reads from the shared volume:

$ nano log-frontend.yaml

apiVersion: v1
kind: Pod
metadata:
  name: log-viewer
spec:
  containers:
  - name: log-reader-container
    image: busybox:latest
    command: ["/bin/sh", "-c", "tail -f /var/log/app.log"]
    volumeMounts:
    - name: shared-storage
      mountPath: /var/log
  volumes:
  - name: shared-storage
    persistentVolumeClaim:
      claimName: rwx-pvc

3. Create a second writer pod to prove concurrent writes work:

$ nano updatelog-backend.yaml

apiVersion: v1
kind: Pod
metadata:
  name: updatelog
spec:
  containers:
  - name: log-writer-container
    image: busybox:latest
    command: ["/bin/sh", "-c", "while true; do echo Update from backend pod $(date) >> /var/log/app.log; sleep 1; done"]
    volumeMounts:
    - name: shared-storage
      mountPath: /var/log
  volumes:
  - name: shared-storage
    persistentVolumeClaim:
      claimName: rwx-pvc

4. Apply all three pods:

$ kubectl apply -f log-backend.yaml

$ kubectl apply -f log-frontend.yaml

$ kubectl apply -f updatelog-backend.yaml

5. Verify all three are running:

$ kubectl get pods

Output:

NAME                              READY   STATUS    RESTARTS      AGE
log-viewer                        1/1     Running   1 (37s ago)   59s
log-writer                        1/1     Running   0             64s
updatelog                         1/1     Running   0             51s

6. Confirm both writers are hitting the shared log:

$ kubectl logs log-viewer

Output:

Update from backend pod Tue Apr 30 18:48:19 UTC 2024
Tue Apr 30 18:48:20 UTC 2024
Update from backend pod Tue Apr 30 18:48:20 UTC 2024
Tue Apr 30 18:48:21 UTC 2024

Both log-writer and updatelog write concurrently while log-viewer reads — confirming RWX lets multiple pods share the same volume at once.

5. Configure Longhorn for External Access

Expose the Longhorn UI through an Nginx Ingress controller.

1. Install the Nginx Ingress Controller:

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.1/deploy/static/provider/cloud/deploy.yaml

2. Verify the controller pod is running:

$ kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx

Output:

NAMESPACE       NAME                                        READY   STATUS      RESTARTS   AGE
ingress-nginx   ingress-nginx-admission-create-n2gvf        0/1     Completed   0          98s
ingress-nginx   ingress-nginx-admission-patch-vqfhn         0/1     Completed   0          98s
ingress-nginx   ingress-nginx-controller-57b7568757-ctk5z   1/1     Running     0          99s

3. Wait a few minutes for the controller's LoadBalancer service to get an external IP, then check it:

$ kubectl get services ingress-nginx-controller --namespace=ingress-nginx

Output:

NAME                       TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                      AGE
ingress-nginx-controller   LoadBalancer   10.106.252.171   203.0.113.5   80:30886/TCP,443:32107/TCP   4m25s

The EXTERNAL-IP is your load balancer's public IP — point a DNS A record at it with your DNS provider. (Some cloud providers require a provider-specific annotation on the Ingress controller's Service before it provisions a load balancer — check your provider's docs if EXTERNAL-IP stays <pending>.)

4. Create an Ingress resource file:

$ nano longhorn-ingress.yaml

5. Add the following, replacing longhorn.example.com with your actual domain:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: longhorn-production44
  namespace: longhorn-system
spec:
  ingressClassName: nginx
  rules:
  - host: longhorn.example.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: longhorn-frontend
            port:
              number: 80

6. Apply the Ingress:

$ kubectl apply -f longhorn-ingress

7. Verify it's configured:

$ kubectl get ingress

Output:

NAME                    CLASS   HOSTS                ADDRESS          PORTS   AGE
longhorn-production   nginx   longhorn.example.com  203.0.113.5      80      2m20s

6. Access the Longhorn UI

1. Open your domain in a browser:

http://longhorn.example.com

Review your cluster's volumes, nodes, and storage summary on the dashboard.
Click Volume in the top navigation to view all Longhorn volumes and confirm your RWO and RWX volumes show a healthy state.
Click any volume to see replica count, snapshots, and backups.
From the volumes list, click Create Volume to provision a new one from the UI — enter the details and use the Access Mode dropdown to pick ReadWriteOnce or ReadWriteMany.
Click OK, then select the new volume and click Attach to assign it to a worker node with enough free space; pick the node from the Node dropdown and click Attach.
Confirm the volume shows a healthy state with Attached To set to your chosen node.

7. Back Up Longhorn Volumes to Object Storage

Longhorn backups work with any S3-compatible object storage for recovery or disaster-recovery volume creation.

Get the Hostname, Access Key, and Secret Key for your object storage instance.

1. Create a Secret file for your object storage credentials:

$ nano objectstorage-secret.yaml

2. Add the following, replacing examplekey, examplesecret, and your-s3-endpoint with your real credentials:

apiVersion: v1
kind: Secret
metadata:
  name: longhorn-backup-secret
  namespace: longhorn-system
type: Opaque
stringData:
  AWS_ACCESS_KEY_ID: examplekey
  AWS_ENDPOINTS: https://your-s3-endpoint
  AWS_SECRET_ACCESS_KEY: examplesecret

3. Apply the Secret:

$ kubectl apply -f objectstorage-secret.yaml

4. Verify it exists:

$ kubectl get secrets -n longhorn-system

Output:

NAME                      TYPE                DATA   AGE
longhorn-backup-secret    Opaque              3      35s

5. In the Longhorn UI, go to Setting → General, scroll to Backup, and set the Backup Target to your bucket's S3 URI:

s3://example-bucket@your-s3-endpoint/

6. Enter your Secret's name (longhorn-backup-secret) in the Backup Target Credential Secret field, then press Enter to save.

Click Volume, select a target volume (e.g. test-volume), and click Create Backup.
Add a label if desired (e.g. longhorn-backup / latest-backup), then wait for the backup to complete.
Click Backup in the main navigation to confirm the new backup is listed.
Check your object storage bucket for a new backupstore directory containing the backup objects.

Once backups are running, use Recurring Job in the Longhorn UI to automate them going forward.

Next Steps

Set up a Longhorn Recurring Job to automate volume backups on a schedule
Deploy stateful workloads (databases, queues) using the RWO or RWX StorageClasses you created
Monitor volume and replica health from the Longhorn UI dashboard
Test a disaster-recovery restore from your object storage backups to confirm your recovery process works

For the full guide with additional tips, visit the original article on Vultr Docs.

Installing FreeRADIUS with PostgreSQL

Sanskriti Harmukh — Thu, 03 Sep 2026 17:18:02 +0000

FreeRADIUS is a popular open-source RADIUS (Remote Authentication Dial-In User Service) application for managing network access through user authentication, authorization, and accounting (AAA) services. It integrates with database engines such as PostgreSQL for centralized user management. This guide installs FreeRADIUS, configures it to use PostgreSQL as its backend database, loads the RADIUS schema, and authenticates a test user against the database to create a reliable RADIUS solution. By the end, you'll have FreeRADIUS running with a PostgreSQL-backed user store, verified with a live authentication test.

Prerequisites: an Ubuntu 24.04 server with a non-root sudo user, SSH access to the instance, and PostgreSQL already installed.

Install FreeRADIUS

FreeRADIUS is available in the default Ubuntu package repositories.

1. Install FreeRADIUS and the PostgreSQL plugin:

$ sudo apt-get install freeradius freeradius-postgresql

2. Check the installed version:

$ freeradius -v

Output:

radiusd: FreeRADIUS Version 3.2.3, for host x86_64-pc-linux-gnu, built on Mar 31 2024 at 05:22:45
FreeRADIUS Version 3.2.3
Copyright (C) 1999-2022 The FreeRADIUS server project and contributors
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License
For more information about these matters, see the file named COPYRIGHT

Configure the PostgreSQL Database Schema for FreeRADIUS

FreeRADIUS requires a specific schema to work with a database server like PostgreSQL.

1. Create a new schema file:

$ sudo touch /etc/freeradius_schema.sql

2. Edit the file:

$ sudo nano /etc/freeradius_schema.sql

3. Add the following database schema to the file:

/*
*
* PostgreSQL schema for FreeRADIUS
*
*/

/*
* Table structure for table 'radacct'
*
*/
CREATE TABLE IF NOT EXISTS radacct (
       RadAcctId               bigserial PRIMARY KEY,
       AcctSessionId           text NOT NULL,
       AcctUniqueId            text NOT NULL UNIQUE,
       UserName                text,
       Realm                   text,
       NASIPAddress            inet NOT NULL,
       NASPortId               text,
       NASPortType             text,
       AcctStartTime           timestamp with time zone,
       AcctUpdateTime          timestamp with time zone,
       AcctStopTime            timestamp with time zone,
       AcctInterval            bigint,
       AcctSessionTime         bigint,
       AcctAuthentic           text,
       ConnectInfo_start       text,
       ConnectInfo_stop        text,
       AcctInputOctets         bigint,
       AcctOutputOctets        bigint,
       CalledStationId         text,
       CallingStationId        text,
       AcctTerminateCause      text,
       ServiceType             text,
       FramedProtocol          text,
       FramedIPAddress         inet,
       FramedIPv6Address       inet,
       FramedIPv6Prefix        inet,
       FramedInterfaceId       text,
       DelegatedIPv6Prefix     inet,
       Class                   text
);

-- For use by update-, stop- and simul_* queries
CREATE INDEX radacct_active_session_idx ON radacct (AcctUniqueId) WHERE AcctStopTime IS NULL;

-- For use by on-off-
CREATE INDEX radacct_bulk_close ON radacct (NASIPAddress, AcctStartTime) WHERE AcctStopTime IS NULL;

-- and for common statistic queries:
CREATE INDEX radacct_start_user_idx ON radacct (AcctStartTime, UserName);

-- and for Class
CREATE INDEX radacct_calss_idx ON radacct (Class);


/*
* Table structure for table 'radcheck'
*/
CREATE TABLE IF NOT EXISTS radcheck (
       id                      serial PRIMARY KEY,
       UserName                text NOT NULL DEFAULT '',
       Attribute               text NOT NULL DEFAULT '',
       op                      VARCHAR(2) NOT NULL DEFAULT '==',
       Value                   text NOT NULL DEFAULT ''
);

create index radcheck_UserName on radcheck (UserName,Attribute);

/*
* Table structure for table 'radgroupcheck'
*/
CREATE TABLE IF NOT EXISTS radgroupcheck (
       id                      serial PRIMARY KEY,
       GroupName               text NOT NULL DEFAULT '',
       Attribute               text NOT NULL DEFAULT '',
       op                      VARCHAR(2) NOT NULL DEFAULT '==',
       Value                   text NOT NULL DEFAULT ''
);

create index radgroupcheck_GroupName on radgroupcheck (GroupName,Attribute);

/*
* Table structure for table 'radgroupreply'
*/
CREATE TABLE IF NOT EXISTS radgroupreply (
       id                      serial PRIMARY KEY,
       GroupName               text NOT NULL DEFAULT '',
       Attribute               text NOT NULL DEFAULT '',
       op                      VARCHAR(2) NOT NULL DEFAULT '=',
       Value                   text NOT NULL DEFAULT ''
);

create index radgroupreply_GroupName on radgroupreply (GroupName,Attribute);

/*
* Table structure for table 'radreply'
*/
CREATE TABLE IF NOT EXISTS radreply (
       id                      serial PRIMARY KEY,
       UserName                text NOT NULL DEFAULT '',
       Attribute               text NOT NULL DEFAULT '',
       op                      VARCHAR(2) NOT NULL DEFAULT '=',
       Value                   text NOT NULL DEFAULT ''
);

create index radreply_UserName on radreply (UserName,Attribute);

/*
* Table structure for table 'radusergroup'
*/
CREATE TABLE IF NOT EXISTS radusergroup (
       id                      serial PRIMARY KEY,
       UserName                text NOT NULL DEFAULT '',
       GroupName               text NOT NULL DEFAULT '',
       priority                integer NOT NULL DEFAULT 0
);

create index radusergroup_UserName on radusergroup (UserName);

--
-- Table structure for table 'radpostauth'
--

CREATE TABLE IF NOT EXISTS radpostauth (
       id                      bigserial PRIMARY KEY,
       username                text NOT NULL,
       pass                    text,
       reply                   text,
       CalledStationId         text,
       CallingStationId        text,
       authdate                timestamp with time zone NOT NULL default now(),
       Class                   text
);

CREATE INDEX radpostauth_username_idx ON radpostauth (username);
CREATE INDEX radpostauth_class_idx ON radpostauth (Class);

/*
* Table structure for table 'nas'
*/
CREATE TABLE IF NOT EXISTS nas (
       id                      serial PRIMARY KEY,
       nasname                 text NOT NULL,
       shortname               text NOT NULL,
       type                    text NOT NULL DEFAULT 'other',
       ports                   integer,
       secret                  text NOT NULL,
       server                  text,
       community               text,
       description             text
);

create index nas_nasname on nas (nasname);

/*
* Table structure for table 'nasreload'
*/
CREATE TABLE IF NOT EXISTS nasreload (
       NASIPAddress     inet PRIMARY KEY,
       ReloadTime       timestamp with time zone NOT NULL
);

Save and close the file. This schema creates the following tables: radcheck (user-specific authentication attributes), radreply (reply attributes after successful authentication), radgroupcheck and radgroupreply (group-specific variants), radusergroup (maps users to groups), radacct (accounting records), radpostauth (authentication attempt logs), nas (Network Access Server records), and nasreload (dynamic NAS config reloads).

4. Access the PostgreSQL console as the postgres user:

$ sudo -u postgres psql

5. Set a password for the postgres user:

postgres=#  ALTER USER postgres WITH ENCRYPTED PASSWORD 'radpass';

6. Exit the PostgreSQL console:

postgres=# \q

7. Create a new freeradius database:

$ sudo -u postgres createdb freeradius

8. Enable password authentication on the database server (replace 17 with your actual PostgreSQL version):

$ sudo sed -i '/^local/s/peer/scram-sha-256/' /etc/postgresql/17/main/pg_hba.conf

9. Import the schema file into the freeradius database:

$ sudo -u postgres psql -d freeradius -f /etc/freeradius_schema.sql

Output:

CREATE TABLE
CREATE INDEX
...

10. Log in to the freeradius database:

$ sudo -u postgres psql -d freeradius

11. Verify all FreeRADIUS tables are available:

freeradius=# \dt

Output:

             List of relations
 Schema |     Name      | Type  |  Owner   
--------+---------------+-------+----------
 public | nas           | table | postgres
 public | nasreload     | table | postgres
 public | radacct       | table | postgres
 public | radcheck      | table | postgres
 public | radgroupcheck | table | postgres
 public | radgroupreply | table | postgres
 public | radpostauth   | table | postgres
 public | radreply      | table | postgres
 public | radusergroup  | table | postgres
(9 rows)

12. Create a sample user in the radcheck table (username kiki, password 1234):

freeradius=# INSERT INTO radcheck (UserName, Attribute, op, Value)
VALUES ('kiki', 'Cleartext-Password', ':=', '1234');

13. Query the radcheck table to view the record:

freeradius=# SELECT * FROM radcheck WHERE UserName = 'kiki';

Output:

id | username  | attribute           | op  | value
----+----------+--------------------+-----+------
 1 | kiki      | Cleartext-Password  | :=  | 1234

14. Create a test server entry in the nas table:

freeradius=# INSERT INTO nas (nasname, shortname, type, ports, secret, community, description)
VALUES ('127.0.0.1', 'localhost', 'other', 0, 'testing123', NULL, 'Local NAS for testing');

15. Query the nas table to verify the entry:

freeradius=# SELECT * FROM nas WHERE nasname = '127.0.0.1';

Output:

 id | nasname    | shortname | type  | ports | secret     | community | description
----+------------+-----------+-------+-------+------------+-----------+-----------------------
  1 | 127.0.0.1  | localhost | other | 0     | testing123 |           | Local NAS for testing

16. Exit the PostgreSQL console:

freeradius=# \q

Configure FreeRADIUS to Use PostgreSQL

1. Enable the FreeRADIUS SQL module by symlinking it into mods-enabled:

$ sudo ln -s /etc/freeradius/3.0/mods-available/sql /etc/freeradius/3.0/mods-enabled/

2. Open the default site configuration file:

$ sudo nano /etc/freeradius/3.0/sites-available/default

3. Find the -sql directive and remove the leading - to enable it:

#  See "Authorization Queries" in mods-available/sql
-sql

4. Open the inner-tunnel site configuration file:

$ sudo nano /etc/freeradius/3.0/sites-available/inner-tunnel

5. Find the following SQL directives and remove the leading - or # to enable each one:

#  See "Simultaneous Use Checking Queries" in `mods-config/sql/main/$driver/queries.>
#       sql

#  See "Authentication Logging Queries" in `mods-config/sql/main/$driver/queries.con>
-sql

Save and close the file.

6. Open the sql module configuration file:

$ sudo nano /etc/freeradius/3.0/mods-available/sql

7. Change dialect from SQLite to PostgreSQL:

dialect = "postgresql"

8. Change driver from rlm_sql_null to rlm_sql_${dialect}:

driver = "rlm_sql_${dialect}"

9. Uncomment the database connection section and enter your PostgreSQL connection details:

# Connection info:
server = "localhost"
port = 5432
login = "postgres"
password = "radpass"

10. Change radius_db from radius to the database you created earlier:

radius_db = "freeradius"

11. Uncomment read_clients so FreeRADIUS reads client details from the nas table:

read_clients = yes

Save and close the file.

Test the FreeRADIUS Integration with PostgreSQL

Authenticate against the local server with the test user created earlier to confirm FreeRADIUS is reading correctly from the database.

1. Stop the FreeRADIUS system service:

$ sudo service freeradius stop

2. Start FreeRADIUS in debugging mode as a background process:

$ sudo /usr/sbin/freeradius -X &

Output:

Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel
Listening on auth address * port 1812 bound to server default
Listening on acct address * port 1813 bound to server default
Listening on auth address :: port 1812 bound to server default
Listening on acct address :: port 1813 bound to server default
Listening on proxy address * port 49424
Listening on proxy address :: port 46803
Ready to process requests

If you get an error like the following (address already in use):

Failed binding to auth address 127.0.0.1 port 18120 bound to server inner-tunnel: Address already in 
use /etc/freeradius/sites-enabled/inner-tunnel[33]: Error binding to port for 127.0.0.1 port 18120

Find and stop the existing FreeRADIUS process, then start it again:

$ sudo ps aux | grep radius

Output:

freerad     9374  0.0  3.0  98528 30080 ?        Ssl  06:43   0:00 /usr/sbin/freeradius -f
root       23698  0.0  0.2   7076  2048 pts/0    S+   16:33   0:00 grep --color=auto radius

$ kill-9 9374

$ sudo /usr/sbin/freeradius -X

3. Authenticate as the test user with radtest:

$ radtest kiki 1234 localhost 0 testing123

Output:

Sent Access-Request Id 36 from 0.0.0.0:a668 to 127.0.0.1:1812 length 74
 User-Name = "kiki"
 User-Password = "1234"
 NAS-IP-Address = 127.0.1.1
 NAS-Port = 0
 Message-Authenticator = 0x00
 Cleartext-Password = "1234"
Received Access-Accept Id 36 from 127.0.0.1:714 to 127.0.0.1:42600 length 20

The Received Access-Accept... response confirms you've successfully authenticated against the server.

Next Steps

Use the radgroupcheck and radgroupreply tables for group-based access control, such as restricting bandwidth or session limits per group
Add real Network Access Servers (NAS) to the nas table for production RADIUS clients
Review accounting data in the radacct table to track session usage
Consult the FreeRADIUS documentation for advanced configuration options

For the full guide with additional tips, visit the original article on Vultr Docs.

Installing K3s with NVIDIA GPU Operator on Ubuntu 22.04

Sanskriti Harmukh — Thu, 03 Sep 2026 17:17:33 +0000

K3s is a lightweight, fully compliant Kubernetes distribution designed for simplified deployment and operation in resource-constrained environments. With a small memory footprint and a single-binary architecture, K3s is optimized for edge computing, IoT devices, and environments where a traditional Kubernetes setup would be too resource-intensive. It strips out non-essential features and dependencies, making it faster and easier to install while retaining all core Kubernetes functionality. This guide installs and configures K3s on a GPU-enabled Ubuntu 22.04 server, configures Kubernetes with Helm, sets up firewall rules for external cluster access, and installs the NVIDIA GPU Operator to manage GPU resources within K3s for optimized GPU workloads. By the end, you'll have a lightweight Kubernetes cluster with GPU scheduling ready for production workloads.

Prerequisites: a GPU-enabled server (with an NVIDIA GPU and its driver already installed) running Ubuntu 22.04, accessed over SSH as a non-root user with sudo privileges.

Install K3s and the NVIDIA GPU Operator

1. Disable the Docker system service:

$ sudo systemctl disable docker

2. Stop the Docker system service:

$ sudo systemctl stop docker

3. View the Docker service status and verify it's inactive:

$ sudo systemctl status docker

Output:

○ docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; disabled; vendor preset: enabled)
     Active: inactive (dead) since Wed 2024-11-06 20:45:17 UTC; 5s ago
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
    Process: 1088 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=0/SUCCESS)
   Main PID: 1088 (code=exited, status=0/SUCCESS)
        CPU: 404ms

4. Install K3s:

$ curl -sfL https://get.k3s.io | sh -

Output:

[INFO]  env: Creating environment file /etc/systemd/system/k3s.service.env
[INFO]  systemd: Creating service file /etc/systemd/system/k3s.service
[INFO]  systemd: Enabling k3s unit
Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.
[INFO]  systemd: Starting k3s

5. Create a .kube directory in your home directory (replace linuxuser with your actual user):

$ mkdir -p /home/linuxuser/.kube

6. Symlink the K3s config as the default kubeconfig so kubectl and other CLI tools can find it:

$ ln -s /etc/rancher/k3s/k3s.yaml /home/linuxuser/.kube/config

7. Change the config file's permissions to 755 so Helm can read it:

$ sudo chmod 755 /home/linuxuser/.kube/config

8. Install Helm to manage Kubernetes applications:

$ curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

9. Add the NVIDIA Helm repository:

$ helm repo add nvidia https://helm.ngc.nvidia.com/nvidia && helm repo update

This adds the NVIDIA Helm chart repository (which contains the GPU Operator and other NVIDIA tools for Kubernetes) and refreshes Helm's local repository cache.

10. Install the NVIDIA GPU Operator:

$ helm install --wait gpu-operator nvidia/gpu-operator --create-namespace -n gpu-operator --set driver.enabled=false

This installs the GPU Operator into a new gpu-operator namespace and skips the bundled NVIDIA driver installation (--set driver.enabled=false) since the driver is already installed on the host.

11. Add the required firewall rules:

$ sudo ufw allow 6443/tcp && sudo ufw allow 30000:32767/tcp && sudo ufw allow 30000:32767/udp

12. Enable the K3s system service so it starts on boot:

$ sudo systemctl enable k3s

13. View the K3s service status and verify it's running:

$ sudo systemctl status k3s

Output:

● k3s.service - Lightweight Kubernetes
 Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: enabled)
 Active: active (running) since Wed 2024-11-06 20:45:47 UTC; 7min ago
   Docs: https://k3s.io
Main PID: 2883 (k3s-server)
  Tasks: 206
 Memory: 3.9G
    CPU: 1min 19.382s
 CGroup: /system.slice/k3s.service
 ...................................

Next Steps

Deploy a CUDA-enabled workload or sample pod to confirm the GPU Operator schedules pods onto the GPU correctly
Add a StorageClass for persistent workloads — run kubectl get storageclass and substitute your cloud provider's actual StorageClass name
If you expose services externally with a LoadBalancer, note that some cloud providers require a provider-specific LoadBalancer annotation
Install kubectl and NVIDIA's DCGM exporter to monitor GPU utilization across the cluster

For the full guide with additional tips, visit the original article on Vultr Docs.

Installing Mosquitto MQTT Broker on Ubuntu 24.04

Sanskriti Harmukh — Thu, 03 Sep 2026 17:17:04 +0000

Mosquitto is an open-source message broker implementing the MQTT (Message Queuing Telemetry Transport) protocol — a lightweight TCP/IP messaging platform built for IoT devices with minimal resources, such as low bandwidth or short battery life. It relies on a publish-subscribe (pub/sub) topology, where publishers send messages to the broker and subscribers receive them through a channel. This guide installs Mosquitto on Ubuntu 24.04, manages it as a systemd service, tests pub/sub messaging with the Mosquitto CLI clients, and secures the broker with password authentication. By the end, you'll have a password-protected Mosquitto MQTT broker ready for IoT messaging.

Prerequisites: an Ubuntu 24.04 server, a non-root user with sudo privileges, and an updated system.

Install Mosquitto MQTT Broker

Mosquitto is available in the default Ubuntu 24.04 package repositories.

1. Install the Mosquitto package:

$ sudo apt install -y mosquitto

2. Verify the installed version:

$ mosquitto -v

Output:

1730087147: mosquitto version 2.0.18 starting
1730087147: Using default config.
1730087147: Starting in local only mode. Connections will only be possible from clients running on this machine.
1730087147: Create a configuration file which defines a listener to allow remote access.

Manage the Mosquitto System Service

Mosquitto runs as a system service under mosquitto.

1. View the service status:

$ sudo systemctl status mosquitto

Output:

● mosquitto.service - Mosquitto MQTT Broker
 Loaded: loaded (/usr/lib/systemd/system/mosquitto.service; enabled; preset: enabl>
 Active: active (running) since Fri 2024-10-25 06:51:37 UTC; 12min ago
   Docs: man:mosquitto.conf(5)
      man:mosquitto(8)
...

2. Stop the service:

$ sudo systemctl stop mosquitto

3. Start the service:

$ sudo systemctl start mosquitto

4. Restart the service:

$ sudo systemctl restart mosquitto

Install and Test the Mosquitto Clients

Publishers and subscribers connect to a Mosquitto server and exchange messages using the Mosquitto command-line interface.

1. Install the mosquitto-clients package:

$ sudo apt install -y mosquitto-clients

2. Subscribe to a topic as a background process:

$ mosquitto_sub -t "home/sensor/temperature" &

Output:

23.5

3. Publish a message to the topic:

$ mosquitto_pub -t "home/sensor/temperature" -m "30.5" -q 1 -r

Output:

30.5
30.5

4. Publish another message:

$ mosquitto_pub -t "home/sensor/temperature" -m "45.2" -q 1 -r

Output:

45.2
45.2

5. View active background jobs and note the mosquitto_sub job ID:

$ jobs

Output:

[1]   Running                 mosquitto_sub -t "home/lights/sitting_room" &

6. Stop the job by specifying its ID:

$ kill %1

Output:

[1]   Done                    mosquitto_sub -t "home/lights/sitting_room" &

Secure the Mosquitto Server

By default, Mosquitto allows clients to connect without any authentication. Enable password-based authentication so clients must connect with a username and password.

1. Create a new configuration file:

$ sudo nano /etc/mosquitto/conf.d/default.conf

2. Add the following to disable anonymous connections and point Mosquitto at the credentials file:

allow_anonymous false
password_file /etc/mosquitto/passwd

Save and close the file.

3. Open the password file:

$ sudo nano /etc/mosquitto/passwd

4. Add user credentials (replace EXAMPLE_PASSWORD and STRONG_PASSWORD with your own values):

john_doe:EXAMPLE_PASSWORD
mary_smith:STRONG_PASSWORD

Save and close the file.

5. Encrypt the plaintext passwords:

$ sudo mosquitto_passwd -U /etc/mosquitto/passwd

6. Verify the passwords are encrypted:

$ sudo cat /etc/mosquitto/passwd

Output:

john_doe:$6$TSzNycsj...5Qyvgd4g==
mary_smith:$6$DtlKf1lG.../rLHIL0Q==

7. Restart Mosquitto to apply the changes:

$ sudo systemctl restart mosquitto

8. Subscribe using a valid username and password:

$ mosquitto_sub -u john_doe -P EXAMPLE_PASSWORD -t "/home/sensor/temperature"

9. Publish a message using valid credentials:

$ mosquitto_pub -u john_doe -P EXAMPLE_PASSWORD -t "home/sensor/temperature" -m "22.5" -q 1 -r

Output:

22.5

10. View active background jobs and note the job ID:

$ jobs

Output:

[1]   Running                 mosquitto_sub -u john_doe -P EXAMPLE_PASSWORD -t "home/lights/sitting_room" &

11. Stop the job by specifying its ID:

$ kill %1

Output:

[1]   Done                    mosquitto_sub -u john_doe -P EXAMPLE_PASSWORD -t "home/lights/sitting_room" &

12. Confirm authentication is enforced by trying incorrect credentials:

$ mosquitto_pub -u john_doe -P VERY_WRONG_PASSWORD -t "home/sensor/temperature" -m "22.5" -q 1 -r

Output:

Connection error: Connection Refused: not authorised.
Error: The connection was refused.

The connection fails because Mosquitto can't authorize the user.

Next Steps

Integrate Mosquitto with a programming language like Python, PHP, Ruby, or Go to build IoT applications
Add TLS encryption to secure MQTT traffic in transit
Configure per-topic ACLs to restrict which clients can publish or subscribe to specific topics
Monitor broker health and traffic using Mosquitto's $SYS topics

For the full guide with additional tips, visit the original article on Vultr Docs.

Installing Apache Tomcat on Ubuntu 24.04

Sanskriti Harmukh — Thu, 03 Sep 2026 17:16:35 +0000

Apache Tomcat is an open-source web server application that lets developers run Java applications in a secure, efficient environment. It implements the Java Servlet and JavaServer Pages (JSP) specifications to deploy and manage Java-based web applications, and it supports load balancing, clustering, and high availability for different workloads. This guide installs Apache Tomcat on Ubuntu 24.04, secures it with a trusted SSL certificate, and deploys a sample Java web application. By the end, you'll have a working Apache Tomcat server running dynamic web applications over HTTPS.

Prerequisites

An Ubuntu 24.04 server with a non-root user configured for SSH access with sudo privileges.
A domain A record with your DNS provider pointing to the server's IP address (for example, tomcat.example.com).
SSH access to the server.
The server's package index already updated.

Install Java OpenJDK

Apache Tomcat requires JDK version 17 or later.

1. Install OpenJDK 17:

$ sudo apt install openjdk-17-jdk -y

2. View the installed Java version:

$ java -version

Output:

openjdk version "17.0.13" 2024-10-15
OpenJDK Runtime Environment (build 17.0.13+11-Ubuntu-2ubuntu124.04)
OpenJDK 64-Bit Server VM (build 17.0.13+11-Ubuntu-2ubuntu124.04, mixed mode, sharing)

3. Create a new tomcat group to use with the Apache Tomcat service:

$ sudo groupadd tomcat

4. Create a new tomcat user with /opt/tomcat as the home directory and membership in the tomcat group:

$ sudo useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat

Install Apache Tomcat

Apache Tomcat isn't available in the default Ubuntu package repositories, so download the release archive directly.

1. Visit the Apache Tomcat releases page and download the latest Apache Tomcat 11 release file:

$ wget -O tomcat.tar.gz https://dlcdn.apache.org/tomcat/tomcat-11/v11.0.1/bin/apache-tomcat-11.0.1.tar.gz

This downloads Tomcat release version 11.0.1. Check the releases page for the latest version before downloading.

2. Create a tomcat directory in a system-wide location such as /opt:

$ sudo mkdir /opt/tomcat

3. Extract the downloaded archive into /opt/tomcat:

$ sudo tar -xvzf tomcat.tar.gz -C /opt/tomcat --strip-components=1

The --strip-components=1 option removes the top-level directory in the archive so the contents land directly in /opt/tomcat.

4. Remove the downloaded archive to free up disk space:

$ sudo rm -rf tomcat.tar.gz

5. Grant the tomcat user and group ownership of /opt/tomcat:

$ sudo chown -R tomcat:tomcat /opt/tomcat

6. Grant the tomcat group read privileges to the conf directory:

$ sudo chmod -R g+r /opt/tomcat/conf

7. Grant the tomcat group execute permissions on the /opt/tomcat/conf directory:

$ sudo chmod g+x /opt/tomcat/conf

Create Apache Tomcat Users

Apache Tomcat requires dedicated accounts with administrative privileges to access the manager and host-manager web applications.

1. Open the tomcat-users.xml configuration file:

$ sudo nano /opt/tomcat/conf/tomcat-users.xml

2. Add the following above the </tomcat-users> directive. Replace manager_password and admin_password with your own values:

<role rolename="manager-gui" />
<user username="manager" password="manager_password" roles="manager-gui" />

<role rolename="admin-gui" />
<user username="admin" password="admin_password" roles="manager-gui,admin-gui" />

Save and close the file. This creates a manager user and an admin user with manager and administrator privileges respectively for the Tomcat web management dashboard.

3. Open the manager context.xml file to remove restrictions on the manager application:

$ sudo nano /opt/tomcat/webapps/manager/META-INF/context.xml

4. Comment out the following Valve directive:

<!--  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
         allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" /> -->

Save and close the file.

5. Open the host-manager context.xml file to remove restrictions on the host-manager application:

$ sudo nano /opt/tomcat/webapps/host-manager/META-INF/context.xml

6. Comment out the same Valve directive:

<!--  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
         allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />  -->

Save and close the file.

Set Up Apache Tomcat as a System Service

1. View and note the Java installation path:

$ sudo update-java-alternatives -l

Output:

java-1.17.0-openjdk-amd64      1711       /usr/lib/jvm/java-1.17.0-openjdk-amd64

2. Create a new tomcat.service system service file:

$ sudo nano /etc/systemd/system/tomcat.service

3. Add the following configuration. Modify JAVA_HOME if your Java installation path differs:

[Unit]
Description=Tomcat
After=network.target

[Service]
Type=forking

User=tomcat
Group=tomcat

Environment="JAVA_HOME=/usr/lib/jvm/java-1.17.0-openjdk-amd64"
Environment="JAVA_OPTS=-Djava.security.egd=file:///dev/urandom"
Environment="CATALINA_BASE=/opt/tomcat"
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid"
Environment="CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC"

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh

RestartSec=10
Restart=always

[Install]
WantedBy=multi-user.target

Save and close the file. This service runs the startup.sh and shutdown.sh scripts in the Tomcat installation directory to manage the application's processes.

4. Reload the systemd daemon:

$ sudo systemctl daemon-reload

5. Enable the Apache Tomcat service to start at boot:

$ sudo systemctl enable tomcat

6. Start the Apache Tomcat service:

$ sudo systemctl start tomcat

7. View the Apache Tomcat service status and verify that it's running:

$ sudo systemctl status tomcat

Output:

● tomcat.service - Tomcat
     Loaded: loaded (/etc/systemd/system/tomcat.service; enabled; preset: enabled)
     Active: active (running) since Thu 2024-12-05 12:12:25 UTC; 6s ago
    Process: 12213 ExecStart=/opt/tomcat/bin/startup.sh (code=exited, status=0/SUCCESS)
   Main PID: 12220 (java)
      Tasks: 31 (limit: 2269)
     Memory: 112.5M (peak: 115.7M)
        CPU: 2.430s
     CGroup: /system.slice/tomcat.service
             └─12220 /usr/lib/jvm/java-1.17.0-openjdk-amd64/bin/java -Djava.util.logging.config.file=/opt/tomcat/conf/logging.proper>

Secure Apache Tomcat with Trusted SSL Certificates

Apache Tomcat listens on the insecure HTTP port 8080 and the HTTPS port 8443. Use Let's Encrypt certificates via Certbot to enable secure connections.

1. View the UFW status and verify that the firewall is active:

$ sudo ufw status

If the status is inactive, allow the SSH port 22 and enable UFW:

$ sudo ufw allow 22 && sudo ufw enable

2. Allow HTTP connections through the firewall:

$ sudo ufw allow http

3. Reload UFW to apply the changes:

$ sudo ufw reload

4. Install the Snapd package:

$ sudo apt install snapd -y

5. Install the Certbot Let's Encrypt client using Snap:

$ sudo snap install --classic certbot

6. Generate a new SSL certificate for Apache Tomcat. Replace tomcat.example.com and admin@example.com with your actual details:

$ sudo certbot certonly --standalone -d tomcat.example.com -m admin@example.com --agree-tos

Your output should be similar to the following when successful:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for tomcat.example.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/tomcat.example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/tomcat.example.com/privkey.pem
This certificate expires on 2025-02-27.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

7. Copy the Let's Encrypt certificate files to the Tomcat configuration directory. Replace tomcat.example.com with your actual domain:

$ sudo bash -c 'cp /etc/letsencrypt/live/tomcat.example.com/*.pem /opt/tomcat/conf/'

8. Grant the Tomcat user and group ownership of the .pem certificate files:

$ sudo bash -c 'chown -R tomcat:tomcat /opt/tomcat/conf/*.pem'

9. Allow the Tomcat HTTP port 8080 and HTTPS port 8443 through the firewall:

$ sudo ufw allow 8080,8443/tcp

10. Reload UFW to apply the changes:

$ sudo ufw reload

11. View the UFW status and verify the firewall rules:

$ sudo ufw status

Output:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
8080/tcp                   ALLOW       Anywhere
8443/tcp                   ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)
8080/tcp                   ALLOW       Anywhere (v6)
8443/tcp (v6)              ALLOW       Anywhere (v6)

12. Open the server.xml file to enable the SSL files in the Tomcat configuration:

$ sudo nano /opt/tomcat/conf/server.xml

13. Add the following before the <Connector section to load your SSL certificate files:

    <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true">
        <SSLHostConfig>
            <Certificate certificateFile="conf/cert.pem"
                 certificateKeyFile="conf/privkey.pem"
                 certificateChainFile="conf/chain.pem" />
        </SSLHostConfig>
    </Connector>

Save and close the file. This lets Apache Tomcat accept HTTPS connections on port 8443 using the .pem certificate files in /opt/tomcat/conf.

14. Restart the Apache Tomcat service:

$ sudo systemctl restart tomcat

Access the Apache Tomcat Web Management Dashboard

1. Visit your Apache Tomcat domain on port 8443 in a web browser:

https://tomcat.example.com:8443

Verify that the default Apache Tomcat page displays.

2. Click Manager App to access the manager application, and sign in with your manager username and password.

3. Verify that the manager application loads correctly.

4. Click Host Manager to access the host-manager interface, and log in with your administrator credentials.

Create a Java Web Application to Run on Apache Tomcat

Create a sample Java web application with the following structure:

/home/linuxuser/example-app/
    ├── WEB-INF/
    │   ├── web.xml
    │   └── classes/
    │       └── GreetingsServlet.class

1. Create the project directory:

$ mkdir example-app

2. Switch to the example-app directory:

$ cd example-app

3. Create a WEB-INF subdirectory:

$ mkdir WEB-INF

4. Create a classes subdirectory inside WEB-INF:

$ mkdir WEB-INF/classes

5. Create a new GreetingsServlet.java file:

$ nano GreetingsServlet.java

6. Add the following contents:

import jakarta.servlet.*;
import jakarta.servlet.http.*;
import java.io.IOException;

public class GreetingsServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        response.setContentType("text/html");
        response.getWriter().println("<h1 align='center'>Hello, World!</h1>");
    }
}

Save and close the file. This creates a GreetingsServlet that extends HttpServlet and displays a Hello, World! message when it runs.

7. Create a new web.xml file in the WEB-INF directory:

$ nano WEB-INF/web.xml

8. Add the following contents:

<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
         version="5.0">

    <servlet>
        <servlet-name>GreetingsServlet</servlet-name>
        <servlet-class>GreetingsServlet</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>GreetingsServlet</servlet-name>
        <url-pattern>/helloworld</url-pattern>
    </servlet-mapping>
</web-app>

Save and close the file. This maps the GreetingsServlet to the /helloworld URL pattern so Tomcat serves the example-app application at that path.

9. Compile the servlet using the Tomcat servlet-api.jar library:

$ sudo javac -cp /opt/tomcat/lib/servlet-api.jar -d . GreetingsServlet.java

10. Move the compiled class file into WEB-INF/classes:

$ mv GreetingsServlet.class WEB-INF/classes/

11. List files in the classes subdirectory to confirm the class file is present:

$ ls WEB-INF/classes

Output:

GreetingsServerlet.class

12. Switch to the parent directory:

$ cd ..

13. Move the example-app project into the Tomcat webapps directory to deploy it:

$ sudo mv example-app /opt/tomcat/webapps/example-app

14. Restart Apache Tomcat to apply the changes:

$ sudo systemctl restart tomcat

15. Open the Tomcat web management interface and click Manager App to view all deployed web applications:

https://tomcat.example.com:8443

16. Verify that example-app appears in the list of applications.

17. Visit the /example-app/helloworld path to verify the application runs correctly:

https://tomcat.example.com:8443/example-app/helloworld

Next Steps

Apache Tomcat is installed, secured with a trusted SSL certificate, and running a sample Java web application. From here you can:

Deploy your own WAR files through the Tomcat manager application
Tune CATALINA_OPTS JVM memory settings for your workload
Set up log rotation and monitoring for the Tomcat service
Automate the Let's Encrypt certificate renewal and Tomcat restart with a cron job or systemd timer

For the full guide with additional tips, visit the original article on Vultr Docs.

Installing Apache Airflow on Ubuntu 24.04

Sanskriti Harmukh — Thu, 03 Sep 2026 17:09:02 +0000

Apache Airflow is an open-source workflow management platform that manages data pipelines and automates workflows such as Extract, Transform, and Load (ETL) processes. It uses Python-based Directed Acyclic Graphs (DAGs) to schedule and execute tasks while streamlining the management of all required dependencies for error-free execution. This guide installs Apache Airflow on Ubuntu 24.04, configures a secure environment behind Nginx with Let's Encrypt, and tests the deployment with a sample DAG. By the end, you'll have a working Apache Airflow instance served securely over HTTPS.

Prerequisites

An Ubuntu 24.04 server with at least 4 GB RAM.
A domain A record with your DNS provider pointing to the server's IP address.

Install Apache Airflow

Apache Airflow is available as a Python package installed with a package manager such as Pip.

1. Update the server's package index:

$ sudo apt update

2. View the available Python version:

$ python3 --version

Your output should be similar to:

Python 3.12.3

Install Python if it's not available on your server:

$ sudo apt install python3

3. Install the python3-venv virtual environment module and the PostgreSQL development library:

$ sudo apt install python3-venv libpq-dev -y

4. Create a new virtual environment, for example airflow_env:

$ python3 -m venv airflow_env

5. Activate the airflow_env virtual environment:

$ source ~/airflow_env/bin/activate

Verify that your shell prompt changes to the airflow_env virtual environment:

(airflow_env) linuxuser@example:~$

6. Use Pip to install Apache Airflow with PostgreSQL support:

$ pip install apache-airflow[postgres] psycopg2

7. Install PostgreSQL:

$ sudo apt install postgresql postgresql-contrib

8. Start the PostgreSQL service:

$ sudo systemctl start postgresql

9. Access the PostgreSQL console using the postgres user:

$ sudo -u postgres psql

Your output should be similar to:

psql (16.6 (Ubuntu 16.6-0ubuntu0.24.04.1))
Type "help" for help.

postgres=#

10. Create a new airflow PostgreSQL user with a strong password. Replace YourStrongPassword with your desired password:

postgres=# CREATE USER airflow PASSWORD 'YourStrongPassword';

11. Create a new database, for example airflowdb:

postgres=# CREATE DATABASE airflowdb;

12. Grant the airflow user full privileges to all tables in the public schema:

postgres=# GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO airflow;

13. Grant the airflow user ownership privileges to the airflowdb database:

postgres=# ALTER DATABASE airflowdb OWNER TO airflow;

14. Grant the airflow user all privileges on the public schema:

postgres=# GRANT ALL ON SCHEMA public TO airflow;

15. Exit the PostgreSQL console:

postgres=# exit;

16. Open the airflow.cfg file in your Airflow installation directory:

$ nano ~/airflow/airflow.cfg

Temporarily initialize the database and start the Airflow scheduler to create the necessary directories if the airflow directory is missing:

$ airflow db init; airflow scheduler

Press Ctrl+C to stop the scheduler.

17. Replace the default executor and sql_alchemy_conn values with the following configuration to enable parallel execution and set PostgreSQL as the metadata database:

executor = LocalExecutor
sql_alchemy_conn = postgresql+psycopg2://airflow:YourStrongPassword@localhost/airflowdb

Save and close the file.

18. Initialize the Airflow metadata database to apply the changes:

$ airflow db init

Your output should be similar to:

DB: postgresql+psycopg2://airflow:***@localhost/airflow
[2025-01-05T23:58:36.808+0000] {migration.py:207} INFO - Context impl PostgresqlImpl.
[2025-01-05T23:58:36.809+0000] {migration.py:210} INFO - Will assume transactional DDL.
INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
INFO  [alembic.runtime.migration] Running stamp_revision  -> 5f2621c13b39
WARNI [airflow.models.crypto] empty cryptography key - values will not be stored encrypted.
Initialization done

19. Create a new administrative user to use with Apache Airflow. Replace admin with your desired username:

$ airflow users create \
   --username admin \
   --password yourSuperSecretPassword \
   --firstname Admin \
   --lastname User \
   --role Admin \
   --email admin@example.com

20. Start the Airflow web server on port 8080 as a background process and redirect logs to webserver.log:

$ nohup airflow webserver -p 8080 > webserver.log 2>&1 &

21. Start the Airflow scheduler and redirect logs to scheduler.log:

$ nohup airflow scheduler > scheduler.log 2>&1 &

Configure Nginx as a Reverse Proxy to Expose Apache Airflow

Apache Airflow listens for connections on the default port 8080. Use Nginx to front that port and serve requests over HTTP and HTTPS.

1. Install Nginx:

$ sudo apt install -y nginx

2. Create a new airflow Nginx virtual host configuration file:

$ sudo nano /etc/nginx/sites-available/airflow

3. Add the following configuration to the file. Replace airflow.example.com with your actual domain:

server {
    listen 80;
    server_name airflow.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

Save and close the file. This configuration listens for connections on your airflow.example.com domain and forwards them to the Apache Airflow port 8080.

4. Link the configuration to the Nginx sites-enabled directory to enable it:

$ sudo ln -s /etc/nginx/sites-available/airflow /etc/nginx/sites-enabled/

5. Test the Nginx configuration for errors:

$ sudo nginx -t

Your output should be similar to:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

6. Reload Nginx to apply the changes:

$ sudo systemctl reload nginx

7. Allow connections to the HTTP port 80 through the firewall:

$ sudo ufw allow 80/tcp

8. Reload UFW to apply the firewall configuration changes:

$ sudo ufw reload

9. Access your airflow.example.com domain in a web browser and verify that the Airflow login page displays.

http://airflow.example.com

Generate Trusted SSL Certificates to Secure Apache Airflow

SSL certificates encrypt the connection between a client and the Apache Airflow server. Use Certbot to generate Let's Encrypt SSL certificates.

1. Install the Certbot Let's Encrypt client:

$ sudo snap install --classic certbot

Install Snap first if it's not available on your workstation:

$ sudo apt install snapd -y

2. Move the Certbot binary to /usr/bin to enable it as a system-wide command:

$ sudo ln -s /snap/bin/certbot /usr/bin/certbot

3. Request a new Let's Encrypt SSL certificate using the Nginx plugin and your domain. Replace airflow.example.com with your actual domain and admin@example.com with your active email address:

$ sudo certbot --nginx --redirect -d airflow.example.com -m admin@example.com --agree-tos

Your output should be similar to the following when the certificate request succeeds:

...
Account registered.
Requesting a certificate for airflow.example.com

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/airflow.example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/airflow.example.com/privkey.pem
This certificate expires on 2025-04-21.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for airflow.example.com to /etc/nginx/sites-enabled/airflow
Congratulations! You have successfully enabled HTTPS on https://airflow.example.com
...

4. Verify that Certbot auto-renews the SSL certificate before it expires:

$ sudo certbot renew --dry-run

5. Restart Nginx to apply the SSL configuration changes:

$ sudo systemctl restart nginx

Access Apache Airflow

1. Access the Apache Airflow web interface using your domain:

https://airflow.example.com

Enter the credentials you set earlier to log in:

Username: admin
Password: yourSuperSecretPassword

Create and Run DAGs Using Apache Airflow

1. Create the dags directory in the Airflow installation directory:

$ mkdir ~/airflow/dags

2. Create a new my_first_dag.py Python application file in the dags directory:

$ nano ~/airflow/dags/my_first_dag.py

3. Add the following code to define a new DAG:

from airflow import DAG
from airflow.operators.python_operator import PythonOperator
from datetime import datetime, timedelta

with DAG(
    'my_first_dag',
    start_date=datetime(2024, 1, 1),
    schedule_interval=timedelta(days=1),
    catchup=False
) as dag:

    def print_hello():
        print('Hello from Airflow!')

    hello_task = PythonOperator(
        task_id='hello_task',
        python_callable=print_hello
    )

Save and close the file. This creates a my_first_dag sample DAG that runs daily and prints Hello from Airflow!.

4. In the Apache Airflow interface, navigate to the DAGs list, find the DAG, and enable it to trigger it manually.

5. Use the Graph View and Event Log to monitor the DAG.

Next Steps

Apache Airflow is running behind Nginx with HTTPS and executing your first DAG. From here you can:

Add more DAGs to automate real ETL and data pipeline workflows
Configure Airflow connections and variables for external systems (databases, APIs, object storage)
Set up monitoring and alerting for task failures and SLA misses
Review the Certbot renewal timer and Airflow's authentication/RBAC options before going to production

For the full guide with additional tips, visit the original article on Vultr Docs.

Installing Docker on Ubuntu 24.04

Sanskriti Harmukh — Thu, 03 Sep 2026 17:08:07 +0000

Docker is an open-source containerization platform that automates deploying, scaling, and managing applications in containers — lightweight, portable packages that bundle an application's code, runtime, libraries, and dependencies so it runs consistently anywhere. This guide walks through installing Docker Engine on an Ubuntu 24.04 server, managing the Docker systemd service, and running Docker commands as a non-root user. By the end, you'll have a fully working Docker installation ready to build and run containers.

Prerequisites

Access to an Ubuntu 24.04 server as a non-root user with sudo privileges.

Note: Some GPU-enabled cloud instances running Ubuntu ship with Docker pre-installed. Installing Docker again on those servers can conflict with the NVIDIA Container Toolkit and affect GPU performance or container compatibility, so check first if Docker is already present.

Install Docker

1. Install the packages required to add the Docker repository:

$ sudo apt install ca-certificates curl -y

2. Create the keyrings directory that APT uses to store repository signing keys:

$ sudo install -m 0755 -d /etc/apt/keyrings

3. Download the Docker GPG key to the keyrings directory:

$ sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

4. Set read permissions on the key so APT can read it:

$ sudo chmod a+r /etc/apt/keyrings/docker.asc

5. Add the Docker repository to your APT sources:

$ echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

6. Update the package index:

$ sudo apt update

7. Install Docker Engine and its plugins:

$ sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

This installs Docker Engine with the following components:

docker-ce: The Docker Engine community edition package.
docker-ce-cli: The Docker command-line interface (CLI).
containerd.io: A container runtime that manages the lifecycle of Docker containers.
docker-buildx-plugin: Extends Docker's image-building capabilities for multi-platform builds.
docker-compose-plugin: Manages multi-container Docker applications defined in YAML files.

8. View the installed Docker version:

$ sudo docker --version

Output:

Docker version 29.6.1, build 8900f1d

Manage the Docker System Service

1. Enable the Docker service to start automatically at boot:

$ sudo systemctl enable docker

On Ubuntu, the package installer already enables this service, so the command confirms it is enabled.

2. View the Docker service status:

$ sudo systemctl status docker

Verify that the output shows active (running).

3. Stop Docker:

$ sudo systemctl stop docker

4. Restart the Docker service:

$ sudo systemctl restart docker

5. Add your non-root user to the docker group to run Docker CLI commands without sudo privileges. Replace linuxuser with your actual username:

$ sudo usermod -aG docker linuxuser

6. Enable the new user group changes in your active session:

$ newgrp docker

Next Steps

Docker Engine and the Compose plugin are installed and running, and your user can run Docker commands without sudo. From here you can:

Pull and run your first container images, or write a docker-compose.yml for a multi-container app
Explore Docker volumes and networks for persistent storage and service-to-service communication
Set up a container registry workflow for building and pushing your own images
Look into Docker Compose profiles or Swarm/Kubernetes if you need multi-host orchestration

For the full guide with additional tips, visit the original article on Vultr Docs.

Installing OpenLiteSpeed on Ubuntu 22.04

Sanskriti Harmukh — Wed, 26 Aug 2026 17:47:13 +0000

OpenLiteSpeed is a free, open-source, high-performance web server with HTTP/2 and HTTP/3 support, native PHP handling, and a graphical admin console for managing virtual hosts. This guide installs it on Ubuntu 22.04, creates a virtual host with a custom web root, and secures it with a real TLS certificate.

Prerequisites: an Ubuntu 22.04 instance, non-root sudo user, a domain A record (e.g. app.example.com).

Install OpenLiteSpeed

Not in the default repos — use the official setup script:

$ wget -O openlitespeed.sh https://repo.litespeed.sh
$ sudo bash openlitespeed.sh
$ sudo apt install openlitespeed -y
$ cat /usr/local/lsws/VERSION

Manage the Service

Runs as lshttpd.service, aliased to lsws:

$ sudo systemctl enable lshttpd.service
$ sudo systemctl start lsws
$ sudo systemctl status lsws

Stop/restart with sudo systemctl stop lsws / restart lsws.

Access the Admin Console

Runs on port 7080; default password lives at /usr/local/lsws/admin/password.

$ sudo bash /usr/local/lsws/admin/misc/admpass.sh

Set a custom admin username and password when prompted, then open the port:

$ sudo ufw allow 7080/tcp
$ sudo ufw reload

Visit http://SERVER-IP:7080, accept the self-signed cert warning, log in with the credentials you just set.

Move the default listener off 8088 onto standard HTTP:

Listeners → view the Default listener → Edit on Address Settings.
Change Port from 8088 to 80 → Save.
Graceful Restart (top right, next to LSWS PID) → Go.

Create a Virtual Host

$ sudo mkdir /usr/local/lsws/app.example.com
$ sudo mkdir /usr/local/lsws/app.example.com/{html,logs,conf} -p
$ sudo chown lsadm:lsadm -R /usr/local/lsws/app.example.com/

html — served application files
logs — access/error logs
conf — site-specific config

In the console:

Virtual Hosts → Add, replacing app.example.com with your domain:
- Virtual Host Name: app.example.com
- Virtual Host Root: $SERVER_ROOT/app.example.com/
- Config File: $SERVER_ROOT/conf/vhosts/$VH_NAME/vhconf.conf
- Follow Symbolic Link, Enable Scripts/ExtApps, Restrained: Yes
- External App Set UID Mode: Server UID
Save → CLICK TO CREATE on the config-file-missing prompt → Save again.
Open the new virtual host → General → Edit:
- Document Root: $VH_ROOT/html/
- Domain Name: app.example.com
- Enable GZIP Compression, Enable Brotli Compression: Yes
Log → Edit (error log): Use Server's Log: Yes, File Name: $VH_ROOT/logs/error.log, Log Level: ERROR, Rolling Size: 10M, Keep Days: 30.
Log → Add (access log): Log Control: Own Log File, File Name: $VH_ROOT/logs/access.log, same rolling/retention values.
Rewrite → Edit: Enable Rewrite: Yes, Auto Load from .htaccess: Yes.
Listeners → Default Listener → Virtual Host Mappings → Add: select your virtual host, enter app.example.com in Domains.
Save, then Graceful Restart → Go.

Add a test page:

$ sudo nano /usr/local/lsws/app.example.com/html/index.html

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>OpenLiteSpeed Server Install Test</title>
</head>
<body>
    <h1 style="text-align: center;">It works!</h1>
</body>
</html>

$ sudo ufw allow 80/tcp

Visit http://app.example.com and confirm the page loads.

Secure with Let's Encrypt

$ sudo snap install --classic certbot
$ sudo certbot certonly --webroot -w /usr/local/lsws/app.example.com/html/ --agree-tos --no-eff-email --staple-ocsp --preferred-challenges http -m name@example.com -d app.example.com
$ sudo certbot renew --dry-run

Certbot doesn't have an OpenLiteSpeed plugin — wire the certificate in manually via the console:

Listeners → Add: Listener Name: HTTPS, IP Address: ANY IPv4, Port: 443, Secure: Yes → Save.
Open the new HTTPS listener → Virtual Host Mappings → Add: Virtual Host: app.example.com, Domains: app.example.com.
SSL → Edit:
- Private Key File: /etc/letsencrypt/live/app.example.com/privkey.pem
- Certificate File: /etc/letsencrypt/live/app.example.com/fullchain.pem
- Chained Certificate: Yes
Save, then Graceful Restart → Go.

For multiple virtual hosts, open each one's SSL tab individually to bind a certificate.

Firewall Rules

$ sudo ufw allow 22/tcp && sudo ufw enable
$ sudo ufw allow 7080/tcp
$ sudo ufw allow http
$ sudo ufw allow https
$ sudo ufw reload
$ sudo ufw status

Visit https://app.example.com to confirm TLS is working end to end.

Next Steps

OpenLiteSpeed is running with a virtual host, HTTPS, and a working test page. From here:

Add PHP via the console's Server Configuration → External App for dynamic sites
Repeat the virtual host steps per additional domain you host on the same server
Automate cert renewal hooks to reload the listener after Certbot rotates the certificate

For the full guide, visit the original article on Vultr Docs.

Installing Webmin on Ubuntu 24.04

Sanskriti Harmukh — Wed, 26 Aug 2026 17:38:40 +0000

Webmin is an open-source, web-based control panel for Linux server administration — user accounts, disk quotas, networking, packages, and more, all without touching the command line. This guide installs it on Ubuntu 24.04, secures it with a real TLS certificate, locks down the firewall, and tours the dashboard.

Prerequisites: an Ubuntu 24.04 instance, non-root sudo user, a domain A record (e.g. webmin.example.com).

Install Webmin

Not in the default repos — use the official setup script:

$ sudo curl -o setup-repos.sh https://raw.githubusercontent.com/webmin/webmin/master/setup-repos.sh
$ sudo bash setup-repos.sh
$ sudo apt install --install-recommends webmin -y
$ sudo systemctl status webmin

Webmin listens on port 10000 by default.

Secure with Let's Encrypt

Webmin serves plain HTTP on 10000 out of the box — fix that first.

$ sudo ufw allow 80/tcp
$ sudo apt install certbot -y
$ sudo certbot certonly --standalone -d webmin.example.com -m webmin@example.com --agree-tos

Merge cert + key into the format Webmin expects, and install it:

$ sudo cat /etc/letsencrypt/live/webmin.example.com/fullchain.pem /etc/letsencrypt/live/webmin.example.com/privkey.pem > webmin.pem
$ sudo mv webmin.pem /etc/webmin/
$ sudo nano /etc/webmin/miniserv.conf

Find and replace the keyfile value:

keyfile=/etc/webmin/webmin.pem

$ sudo systemctl restart webmin

Lock Down the Firewall

$ sudo ufw allow 10000
$ sudo ufw allow https
$ sudo ufw deny http
$ sudo ufw reload
$ sudo ufw status

Denying plain HTTP after the cert is issued closes the unencrypted path — the cert renewal process doesn't need port 80 open long-term the way initial issuance does (Certbot's --standalone renewal reopens it briefly, or switch to a DNS challenge if you'd rather keep 80 closed permanently).

Access Webmin

Visit https://webmin.example.com:10000, log in with your sudo user credentials.
Dashboard shows CPU, memory, disk, and running processes at a glance.
System → Software Package Updates — review and apply pending package updates.
Tools → File Manager — browse and edit files on the server.
Tools → Terminal — a full shell session in the browser.

All system users with login privileges can log in; only sudo users get administrative actions.

Next Steps

Webmin is running behind TLS with the firewall scoped to only the ports it needs. From here:

Explore Webmin modules for specific services you run (Apache, BIND, Postfix, etc.)
Set up additional restricted users for team members who only need specific modules
Switch Certbot to a DNS-01 challenge if you want port 80 closed permanently between renewals

For the full guide, visit the original article on Vultr Docs.