The whole stack runs on a budget VPS – 1 vCPU, 2.9GB RAM, 30GB disk, $22/year. All three services are running with room to spare.

Initial Setup

SSH key auth first, password auth off:

1# local: generate key if you don't have one
2ssh-keygen -t ed25519 -C "your_email@example.com"
3# paste ~/.ssh/id_ed25519.pub into your provider's SSH key field
4
5# on the server: disable password login
6sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
7systemctl restart sshd

Test key login before disabling password auth. If you lock yourself out, you’re recovering via the provider’s console.

Swap – critical on 3GB RAM:

1fallocate -l 2G /swapfile
2chmod 600 /swapfile
3mkswap /swapfile
4swapon /swapfile
5echo '/swapfile none swap sw 0 0' >> /etc/fstab

Without this, CouchDB and Conduit together will occasionally OOM under load.

Firewall:

1ufw allow ssh
2ufw allow 80/tcp
3ufw allow 443/tcp
4ufw allow 3478        # TURN (UDP+TCP)
5ufw allow 5349        # TURN TLS
6ufw allow 49152:65535/udp  # TURN relay range
7ufw enable

The TURN ports are for Matrix voice/video – skip them if you’re not setting up coturn.

Docker:

1curl -fsSL https://get.docker.com | sh

Service 1: Obsidian LiveSync (CouchDB)

LiveSync uses CouchDB as the sync backend. Install it directly on the host rather than in Docker – it’s simpler to configure and easier to troubleshoot.

1apt install -y couchdb

The installer prompts for admin credentials. Set them and keep them somewhere safe.

Configure /opt/couchdb/etc/local.ini:

 1[chttpd]
 2bind_address = 127.0.0.1
 3
 4[couch_httpd_auth]
 5require_valid_user = true
 6
 7[httpd]
 8enable_cors = true
 9
10[cors]
11origins = app://obsidian.md, capacitor://localhost, http://localhost
12credentials = true
13headers = accept, authorization, content-type, origin, referer
14methods = GET, PUT, POST, HEAD, DELETE
15max_age = 3600

1systemctl restart couchdb
2curl -X PUT http://admin:PASSWORD@localhost:5984/obsidian-sync

nginx config:

 1server {
 2    listen 80;
 3    server_name sync.your.domain;
 4    location / {
 5        proxy_pass http://127.0.0.1:5984;
 6        proxy_set_header Host $host;
 7        proxy_set_header X-Real-IP $remote_addr;
 8        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 9    }
10}

Get a cert: certbot --nginx -d sync.your.domain

In Obsidian: install the LiveSync community plugin, set the CouchDB URI to your domain, enter credentials, set a database name and an E2E passphrase. Enable sync. The passphrase encrypts vault content before it leaves your device – CouchDB never sees plaintext.

Service 2: Private Matrix Chat (Conduit + coturn)

Conduit is a Matrix homeserver written in Rust – much lighter than Synapse, which would be too heavy for 3GB RAM. I run it with federation disabled – this is a personal instance, not connected to the public Matrix network.

/opt/conduit/docker-compose.yml:

 1services:
 2  conduit:
 3    image: matrixconduit/matrix-conduit:latest
 4    restart: unless-stopped
 5    volumes:
 6      - conduit_data:/var/lib/matrix-conduit
 7    environment:
 8      CONDUIT_SERVER_NAME: "chat.your.domain"
 9      CONDUIT_DATABASE_BACKEND: "rocksdb"
10      CONDUIT_ALLOW_REGISTRATION: "true"      # flip to false after accounts created
11      CONDUIT_ALLOW_FEDERATION: "false"
12      CONDUIT_MAX_REQUEST_SIZE: "20000000"
13      CONDUIT_LOG: "warn"
14    ports:
15      - "127.0.0.1:6167:6167"
16
17volumes:
18  conduit_data:

1cd /opt/conduit && docker compose up -d

For voice and video calls, Matrix uses WebRTC – which needs a TURN server to traverse NAT. coturn handles this:

1apt install -y coturn
2openssl rand -hex 32   # generate a static auth secret, keep it

/etc/turnserver.conf:

listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=YOUR_SECRET
realm=chat.your.domain
cert=/etc/letsencrypt/live/chat.your.domain/fullchain.pem
pkey=/etc/letsencrypt/live/chat.your.domain/privkey.pem
min-port=49152
max-port=65535

