DEV Community: Sanskriti Harmukh

Deploying Redpanda Kafka-Compatible Streaming Platform on Ubuntu 24.04

Sanskriti Harmukh — Tue, 07 Jul 2026 21:47:18 +0000

Redpanda is a Kafka-API-compatible streaming platform written in C++ with no JVM and no ZooKeeper. This guide installs Redpanda on Ubuntu 24.04, secures it with a Let's Encrypt certificate and SASL/SCRAM authentication, tunes the kernel for production, verifies with a producer/consumer test, and exposes Redpanda Console behind Nginx basic auth. By the end, you'll have a secured, production-tuned single-node Redpanda cluster with a web console.

Prerequisite: Ubuntu 24.04 server sized per Redpanda's CPU/memory requirements, non-root sudo user, and a domain A record (e.g. redpanda.example.com).

Install Redpanda

$ sudo apt update
$ curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/cfg/setup/bash.deb.sh' | sudo -E bash

Warning: Only run vendor setup scripts you trust — piped curl | sudo bash runs with root privileges.

$ sudo apt install redpanda -y
$ rpk --version

Open the Firewall

Port	Service	Purpose
9092	Kafka API	Producer/consumer traffic
8082	Pandaproxy (HTTP)	REST access for non-Kafka clients
8081	Schema Registry	Avro/Protobuf schema versioning
9644	Admin API	Monitoring, config, health checks
33145	Internal RPC	Inter-node communication

$ sudo ufw allow 9092,8082,8081,9644,33145/tcp
$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp
$ sudo ufw reload

Issue a Let's Encrypt Certificate

Redpanda ships with plaintext networking by default, fine for a lab, not for anything else.

$ sudo apt install certbot -y
$ DOMAIN=redpanda.example.com
$ EMAIL=admin@example.com
$ sudo certbot certonly --standalone -d $DOMAIN --non-interactive --email $EMAIL

Certbot stores certs under /etc/letsencrypt/live, readable only by root. Redpanda runs as its own redpanda user, so copy the certs into a dedicated directory:

$ sudo mkdir /etc/redpanda/certs
$ sudo cp /etc/letsencrypt/live/$DOMAIN/fullchain.pem /etc/redpanda/certs/node.crt
$ sudo cp /etc/letsencrypt/live/$DOMAIN/privkey.pem /etc/redpanda/certs/node.key
$ sudo cp /etc/letsencrypt/live/$DOMAIN/chain.pem /etc/redpanda/certs/ca.crt
$ sudo chown -R redpanda:redpanda /etc/redpanda/certs/
$ sudo chmod 400 /etc/redpanda/certs/node.key
$ sudo chmod 444 /etc/redpanda/certs/node.crt /etc/redpanda/certs/ca.crt

Automate renewal — Let's Encrypt certs expire every 90 days, so wire a deploy hook that refreshes Redpanda's copies and restarts the service:

$ sudo nano /etc/letsencrypt/renewal-hooks/deploy/redpanda-renewal.sh

#!/bin/bash
DOMAIN="redpanda.example.com"

cp /etc/letsencrypt/live/$DOMAIN/fullchain.pem /etc/redpanda/certs/node.crt
cp /etc/letsencrypt/live/$DOMAIN/privkey.pem /etc/redpanda/certs/node.key
cp /etc/letsencrypt/live/$DOMAIN/chain.pem /etc/redpanda/certs/ca.crt

chown -R redpanda:redpanda /etc/redpanda/certs/
chmod 400 /etc/redpanda/certs/node.key
chmod 444 /etc/redpanda/certs/node.crt /etc/redpanda/certs/ca.crt

systemctl restart redpanda

$ sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/redpanda-renewal.sh
$ sudo certbot renew --dry-run

Tune for Production

$ sudo rpk redpanda mode production
$ sudo rpk redpanda tune all
$ sudo systemctl start redpanda-tuner

tune all optimizes I/O schedulers and CPU settings, takes ~30 seconds. The tuner service reapplies these on every reboot since kernel tuning doesn't persist otherwise.

Bootstrap Authentication

Set security policy before the first startup so it's enforced from the very first boot.

$ sudo nano /etc/redpanda/.bootstrap.yaml

enable_sasl: true
admin_api_require_auth: true
superusers:
  - admin

Note: This file is only read on first startup. Later changes go through the Admin API or rpk cluster config.

Set the superuser's password:

$ echo "RP_BOOTSTRAP_USER=admin:STRONG_PASSWORD:SCRAM-SHA-256" | sudo tee -a /etc/default/redpanda

Configure the Node

$ sudo cp /etc/redpanda/redpanda.yaml /etc/redpanda/redpanda-backup.yaml
$ sudo nano /etc/redpanda/redpanda.yaml

Replace the contents (swap redpanda.example.com for your domain):

redpanda:
  data_directory: /var/lib/redpanda/data
  seed_servers: []

  rpc_server:
    address: 0.0.0.0
    port: 33145
  advertised_rpc_api:
    address: redpanda.example.com
    port: 33145

  kafka_api:
    - name: tls_listener
      address: 0.0.0.0
      port: 9092
      authentication_method: sasl
  advertised_kafka_api:
    - name: tls_listener
      address: redpanda.example.com
      port: 9092
  kafka_api_tls:
    - name: tls_listener
      key_file: /etc/redpanda/certs/node.key
      cert_file: /etc/redpanda/certs/node.crt
      truststore_file: /etc/redpanda/certs/ca.crt
      enabled: true
      require_client_auth: false

  admin:
    - address: 0.0.0.0
      port: 9644
  admin_api_tls:
    - enabled: true
      key_file: /etc/redpanda/certs/node.key
      cert_file: /etc/redpanda/certs/node.crt
      truststore_file: /etc/redpanda/certs/ca.crt

rpk:
  tune_network: true
  tune_disk_scheduler: true
  tune_disk_nomerges: true
  tune_disk_write_cache: true
  tune_disk_irq: true
  tune_cpu: true
  tune_aio_events: true
  tune_clocksource: true
  tune_swappiness: true
  coredump_dir: /var/lib/redpanda/coredump
  tune_ballast_file: true

This enables SASL-over-TLS on the Kafka API (9092), TLS on the Admin API (9644), advertises both under your public domain, and applies the full rpk tuning profile.

$ sudo systemctl start redpanda
$ sudo systemctl status redpanda

Create an rpk Profile

Run rpk as your regular user (not sudo) so it picks up your profile.

$ nano ~/rpk-profile.yaml

kafka_api:
  sasl:
    user: admin
    password: STRONG_PASSWORD
    mechanism: SCRAM-SHA-256
  tls:
    enabled: true
    ca_file: /etc/redpanda/certs/ca.crt
  brokers:
    - redpanda.example.com:9092

admin_api:
  tls:
    enabled: true
    ca_file: /etc/redpanda/certs/ca.crt
  addresses:
    - redpanda.example.com:9644

$ rpk profile create production --from-profile ~/rpk-profile.yaml
$ rpk cluster health

CLUSTER HEALTH OVERVIEW
=======================
Healthy:                          true
Unhealthy reasons:                []
Controller ID:                    0
All nodes:                        [0]
Nodes down:                       []
Cluster UUID:                     65e28fbb-c1b4-42c3-b0b7-fd82608699f3

Test with a Producer and Consumer

$ rpk topic create test-topic

TOPIC       STATUS
test-topic  OK

$ echo "Hello Redpanda" | rpk topic produce test-topic

Produced to partition 0 at offset 0 with timestamp 1699618845123.

$ rpk topic consume test-topic --num 1

Deploy Redpanda Console

$ sudo apt install redpanda-console -y
$ sudo nano /etc/redpanda/redpanda-console-config.yaml

server:
  listenPort: 8080
  listenAddress: 127.0.0.1

kafka:
  brokers:
    - redpanda.example.com:9092
  tls:
    enabled: true
    caFilepath: /etc/redpanda/certs/ca.crt
  sasl:
    enabled: true
    username: admin
    password: STRONG_PASSWORD
    mechanism: SCRAM-SHA-256

redpanda:
  adminApi:
    enabled: true
    urls:
      - https://redpanda.example.com:9644
    tls:
      enabled: true
      caFilepath: /etc/redpanda/certs/ca.crt
    authentication:
      basic:
        username: admin
        password: STRONG_PASSWORD

$ sudo systemctl enable redpanda-console
$ sudo systemctl start redpanda-console

Front the Console with Nginx Basic Auth

Redpanda Console CE has no built-in login — put Nginx basic auth in front of it.

$ sudo apt install nginx -y
$ sudo apt install apache2-utils -y
$ sudo htpasswd -c /etc/nginx/.htpasswd admin

$ sudo nano /etc/nginx/sites-available/redpanda-console

server {
    listen 80;
    server_name redpanda.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name redpanda.example.com;

    ssl_certificate /etc/letsencrypt/live/redpanda.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/redpanda.example.com/privkey.pem;

    location / {
        auth_basic "Restricted Access";
        auth_basic_user_file /etc/nginx/.htpasswd;
        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;
    }
}

$ sudo ln -s /etc/nginx/sites-available/redpanda-console /etc/nginx/sites-enabled/
$ sudo nginx -t
$ sudo systemctl restart nginx

Open https://redpanda.example.com, enter the basic-auth credentials to reach the console dashboard.

Next Steps

Redpanda is running with TLS, SASL auth, production tuning, and a secured console. From here you can:

