Stack / Uses – RealAndWorks

Hardware

Inference workstation (inky) — Xeon server-grade CPU, 64 GB RAM, an RTX 3090 (24 GB), NVMe storage. Runs llama.cpp 24/7, serving Qwenopus 3.6 (27B) for local LLM inference and agent workloads.
GPU node (sg1) — RTX 4070, dedicated to neural TTS, video rendering, and GPU-accelerated media tasks. Isolated so inference jobs never contend with media work.
Hosting node (prokopton) — containerised multi-site estate: five WordPress stacks, Caddy reverse proxy, zero open ports via Cloudflare Tunnels.

Models & Inference

Qwenopus 3.6 (27B) — primary reasoning model, runs fully self-hosted via llama.cpp on the RTX 3090, GGUF-quantized (Q4_K_M / Q5_K_M) to fit the 3090’s 24 GB.
Model hot-swap — a lightweight proxy layer lets me switch active models without restarting dependent services. Agents and automations never hard-code a model path.
Web-search-augmented proxy — LLM responses are optionally grounded with live search results piped through a local proxy, keeping the model’s knowledge current without fine-tuning.
Smaller 7–8B models handle high-volume classification and routing tasks where cost-per-call matters.

Infrastructure

Docker + Compose — every service is containerised. Compose files are the single source of truth; there is no manual server state to drift.
Caddy — automatic TLS, reverse proxy, and zero-downtime reloads. Config lives in git.
Cloudflare Tunnels — outbound-only connectivity; no firewall rules, no exposed ports.
systemd — long-running llama.cpp servers and agent daemons are managed as systemd services with automatic restart on failure.
WordPress + MariaDB — content management for client sites and this portfolio, all containerised.

Media & Voice

Remotion — programmatic video generation from React/TypeScript components. Agent-authored scripts render directly to MP4.
Voicebox neural TTS — high-quality voice synthesis running on the GPU node. Used for video narration and voice agent responses.
Twilio + x.ai voice — inbound and outbound telephony routed through a voice call-screening agent. Calls are transcribed, reasoned over, and responded to autonomously.

Automation

Telegram gateway — primary interface for interacting with running agents. Commands, status updates, and media outputs flow through a structured bot layer.
GoHighLevel — CRM and campaign automation for client-facing workflows, integrated with the agent layer via webhooks.

Languages

Python — agent orchestration, LLM tooling, data pipelines, API wrappers.
Bash — system automation, deployment scripts, and glue between services. If it runs once in the terminal, it becomes a script; if it runs twice, it gets a systemd unit.

How I build — toolchain

The systems above run self-hosted on hardware I own. The toolchain that builds them is a separate decision, and there I use the best tool for the job — including cloud agentic tooling. Owning the production stack and renting the build environment are not in tension; knowing which is which is the point.

Claude Code CLI — my primary build environment. I drive most engineering from the terminal: reading the codebase, writing the diff, running the tests, and shipping — in one loop, where the work already lives.
Agentic multi-agent dev workflow — work is decomposed across planner, builder, and reviewer agents running in parallel, so one engineer ships at the cadence of a small team. Each agent stays in its lane; I stay the architect and the final reviewer.
Neovim + tmux — the editing surface and session multiplexer the agents and I share. Long-running builds and inference sit in named panes; nothing gets lost between sessions.
Git + scripted deploys — every change is versioned and rolled out through Compose and rsync deploy scripts, not hand-edited on the server. The repo is the source of truth; production is a checkout.