LTC Labs - I no longer run my infrastructure myself, the AI runs it

How Claude provisions containers, sets up email and deploys Odoos on my Proxmox without me touching a key

1. How this started

One day I wrote to Claude that I wanted a local AI server on my Proxmox. I didn't give it a command, I gave it an idea. Here is what happened next (real screenshots and conversation from task #719 of my internal Odoo).

task719-img1.png

Me:

Improve this prompt: "I want to create a new server with local AI. A new container on pve1, ct-132 (ollama-gemma4) (192.168.1.132), 16 cores, 16GB RAM, 50GB HDD. I want to set up LLM Ollama + gemma4 (#6 Arena AI). Analyze my work environment and prepare a plan to do all this using system-admin"

task719-img2.png

Claude:

Phase 0 - Project detected

Environment: Proxmox pve1 (192.168.1.2), dual infra pve1/ipve1.

Precedent: CT-131 (aicowork) already runs Ollama + Open WebUI + Qwen2.5 7B - direct reference.

Applicable skill: system-admin (remote SSH, Proxmox, containers).

task719-img3.png

Phase 4 - Critical gaps detected

1. "gemma4" doesn't exist as an official model. Google has Gemma 2 and Gemma 3. The #6 on LMArena (April 2026) needs to be verified - you probably mean gemma-3-27b or similar. Clarify before executing.

2. Resources: 16 GB RAM / 50 GB HDD - a Gemma 3 27B needs ~20 GB just for weights (Q4). Recommended 80-100 GB.

3. GPU: passthrough or CPU-only? Running a 27B on CPU will be very slow.

4. UI: Open WebUI like on CT-131, or just the Ollama API?

5. External access: nginx reverse proxy / subdomain?

task719-img4.png

Steps I'm going to plan (not execute yet)

1. SSH into pve1, check free resources, CTID and IP.

2. Research the actual model on LMArena via WebFetch.

3. Provisioning plan with pct create and exact parameters.

4. Plan for installing Ollama + pulling the model + test.

5. Open WebUI plan if applicable.

6. Reverse proxy / DNS if applicable.

Awaiting your OK before touching anything.

What came after was the easy part. I confirmed, Claude connected to pve1 over SSH, created CT-132 with pct create, installed Ollama natively, downloaded the model (ended up being Gemma 4 26B, 17 GB on disk), set up Open WebUI natively under systemd as user aicowork, registered a Python tool so the LLM can run commands, and left the service listening on http://192.168.1.132:8080. I didn't open a single SSH session.

What matters isn't that Claude knows how to run a pct create. What matters is that it identified the gaps before touching anything (non-existent model, insufficient disk), used the CT-131 precedent as a mental template, and stopped to ask me for confirmation. It's like having a junior sysadmin with perfect memory of the environment.


2. I don't just have infra. The AI can operate it.

The piece that's missing is this: infrastructure by itself isn't worth much. What turns it into something new is the sandwich infra + skills + AI.

  • Infra: Proxmox, containers, mail VPS, SSH key access.
  • Skills: instructions I've been writing for Claude so it knows how to operate my environment (system-admin, odoo-pilot, oci-creator, ict-project-creator...). They are plain markdown, versioned.
  • AI: Claude Code connected over SSH from the development container, reading the skills and the project memory.

Result: tasks that used to take me half an afternoon are now a single sentence.

Example 1 - "Create catchall@clientx.com"

I tell Claude: create catchall@clientx.com and set it up as outbound on the client's Odoo.

What it does, without me stepping in:

  1. Loads the system-admin skill. It knows mail lives on elpanocho.com (OVH VPS, ~7 EUR/month), Postfix + Dovecot + Virtualmin.
  2. SSH into ubuntu@elpanocho.com with its key, creates the mailbox in Postfix, adds the catchall alias.
  3. Generates the DKIM key with OpenDKIM for the client's domain, publishes the TXT record in the PiensaSolutions DNS panel.
  4. Loads the odoo-pilot skill. Enters the client's Odoo over XML-RPC, configures the outgoing SMTP server (port 587, STARTTLS, correct smtp_from), and an inbound fetchmail for the catchall.
  5. Sends a test email and verifies headers (SPF/DKIM/DMARC PASS).

I get the summary. If something fails, it tells me exactly what failed and where.

Example 2 - "Provision a new Odoo for client Y"