Add more brokers and set seed_servers for a multi-node cluster
Wire Kafka Connect or a schema registry client against port 8081
Point existing Kafka producers/consumers at Redpanda. The wire protocol is compatible, no client changes needed

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

Deploying SFTPGo as an Azure Storage SFTP Alternative on Linux

Sanskriti Harmukh — Tue, 07 Jul 2026 21:42:43 +0000

Azure Storage SFTP is Microsoft's managed file transfer service on top of Azure Blob Storage, convenient, but billed continuously per endpoint (roughly $0.30/hour, ~$220/month) and tied to Azure AD. SFTPGo is an open-source file transfer server offering SFTP, FTP/S, and WebDAV with pluggable storage backends (local disk, Azure Blob, S3-compatible, GCS) and no per-endpoint charge. This guide deploys SFTPGo with Docker Compose and Traefik, sets up user auth (password + SSH key + 2FA), connects S3-compatible object storage, and covers the migration path from Azure Storage SFTP. By the end, you'll have a self-hosted file transfer server with the same capabilities at zero endpoint cost.

Azure Storage SFTP → SFTPGo Mapping

Azure Storage SFTP	SFTPGo Equivalent	Notes
SFTP Endpoint	SFTPGo SFTP Server	Configurable port, default `2022`
Azure Blob Storage	Azure Blob backend	Native support; point at the same container, no migration needed
Azure AD Authentication	LDAP/OIDC plugin	External identity provider via plugin
Local Users	Web UI / REST API user management
Hierarchical Namespace	Virtual directories	No HNS requirement
Azure Monitor	Built-in logging + webhooks/syslog

Prerequisite: Linux server with Docker + Compose, a DNS A record for your domain, and (if migrating) an existing Azure Storage account with SFTP enabled plus the Azure CLI installed locally.

Deploy with Docker Compose

1. Create the project directories:

$ mkdir -p ~/sftpgo/{data,config}
$ cd ~/sftpgo

2. Create the environment file:

$ nano .env

DOMAIN=sftp.example.com
LETSENCRYPT_EMAIL=admin@example.com

3. Create the Compose manifest:

$ nano docker-compose.yml

services:
  traefik:
    image: traefik:v3.6
    container_name: traefik
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "letsencrypt:/letsencrypt"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
    restart: unless-stopped

  sftpgo:
    image: drakkan/sftpgo:v2.7
    container_name: sftpgo
    restart: unless-stopped
    ports:
      - "2022:2022"
      - "2121:2121"
      - "10080:10080"
    environment:
      - SFTPGO_HTTPD__BINDINGS__0__PORT=8080
      - SFTPGO_HTTPD__BINDINGS__0__ADDRESS=0.0.0.0
      - SFTPGO_SFTPD__BINDINGS__0__PORT=2022
      - SFTPGO_FTPD__BINDINGS__0__PORT=2121
      - SFTPGO_WEBDAVD__BINDINGS__0__PORT=10080
      - SFTPGO_DATA_PROVIDER__DRIVER=sqlite
      - SFTPGO_DATA_PROVIDER__NAME=/var/lib/sftpgo/sftpgo.db
    volumes:
      - ./data:/srv/sftpgo
      - ./config:/var/lib/sftpgo
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.sftpgo.rule=Host(`${DOMAIN}`)"
      - "traefik.http.routers.sftpgo.entrypoints=websecure"
      - "traefik.http.routers.sftpgo.tls.certresolver=letsencrypt"
      - "traefik.http.services.sftpgo.loadbalancer.server.port=8080"
    healthcheck:
      test: ["CMD", "sftpgo", "ping", "-c", "/var/lib/sftpgo"]
      interval: 30s
      timeout: 10s
      retries: 3

volumes:
  letsencrypt:

