El problema

Self-hostear algo como Grafana, tu app, una API, necesita tres cosas: un nombre estable que resuelva a tu IP, un certificado TLS válido (Let's Encrypt no emite para IPs), y no depender de un subdominio de DDNS gratuito que puede cambiar o desaparecer. Un dominio propio resuelve las tres. El asunto es el costo y la disponibilidad del nombre.

Ahí entra la clase numérica de .xyz.

Y si hosteás desde tu casa, se suma un cuarto: el ISP normalmente no te da IP pública sino que te deja detrás de CGNAT (una IP compartida entre varios clientes). Con CGNAT el port forwarding ni siquiera funciona ya que no hay a dónde forwardear.

Un dominio propio + un túnel saliente resuelven las cuatro.

Qué es la clase 1.111B

En 2017 el registro de .xyz abrió un bloque: todos los dominios de 6 a 9 dígitos con terminación .xyz (de 000000.xyz a 999999999.xyz), 1.111 mil millones de combinaciones, a US$0,99 por año para siempre — registro, renovación y transferencia, con las tasas ICANN incluidas. La renovación cuesta lo mismo que el alta.

Por qué lo recomiendo

1. Costo irrisorio: ~US$1/año, para siempre y sin sorpresas en la renovación.
2. Disponibilidad: con 1.111 mil millones de combinaciones, encontrás uno libre sin pelear.
3. Sin riesgo de marca: un número no colisiona con ninguna marca ni te lo van a disputar.
4. Funcional, no de marca: para self-hosting no necesitás un nombre lindo ni memorable, solo necesitás que resuelva.
5. Wildcard + subdominios: un solo dominio te da infinitos subdominios con un registro wildcard.
6. Let's Encrypt gratis: con el desafío DNS-01 sacás un certificado wildcard (*.12345678.xyz) y cubrís todos los subdominios con uno solo.
7. Independencia: es tu dominio. No dependés de un DDNS de terceros que puede cerrarse.

Cómo lo uso

El dominio numérico (ej. 12345678.xyz) como raíz, con DNS en Cloudflare (gratis) y un wildcard *. Y lo clave para hostear desde casa es el Cloudflare Tunnel (el demonio cloudflared) que me dá un túnel saliente hacia Cloudflare, sin IP pública y sin abrir puertos en el router. Cada servicio tiene su subdominio (app., api., grafana.).

Contras

• Es feo y poco memorable. Para self-hosting da igual; para una marca, no.
• Los TLD baratos (.xyz incluido) arrastran cierta reputación de spam/phishing; algunos filtros corporativos los miran con recelo. Para uso propio no molesta, pero puede aparecer.
• No es para producción “seria” de cara a terceros (un banco no va a confiar), pero para infraestructura propia y demos va perfecto.

While Simon might be running an Nvidia Spark, I am humbly proof-of-concepting this on an old Thinkpad with 16GB of RAM. The goal was to test the limits, see what breaks, and keep my data offline. Hopefully I too will one day be able to do similar experiments!

The Hardware Stack

• Host: Proxmox VE 9 running on a ThinkPad T420
• CPU: Intel Core i5-2520M (4 Cores, 2 Threads each)
• RAM: 16GB DDR3
• Storage: 480GB SSD

1. The Infrastructure (Proxmox LXC)

The stack lives in a Proxmox LXC. If you wanted to allow the container to run its own instances, you must grant the LXC specific permissions on the Proxmox host. My initial idea was to run agents with Podman, so I had to do this:

# Edit /etc/pve/lxc/ID.conf
features: nesting=1,keyctl=1

Allows nesting and keyctl=1 allows the container to manage its own cryptographic keys and process-specific tokens which is required when running Podman in a nested environment.

2. The Engine (llama.cpp)

To squeeze performance out of an older i5, we compile locally to utilize the AVX (AVX1) instruction set.

# Install dependencies
apt update && apt install -y   git curl tmux direnv   build-essential cmake ccache   libssl-dev libsqlite3-dev liblzma-dev   zlib1g-dev libbz2-dev libreadline-dev

# Clone repo
git clone https://github.com/ggerganov/llama.cpp

# Compile
cd llama.cpp
cmake -B build -DGGML_AVX=ON -DGGML_NATIVE=ON
cmake --build build --config Release --target llama-server -j 4

I included ccache in the dependencies. It’s optional, but it will cut recompilation time.

Run a few tests:

# The llama-server binary should exist
ls -lh build/bin/llama-server

3. Orchestration & Persistence (TMUX)

On limited hardware, high CPU load can cause SSH lag. Use TMUX inside the LXC to decouple the LLM from your connection.

Step-by-Step Setup:

# Start Session
tmux new -s ai_bunker

# Prepare Models
mkdir -p models
wget -O models/qwen-0.5b.gguf https://huggingface.co/Qwen/Qwen2.5-Coder-0.5B-Instruct-GGUF/resolve/main/qwen2.5-coder-0.5b-instruct-q4_k_m.gguf

# Fire up the Server
mkdir -p bunker_memory
./build/bin/llama-server   \
-m models/qwen-0.5b.gguf  \
--port 8080  \
--ctx-size 2048  \
--threads 4   \
--mlock   \
--no-mmap  \
--host 0.0.0.0   \
--slot-save-path ./bunker_memory

4. Direct Inference (curl)

curl http://localhost:8080/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "local",
    "max_tokens": 128,
    "temperature": 0.2,
    "messages": [
      {
        "role": "user",
        "content": "Write a simple Python function that reverses a string."
      }
    ]
  }'