nginx config:

 1server {
 2    listen 80;
 3    server_name chat.your.domain;
 4    location / {
 5        proxy_pass http://127.0.0.1:6167;
 6        proxy_set_header Host $host;
 7        proxy_set_header X-Real-IP $remote_addr;
 8        proxy_set_header Upgrade $http_upgrade;
 9        proxy_set_header Connection "upgrade";
10    }
11}

Once Conduit is up: go to Element Web, set homeserver to your domain, register your accounts while ALLOW_REGISTRATION is true, then flip it to false and restart the container. Anyone who finds your homeserver URL can register while it’s open.

Service 3: Calibre-Web

Calibre-Web gives you a browser-based library for EPUB, PDF, and MOBI files. The Docker image is from linuxserver.io.

Critical step before starting the container: Calibre-Web needs a properly initialized metadata.db. Not an empty file, not a directory – a valid Calibre library database. It must be created by calibredb.

1apt install -y calibre   # ~300MB, takes a few minutes
2mkdir -p /opt/calibre/books
3calibredb --with-library /opt/calibre/books list   # initializes metadata.db
4chown -R 1000:1000 /opt/calibre/books              # container runs as uid 1000
5chmod -R 755 /opt/calibre/books

Do this before starting the container. If you start it first and hit “invalid path” or “DB not writable”, this is why.

/opt/calibre/docker-compose.yml:

 1services:
 2  calibre-web:
 3    image: lscr.io/linuxserver/calibre-web:latest
 4    restart: unless-stopped
 5    environment:
 6      - PUID=1000
 7      - PGID=1000
 8      - TZ=Asia/Kolkata
 9    volumes:
10      - calibre_config:/config
11      - /opt/calibre/books:/books
12    ports:
13      - "127.0.0.1:8083:8083"
14
15volumes:
16  calibre_config:

nginx config:

1server {
2    listen 80;
3    server_name books.your.domain;
4    location / {
5        proxy_pass http://127.0.0.1:8083;
6        proxy_set_header Host $host;
7        proxy_set_header X-Real-IP $remote_addr;
8    }
9}

Default login is admin / admin123. Change it immediately. Set library path to /books.

Cloudflare in Front

All three subdomains go through Cloudflare. DNS A records point to the VPS IP, proxy status set to orange cloud (proxied) for all three. SSL mode set to Full – not Full Strict, since the Let’s Encrypt cert on origin is valid enough and Full Strict adds complexity for no real benefit here.

certbot handles the Let’s Encrypt certs on the origin:

1certbot --nginx -d sync.your.domain
2certbot --nginx -d chat.your.domain
3certbot --nginx -d books.your.domain

Resource Usage

All three services running simultaneously:

Swap barely touched. Disk at ~6GB of 30GB. Plenty of headroom for adding services.

Pitfalls

The whole thing took an afternoon to set up. $22/year for services I fully control and can inspect end to end.

This post covers what I set up, what broke, and what actually works now.

Starting point

The provider gives you a root password on first boot. First thing I did was generate an ed25519 SSH key pair locally, paste the public key into the VPS control panel, add a Host personal entry to ~/.ssh/config, and verify key auth works before touching anything else. Then disabling password login:

1sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
2systemctl restart sshd

Don’t close your existing SSH session before confirming you can open a new one with key auth. Classic footgun.

Before any services: add swap. 2.9GB of RAM is workable but tight once Docker gets involved.

1fallocate -l 2G /swapfile
2chmod 600 /swapfile
3mkswap /swapfile
4swapon /swapfile
5echo '/swapfile none swap sw 0 0' >> /etc/fstab

Then update packages, set up UFW to allow SSH, HTTP, HTTPS, and the TURN port range (3478, 5349, 49152:65535), and drop everything else.

After all that, the box looked like this:

OS: Ubuntu 24.04 LTS
RAM: 2.9GB (470MB used, 2.4GB free)
Disk: 30GB (2.4GB used, 26GB free)
Swap: 2GB (none used yet)
CPU: 1 core

Plenty of room to work with.

Service 1: Obsidian LiveSync

CouchDB as the backend for Obsidian’s LiveSync community plugin. The plugin syncs your vault across devices using a CouchDB instance you control. End-to-end encrypted via a passphrase set in the plugin – CouchDB stores ciphertext only.

