If you’ve been following along with my blog or projects, you know I build AI-first automation systems and tooling around local-first, private infrastructure. To replicate any of the workflows I share, you’ll want to get your environment set up similarly.
Absolutely — here’s a comprehensive, production-ready section you can drop right under that line:
🧰 System Requirements & Full Stack Overview
To run this automation engine effectively — especially if you want to include agents, pipelines, memory, and LLM inference — you’ll want a solid base system and a clear understanding of the services involved.
💻 Recommended Hardware Specs
You don’t need a full data center — just a dependable, always-on node.
Component | Minimum | Recommended |
---|---|---|
CPU | 4-core (e.g., Intel i5) | ✅ 8-core (e.g., Ryzen 7 5800H) |
RAM | 16GB | ✅ 32GB or more |
Storage | 256GB SSD | ✅ 512GB+ NVMe SSD |
GPU | Not required (CPU inference OK) | Optional eGPU or server GPU |
OS | Linux (Ubuntu/Debian) or macOS | ✅ Linux preferred for infra work |
Network | Stable wired or Tailscale mesh | ✅ Tailscale + Cloudflare Tunnel |
Power | 24/7 uptime recommended | Use a mini PC or UPS-supported |
🧩 Full Software & Service Stack
These are all the services and technologies required to reproduce the full automation platform from this guide.
📦 Core Runtime Environment
- Docker (container orchestration)
- Docker Compose (for service grouping)
- Tailscale (for private networking)
- Cloudflare Tunnel (for secure external access)
- Node.js + Bun (backend + scripts)
🧠 AI/LLM Stack
- Ollama – Local LLM inference layer
↳ Suggested models:llama3:8b
(reasoning)dolphin-mixtral
(conversational)deepseek-coder
(codegen)mxbai-embed-large
(embedding)llava
orMiniGPT
(vision)
- Whisper – Audio transcription
- Coqui TTS – Voice synthesis (optional)
- runLLM() – Unified LLM orchestration function
🧱 Infrastructure + Data
- Supabase (local) – Postgres DB, Auth, Storage
- Qdrant – Vector database for long-term memory
- n8n – Visual automation builder
- OpenWebUI – Optional UI layer to interact with LLMs
- Redis (optional) – Pub/sub or caching layer
📡 Monitoring & Observability
- Grafana – Visual dashboards
- Prometheus – Metric collection
- Uptime Kuma – Uptime and health monitoring
- Loki (optional) – Log aggregation
🔧 Guardian Microservices
- Guardian Server (Hono) – Central MCP
- Memory system – Interfaces with Supabase + Qdrant
- Pipelines:
- BlogGen
- CodeGen
- AgentFlow runtime
- Integrations:
- GitHub
- Notion
- WordPress
- Slack
- Email (IMAP/SMTP)
📦 Frontend / CMS / Blog
- React + MUI frontend (optional dashboard or viewer)
- WordPress (headless blog backend)
- Cloudinary or S3 (for blog image hosting)
- n8n workflows for blog auto-posting
📁 Recommended Folder Structure
/guardian-stack
├── docker/
│ ├── supabase/
│ ├── qdrant/
│ ├── ollama/
│ └── n8n/
├── guardian-server/
│ ├── routes/
│ └── pipelines/
├── agents/
│ ├── dev/
│ └── ingest/
├── public/
│ └── uploads/
├── logs/
└── monitor/
├── grafana/
└── prometheus/
🧠 TL;DR:
If you want to reproduce what I’m doing:
- Buy a Ryzen mini PC with 32GB RAM
- Install Docker + Tailscale + Ollama + Supabase CLI
- Spin up Guardian Server
- Start building pipelines and feeding them memory
This isn’t a toy — it’s your own private AI platform, running 24/7 on your own terms.
Here’s everything I use — and where to go to install it properly.
🐳 1. Docker (Base Requirement)
Why I use it: Every core service I run — from Supabase to Qdrant — runs in a Docker container. This gives me full control and portability whether I’m working locally or remotely on a VPS.
🔗 Install: Docker Desktop Docs →
Once installed, test it with:
docker --version
docker-compose --version
🧠 2. Qdrant (Vector Database)
What it does: Qdrant stores embeddings — it’s the memory layer of my system. Every time an agent or automation interacts with the world, the experience is semantically embedded and stored here for future recall.
🔗 Docs: Qdrant Quickstart →
Look for the Docker setup. You’ll want this running in the background at all times.
🗄️ 3. Supabase (Database + Auth + Storage)
What it does: Supabase is my default Postgres database, with real-time updates, built-in authentication, and file storage. It powers the core backend of my apps and agents.
🔗 Docs: Supabase Local Setup →
Start with Docker-based setup and keep the default Postgres settings unless you’re doing something custom.
🔍 What It Does
Supabase is the backend layer for your local AI system. It provides:
Feature | Purpose |
---|---|
PostgreSQL | Relational DB for tasks, memory, workflows, users |
Realtime | Pub/sub WebSocket updates (used by agents or dashboards) |
Auth | Email/password, magic links, OAuth — out of the box |
Storage | File uploads, image hosting, receipts, embeddings |
Edge Functions | Serverless API endpoints (optional) |
Studio | Admin UI (like Firebase Console but for Postgres) |
In your Guardian system, Supabase is the source of truth for nearly everything.
Agents read/write to it, UIs query it, and orchestrators persist memory and logs in it.
🧠 Why Realtime and AI-Supported SQL Matter in Agentic Systems
In autonomous and AI-driven systems like Guardian, realtime updates aren’t a nice-to-have — they’re a core requirement. Your agents need to react to change, listen for signals, and respond immediately when tasks update, flows progress, or memory shifts. Supabase’s built-in pub/sub layer gives you that, via:
- Realtime subscriptions over WebSockets
- Fine-grained row-level change detection
- Immediate propagation to UIs or orchestrators
This will be central to Guardian’s evolution into a fully autonomous feedback loop.
Example: A new task is inserted → Guardian receives a realtime event → spins up an agent → begins executing autonomously.
🛠️ Supabase SQL Editor + AI = Superpower for Engineering
Supabase Studio also includes a powerful SQL editor with AI assistance, letting you:
- Query or mutate your database live
- Preview results in real time
- Use natural language prompts to write SQL instantly
- Rapidly prototype schema changes
- Apply migrations manually if needed
You’ll see this in action across many of these guides — it’s my preferred way to engineer or evolve the database on the fly.
Whether I’m adding a
memory_embeddings
table or adjusting thetasks
schema, the SQL editor with AI speeds up that flow dramatically.This is especially useful for:
- Debugging agent state
- Viewing memory embeddings
- Testing Supabase Row Level Security (RLS) policies
- Creating views or computed fields
Having low-latency introspection and control over your database in the same UI where you debug your agentic system is a huge advantage.
💾 Local vs Cloud Tradeoffs
🖥️ Local Supabase
✅ Pros:
- Sovereign data (fully self-owned)
- Works offline
- Can run alongside Qdrant and Ollama in a single Docker stack
🛑 Cons:
- Heavy: Postgres + Kong + Realtime + Studio → eats 1.5–2.5 GB RAM
- Setup can be sysadmin-y (e.g. editing
.env
, Docker volumes) - Not great on low-end laptops
- Needs port and volume management
☁️ Supabase Cloud (Free Tier)
✅ Pros:
- Instantly up, zero install
- Very generous free limits:
- 500 MB DB
- 1 GB file storage
- 50,000 monthly active users
- Unlimited edge functions
- Fast, stable, production-grade
🛑 Cons:
- Not air-gapped or sovereign
- Internet required
- Might hit cold start/slowness during scale
💡 Best of both: Start with cloud while building/testing, then migrate to local if you outgrow it or want full data control.
🧰 Local Supabase Setup: Step-by-Step
1. Clone the repo
git clone https://github.com/supabase/supabase.git
cd supabase
2. Install Docker + Docker Compose
Ensure:
docker -v
docker compose version
3. Edit environment config
cp .env.example .env
nano .env # or use `vi` if you're comfortable
Set or check:
SUPABASE_ANON_KEY=...
SUPABASE_SERVICE_ROLE_KEY=...
POSTGRES_PASSWORD=postgres
If confused about nano:
- Move with arrows
- Edit text like normal
- Save:
CTRL+O
, thenEnter
- Exit:
CTRL+X
4. Start Supabase
docker compose up
If you’re using Compose v2, use:
docker compose --env-file .env up
5. Open Studio
Visit http://localhost:54323
🛠️ Edge Cases & Troubleshooting
Problem | Fix |
---|---|
❌ Port already in use (e.g. 5432) | Change POSTGRES_PORT in .env , or stop existing Postgres |
❌ Permission denied | Try sudo docker compose up |
❌ “Service not found” | Make sure you’re in the root of the supabase/ folder |
❌ Kong keeps restarting | Ensure you’re not missing .env or .secrets files |
❌ Postgres won’t persist | Check Docker volumes; consider docker volume prune if cluttered |
❌ Missing keys in .env | Run openssl rand -base64 32 to generate random keys |
🧩 Cloud Option (Fastest Start)
If you want to skip all of that:
- Go to https://supabase.com
- Create a new project (free)
- Grab your
anon
andservice_role
keys from the dashboard - Update your local
.env
:
SUPABASE_URL=https://your-project.supabase.co
SUPABASE_ANON_KEY=...
SUPABASE_SERVICE_ROLE_KEY=...
This gives you zero-config setup and works instantly with Guardian, AgentFlowUI, and any of your frontend apps.
🧠 Recommendation
Your Machine | Strategy |
---|---|
MacBook w/ 16+ GB RAM | Run locally (full stack) |
Dev laptop w/ 8–16 GB | Cloud Supabase + local Ollama + Qdrant |
Always-on Mini PC | Full Sovereign Stack (Supabase, Qdrant, n8n, MCP, Ollama) |
Cloud CI/CD pipeline | Use cloud Supabase + test containers for Qdrant & agents |
🤖 4. Ollama (LLM Runtime)
Prerequisites: Docker
What it does: Ollama lets me run LLMs like llama3
, mistral
, and others locally with a single command. It integrates directly with Guardian and code generation agents.
🔗 Docs: Ollama Install →
Once installed, run:
ollama run llama3
This spins up the default local model for querying.
We’ll also need an embedding model to work with memories.
📡 5. n8n (Workflow Automation)
Prerequisites: Docker
What it does: I use n8n for scheduling automations, connecting services like Slack, GitHub, Notion, and email. It’s my event-based control plane for external workflows.
🔗 Docs: n8n Self-Hosting Guide →
You can access the local web UI at http://localhost:5678
once it’s up.
🧠 Bonus Tools for Advanced Setup
🧷 Guardian Server
The Guardian Server is the brainstem of the entire system — a lightweight but powerful Hono-based backend (previously Express) that connects and orchestrates all services, memory systems, and agents in one unified layer.
It acts as the sovereign MCP (Model Context Protocol) — a central API layer that exposes REST endpoints and functions for agents, automations, and UI interactions.
⚙️ Core Responsibilities
Here’s what Guardian actually does under the hood:
🔄 Centralized HTTP & Function Router
- Exposes secure, typed REST routes and function calls
- Allows agents, pipelines, n8n, or external services to trigger actions
- Manages inbound and outbound traffic to all connected tools
🧠 LLM Orchestration Engine
- Wraps
runLLM()
as a universal LLM call handler - Injects system memory, contextual classification, and task-specific logic automatically
- Ensures every call to Ollama or any external model is enriched with:
- Recent memory
- Task metadata
- Role-specific instruction
🧠 Memory System Interface
- Wraps and unifies Supabase and Qdrant into a structured memory layer
- Handles:
addMemory()
calls with LLM-classified metadata- Retrieval based on embedding similarity and task type
- Time-based or context-prioritized lookups
- Enables agents to “think” with personalized, scoped memory
🔌 Integration Hub
Guardian also manages all critical service integrations:
- GitHub (repos, PRs, commits, branches)
- Notion (Kanban boards, docs, changelogs)
- Slack (HITL, notifications, conversations)
- Email (incoming triggers, logging, enrichment)
- WordPress (blog publishing, drafts, media uploads)
Each integration is modular — triggered by task type, pipeline step, or agent directive.
🧪 Pipeline + Automation Infrastructure
Guardian doesn’t just expose functions — it powers full pipelines behind the scenes.
Examples:
- 📝 BlogGen Pipeline — takes a topic or source, generates a full blog post, adds memory, queues post to WordPress, and optionally creates social media snippets
- 💻 CodeGen Pipeline — turns task specs into PR-ready code + tests, injects into GitHub, and logs all memory and file changes
Every pipeline includes built-in memory updates, agent task feedback, and observability.
🔐 Why It Matters
Without Guardian:
- There’s no single source of truth.
- Agents would call services in silos.
- Memory would be fragmented or missing altogether.
- LLM calls would be raw and stateless.
- Pipelines would break with context loss.
With Guardian:
- Every agent, automation, or trigger flows through a coherent system.
- Memory, reasoning, and control are synchronized.
- You unlock a true AI operating layer — extensible, observable, and yours.
🔗 [Guardian source coming soon…]
When I open-source it, you’ll be able to run your own self-hosted Guardian node — complete with pipelines, memory, LLM integration, and agent orchestration out of the box.
🔒 Tailscale + Cloudflare Access (Security Layer)
If you’re planning to move beyond your local machine, I recommend two tools to lock it all down:
- Tailscale for private, encrypted peer-to-peer access between devices
- Cloudflare Access to gate API or admin endpoints behind Zero Trust
I’ll cover these in detail in a future tutorial once you’re ready to scale past localhost.
🧪 What’s Next?
Once you have all of this installed and running locally, you’ll be able to:
- Query local LLMs via Guardian
- Automate workflows with n8n
- Track and store vector memories with Qdrant
- Build full-stack apps with Supabase powering your backend
In the next tutorial, I’ll walk through wiring these services together using my default development setup.
Leave a Reply