Composing Self-Hosted AI Workflow Stacks in 2026

A practical look at the emerging patterns for running agentic workflows on your own infrastructure using n8n, local LLMs, vector stores, and custom execution engines.

Self-hosted AI workflow stacks have moved past the proof-of-concept stage. Teams are now running production workloads that combine workflow orchestration, local language models, vector search, and custom execution logic on infrastructure they control. The pattern is consistent: a workflow engine handles the control flow, a local LLM server provides inference, a vector database supplies memory, and a relational database persists state. The differences lie in how these components are wired together and where the execution logic lives.

Three recent developments illustrate the range of approaches. The n8n Self-Hosted AI Starter Kit packages n8n with Ollama, Qdrant, and PostgreSQL in a single Docker Compose file. Sim, an Apache-2.0 licensed alternative, builds its own execution engine and adds an MCP server for Claude Code integration. A production video-clipping pipeline uses self-hosted n8n with Redis, Gemini 2.5 Flash, MediaPipe, and a custom FFmpeg build across seven microservices. Each stack makes different trade-offs between convenience, control, and operational complexity.

The Baseline: n8n Self-Hosted AI Starter Kit

The n8n Self-Hosted AI Starter Kit is the most widely referenced starting point. It provides a Docker Compose template that spins up four services: n8n for workflow orchestration with over 400 integrations, Ollama for running local LLMs, Qdrant for vector search, and PostgreSQL for durable storage. The kit includes demo workflows for appointment scheduling, PDF summarisation, Slack bots, and financial document analysis.

This combination covers the core requirements for agentic workflows. n8n handles the orchestration layer including triggers, branching, error handling, and human-in-the-loop steps. Ollama removes the dependency on external API providers and keeps data local. Qdrant gives agents a queryable memory layer for retrieval-augmented generation. PostgreSQL stores workflow state, credentials, and execution history.

The kit supports GPU acceleration profiles for Nvidia and AMD on Linux, and Apple Silicon on macOS. This matters because local LLM inference is the primary compute bottleneck. Teams can start on CPU and migrate to GPU hardware as throughput demands grow.

The Alternative: Sim's Custom Execution Engine

Sim takes a different architectural approach. Rather than embedding n8n, the team built their own execution engine from scratch. The repository shows a dedicated execution service written in TypeScript that handles workflow runs, debugging, and resume-from-checkpoint capabilities. Background job infrastructure runs on Trigger.dev.

Sim's feature set targets agentic workflows specifically. The platform includes 270 plus integrations covering 5,400 actions and 520 triggers. A code node uses E2B sandboxes to run Python or TypeScript with full package manager access. The MCP server at mcp.sim.ai lets Claude Code or any MCP client manage workspaces, deploy workflows, and interact with tables, knowledge bases, files, and logs.

The collaborative workspace model is a notable difference. Tables, files, and knowledge bases live in the same workspace as chat and workflows. This reduces the impedance mismatch between data preparation and workflow execution. For teams that want a unified environment rather than stitching together separate services, this integration can accelerate iteration.

Production Pattern: The Video Clipping Pipeline

A documented production system shows how these components compose in practice. The stack uses self-hosted n8n with Redis for queuing, Gemini 2.5 Flash for video scoring, MediaPipe for face tracking, and a custom FFmpeg build for auto-reframing and subtitle burn-in. The entire pipeline runs as seven microservices orchestrated by Docker Compose.

This architecture reveals several practical decisions. Redis decouples the workflow engine from the compute-intensive media processing. The custom FFmpeg build handles operations that standard nodes cannot express. External APIs (Gemini) are used selectively for capabilities that local models do not yet match reliably. The seven-service topology reflects a deliberate separation of concerns: orchestration, queuing, AI inference, computer vision, media processing, storage, and API gateway.

The builder packaged the complete architecture as a starter kit after six months of production operation. This suggests the pattern is reproducible and the operational burden is manageable for a small team.

Comparing the Stacks