Install CouchDB natively (not Docker – LiveSync requires specific CouchDB config that’s simpler to manage directly):

1apt install -y couchdb

The installer asks for admin credentials. Set them and remember them. Then configure CouchDB to accept external connections by editing /opt/couchdb/etc/local.ini:

 1[chttpd]
 2bind_address = 127.0.0.1  ; nginx will proxy, no need to expose directly
 3
 4[couch_httpd_auth]
 5require_valid_user = true
 6
 7[httpd]
 8enable_cors = true
 9
10[cors]
11origins = app://obsidian.md, capacitor://localhost, http://localhost
12credentials = true
13headers = accept, authorization, content-type, origin, referer
14methods = GET, PUT, POST, HEAD, DELETE
15max_age = 3600

Then create the sync database:

1curl -X PUT http://admin:password@localhost:5984/obsidian-sync

nginx proxies the sync subdomain to localhost:5984. Cloudflare sits in front with Full SSL mode. In the Obsidian LiveSync plugin settings, point it at your CouchDB subdomain, enter the credentials, set your E2E passphrase, and enable sync.

It just works after that. Notes push from Mac, pull on iPhone, no iCloud dependency.

Service 2: Private Matrix Chat

Conduit is a Matrix homeserver written in Rust. It’s small (62MB RAM), single-binary, and handles everything a private two-person server needs. Element Web as the client – works in any browser, no app required.

Docker Compose setup:

 1services:
 2  conduit:
 3    image: matrixconduit/matrix-conduit:latest
 4    restart: unless-stopped
 5    volumes:
 6      - conduit_data:/var/lib/matrix-conduit
 7    environment:
 8      CONDUIT_SERVER_NAME: "your.chat.domain"
 9      CONDUIT_DATABASE_BACKEND: "rocksdb"
10      CONDUIT_ALLOW_REGISTRATION: "true"
11      CONDUIT_ALLOW_FEDERATION: "false"
12      CONDUIT_MAX_REQUEST_SIZE: "20000000"
13      CONDUIT_TRUSTED_SERVERS: '["matrix.org"]'
14      CONDUIT_LOG: "warn"
15    ports:
16      - "127.0.0.1:6167:6167"
17
18volumes:
19  conduit_data:

ALLOW_FEDERATION: false is important for a private server. No traffic leaves your machine to federate with matrix.org or anyone else.

For Element Web, the easiest route is the hosted version at app.element.io – just point it at your homeserver URL when logging in. If you want it self-hosted too, serve the static build from nginx.

For voice and video calls, WebRTC needs a TURN server or calls fail behind NAT. coturn handles this:

1apt install -y coturn

Configure /etc/turnserver.conf:

listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=<generate with: openssl rand -hex 32>
realm=your.chat.domain
cert=/etc/letsencrypt/live/your.chat.domain/fullchain.pem
pkey=/etc/letsencrypt/live/your.chat.domain/privkey.pem

Add the TURN server details in Conduit’s config, then tell Element where to find it in the Synapse well-known file. After that, voice and video calls work reliably regardless of NAT.

Create user accounts via the Conduit admin API or by registering through Element while ALLOW_REGISTRATION: true. After both accounts are created, set ALLOW_REGISTRATION: false so no new accounts can be made.

Service 3: Personal Book Library

Calibre-Web in Docker. Serves EPUB, PDF, MOBI with a clean browser interface. Can read books directly in the browser without downloading.

The setup hit two non-obvious problems worth documenting.

Problem 1: Calibre-Web needs a real metadata.db

The container starts and asks for a library path. I pointed it at /books (mapped to /opt/calibre/books on the host). It said “invalid path.”

The issue is that Calibre-Web expects a valid Calibre library database (metadata.db) to already exist at that path. An empty directory is not enough. The database needs to have the correct schema – not just the file.

The fix is to install Calibre on the host and use calibredb to initialize the library properly:

1apt install -y calibre  # takes a while, ~300MB
2calibredb --with-library /opt/calibre/books list

The calibredb list call creates a properly initialized metadata.db if one doesn’t exist. After this, /books becomes a valid library path.

Problem 2: Permissions

Even after the database exists, Calibre-Web may refuse to write to it. The linuxserver/calibre-web Docker image runs as user 1000 internally. If the files on the host are owned by root, the container can’t write.

1chown -R 1000:1000 /opt/calibre/books
2chmod -R 755 /opt/calibre/books

