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

Posted by:

|

On:

|

, , , ,

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.

ComponentMinimumRecommended
CPU4-core (e.g., Intel i5)✅ 8-core (e.g., Ryzen 7 5800H)
RAM16GB✅ 32GB or more
Storage256GB SSD✅ 512GB+ NVMe SSD
GPUNot required (CPU inference OK)Optional eGPU or server GPU
OSLinux (Ubuntu/Debian) or macOS✅ Linux preferred for infra work
NetworkStable wired or Tailscale mesh✅ Tailscale + Cloudflare Tunnel
Power24/7 uptime recommendedUse 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:

FeaturePurpose
PostgreSQLRelational DB for tasks, memory, workflows, users
RealtimePub/sub WebSocket updates (used by agents or dashboards)
AuthEmail/password, magic links, OAuth — out of the box
StorageFile uploads, image hosting, receipts, embeddings
Edge FunctionsServerless API endpoints (optional)
StudioAdmin 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

ProblemFix
❌ Port already in use (e.g. 5432)Change POSTGRES_PORT in .env, or stop existing Postgres
Permission deniedTry sudo docker compose up
❌ “Service not found”Make sure you’re in the root of the supabase/ folder
Kong keeps restartingEnsure you’re not missing .env or .secrets files
❌ Postgres won’t persistCheck Docker volumes; consider docker volume prune if cluttered
❌ Missing keys in .envRun openssl rand -base64 32 to generate random keys

🧩 Cloud Option (Fastest Start)

If you want to skip all of that:

  1. Go to https://supabase.com
  2. Create a new project (free)
  3. Grab your anon and service_role keys from the dashboard
  4. 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 MachineStrategy
MacBook w/ 16+ GB RAMRun locally (full stack)
Dev laptop w/ 8–16 GBCloud Supabase + local Ollama + Qdrant
Always-on Mini PCFull Sovereign Stack (Supabase, Qdrant, n8n, MCP, Ollama)
Cloud CI/CD pipelineUse 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

Your email address will not be published. Required fields are marked *