AI Assistant · CNC · clawdie.si
Most AI assistants stop at conversation.
Clawdie doesn't.
She lives on your hardware, remembers your world, and is being built
to drive the machine that manufactures your dome.
From first message to finished structure —
the two of us are building this together.
Clawdie is a self-hosted personal AI assistant running on FreeBSD. She connects through Telegram, remembers everything in a PostgreSQL database, and runs entirely on your own hardware. No corporate cloud. No platform subscription. No data leaving your server. LLM inference needs an API key or a local Ollama setup — you choose the provider, you own the relationship.
Built on giants' shoulders: Peter Steinberger's OpenClaw set the broader direction, NanoClaw by Gavriel carried that line into a lean personal-assistant upstream, and Clawdie takes it onto FreeBSD with native jail isolation, ZFS snapshots, and a pi-driven setup flow. The same stack ties into the wider OSA mission.
The FreeBSD deployment path is actively being built and proven in practice. Our mission is always one step ahead — connecting the assistant to the physical machine that will build domes.
Why Clawdie over alternatives
| Clawdie | Open WebUI | Ollama | Home Asst. | |
|---|---|---|---|---|
| Self-hosted | ✓ | ✓ | ✓ | ✓ |
| Telegram nativeno new app to install | ✓ | ✗ | ✗ | ≈ |
| FreeBSD · PF · ZFSnative skills, not wrappers | ✓ | ✗ | ✗ | ✗ |
| Platform diversityLinux-origin upstream, FreeBSD-native deployment | ✓ | ✗ | ✗ | ✗ |
| Jail isolationagent sandboxing | ✓ | ✗ | ✗ | ✗ |
| Multi-agentconcurrent sessions, roles | ✓ | ✗ | ✗ | ✗ |
| Memory · pgvectorpersists across sessions | ✓ | ✓ | ✗ | ≈ |
| Preloaded skills memorylower-friction onboarding, fewer setup-time LLM calls | ✓ | ✗ | ✗ | ✗ |
| Skill systemextend without touching core | ✓ | ✗ | ✗ | ≈ |
| Provider-agnosticany LLM API, local or cloud | ✓ | ✓ | ✓ | ✓ |
✓ native ≈ partial / plugin ✗ not supported
No wizard. No interactive installer. Bootstrap the repo, then run the
explicit setup steps that exist on current main.
setup.sh only bootstraps the repo. Provider choice,
Telegram auth, and platform provisioning happen during
just install after you create .env.
Most AI tooling assumes Linux. We run FreeBSD — and document everything that works, so others don't have to figure it out from scratch.
Agent service handles Telegram, REST, and
scheduling on the host. hostd holds privileged
ops (bastille, zfs, pf) behind a Unix socket — the only thing on
the box with root. Service jails (cms, git,
optional llama-cpp) sit on the warden0 VNET bridge.
PostgreSQL 18 on the host — one engine, three
databases per tenant
({tenant}_ops, _skills,
_memory). Sanoid ZFS snapshots on all datasets,
home included.
warden0 bridge with pf NAT for egress.
_ops (tasks, activity),
_skills (read-only knowledge),
_memory (pgvector). Add a tenant, get a fresh
3-DB set; share the engine.
Most AI infrastructure assumes Linux by default. We chose FreeBSD on purpose: not to be contrarian, but to avoid monoculture thinking and build on jails, PF, and ZFS as first-class primitives.
Serious operators often keep more than one platform in service because shared failure modes are real. If one ecosystem hits a critical kernel, container, packaging, or networking bug, platform diversity reduces blast radius. Clawdie follows that same logic for self-hosted AI.
NanoClaw and OpenClaw evolve mainly in the Linux ecosystem. Clawdie stays close to that upstream line, but gives operators a FreeBSD deployment path with native jail isolation and host-level control. That combination is the point: upstream-aware, but not upstream-dependent.
The licensing culture matters too. BSD-style licensing keeps the base system operationally attractive for infrastructure work: clear, permissive, and easy to integrate into serious long-lived deployments.
That same thinking shapes onboarding. We want Clawdie to ship with preloaded skills memory in a separate skills database, so first install depends less on live embedding calls and less on immediate provider setup. FreeBSD is not just the operating system choice; it is part of a more self-contained operating model.
What follows is vision, not prototype. The CNC machine is being designed openly, with AI assistance, one step at a time. This page is part of that process. We publish the thinking before the build.
An AI assistant that only talks is only half useful. The goal is to connect Clawdie to a physical machine — an Open Source CNC machine designed to manufacture geodesic dome components.
Clawdie becomes the control system of the CNC machine — translating dome designs from OSA into machine instructions, managing the build sequence, monitoring the process, and logging everything back into persistent memory.
"The CNC machine is not a feature. It is the point. AI that builds things is fundamentally different from AI that talks about things."
The hardware stack is being designed for openness — RISC-V where possible, documented at every step, replicable by anyone with access to basic CNC equipment.
Clawdie and OSA are two parts of the same mission. One is the why. One is the how.
OSA designs the dome. Clawdie builds it. — the two of us, working on it
Visit osa.smilepowered.org for the manifesto, the open dome designs, and the case for why we are still building boxes when we know how to build better.
No membership. No newsletter. Just open work, published as it happens. If this resonates — follow, contribute, replicate.
clawdie.si runs on FreeBSD 15, nginx, and Let's Encrypt — entirely Open Source, self-hosted, zero corporate cloud dependency. Same server as OSA. Same principles.
The orchestrator runs directly on the host as an rc.d service with full system access. Bastille-managed jails handle agent isolation, PostgreSQL memory, and browser automation. ZFS snapshots protect everything.
Setup is driven by pi coding agent — clone the repo,
run
./setup.sh, then an AI session walks through jail provisioning, Telegram, and
service setup. Everything documented here is replicable. If it runs on
our server, it can run on yours.