5. Connecting via browser

Since the llama-server is bound to 0.0.0.0:8080, it’s accessible to any tool on your network. The lightest method is via a browser calling the endpoint directly.

6. Connecting locally (Wave & Claude & Aider)

Most modern terminals and AI extensions expect an OpenAI-compatible endpoint. However, these tools inject massive system prompts, and will cause context overflow errors and eat up more tokens than you might have.

I got it working, but it was slow. If you have a better machine and want to go ahead, you may want to configure your tools to use your local model. To do so for Wave, you can follow the documentation. Most AI terminals have similar setup. You need to edit the configuration at ~/.config/waveterm/waveai.json or run a custom command to configure Wave:

wsh editconfig waveai.json

Inside the JSON file, add a new entry. Based on your existing llama-server setup, use this exact structure:

{
  "ia-bunker": {
    "display:name": "IA Bunker - Qwen Coder",
    "display:order": 1,
    "display:icon": "shield",
    "display:description": "Local Qwen 2.5 Coder on Thinkpad T420",
    "ai:apitype": "openai-chat",
    "ai:model": "qwen-coder",
    "ai:endpoint": "http://192.168.1.XX:8080/v1/chat/completions",
    "ai:apitoken": "not-needed"
  }
}

Replace 192.168.1.XX with your local IP.

wsh setconfig waveai:defaultmode="ia-bunker"

I also experimented with running higher-level terminal agents (for example, Claude and Aider) inside Podman and pointing them at the bunker via environment variables.

On a 2 k token context, this usually results in exceedcontextsize_error failures or multi-minute stalls before the first token is produced.

These are the commands I tried inside the container that successfully loaded Aider & then Claude, but unfortunately, they just stalled with my setup (you may have more luck):

podman run -it --rm \
  -v $(pwd):/app \
  -e OPENAI_API_BASE=http://172.17.0.1:8080/v1 \
  -e OPENAI_API_KEY=not-needed \
  paulgauthier/aider-full \
  --model openai/gpt-3.5-turbo \ #  used to select prompt profile
  --no-auto-commits

podman run -it --rm \
  --network host \
  -v $(pwd):/app \
  -e ANTHROPIC_BASE_URL="http://127.0.0.1:8080" \
  -e ANTHROPIC_AUTH_TOKEN="local-bunker" \
  -e CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 \
  node:20-alpine \
  sh -c "apk add --no-cache git && npm install -g @anthropic-ai/claude-code@latest && claude --model qwen-coder"

7. The Global Tunnel: Tailscale in the Bunker

To access your “Bunker” from a coffee shop you could install Tailscale, CloudFlare or Zerotier directly inside the LXC. This turns your old Thinkpad into a secure, private node on your personal VPN. It’s probably worth securing the entry with some auth if you wanted to do that.

But it’s a topic for another post!

PS: Tweak your Engine

Initially, I was getting a painfully slow 0.25 tokens/s. To make it usable on this vintage i5, I had to aggressively tune the llama-server flags:

• —ctx-size 2048: Dropping this down helped because smaller context equals faster “thinking”.
• -ctk q80 -ctv q80: I tried this KV-cache quantization (-ctk/-ctv), but opted out, as on a small-context (2k) Sandy Bridge CPU, the added CPU overhead often outweighs the memory savings. If I had a newer CPU, this might have helped.
• —mlock: Essential to prevent the model from being paged to the Swap partition, which would turn the 20-minute wait into a total system hang.