After both fixes, the setup page accepted /books and the library came up clean.

Docker Compose:

 1services:
 2  calibre-web:
 3    image: lscr.io/linuxserver/calibre-web:latest
 4    restart: unless-stopped
 5    environment:
 6      - PUID=1000
 7      - PGID=1000
 8      - TZ=Asia/Kolkata
 9    volumes:
10      - calibre_config:/config
11      - /opt/calibre/books:/books
12    ports:
13      - "127.0.0.1:8083:8083"
14
15volumes:
16  calibre_config:

Default login after first start: admin / admin123. Change it immediately.

nginx and Cloudflare

All three services sit behind nginx. Each subdomain gets a server block that proxies to the local port:

1server {
2    listen 80;
3    server_name your.sync.domain;
4    location / {
5        proxy_pass http://127.0.0.1:5984;
6        proxy_set_header Host $host;
7        proxy_set_header X-Real-IP $remote_addr;
8    }
9}

Cloudflare handles DNS and acts as the TLS terminator in Full mode. Let’s Encrypt issues certs on each subdomain via certbot. The certs auto-renew – I won’t have to touch them.

Credentials stored in pass on the Mac, encrypted with a GPG key. No plaintext passwords in config files or notes.

Resource usage after all three services

Service          RAM
---------        ----
Calibre-Web      159MB
Conduit          62MB
CouchDB          ~80MB
nginx + system   ~453MB
---------        ------
Total            754MB / 2.9GB  (26% used)
Swap used        780KB
Disk used        ~6GB / 30GB

74% of RAM still free. The 2GB swap sits untouched. There’s room for more things.

What’s next

The daily note has some ideas: run Bifrost on the VPS and wire up a blog-writing pipeline, use the unlimited bandwidth for a VPN, set up a small agent. The RAM budget will tighten but there’s headroom to experiment.

For $22/year, the box is already earning its keep.

Tools: Ubuntu 24.04, Docker, nginx, Cloudflare, Let’s Encrypt, CouchDB, Conduit (Matrix), Element Web, Calibre-Web, coturn, UFW, pass + GPG, certbot.

References

• LandChad.net – practical self-hosting guides, covers nginx, certbot, and many services: https://landchad.net
• Conduit (Matrix homeserver in Rust): https://conduit.rs
• Obsidian LiveSync plugin: https://github.com/vrtmrz/obsidian-livesync
• Calibre-Web: https://github.com/janeczku/calibre-web
• coturn TURN server: https://github.com/coturn/coturn

This is the story of setting that up in one session, and the parts that went sideways.

The Stack

Four moving parts:

• Bifrost – LLM gateway already running on localhost:24242, routing to Ollama cloud models
• Hermes Agent – open-source AI agent framework by Nous Research, pointed at Bifrost
• Ollama – cloud relay for gemma4 and qwen3.5 cloud models via ollama.com
• Camoufox – Firefox fork with TLS fingerprint spoofing for scraping tasks

The goal was to have Hermes run as a Telegram bot so I could assign it tasks from my phone, with all model traffic flowing through Bifrost so routing stays centralized.

Bifrost First

Bifrost was already up on port 24242 with Ollama configured. The only addition needed was an ollama-cloud provider pointing at https://ollama.com rather than localhost. This is a non-obvious distinction.

The trap: Ollama’s OpenAI-compatible endpoint (/v1/chat/completions) does not work for cloud models. It hangs. Cloud models only work through Ollama’s native /api/chat endpoint. Pointing Bifrost directly at https://ollama.com instead of localhost:11434 bypasses the broken compat layer and hits the right path.

Once the provider was registered and OLLAMA_API_KEY was set in .zshrc, both cloud models confirmed working:

1ollama pull gemma4:31b-cloud
2ollama pull qwen3.5:cloud

Installing Hermes

1curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

That puts everything under ~/.hermes/. The setup wizard runs next:

1hermes setup