Traefik terminates TLS on 80/443 for the admin UI; SFTP/FTP/S/WebDAV listen directly on 2022/2121/10080. Port 8080 (the admin UI's internal port) is never exposed to the host — Traefik proxies to it over the Docker network.

4. Start the stack:

$ docker compose up -d
$ docker compose ps
$ docker compose logs

Initial Admin Setup

Open https://sftp.example.com/web/admin.
Create the administrator: username, strong password, confirm, Create admin and Sign in.
Review Server Manager → Configurations — check the SFTP, ACME, and SMTP sections match your requirements.

Create a User and Configure Authentication

1. Password auth: Users → Add — username, password, Status: Active, File system: Local disk, Root directory: /srv/sftpgo/USERNAME. Save.

2. SSH key auth (passwordless, mirrors Azure's SSH key support):

$ ssh-keygen -t ed25519 -f ~/.ssh/sftpgo_key -C "sftp-user"
$ cat ~/.ssh/sftpgo_key.pub

Paste the public key into Users → Edit → Public keys, then test:

$ sftp -i ~/.ssh/sftpgo_key -P 2022 USERNAME@sftp.example.com

3. 2FA: Users → Edit → ACLs → Require 2FA for — select the protocols to gate. The user sets up their authenticator app on next WebClient login.

Connect S3-Compatible Object Storage

SFTPGo supports Azure Blob directly, but also any S3-compatible provider — useful if you're consolidating storage away from Azure.

Gather your endpoint URL, access key, secret key, and bucket name from the provider.
Users → Edit → File system → Storage: S3 (Compatible).
Fill in Bucket, Region, Access Key, Access Secret, Endpoint (full URL).
Enable Use path-style addressing.
Save, then verify:

$ echo "Hello SFTPGo" > testfile.txt
$ sftp -P 2022 USERNAME@sftp.example.com
sftp> put testfile.txt
sftp> ls
sftp> exit

S3 backend limitations: resume uploads disabled, no symlinks, non-atomic directory rename, chmod/chown silently ignored.

Test All Protocols

$ echo "Hello SFTPGo" > testfile.txt
$ sftp -P 2022 USERNAME@sftp.example.com
sftp> put testfile.txt
sftp> get testfile.txt /tmp/testfile-downloaded.txt
sftp> exit

$ sftp -i ~/.ssh/sftpgo_key -P 2022 USERNAME@sftp.example.com

$ sudo apt install lftp -y
$ lftp -u USERNAME -p 2121 ftp://sftp.example.com
lftp> ls
lftp> exit

Migrate from Azure Storage SFTP

Export Users

$ az storage account local-user list --account-name STORAGE_ACCOUNT --resource-group RESOURCE_GROUP
$ az storage account local-user show --account-name STORAGE_ACCOUNT --resource-group RESOURCE_GROUP --name USERNAME

Record username, SSH public keys, home directory (container + path), and permission scope for each user.

Recreate Users in SFTPGo

$ curl -u ADMIN_USERNAME:ADMIN_PASSWORD https://sftp.example.com/api/v2/token

Copy the access_token — it expires in 15 minutes.

$ curl -X POST "https://sftp.example.com/api/v2/users" \
    -H "Authorization: Bearer ACCESS_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "username": "USERNAME",
      "password": "PASSWORD",
      "status": 1,
      "public_keys": ["SSH_PUBLIC_KEY"],
      "home_dir": "/srv/sftpgo/data/USERNAME",
      "permissions": {"/": ["*"]}
    }'

"status": 1 is required — without it the account is created disabled.

Migrate Data

If SFTPGo will use Azure Blob as its own backend, just point users at the same container — no data transfer needed. For local-disk backends, pull the data down:

$ az storage blob download-batch --account-name STORAGE_ACCOUNT --source CONTAINER_NAME --destination ~/sftpgo/data/USERNAME/
$ sudo chown -R 1000:1000 ~/sftpgo/data/

Map Authentication Methods

Azure Method	SFTPGo Equivalent
SSH Public Keys	Public Keys (direct)
Local User Passwords	Password Authentication
Azure AD (Preview)	LDAP/OIDC plugin, or external auth hook

Update Clients

Document the new endpoint (sftp.example.com, port 2022, SSH key or password) and roll it out before decommissioning the Azure endpoint. Export SFTPGo's SSH host key (/var/lib/sftpgo/id_*) and share the fingerprint so clients don't hit host-key warnings.

Things to Watch

Hierarchical Namespace: Azure Storage SFTP requires HNS; SFTPGo simulates directories without it — check any app that depends on HNS-specific behavior.
Container-level permissions: map to SFTPGo's per-directory ACLs.
Lifecycle policies: SFTPGo doesn't manage Azure Blob lifecycle rules — keep configuring those in Azure if you stay on the Blob backend.
Azure Monitor: replace with SFTPGo's logging, syslog, or webhook integrations.

Next Steps

SFTPGo is running as a self-hosted Azure Storage SFTP replacement with zero per-endpoint charge. From here you can:

Enable the Azure Blob backend directly if you want to keep data in place
Set quotas, bandwidth limits, and IP ACLs per user under Edit → Disk quota / ACLs
Wire event hooks (webhooks/syslog) to replace Azure Monitor alerting

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

Deploying ClearML as a GCP Vertex AI Alternative on Ubuntu

Sanskriti Harmukh — Tue, 07 Jul 2026 21:37:38 +0000

Google Vertex AI is Google Cloud's managed ML platform with experiment tracking, training jobs, pipelines, a model registry, and endpoints, but it locks you into GCP-specific APIs and per-use billing. ClearML is an open-source MLOps platform that covers the same ground on any Docker host or Kubernetes cluster, capturing training metrics automatically with no code changes and keeping every byte of data on infrastructure you control. This guide deploys ClearML Server with Docker Compose and Traefik, registers an agent, runs an experiment, builds a pipeline, runs a hyperparameter sweep, and deploys a Triton-served model. By the end, you'll have a self-hosted Vertex AI replacement covering the full ML lifecycle.

Vertex AI → ClearML Mapping

GCP Vertex AI	ClearML Equivalent	Purpose
Vertex AI Workbench	ClearML Web UI	Browser-based monitoring and configuration
Vertex AI Experiments	ClearML Experiment Manager	Automatic hyperparameter/metric/artifact tracking
Vertex AI Training Job	ClearML Agent + Tasks	Any machine becomes a remote worker via queues
Vertex AI Pipelines	ClearML Pipelines	Python-native DAGs, no separate compile step
Vertex AI Model Registry	ClearML Model Repository	Versioned models with full lineage
Vertex AI Endpoints	ClearML Serving (Triton)	Self-hosted inference with canary/A-B support
Cloud Monitoring/Logging	ClearML Scalars/Plots	Built-in metrics and hardware dashboards

Prerequisite: Ubuntu host with Docker + Compose, DNS A records for app.clearml.example.com, api.clearml.example.com, files.clearml.example.com. NVIDIA Container Toolkit if you'll run GPU agents.

Deploy the ClearML Server

1. Raise Elasticsearch's virtual memory limit and restart Docker:

$ echo "vm.max_map_count=524288" | sudo tee /etc/sysctl.d/99-clearml.conf
$ sudo sysctl --system
$ sudo systemctl restart docker

2. Create persistent data directories with the correct ownership:

$ sudo mkdir -p /opt/clearml/{data/elastic_7,data/mongo_4/db,data/mongo_4/configdb,data/redis,data/fileserver,logs,config}
$ sudo chown -R 1000:1000 /opt/clearml

3. Download the official Compose file:

$ mkdir -p ~/clearml && cd ~/clearml
$ curl -fsSL https://raw.githubusercontent.com/clearml/clearml-server/master/docker/docker-compose.yml -o docker-compose.yml

4. Edit it: comment out the ports: blocks under apiserver, webserver, and fileserver (Traefik will handle external routing), and replace the networks: section with named bridges:

networks:
  backend:
    name: clearml_backend
    driver: bridge
  frontend:
    name: clearml_frontend
    driver: bridge

5. Set the public hostnames:

$ nano .env

CLEARML_WEB_HOST=https://app.clearml.example.com
CLEARML_API_HOST=https://api.clearml.example.com
CLEARML_FILES_HOST=https://files.clearml.example.com

6. Start the stack:

$ docker compose up -d
$ docker compose ps
$ docker compose logs --tail 50

Front the Stack with Traefik

1. Create the Traefik directory and cert store:

$ mkdir -p ~/clearml/traefik && cd ~/clearml/traefik
$ mkdir -p letsencrypt && touch letsencrypt/acme.json && chmod 600 letsencrypt/acme.json

2. Set the ACME email:

$ nano .env

LETSENCRYPT_EMAIL=admin@example.com

3. Create the Traefik Compose file:

$ nano docker-compose.yml

services:
  traefik:
    image: traefik:v3.6
    container_name: traefik
    command:
      - "--log.level=INFO"
      - "--providers.file.filename=/etc/traefik/dynamic_conf.yml"
      - "--entryPoints.web.address=:80"
      - "--entryPoints.websecure.address=:443"
      - "--entryPoints.web.http.redirections.entrypoint.to=websecure"
      - "--certificatesResolvers.le.acme.httpChallenge.entryPoint=web"
      - "--certificatesResolvers.le.acme.email=${LETSENCRYPT_EMAIL}"
      - "--certificatesResolvers.le.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "./letsencrypt:/letsencrypt"
      - "./dynamic_conf.yml:/etc/traefik/dynamic_conf.yml:ro"
    networks:
      - clearml-frontend
    restart: unless-stopped

networks:
  clearml-frontend:
    name: clearml_frontend
    external: true

4. Route each subdomain to its ClearML service:

$ nano dynamic_conf.yml

http:
  routers:
    clearml-web:
      rule: "Host(`app.clearml.example.com`)"
      entryPoints: [websecure]
      service: clearml-web
      tls: {certResolver: le}
    clearml-api:
      rule: "Host(`api.clearml.example.com`)"
      entryPoints: [websecure]
      service: clearml-api
      tls: {certResolver: le}
    clearml-files:
      rule: "Host(`files.clearml.example.com`)"
      entryPoints: [websecure]
      service: clearml-files
      tls: {certResolver: le}
  services:
    clearml-web:
      loadBalancer:
        servers: [{url: "http://clearml-webserver:80"}]
    clearml-api:
      loadBalancer:
        servers: [{url: "http://clearml-apiserver:8008"}]
    clearml-files:
      loadBalancer:
        servers: [{url: "http://clearml-fileserver:8081"}]

5. Start Traefik and confirm certificates issued:

$ docker compose up -d
$ docker logs traefik 2>&1 | grep -i certificate

Create the Admin Account and API Credentials

Open https://app.clearml.example.com, enter a username and company name, and click Create Account.
Settings → Workspace → Create new credentials.
Copy the generated block — you'll need it for the agent and SDK:

api {
  web_server: https://app.clearml.example.com
  api_server: https://api.clearml.example.com
  files_server: https://files.clearml.example.com
  credentials {
    "access_key" = "YOUR_ACCESS_KEY"
    "secret_key" = "YOUR_SECRET_KEY"
  }
}

Register a ClearML Agent

$ mkdir -p ~/clearml-agent && cd ~/clearml-agent
$ sudo apt install python3.12-venv -y
$ python3 -m venv clearml_venv
$ source clearml_venv/bin/activate
$ pip install clearml-agent
$ clearml-agent init

Paste the credentials block when prompted; press Enter to accept defaults for the rest. Then start the daemon:

$ clearml-agent daemon --queue default --detached

For GPU workloads:

$ clearml-agent daemon --gpus 0,1 --queue default --detached

Confirm registration in Workers & Queues → Workers.

Install the SDK and Run a First Experiment

$ source ~/clearml-agent/clearml_venv/bin/activate
$ pip install clearml scikit-learn joblib pandas
$ clearml-init

Paste the credentials block again when prompted.

$ mkdir -p ~/clearml/experiments && cd ~/clearml/experiments
$ nano 01_first_experiment.py

import joblib
from clearml import Task
from sklearn.datasets import load_iris
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score, classification_report

task = Task.init(project_name='ClearML Tutorial', task_name='01_First_Experiment',
                 tags=['tutorial', 'random-forest'])

hyperparams = {'n_estimators': 100, 'max_depth': 5, 'random_state': 42}
task.connect(hyperparams)

iris = load_iris()
X_train, X_test, y_train, y_test = train_test_split(
    iris.data, iris.target, test_size=0.2, random_state=42)

clf = RandomForestClassifier(**hyperparams).fit(X_train, y_train)
y_pred = clf.predict(X_test)
accuracy = accuracy_score(y_test, y_pred)
report = classification_report(y_test, y_pred, target_names=iris.target_names, output_dict=True)

logger = task.get_logger()
logger.report_scalar(title='Performance', series='Accuracy', value=accuracy, iteration=1)
for label, metrics in report.items():
    if isinstance(metrics, dict):
        for metric_name, value in metrics.items():
            logger.report_scalar(title=f'Class: {label}', series=metric_name, value=value, iteration=1)

model_path = 'iris_rf_model.pkl'
joblib.dump(clf, model_path)
task.upload_artifact(name='trained_model', artifact_object=model_path)
task.close()

$ python3 01_first_experiment.py

The output prints a task URL — open it to see execution details, hyperparameters, artifacts, console output, and scalar charts under the ClearML Tutorial project.

Build a Pipeline

$ nano 02_pipeline.py

from clearml import PipelineController

def step_one(pickle_data_url):
    import pickle, pandas as pd
    from clearml import StorageManager
    pickle_data_url = pickle_data_url or 'https://github.com/allegroai/events/raw/master/odsc20-east/generic/iris_dataset.pkl'
    local_iris_pkl = StorageManager.get_local_copy(remote_url=pickle_data_url)
    with open(local_iris_pkl, 'rb') as f: iris = pickle.load(f)
    df = pd.DataFrame(iris['data'], columns=iris['feature_names']); df['target'] = iris['target']
    return df

def step_two(data_frame, test_size=0.2, random_state=42):
    from sklearn.model_selection import train_test_split
    y = data_frame['target']; X = data_frame.drop(columns=['target'])
    return train_test_split(X, y, test_size=test_size, random_state=random_state)

def step_three(data):
    from sklearn.linear_model import LogisticRegression
    X_train, X_test, y_train, y_test = data
    return LogisticRegression(solver='lbfgs', max_iter=1000).fit(X_train, y_train)

if __name__ == '__main__':
    pipe = PipelineController(project='ClearML Tutorial', name='02_Pipeline_Experiment',
                              version='1.0', add_pipeline_tags=True)
    pipe.add_parameter('url', 'https://github.com/allegroai/events/raw/master/odsc20-east/generic/iris_dataset.pkl')
    pipe.add_function_step('step_one',   step_one,   function_kwargs={'pickle_data_url': '${pipeline.url}'}, function_return=['data_frame'])
    pipe.add_function_step('step_two',   step_two,   function_kwargs={'data_frame': '${step_one.data_frame}'}, function_return=['processed_data'])
    pipe.add_function_step('step_three', step_three, function_kwargs={'data': '${step_two.processed_data}'}, function_return=['model'])
    pipe.start_locally(run_pipeline_steps_locally=True)

$ python3 02_pipeline.py

Run a Hyperparameter Sweep

$ nano 03_hpo.py

from clearml import Task
from clearml.automation import HyperParameterOptimizer, DiscreteParameterRange, UniformIntegerParameterRange, RandomSearch

tasks = Task.get_tasks(project_name='ClearML Tutorial',
                       task_filter={'status': ['completed', 'published']},
                       task_name='01_First_Experiment')
base_task_id = tasks[-1].id

Task.init(project_name='ClearML Tutorial', task_name='03_Hyperparameter_Optimization',
          task_type=Task.TaskTypes.optimizer)

optimizer = HyperParameterOptimizer(
    base_task_id=base_task_id,
    hyper_parameters=[
        UniformIntegerParameterRange('General/n_estimators', min_value=10, max_value=200, step_size=20),
        DiscreteParameterRange('General/max_depth', values=[3, 5, 7, 10]),
    ],
    objective_metric_title='Performance', objective_metric_series='Accuracy',
    objective_metric_sign='max', optimizer_class=RandomSearch,
    max_number_of_concurrent_tasks=2, total_max_jobs=6,
)
optimizer.start(); optimizer.wait()
top = optimizer.get_top_experiments(1)
if top:
    print(top[0].id, top[0].get_parameters_as_dict().get('General', {}))

$ python3 03_hpo.py

Monitor progress in the Web UI under ClearML Tutorial.

Deploy a Model with ClearML Serving

$ cd ~/clearml
$ git clone https://github.com/clearml/clearml-serving.git
$ pip install clearml-serving
$ clearml-serving create --name "serving-example"

Set the serving .env:

$ nano clearml-serving/docker/.env

CLEARML_WEB_HOST="https://app.clearml.example.com"
CLEARML_API_HOST="https://api.clearml.example.com"
CLEARML_FILES_HOST="https://files.clearml.example.com"
CLEARML_API_ACCESS_KEY="YOUR_ACCESS_KEY"
CLEARML_API_SECRET_KEY="YOUR_SECRET_KEY"
CLEARML_SERVING_TASK_ID="SERVING_SERVICE_ID"

Start the Triton serving stack:

$ cd ~/clearml/clearml-serving/docker
$ docker compose --env-file .env -f docker-compose-triton.yml up -d

Train and register a sample model:

$ pip install -r ~/clearml/clearml-serving/examples/pytorch/requirements.txt
$ python3 ~/clearml/clearml-serving/examples/pytorch/train_pytorch_mnist.py

Copy the Model ID from the task's Artifacts tab, then add the endpoint:

$ clearml-serving --id SERVING_SERVICE_ID model add \
    --engine triton \
    --endpoint "test_model_pytorch" \
    --preprocess "clearml-serving/examples/pytorch/preprocess.py" \
    --model-id MODEL_ID \
    --input-size 1 28 28 --input-name "INPUT__0" --input-type float32 \
    --output-size 10 --output-name "OUTPUT__0" --output-type float32

$ docker compose --env-file .env -f docker-compose-triton.yml restart

Test inference:

$ curl -X POST "http://SERVER_IP:8080/serve/test_model_pytorch" \
    -H "Content-Type: application/json" \
    -d '{"url": "https://raw.githubusercontent.com/clearml/clearml-serving/main/examples/pytorch/5.jpg"}'

Verify Everything

$ curl -s https://api.clearml.example.com/debug.ping | head -c 100
$ curl -s -o /dev/null -w "%{http_code}" https://files.clearml.example.com/

In the Web UI: confirm the agent shows under Workers & Queues, the first experiment has metrics/artifacts, and cloning + re-enqueuing an experiment gets picked up by the agent.

Migrating from Vertex AI

Vertex AI concept	ClearML replacement
`google.cloud.aiplatform` experiment tracking	`clearml.Task` — auto-captures Git state, deps, uncommitted changes
Custom Training Jobs	`clearml.Task` + `task.execute_remotely()`, or enqueue via UI
Vertex AI Workbench notebooks	Standard Jupyter/JupyterHub — `Task.init()` works identically
Kubeflow-based Vertex Pipelines	`PipelineController` / `@pipeline` — Python-native, no compile step
Vizier hyperparameter tuning	`HyperParameterOptimizer` — runs on your own agents
Model Registry	`OutputModel` — full lineage to source experiment
Vertex AI Endpoints	ClearML Serving + Triton — canary/A-B on your own infra
Batch Prediction Jobs	No direct equivalent — migrate to standard Tasks writing to object storage
GCS data access	ClearML works with GCS paths directly, or migrate to any storage
IAM + ADC auth	API keys via `clearml.conf` or `CLEARML_API_ACCESS_KEY`/`SECRET_KEY`
`AIP_*` env conventions	Not needed — agents use standard Python/Docker, no Vertex-specific vars
MLflow tracking calls	ClearML's MLflow compatibility layer routes `mlflow.log_*` without a rewrite

Next Steps

ClearML is running with tracking, agents, pipelines, HPO, and Triton serving. From here you can:

Add GPU agents and dedicate queues per hardware profile
Migrate GCS-backed datasets using ClearML Data's explicit versioning
Wire ClearML into CI so every training run is tracked automatically

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

Deploying Matomo Analytics - An Open-Source Google Analytics Alternative

Sanskriti Harmukh — Tue, 07 Jul 2026 21:35:46 +0000

Matomo is an open-source web analytics platform that keeps full ownership of visitor data on infrastructure you control, a privacy-first alternative to Google Analytics. This guide deploys Matomo using Docker Compose with a MariaDB backend, Nginx as the entry point, and Certbot issuing the TLS certificate before the stack goes live. By the end, you'll have Matomo tracking a website with a signed HTTPS certificate at your domain.

Prepare Docker

$ sudo usermod -aG docker $USER
$ newgrp docker

Set Up the Project

1. Create the project directory:

$ mkdir matomo && cd matomo

2. Open the firewall:

$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp

3. Create the environment file:

$ nano .env

MYSQL_ROOT_PASSWORD=your_strong_mysql_root_password
MYSQL_PASSWORD=your_strong_mysql_matomo_password

Use passwords of at least 16 characters.

4. Create the Nginx config:

$ mkdir nginx
$ nano nginx/matomo.conf

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

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl http2;
    server_name matomo.example.com;

    ssl_certificate /etc/letsencrypt/live/matomo.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/matomo.example.com/privkey.pem;

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

Replace every matomo.example.com occurrence with your domain — it appears in both server blocks and the certificate paths.

Deploy with Docker Compose

$ nano docker-compose.yaml

services:
  db:
    image: mariadb:11.4
    command: --max-allowed-packet=64MB
    restart: always
    volumes:
      - matomo-db-data:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
      - MYSQL_DATABASE=matomo
      - MYSQL_USER=matomo
      - MYSQL_PASSWORD=${MYSQL_PASSWORD}
    networks:
      - matomo-net

  app:
    image: matomo
    restart: always
    depends_on:
      - db
    volumes:
      - matomo-app-data:/var/www/html
    environment:
      - MATOMO_DATABASE_HOST=db
      - MATOMO_DATABASE_USERNAME=matomo
      - MATOMO_DATABASE_PASSWORD=${MYSQL_PASSWORD}
      - MATOMO_DATABASE_DBNAME=matomo
    networks:
      - matomo-net

  nginx:
    image: nginx:alpine
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/matomo.conf:/etc/nginx/conf.d/default.conf
      - certbot-etc:/etc/letsencrypt
      - certbot-www:/var/www/certbot
    depends_on:
      - app
    networks:
      - matomo-net

  certbot:
    image: certbot/certbot
    volumes:
      - certbot-etc:/etc/letsencrypt
      - certbot-www:/var/www/certbot

volumes:
  matomo-db-data:
  matomo-app-data:
  certbot-etc:
  certbot-www:

networks:
  matomo-net:

1. Start the database and app first:

$ docker compose up -d db app

2. Issue the certificate before starting Nginx (Certbot needs port 80 free):

$ docker compose run --rm -p "80:80" certbot certonly --standalone -d matomo.example.com --email admin@example.com --agree-tos --no-eff-email

3. Start Nginx:

$ docker compose up -d nginx

Complete the Web Setup

Open https://matomo.example.com and click Next on the welcome screen.
Let Matomo run its system checks (PHP version, memory, extensions), then Next.
On the database step, set Database Server to db, and enter the matomo user and the password from .env.
Matomo creates its tables — click Next to create the Superuser account (username, password, email).
Add your first website: name, URL, timezone, and whether it's ecommerce.
Copy the generated tracking snippet and paste it before </head> on your site's pages.
Finish the wizard and sign in with the Superuser credentials.
The dashboard loads, ready to track traffic.

Next Steps

Matomo is running with HTTPS and a working database backend. From here you can:

Add more websites and grant scoped access to additional user accounts
Enable Heatmaps, Session Recording, or the Marketing Campaigns Reporting plugin
Set up scheduled email reports under Administration → Personal → Email Reports

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

Deploying Plausible Analytics - Self-Hosted Web Analytics Platform

Sanskriti Harmukh — Tue, 07 Jul 2026 21:29:23 +0000

Plausible Analytics is an open-source, self-hosted web analytics tool that tracks traffic without cookies or personal data collection, a privacy-first alternative to Google Analytics. This guide deploys Plausible Community Edition using Docker Compose, fronts it with Nginx, and secures it with a Let's Encrypt certificate. By the end, you'll have Plausible tracking a website's traffic securely at your domain.

Configure the Environment

1. Clone the Community Edition repo:

$ mkdir ~/plausible
$ cd ~/plausible
$ git clone https://github.com/plausible/community-edition.git
$ cd community-edition

2. Generate a secret key:

$ openssl rand -base64 64 | tr -d '\n'

3. Create the environment file:

$ nano .env

ADMIN_USER_EMAIL=admin@example.com
ADMIN_USER_NAME=admin
ADMIN_USER_PWD=ADMIN_PASSWORD
BASE_URL=https://plausible.example.com
SECRET_KEY_BASE=YOUR_SECRET_KEY_BASE

DATABASE_URL=postgres://postgres:postgres@plausible_db:5432/plausible_db
CLICKHOUSE_DATABASE_URL=http://plausible_events_db:8123/plausible_events_db

Fill in your email, a strong admin password, your domain, and the secret key generated above.

4. Expose the app port via a Compose override (auto-merged with compose.yml):

$ nano compose.override.yaml

services:
  plausible:
    ports:
      - 127.0.0.1:8000:8000

Deploy with Docker Compose

$ docker compose up -d
$ docker compose ps

Confirm the app, Postgres, and ClickHouse (events DB) containers are all running.

Front with Nginx and Let's Encrypt

1. Install Nginx:

$ sudo apt update
$ sudo apt install nginx -y

2. Create the virtual host:

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

server {
    listen       80;
    listen       [::]:80;
    server_name  plausible.example.com;

    access_log  /var/log/nginx/plausible.access.log;
    error_log   /var/log/nginx/plausible.error.log;

    location / {
      proxy_pass http://127.0.0.1:8000;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "Upgrade";
    }
}

3. Enable and test:

$ sudo ln -s /etc/nginx/sites-available/plausible.conf /etc/nginx/sites-enabled/
$ sudo nginx -t
$ sudo systemctl reload nginx

4. Issue a Let's Encrypt certificate:

$ sudo apt install certbot python3-certbot-nginx -y
$ sudo ufw allow 80,443/tcp
$ sudo certbot --nginx -d plausible.example.com -m admin@example.com --agree-tos --no-eff-email

Create the Admin Account and Add a Site

Open https://plausible.example.com/register.
Enter your name, email, and password, then Create my account.
Enter the domain you want to track, pick your reporting timezone, click Install Plausible.
Copy the JavaScript tracking snippet into your site's <head>. Click Verify Script installation once it's live.
Refresh after the first page view registers, the dashboard opens with live traffic stats.

Next Steps

Plausible is running and served securely over HTTPS. From here you can:

Add more sites to track from the same dashboard
Set up email or Slack weekly/monthly reports under site settings
Enable the Stats API for custom dashboards or exporting data elsewhere

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

Deploying Dokploy - Self-Hosted PaaS for Docker Applications on Ubuntu 24.04

Sanskriti Harmukh — Tue, 07 Jul 2026 21:12:42 +0000

Dokploy is an open-source, self-hosted PaaS, a free alternative to Heroku, Vercel, and Netlify, that deploys apps from Git, manages databases, and routes traffic with Traefik's automatic HTTPS. This guide installs Dokploy on Ubuntu 24.04, deploys a sample app from a public GitHub repo, attaches a custom domain with a Let's Encrypt certificate, provisions a one-click PostgreSQL database, and checks the resource monitoring dashboard. By the end, you'll have a working PaaS running an app and a database behind HTTPS.

Prerequisite: Ubuntu 24.04 server, non-root sudo user, DNS A records for two subdomains (e.g. dokploy.example.com for the dashboard, app.example.com for your app).

Install Dokploy

1. Update packages:

$ sudo apt update

2. Run the installer (installs Docker if missing, sets up Swarm mode, deploys the Dokploy stack):

$ curl -sSL https://dokploy.com/install.sh | sudo sh

Congratulations, Dokploy is installed!
Wait 15 seconds for the server to start
Please go to http://YOUR-SERVER-IP:3000

3. Add your user to the Docker group:

$ sudo usermod -aG docker $USER
$ newgrp docker

4. Verify the services:

$ docker service ls

ID             NAME               MODE         REPLICAS   IMAGE
yjuz1bv9slln   dokploy            replicated   1/1        dokploy/dokploy:latest
icesr4uht5py   dokploy-postgres   replicated   1/1        postgres:16
aqb1hms95ox8   dokploy-redis      replicated   1/1        redis:7

Access the Dashboard

Open http://SERVER_IP:3000, enter your name, email, and password, and click Register. You land on the main project view.

Note: This is HTTP on port 3000 — HTTPS for the dashboard gets set up later in "Secure the Dokploy Dashboard."

Deploy a Sample App

1. Create a project — Create Project, name it (e.g. demo-project), Create.

2. Add an application — Create Service → Application, name it (e.g. hello-app).

3. Configure the source under General:

Provider: GitHub (or Git for custom repos)
Repository URL: e.g. https://github.com/dokploy/hello-world
Branch: main

4. Set the build type: Nixpacks (auto-detects language/dependencies). Other options: Heroku Buildpacks, Paketo Buildpacks, or a custom Dockerfile.

5. Save, then click Deploy. Watch the Deployments tab for build progress, and Logs for runtime output:

Server listening on port 3000

Add a Custom Domain with SSL

1. Open the firewall:

$ sudo ufw allow 80/tcp
$ sudo ufw allow 443/tcp
$ sudo ufw enable
$ sudo ufw status

2. On the app's Domains tab, click Add Domain:

Host: app.example.com
Container Port: match what your app listens on (check the logs)
HTTPS: enabled
Certificate Provider: Let's Encrypt

3. Confirm DNS resolves to your server:

$ sudo apt install -y dnsutils
$ dig +short app.example.com

Output should match your server's public IP.

4. Visit https://app.example.com — Traefik issues the certificate on first request and renews automatically before expiry.

Secure the Dokploy Dashboard

Settings → Web Server, set a domain (e.g. dokploy.example.com).
Enable HTTPS with Let's Encrypt.
Confirm https://dokploy.example.com works.
Once confirmed, disable direct IP:port access:

$ docker service update --publish-rm "published=3000,target=3000,mode=host" dokploy

Warning: Confirm the HTTPS domain works before running this — otherwise you lock yourself out of the dashboard.

Deploy a Database

In your project, Create Service → Database → PostgreSQL, name it (e.g. app-db), Create.
The General tab shows user, database name, password, internal port/host, and a ready-to-use Internal Connection URL. Only set External Port if you need access from outside the server.
Click Deploy.
(Optional) Backups tab — set frequency and an S3-compatible destination for off-server backup storage.

Connect the app: copy the Internal Connection URL into the app's Environment tab:

DATABASE_URL=INTERNAL-CONNECTION-URL

Save and redeploy.

Monitor Resources

The app's Monitoring tab graphs CPU, memory, block I/O, and network I/O in real time. Use Advanced to set CPU and memory limits per container.

Next Steps

Dokploy is running an app and a database behind HTTPS. From here you can:

Deploy a Docker Compose stack instead of a single app for multi-service projects
Add remote servers to Dokploy for multi-node deployments
Configure custom Traefik middleware for auth, rate limiting, or redirects

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

Deploying Ngrok Ingress Controller on Kubernetes

Sanskriti Harmukh — Tue, 07 Jul 2026 21:09:26 +0000

Ngrok is a distributed reverse proxy that exposes applications to the internet via a masked external domain, without touching internal networking. The Ngrok Ingress Controller brings that model to Kubernetes as an Ingress-as-a-service: it connects your cluster to a static Ngrok domain and offloads traffic management, load balancing, TLS, and authentication to the Ngrok edge instead of the cluster. This guide installs the controller via Helm, deploys a sample app, exposes it through an Ingress resource on a static Ngrok domain, and secures it with GitHub OAuth. By the end, you'll have a cluster app reachable on the internet with no LoadBalancer service involved.

Prerequisite: An Ngrok account with a static domain configured (e.g. example.ngrok-free.app), a Kubernetes cluster (3+ nodes), kubectl configured, and Helm installed (sudo snap install helm --classic).

Install the Ngrok Ingress Controller

1. Generate an Ngrok API key and an AuthToken from your Ngrok dashboard, then export them:

$ export NGROK_AUTHTOKEN=YOUR_AUTHTOKEN
$ export NGROK_API_KEY=YOUR_API_KEY

2. Add and update the Helm repo:

$ helm repo add ngrok https://ngrok.github.io/kubernetes-ingress-controller
$ helm repo update

3. Install the controller:

$ helm install ngrok-ingress-controller ngrok/kubernetes-ingress-controller \
    --namespace ngrok-ingress-controller \
    --create-namespace \
    --set credentials.apiKey=$NGROK_API_KEY \
    --set credentials.authtoken=$NGROK_AUTHTOKEN

4. Verify the deployment and pods:

$ kubectl get deploy -n ngrok-ingress-controller
$ kubectl get pods -n ngrok-ingress-controller

Deploy a Sample Application

1. Save the deployment manifest:

$ nano game-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-snake-game
  namespace: ngrok-ingress-controller
spec:
  replicas: 2
  selector:
    matchLabels:
      app: example-snake-game
  template:
    metadata:
      labels:
        app: example-snake-game
    spec:
      containers:
        - name: game-container
          image: thoschu/de.schulte360.web.snake
          ports:
            - name: http
              containerPort: 8080

$ kubectl apply -f game-deployment.yaml

2. Save the Service manifest:

$ nano game-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: example-game-service
  namespace: ngrok-ingress-controller
spec:
  ports:
    - name: http
      port: 8080
      targetPort: 8080
  selector:
    app: example-snake-game

$ kubectl apply -f game-service.yaml

3. Confirm everything is running:

$ kubectl get deploy -n ngrok-ingress-controller
$ kubectl get pods -n ngrok-ingress-controller
$ kubectl get service -n ngrok-ingress-controller

Configure the Ngrok Ingress

1. Save the Ingress manifest (replace example.ngrok-free.app with your domain):

$ nano app-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-game-ingress
  namespace: ngrok-ingress-controller
spec:
  ingressClassName: ngrok
  rules:
    - host: example.ngrok-free.app
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: example-game-service
                port:
                  number: 8080

2. Apply it and confirm the host is registered:

$ kubectl apply -f app-ingress.yaml
$ kubectl get ingress -n ngrok-ingress-controller

The HOSTS column shows your Ngrok domain.

3. Check the edge in the Ngrok dashboard:

Edges → Cloud Edge — find the edge created by kubernetes-ingress-controller.
Click GLOBAL to see the backend Kubernetes endpoint mapping (k8s.ngrok.com/service=..., k8s.ngrok.com/port=8080).

4. Open the domain in a browser — the snake game loads through the Ngrok edge, no LoadBalancer service involved.

Secure the App with GitHub OAuth

Ngrok's edge supports OAuth, OpenID Connect, SAML, mutual TLS, and IP restrictions — all enforced before traffic reaches your cluster.

In the Ngrok dashboard, open Edges → Cloud Edge, select the domain, and open Routes.
Click OAuth → Begin setup.
Pick GitHub as the Identity Provider, keep Use an ngrok-managed OAuth application enabled.
Under Authorization, keep Restrict access to users that both authenticate and match a given set of rules.
In Email Domains, enter the domain to allow (e.g. yourcompany.com), or list specific addresses under Email Addresses.
Save the changes.
Reload the app's domain — a GitHub sign-in page appears. Authorize the app; if your account matches the allowed domain/email, you land on the app.

Next Steps

The Ngrok Ingress Controller is routing traffic to your cluster with GitHub-gated access. From here you can:

Swap GitHub for Google, GitLab, Microsoft, SAML, or mutual TLS depending on your auth requirements
Route multiple services through the same domain using additional Ingress paths
Upgrade your Ngrok plan to use a custom domain instead of *.ngrok-free.app

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

Deploying PocketBase - Open-Source Go Backend Platform on Linux

Sanskriti Harmukh — Tue, 07 Jul 2026 21:07:11 +0000

PocketBase is an open-source backend written in Go that bundles a real-time SQLite database, authentication, file uploads, and an admin dashboard into a single binary. This guide deploys PocketBase using Docker Compose with Traefik handling automatic HTTPS, admin credentials injected via environment variables, and a sample collection queried through the REST API. By the end, you'll have PocketBase serving a working backend securely at your domain.

Set Up the Directory Structure

1. Create the project folder and data directory:

$ mkdir -p ~/pocketbase/pb_data
$ cd ~/pocketbase

2. Create the environment file:

$ nano .env

DOMAIN=pocketbase.example.com
LETSENCRYPT_EMAIL=admin@example.com
PB_ADMIN_EMAIL=admin@example.com
PB_ADMIN_PASSWORD="SecurePassword123"

Keep the quotes around the password if it contains special characters.

Deploy with Docker Compose

1. Create the Docker Compose manifest:

$ nano docker-compose.yaml

services:
  traefik:
    image: traefik:v3.6
    container_name: traefik
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "letsencrypt:/letsencrypt"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
    restart: unless-stopped

  pocketbase:
    image: ghcr.io/muchobien/pocketbase:0.36.2
    container_name: pocketbase
    environment:
      - PB_ADMIN_EMAIL=${PB_ADMIN_EMAIL}
      - PB_ADMIN_PASSWORD=${PB_ADMIN_PASSWORD}
    expose:
      - "8090"
    volumes:
      - "./pb_data:/pb_data"
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.pocketbase.rule=Host(`${DOMAIN}`)"
      - "traefik.http.routers.pocketbase.entrypoints=websecure"
      - "traefik.http.routers.pocketbase.tls.certresolver=letsencrypt"
      - "traefik.http.services.pocketbase.loadbalancer.server.port=8090"
    restart: unless-stopped

volumes:
  letsencrypt:

Note: PocketBase auto-creates the admin account only on first startup, when pb_data is empty. To reinitialize the admin on an existing install: sudo rm -rf ~/pocketbase/pb_data/*, this permanently deletes all stored data.

2. Start the services:

$ docker compose up -d

3. Verify both services are running:

$ docker compose ps
$ docker compose logs

Access the Admin Dashboard

Open https://pocketbase.example.com/_/ and sign in with PB_ADMIN_EMAIL / PB_ADMIN_PASSWORD from .env. The dashboard covers:

Collections — schemas, fields, validation, API rules
Users — accounts, email verification, access control
Logs — request/error history
Settings — email delivery, external storage, OAuth, scheduled backups

Create a Collection and Query the API

1. Click **+ New collection, name it tasks, and add fields:**

title — Plain text
completed — Bool

2. In **API Rules, set:**

List/Search and View: leave empty (public read)
Create / Update / Delete: @request.auth.id != "" (requires auth)

Click Save changes.

3. Add a record — title: "Learn PocketBase API", completed unchecked.

4. Query the collection over HTTPS:

$ curl -s https://pocketbase.example.com/api/collections/tasks/records | jq

{
  "items": [
    {
      "collectionId": "pbc_2602490748",
      "collectionName": "tasks",
      "completed": false,
      "id": "z35xnphgqng0bff",
      "title": "Learn PocketBase API"
    }
  ],
  "page": 1,
  "perPage": 30,
  "totalItems": 1,
  "totalPages": 1
}

5. Filter with a query parameter:

$ curl -s "https://pocketbase.example.com/api/collections/tasks/records?filter=(completed=false)" | jq '.items[].title'

"Learn PocketBase API"

Next Steps

PocketBase is running and served securely over HTTPS. From here you can:

Build a frontend against the auto-generated REST/Realtime API
Back up the entire app by copying the pb_data directory, no separate database dump needed
Configure SMTP, OAuth providers, and S3-compatible file storage under Settings

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

Deploying Neko - Self-Hosted Virtual Browser Platform on Linux

Sanskriti Harmukh — Tue, 07 Jul 2026 21:04:24 +0000

Neko is an open-source virtual browser platform that runs inside Docker and streams an interactive browser session to multiple users over WebRTC, with synchronized audio/video and admin-controlled input handoff. This guide deploys Neko using Docker Compose with Traefik handling automatic HTTPS, and persistent Firefox profile storage. By the end, you'll have a shared virtual browser session running securely at your domain.

Set Up the Directory Structure

1. Create the project directory with a Firefox profile subdirectory:

$ mkdir -p ~/neko/profile
$ cd ~/neko

2. Create the environment file:

$ nano .env

DOMAIN=neko.example.com
LETSENCRYPT_EMAIL=admin@example.com
NEKO_ADMIN_PASSWORD=StrongAdminPassword123
NEKO_USER_PASSWORD=StrongUserPassword456

3. Set ownership on the profile directory, Neko runs as UID 1000:

$ sudo chown -R 1000:1000 ~/neko/profile

Deploy with Docker Compose

1. Create the Docker Compose manifest:

$ nano docker-compose.yaml

services:
  traefik:
    image: traefik:v3.6
    container_name: traefik
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true"
      - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.letsencrypt.acme.email=${LETSENCRYPT_EMAIL}"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "letsencrypt:/letsencrypt"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
    restart: unless-stopped

  neko:
    image: ghcr.io/m1k1o/neko/firefox:3
    container_name: neko
    shm_size: "2gb"
    expose:
      - "8080"
    ports:
      - "52000-52100:52000-52100/udp"
    volumes:
      - "./profile:/home/neko/.mozilla/firefox/profile.default"
    environment:
      NEKO_MEMBER_PROVIDER: "multiuser"
      NEKO_MEMBER_MULTIUSER_USER_PASSWORD: "${NEKO_USER_PASSWORD}"
      NEKO_MEMBER_MULTIUSER_ADMIN_PASSWORD: "${NEKO_ADMIN_PASSWORD}"
      NEKO_SERVER_PROXY: "true"
      NEKO_DESKTOP_SCREEN: "1280x720@30"
      NEKO_WEBRTC_EPR: "52000-52100"
      NEKO_WEBRTC_ICELITE: "true"
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.neko.rule=Host(`${DOMAIN}`)"
      - "traefik.http.routers.neko.entrypoints=websecure"
      - "traefik.http.routers.neko.tls.certresolver=letsencrypt"
      - "traefik.http.services.neko.loadbalancer.server.port=8080"
    restart: unless-stopped

volumes:
  letsencrypt:

The shm_size: "2gb" allocation is required, Firefox rendering crashes or freezes without enough shared memory. NEKO_WEBRTC_EPR opens the UDP port range WebRTC media travels over; NEKO_WEBRTC_ICELITE suits servers with a public IP and direct inbound UDP.

2. Start the services:

$ docker compose up -d

3. Verify both services are running:

$ docker compose ps
$ docker compose logs

Access Neko

Open https://neko.example.com.
Enter a display name and the admin password from .env, then click CONNECT.
The Firefox window loads in the center with a control bar below. Connected users appear as avatars; a green badge marks whoever holds control.
The side panel has Chat (activity log) and Settings (scroll sensitivity, keyboard layout, autoplay).

Run a Collaborative Session

Share the URL and the user password (not the admin one) with participants.
Each participant enters a display name + password and clicks CONNECT — their avatar appears at the bottom.
Navigate to any URL in the address bar. WebRTC streams it to everyone with minimal delay.
Right-click a user's avatar to Give Controls, Kick, or Ban IP (kick/ban are admin-only).

Next Steps

Neko is running and streaming a shared browser session over HTTPS. From here you can:

Swap the Firefox image for Chromium or a custom browser image
Add a TURN server for participants behind restrictive NATs
Scale to multiple rooms by running additional Neko containers on different subdomains

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

Deploying ClickHouse on Kubernetes

Sanskriti Harmukh — Tue, 07 Jul 2026 21:00:02 +0000

ClickHouse is an open-source, column-oriented database built for OLAP workloads, running complex analytical queries across large datasets with sub-second latency. The official ClickHouse Kubernetes Operator manages ClickHouse and Keeper clusters as CRDs, automating setup, scaling, and upgrades. This guide deploys the operator, a 3-node Keeper coordination group, and a 2-replica ClickHouse cluster with TLS, then verifies replication and connects both internally and externally. By the end, you'll have a ClickHouse cluster running on Kubernetes with encrypted client connections.

Prerequisite: Kubernetes cluster sized for 3 Keeper pods + 2 ClickHouse replicas, production clusters want 3+ nodes with 8 vCPUs and 16 GB RAM each. kubectl and Helm on your workstation.

Architecture

ClickHouse Keeper — 3-node coordination group; tracks replication and elects a leader. Each node persists to its own PVC.
ClickHouse Cluster — 2-replica database cluster. ReplicatedMergeTree uses Keeper to sync data across replicas.
Load Balancer — optional; internal cluster traffic uses the service name directly, no load balancer needed.

The Operator watches ClickHouse CRDs and reconciles StatefulSets, Services, and storage to match.

Install the Operator

1. Install cert-manager (the operator needs it to issue webhook TLS certs):

$ helm install cert-manager oci://quay.io/jetstack/charts/cert-manager \
    --create-namespace \
    --namespace cert-manager \
    --set crds.enabled=true \
    --version v1.19.2

$ kubectl wait --for=condition=Ready pods --all -n cert-manager --timeout=120s

2. Install the ClickHouse Operator:

$ helm install clickhouse-operator oci://ghcr.io/clickhouse/clickhouse-operator-helm \
    --create-namespace \
    --namespace clickhouse-operator-system

$ kubectl wait -n clickhouse-operator-system deployment/clickhouse-operator-controller-manager --for=condition=Available --timeout=120s

Create the Database Cluster

1. Create a dedicated namespace:

$ kubectl create namespace clickhouse-db

Deploy Keeper

2. Save the Keeper cluster manifest:

$ nano keeper-cluster.yaml

apiVersion: clickhouse.com/v1alpha1
kind: KeeperCluster
metadata:
  name: clickhouse-keeper
  namespace: clickhouse-db
spec:
  replicas: 3
  dataVolumeClaimSpec:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 40Gi
  podTemplate:
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchExpressions:
              - key: clickhouse.com/app
                operator: In
                values:
                - clickhouse-keeper
            topologyKey: kubernetes.io/hostname
  containerTemplate:
    resources:
      requests:
        cpu: "500m"
        memory: 1Gi
      limits:
        cpu: "1"
        memory: 2Gi

The podAntiAffinity rule spreads Keeper nodes across different machines so the group survives a single node failure. Adjust storage to your platform's minimum volume size, and pin an explicit StorageClass if your cluster has no default.

3. Apply and wait for readiness:

$ kubectl apply -f keeper-cluster.yaml
$ kubectl wait --for=condition=Ready pods -l app.kubernetes.io/instance=clickhouse-keeper-keeper -n clickhouse-db --timeout=300s

Deploy ClickHouse

4. Generate a password secret without echoing it to the terminal:

$ kubectl create secret generic clickhouse-password --from-literal=password="$(openssl rand -base64 16)" -n clickhouse-db

5. Save the TLS manifest:

$ nano clickhouse-tls.yaml

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: clickhouse-issuer
  namespace: clickhouse-db
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: clickhouse-tls
  namespace: clickhouse-db
spec:
  secretName: clickhouse-tls-cert
  issuerRef:
    name: clickhouse-issuer
    kind: Issuer
  dnsNames:
    - clickhouse-clickhouse-headless
    - clickhouse-clickhouse-headless.clickhouse-db
    - clickhouse-clickhouse-headless.clickhouse-db.svc
    - clickhouse-clickhouse-headless.clickhouse-db.svc.cluster.local

6. Apply and wait for issuance:

$ kubectl apply -f clickhouse-tls.yaml
$ kubectl wait --for=condition=Ready certificate clickhouse-tls -n clickhouse-db --timeout=120s

7. Save the ClickHouse cluster manifest:

$ nano clickhouse-cluster.yaml

apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
metadata:
  name: clickhouse
  namespace: clickhouse-db
spec:
  replicas: 2
  settings:
    defaultUserPassword:
      passwordType: password
      secret:
        name: clickhouse-password
        key: password
    tls:
      enabled: true
      serverCertSecret:
        name: clickhouse-tls-cert
  dataVolumeClaimSpec:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 50Gi
  podTemplate:
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchExpressions:
              - key: clickhouse.com/app
                operator: In
                values:
                - clickhouse-clickhouse
            topologyKey: kubernetes.io/hostname
  keeperClusterRef:
    name: clickhouse-keeper
  containerTemplate:
    resources:
      requests:
        cpu: "1"
        memory: 2Gi
      limits:
        cpu: "2"
        memory: 4Gi

8. Apply and wait for readiness:

$ kubectl apply -f clickhouse-cluster.yaml
$ kubectl wait --for=condition=Ready pods -l app.kubernetes.io/instance=clickhouse-clickhouse -n clickhouse-db --timeout=300s

Verify the Deployment

1. Check both pod groups and the cluster resource:

$ kubectl get pods -l app.kubernetes.io/instance=clickhouse-keeper-keeper -n clickhouse-db
$ kubectl get pods -l clickhouse.com/role=clickhouse-server -n clickhouse-db
$ kubectl get clickhousecluster clickhouse -n clickhouse-db

The last command's READY column reads True once all replicas are up.

2. Connect to the first pod with the built-in client:

$ kubectl exec -it clickhouse-clickhouse-0-0-0 -n clickhouse-db -- clickhouse-client --password $(kubectl get secret clickhouse-password -n clickhouse-db -o jsonpath='{.data.password}' | base64 -d)

3. Confirm the replication macros:

SELECT * FROM system.macros;

4. Create a replicated table and insert data:

CREATE TABLE default.page_views (
    event_time DateTime,
    user_id UInt64,
    page_path String
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{uuid}/{shard}', '{replica}')
ORDER BY (event_time, user_id);

INSERT INTO default.page_views VALUES
    (now() - INTERVAL 1 HOUR, 1001, '/home'),
    (now() - INTERVAL 30 MINUTE, 1002, '/products'),
    (now(), 1001, '/checkout');

Type exit to leave the session.

5. Confirm replication landed on the second pod:

$ kubectl exec -it clickhouse-clickhouse-0-1-0 -n clickhouse-db -- clickhouse-client --password $(kubectl get secret clickhouse-password -n clickhouse-db -o jsonpath='{.data.password}' | base64 -d) -q "SELECT count() FROM default.page_views"

Output 3 confirms the rows replicated to the other pod.

Connect to the Database

The operator creates a headless service, clickhouse-clickhouse-headless, on port 9000 (plain TCP) and 9440 (TLS).

Internal access — from a pod inside the cluster:

$ kubectl run clickhouse-test \
    --image=clickhouse/clickhouse-server \
    --rm -it --restart=Never \
    -n clickhouse-db \
    -- clickhouse-client \
    --host clickhouse-clickhouse-headless \
    --port 9000 \
    --password $(kubectl get secret clickhouse-password -n clickhouse-db -o jsonpath='{.data.password}' | base64 -d)

SELECT version();

External access — needs a LoadBalancer service:

$ nano clickhouse-lb.yaml

apiVersion: v1
kind: Service
metadata:
  name: clickhouse-external
  namespace: clickhouse-db
spec:
  type: LoadBalancer
  selector:
    clickhouse.com/role: clickhouse-server
  ports:
  - port: 9440
    targetPort: 9440
    protocol: TCP

$ kubectl apply -f clickhouse-lb.yaml
$ kubectl get svc clickhouse-external -n clickhouse-db

On your workstation, create a client TLS config that trusts the self-signed cert:

$ nano clickhouse-client-tls.xml

<config>
  <openSSL>
    <client>
      <verificationMode>none</verificationMode>
      <invalidCertificateHandler>
        <name>AcceptCertificateHandler</name>
      </invalidCertificateHandler>
    </client>
  </openSSL>
</config>

Connect using the LoadBalancer's external IP:

$ clickhouse-client --config clickhouse-client-tls.xml --host LB_IP --port 9440 --secure --password $(kubectl get secret clickhouse-password -n clickhouse-db -o jsonpath='{.data.password}' | base64 -d)

Note: verificationMode: none is fine for testing self-signed certs. For production, issue a cert-manager certificate covering the external domain, drop verificationMode, set caConfig to the CA path, and swap AcceptCertificateHandler for RejectCertificateHandler. Restrict the LoadBalancer to trusted IPs via firewall rules.

Scaling and Maintenance

Scaling: bump replicas in the ClickHouseCluster manifest and re-apply — the operator handles pod additions/removals and data movement.
Backups: ClickHouse has native backup/restore tooling — see the official backup docs.
Logging: wire up log collection per the official server-configuration docs to monitor cluster health.

Next Steps

ClickHouse is running with TLS and verified 2-way replication. From here you can:

Scale Keeper to 5 nodes for larger clusters needing more coordination headroom
Move backups to S3-compatible object storage for offsite retention
Front the LoadBalancer with a proper CA-issued certificate before exposing it publicly

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

Deploying Passbolt - An Open-Source Password Management Tool on Ubuntu 24.04

Sanskriti Harmukh — Thu, 02 Jul 2026 16:48:09 +0000

Passbolt is an open-source password manager built around end-to-end encryption with OpenPGP and browser extensions for Chrome and Firefox. It supports login automation, role-based access control, and credential sharing across teams. This guide deploys Passbolt CE on Ubuntu 24.04 using the official APT installer, configures Nginx and Let's Encrypt during install, and walks through the web-based setup wizard. By the end, you'll have Passbolt managing encrypted credentials securely at your domain.

Prerequisite: Ubuntu 24.04 server (also works on Debian 12, Rocky Linux 9, Alma Linux 9 — see notes below), non-root sudo user, and a domain A record pointing at the server.

Open the Firewall

$ sudo ufw allow 80,443/tcp

Install Passbolt CE (Ubuntu 24.04 / Debian 12)

1. Download the installer and the checksum file:

$ curl -LO https://download.passbolt.com/ce/installer/passbolt-repo-setup.ce.sh
$ curl -LO https://github.com/passbolt/passbolt-dep-scripts/releases/latest/download/passbolt-ce-SHA512SUM.txt

2. Verify the installer checksum:

$ sha512sum -c passbolt-ce-SHA512SUM.txt

3. Add the Passbolt repository:

$ sudo bash ./passbolt-repo-setup.ce.sh

4. Install the server:

$ sudo apt install passbolt-ce-server

Answer the interactive prompts:

Create a new database: Yes
Database admin username: root
Database admin password: (set a strong value)
Passbolt database user / password / name: create a dedicated user
Configure Nginx: Yes
SSL certificate option: Auto (Let's Encrypt)
Domain name: passbolt.example.com
Let's Encrypt email: your email

The installer issues a Let's Encrypt certificate, wires Nginx, and starts the application.

Install Passbolt CE (Rocky Linux 9 / Alma Linux 9)

$ curl -LO https://download.passbolt.com/ce/installer/passbolt-repo-setup.ce.sh
$ curl -LO https://github.com/passbolt/passbolt-dep-scripts/releases/latest/download/passbolt-ce-SHA512SUM.txt
$ sha512sum -c passbolt-ce-SHA512SUM.txt
$ sudo bash ./passbolt-repo-setup.ce.sh
$ sudo dnf install passbolt-ce-server
$ sudo /usr/local/bin/passbolt-configure

Answer the prompts:

Install local MariaDB: 1
MariaDB root password / Passbolt DB user / password / DB name
Hostname: passbolt.example.com
SSL certificate generation: 2 (Auto)
Let's Encrypt email

Complete the Web Setup

Open https://passbolt.example.com and click Get Started → Start configuration.
Enter the database connection details (host localhost, the user, password, and database name from the install).
Configure the server OpenPGP key (server name + email; keep RSA-DSA, 3072 bits).
Set the full base URL and enable Force SSL.
Configure SMTP (sender name, sender email, SMTP host, credentials).
Create the administrator account (first name, last name, username).
Set a strong passphrase and store it offline.
Download the recovery kit when prompted — without it, the account is unrecoverable.
Choose a security token color.
Install the Passbolt browser extension when prompted.
The dashboard loads, ready for credentials.

Create Folders and Credentials

Dashboard → Create → Folder — name it (e.g. Infrastructure), save.
Open the folder → Create → Password — enter name, URL, username, and the secret. Save.
Browse to the matching login page — the extension autofills via the registered passphrase.

Next Steps

Passbolt is running with HTTPS at your domain. From here you can:

Invite team members from Users → Add user with per-role permissions
Configure single sign-on (SSO) with SAML or OIDC
Enable MFA (TOTP, YubiKey, DUO) for admin accounts
Schedule encrypted backups of /etc/passbolt/gpg plus the MySQL database

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

Backing Up and Restoring PostgreSQL Databases to S3-Compatible Storage in Coolify

Sanskriti Harmukh — Thu, 02 Jul 2026 16:40:22 +0000

Coolify is an open-source, self-hosted PaaS for deploying applications and databases. Its backup engine ships with first-class support for S3-compatible object storage, so PostgreSQL backups can flow straight to Vultr Object Storage, AWS S3, Wasabi, Backblaze B2, or MinIO without extra tooling. This guide deploys a PostgreSQL service in Coolify, schedules automated backups to an S3 bucket, simulates accidental data loss, and restores the database from the backup. By the end, you'll have a working backup-and-restore loop covering a self-hosted Postgres service in Coolify.

Prerequisite: A running Coolify install (2 CPU cores, 4 GB RAM minimum) and an S3-compatible bucket with access key and secret key.

Deploy a PostgreSQL Service in Coolify

Open the Coolify dashboard at http://SERVER_IP:8000.
Projects → Add — name the project (e.g. Pg Backup) and continue.
Add New Resource → Databases → PostgreSQL (standalone — not Supabase or pgVector variants).
Click Start to deploy.

Insert Sample Data

1. Connect to the running database from the service's terminal in the Coolify UI:

$ psql -U postgres

2. Create a table and insert a couple of rows:

postgres=# CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

postgres=# INSERT INTO users (name, email) VALUES ('John Doe', 'john@example.com');
postgres=# INSERT INTO users (name, email) VALUES ('Jane Smith', 'jane@example.com');

postgres=# SELECT * FROM users;
 id |    name    |      email
----+------------+------------------
  1 | John Doe   | john@example.com
  2 | Jane Smith | jane@example.com
(2 rows)

Register S3-Compatible Storage in Coolify

Create a bucket in your S3 provider (e.g. pg-backups). Capture the bucket name, endpoint URL, access key, and secret key.
In Coolify: S3 Storages → Add:
- Name: Backup Storage
- Endpoint: provider URL — e.g. ewr1.vultrobjects.com, s3.us-east-1.amazonaws.com, or s3.wasabisys.com
- Bucket: pg-backups
- Region: e.g. us-east-1
- Access Key / Secret Key: S3 credentials
Click Validate Connection & Continue.

Enable Scheduled Backups

Open the PostgreSQL resource dashboard → Backup tab.
Add a backup schedule:
- Frequency: */1 * * * * for a one-minute test cadence (drop to daily before production)
- Check Save to S3
- Save
Open the schedule → Settings → enable Backup All Databases (otherwise only the default postgres database gets dumped).
Wait one minute for the first run. Confirm the dump (e.g. pg-dump-all-1771242721.gz) lands in the S3 bucket.

Simulate Data Loss

$ psql -U postgres

postgres=# DROP TABLE users;
postgres=# SELECT * FROM users;
ERROR:  relation "users" does not exist
LINE 1: SELECT * FROM users;
                      ^

Restore from S3

Open the S3 bucket, locate the backup file, and copy its object key (the path without the bucket name) — e.g.:

data/coolify/backups/databases/root-team-0/postgresql-database-k8480c44sogcswc0w4oskg4c-k8480c44sogcswc0w4oskg4c/pg-dump-all-1771242721.gz

In the PostgreSQL resource → Configuration → Import Backup → Choose Restore Method → Select from S3.
Pick the configured S3 storage (Backup Storage), paste the object key into S3 File Path, and enable Backup includes all databases for multi-database dumps.
Click Check File — Coolify confirms it can read the file.
Click Restore Database from S3, type the case-sensitive confirmation text, click Continue, and enter the Coolify password to confirm.

Verify the Restore

$ psql -U postgres

postgres=# SELECT * FROM users;
 id |    name    |      email
----+------------+------------------
  1 | John Doe   | john@example.com
  2 | Jane Smith | jane@example.com
(2 rows)

The original rows are back — the backup captured the database state before the drop.

Next Steps

You now have working backups and restores for Coolify-managed PostgreSQL. From here you can:

Lower the schedule frequency (0 2 * * * for nightly) and set retention
Apply the same pattern to MySQL, MariaDB, MongoDB, and other Coolify-managed databases
Mirror backups to a second S3 region for disaster recovery

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