🧱 Getting Set Up: Tools I Use to Power My Stack

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 or MiniGPT (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 the tasks 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, then Enter

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 and service_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.