It walks through provider selection interactively. I pointed it at the Bifrost custom endpoint (http://localhost:24242/v1) and picked ollama-cloud/gemma4:31b-cloud as the default model.

Key config paths:

~/.hermes/config.yaml    -- main settings
~/.hermes/.env           -- secrets and API keys
~/.hermes/skills/        -- reusable agent procedures
~/.hermes/sessions/      -- full conversation history (searchable)

After setup, a quick smoke test confirmed the agent was up and routing through Bifrost correctly:

1hermes chat -q "what model are you using and where does traffic go"

Context Window

The default context length was under 20k tokens. Ollama cloud models support much larger windows. One config set:

1hermes config set model.context_length 200000

Takes effect on the next session restart.

Telegram Bot

This is where Hermes gets genuinely useful. The gateway turns it into a bot that accepts tasks from any platform you connect.

Create a bot via BotFather, get the token, then add it to ~/.hermes/.env:

1TELEGRAM_BOT_TOKEN=<your-bot-token>
2TELEGRAM_ALLOWED_USERS=<your-numeric-telegram-id>

TELEGRAM_ALLOWED_USERS takes the numeric user ID, not the username. Lock it down. Anyone who finds the bot URL can send it commands if this is not set.

Start the gateway:

1hermes gateway run

For persistent background operation, install it as a service:

1hermes gateway install
2hermes gateway start

A set of aliases in .zshrc makes it easier to manage day to day:

1alias hermes-gateway-start="hermes gateway start"
2alias hermes-gateway-stop="hermes gateway stop"
3alias hermes-gateway-log="tail -f ~/.hermes/logs/gateway.log"

First run hit a missing Python dependency and failed silently. The fix was running hermes gateway run in the foreground once to see the real error, installing the missing package, then moving back to the service.

Camoufox

Camoufox is a Firefox fork built for scraping. It spoofs TLS fingerprints so sites see a legitimate browser rather than a Playwright or CDP signature. It exposes a CDP endpoint that Hermes’s browser tool connects to.

1git clone https://github.com/daijro/camoufox
2cd camoufox && npm install
3python -m camoufox fetch   # ~300MB download

The camoufox fetch step downloads the actual browser binary and does not run automatically via postinstall. If you skip it, the first start fails silently. Run it manually and wait for the download to finish before starting the server.

Start it on port 9377:

1python -m camoufox server --port 9377 &

Smoke test via Hermes:

1hermes chat -q "use the browser to fetch the title of example.com"

Aliases for day-to-day:

1alias camofox-start="python -m camoufox server --port 9377 &"
2alias camofox-stop="pkill -f 'camoufox server'"

What Actually Went Wrong

Ollama native vs compat endpoint. Already covered above, but it cost a couple of hours. If a cloud model hangs at the provider level, check whether your gateway is talking to the right API path.

Camoufox silent failure. The binary fetch is not in postinstall. No error, just no browser. Always run python -m camoufox fetch explicitly before the first start.

Hermes gateway dependency. First start printed nothing useful. Run in foreground before daemonizing so you can see the actual error.

Bifrost and empty API keys. Ollama initially rejected non-empty dummy keys in the Authorization header. Setting the key to an empty string before switching to the real OLLAMA_API_KEY got things unstuck. The order mattered.

Session corruption in OpenCode. An OpenCode session used to orchestrate this setup got a zombie assistant message from an interrupted stream. The message had an empty string for content. Bifrost converted that empty string to null before forwarding, and the upstream provider rejected the entire next request with messages.315.member.content must not be null. Every retry included the same zombie in history, so the error was permanent until manually fixed.

The fix is to delete the zombie row directly from the OpenCode SQLite database:

1sqlite3 ~/.local/share/opencode/opencode.db \
2  "DELETE FROM message WHERE id = '<zombie-message-id>' AND session_id = '<session-id>';"

There is no built-in repair command. Back up the database before editing it.

Final State

Services running when done:

bifrost    :24242  -- Ollama cloud routes
ollama     :11434  -- cloud relay (gemma4, qwen3.5)
camoufox   :9377   -- CDP browser endpoint
hermes     gateway -- Telegram bot (restricted to single user)

The agent receives messages on Telegram, runs tool calls locally (terminal, browser, file ops, web search), and routes all model traffic through Bifrost.

What’s Left

The original plan included running a local Qwen3.5-27B model via llama.cpp with Metal acceleration. That is a 13.5GB download and a build-from-source step, so it was deferred to the next session. The cloud routing setup works fine in the meantime.

References

• Hermes Agent: https://github.com/NousResearch/hermes-agent
• Hermes docs: https://hermes-agent.nousresearch.com/docs/
• Bifrost: https://github.com/maximhq/bifrost
• Camoufox: https://github.com/daijro/camoufox
• OpenCode: https://opencode.ai