I ask for an Odoo 18 with hospitality + POS verticals. Claude uses the oci-creator skill: SSH into pve1, pct create of a new LXC with Docker inside (privileged, we learned this the hard way after failing with overlay2), generates the docker-compose.yml, resolves recursive OCA dependencies, produces addon_requirements.txt before the build, initializes the database with --workers=0 --no-http to avoid the race condition with the entrypoint, installs l10n_es from the start (you can't change the chart of accounts afterwards), applies the deployment checklist (EUR not USD, kg not units, allergens, POS tables, translations with --i18n-overwrite, debranding) and publishes the custom repo on GitLab with the README mirrored in document.page inside Odoo.

All of that is codified in a skill. The memory of the errors too. Every time I hit something new, it gets written down in MEMORY.md and next time it doesn't happen again.


3. Inventory - the containers running this

Three physical pillars:

  • pve1 - Proxmox on-premise at my office (192.168.1.2). Xeon E5-2697v3, 14 cores / 28 threads, 62 GB RAM, 2 TB rpool ZFS. It's the workshop: 33 containers between active and dormant, 12 VMs. Multi-version Odoo development (14 to 19), the local LLM, and internal services all live here.

pve1-summary.png

pve1-cts.png

  • ipve1 - Dedicated barebone in a datacenter (lemontreecloud.com, OVH). Xeon E5-1650v2, 6 cores / 12 threads, 31 GB RAM. The public face: 7 containers, all running, no VMs. Replicas of the pve1 Odoos plus the nginx frontend and the VPN. From ~30 EUR/month.

ipve1-summary.png

ipve1-cts.png

  • elpanocho.com - Independent VPS at OVH (~7 EUR/month). Postfix + Dovecot + Virtualmin + OpenDKIM. MTA and authenticated outbound SMTP for the domains elpanocho.com, fer.elpanocho.com and lemontreecloud.com.

These are the 10 key containers we touch daily on pve1:

ID Hostname IP Resources Service
102 nginx 192.168.1.249 2c / 4G / 20G nginx reverse proxy, entry point to the office (SSL, vhosts)
114 odoo14 192.168.1.188 8c / 8G / 40G Odoo 14 dev/legacy (stopped)
115 odoo15 192.168.1.103 4c / 8G / 20G Odoo 15 + PostgreSQL 15 (legacy running)
116 odoo16 192.168.1.250 16c / 32G / 76G Main Odoo 16 (ict_fer, elPanocho, Claude Code host)
117 odoo17 192.168.1.251 8c / 8G / 25G Odoo 17 + PostgreSQL 15 (version testing)
118 odoo18 192.168.1.252 16c / 32G / 160G Odoo 18 + PostgreSQL 15 (TBP/OCI deploys)
119 odoo19 192.168.1.253 8c / 8G / 30G Odoo 19 + PostgreSQL 15 (new-version sandbox)
131 aicowork 192.168.1.131 16c / 16G / 50G Ollama + Open WebUI Qwen2.5 7B (stopped, replaced by 132)
132 ct-132 192.168.1.132 12c / 32G / 100G Ollama + native Open WebUI + Gemma 4 26B (local LLM)
190 freePBX 192.168.1.190 4c / 4G / 25G FreePBX/Asterisk phone system (stopped)

Important clarification: there is no automatic live replication between office and datacenter. Each node has its own local scheduled backup (weekly vzdump, short retention). What does exist is a logical mapping by service, keeping the VMID consistent across nodes (116 on pve1 = 116 on ipve1) as a convention, so when it's time to move or recreate something, the agent (or I) doesn't have to guess equivalences. The same agent, with the same SSH key, operates on both hosts interchangeably; synchronization, when needed, is orchestrated by hand or via skill, not by cron.

pve1 ipve1 Hostname Purpose
102 100 nginx Reverse proxy; in the cloud it serves public SSL traffic
- 102 vpn SoftEther VPN, remote access to the office network
116 116 odoo16 Cloud hosts public elPanocho, on-prem is dev
117 117 odoo17 Same dev (office) / public (cloud) pairing
118 118 odoo18 Dev + client deploys (TBP/OCI base)
119 119 odoo19 New-version sandbox on both sides
- 150 tbp-odoo18 The Burger Palace client production (cloud only)

4. This works for any SME

I built it for myself. But there's nothing here that wouldn't work for an SME that wants to stop paying SaaS for everything and start having their own infrastructure operated by AI.

Entry cost, no marketing:

  • ipve1-style (dedicated barebone in a datacenter, OVH or similar): from ~30 EUR/month. Enough for 5-7 LXCs running Odoo, nginx, VPN.
  • Mail VPS in the style of elpanocho.com: ~7 EUR/month. Postfix + Dovecot + DKIM. Removes your dependency on Google Workspace or Microsoft 365 for operational mailboxes.
  • pve1-style (Proxmox on-premise in the office): your own hardware. A one-time investment. A second-hand Xeon with 64 GB of RAM costs less than a month of SaaS for 20 employees.

Three ways to get here (no order, no sales pitch):

  • I set it up for you. The infra is yours. You rent it from whichever provider you want and I operate on top of it. I bring the skills, the SSH keys, and leave you operational with the first "create new client end-to-end" flow. From that point on your team talks to the AI, not to the console.
  • I train you through Open Teach Partner. I have a training company focused on open-source (Odoo + OCA, Proxmox infra, Claude agents). If what you want is to understand how to set this up and operate it yourself - or have someone in your company take on that role - there's a program for that.
  • I inspire you and you ask someone else. This post exists precisely so you know this is no longer science fiction. If you find someone who can set it up better, great. The point is that the category exists. Before, you didn't know it did.

Next step

What three years ago required a DevOps team, today is done by a cheap Proxmox, an SSH key, and an agent that has read your memory. I use it every day. It works.

But one question is still in the air: you already know that AI operates the infra. Now you still need to know which infra to pick. VPS, dedicated, hyperscale cloud, European providers, GDPR... That's exactly what I cover in the next post in the series.

host1 is now pve2: crossing to Proxmox 9 without dropping a container
host1 came back last month; this week it was reborn as pve2 on Proxmox 9.2. The cluster crossed a major Debian version live, eleven containers never noticed, and a two-node quorum trap got defused before it could bite.