Component n8n AI Starter Kit Sim Video Pipeline Orchestration n8n (400+ integrations) Custom engine n8n + Redis queue LLM Inference Ollama (local) Any major provider + local Gemini 2.5 Flash (API) Vector Search Qdrant Built-in knowledge bases Not specified Relational Storage PostgreSQL Built-in tables Not specified Code Execution n8n code node E2B sandboxes (Python/TS) Custom FFmpeg service Debugging n8n execution log Per-block debug, resume from any point Custom observability MCP Integration Via n8n community nodes Native MCP server Not used License Apache-2.0 (starter kit), Sustainable Use (n8n) Apache-2.0 Commercial (starter kit sold on Gumroad)

Decision Factors for Teams

Choosing between these approaches depends on three factors: integration breadth, custom logic requirements, and team composition.

Integration breadth: n8n's 400-plus integrations cover most SaaS APIs out of the box. Sim's 270 integrations cover the major categories but may require custom nodes for niche services. The video pipeline uses n8n precisely because the integration library reduces glue code.
Custom logic: Workflows that need heavy computation, specialised libraries, or non-standard protocols benefit from Sim's E2B sandboxes or the video pipeline's dedicated microservices. n8n's code node runs in the main process and shares resources with the orchestration engine.
Team composition: Teams with strong TypeScript or Python skills can extend Sim's engine or build custom microservices. Teams that prefer configuration over code will move faster with n8n's visual editor and node library.

Operational Considerations

Running any of these stacks in production introduces operational responsibilities that managed services absorb. The starter kit approach defers these decisions but does not eliminate them.

Model updates: Ollama makes it easy to pull new model versions, but teams must test prompt compatibility and latency changes before rolling out.
Vector index maintenance: Qdrant collections grow with each document ingestion. Index optimisation, sharding, and backup strategies become relevant at scale.
Queue depth and backpressure: The video pipeline's Redis layer absorbs bursts. Without a queue, n8n executions can block workers during long-running media tasks.
Credential rotation: All three stacks store API keys and database passwords. Rotation policies and secret scanning should be automated.
Observability: n8n's execution log is sufficient for debugging individual runs. Sim's per-block debug with resume capability reduces mean time to resolution. The video pipeline likely supplements with distributed tracing across services.

Where Marketplace Templates Fit

Teams evaluating these stacks face a build-versus-buy decision at the workflow level. The orchestration engine and infrastructure are foundations. The workflows that encode business logic (lead enrichment, document extraction, appointment scheduling, video clipping) are candidates for purchase rather than development.

AutoStack lists production-ready n8n workflows, GoHighLevel snapshots, and AI agent templates that run on these exact stacks. Creators vet their templates against specific n8n versions and dependency matrices. Buyers can purchase a template outright, pay for professional installation, or subscribe to annual maintenance with escrow-protected payments. This reduces the risk of adopting a template that breaks on the next n8n update or model change.

The starter kits and custom engines provide the runtime. Marketplace templates provide the business logic. The combination lets teams focus on domain-specific automation rather than scaffolding.

Next Steps for Evaluation

Deploy the n8n Self-Hosted AI Starter Kit on a development machine. Run the demo workflows to verify GPU detection, model loading, and vector search.
Test Sim's desktop application or cloud workspace. Build a workflow that uses the code node with a third-party package to assess the E2B sandbox experience.
Map your required integrations against n8n's library and Sim's catalogue. Note any gaps that would require custom nodes or HTTP request nodes.
Estimate the operational load: model inference latency, vector index size, workflow execution frequency, and media processing volume if applicable.
Review marketplace templates for your highest-value use cases. Check compatibility with your chosen stack before committing.

The self-hosted AI workflow landscape has converged on a common architecture: orchestration engine plus local LLM plus vector store plus relational database. The variation lies in how tightly these components are integrated and how much custom execution logic the team is willing to maintain. Starting with the n8n AI Starter Kit gives the fastest path to a working baseline. Sim offers a more opinionated, agent-native environment with deeper debugging. The video pipeline demonstrates the ceiling of what a dedicated team can achieve with n8n as the orchestrator and specialised services for compute-intensive steps.