Skitflow

Architecture of Skitflow

Overview of the control plane, runtime, observability, storage, and AI Gateway architecture in Skitflow.

Understanding the architecture of Skitflow is crucial for both deploying and scaling applications. The diagram below shows the current control plane and runtime flow: public ingress, the Docker Swarm runtime with the AI Assistant and AI Code Review, the AI Gateway layer that serves every AI-powered action, the observability store, and the replicated storage fabric.

Enterprise architecture

Skitflow control plane, workloads, AI, and data fabric

A layered view of the public ingress, Docker Swarm runtime, governed AI access, observability store, and replicated storage.

Self-hosted or managed
Ingress
Internet
Users, APIs, webhooks, agents
TLS + routing
Traefik edge
Ingress, domains, certificates
Traffic enters once, then fans out to the Skitflow dashboard or customer workloads through the same governed edge.
Docker Swarm runtime

Skitflow and user workloads run as services across one or more Swarm nodes.

Skitflow App
Dashboard, API, orchestration
Customer workloads
Apps, Compose stacks, services
AI Assistant
Analysis, diagnostics, proposals
AI Code Review
PR findings, confidence score
Operational guardrails
RBAC, confirmations, audit trail
Data and observability plane

Core state, queues, and telemetry are separated into explicit backing services.

Postgres
State, config, audit
Redis
Queue and cache
ClickHouse
Logs, traces, metrics
AI governance

Model access stays centralized for built-in and external agent workflows.

AI Gateway
Routing, API keys, usage
AI providers
BYOK or platform models
Storage fabric

LINSTOR replicated volumes

DRBD-backed replicas keep workload data available across Swarm nodes without turning storage into a mystery box under the diagram.

Node A
Replica 1
Node B
Replica 2
Node C
Replica 3

Core components

When you install Skitflow, it sets up the core services that run the platform:

  • Next.js application — the frontend, dashboard, API, and control plane logic. Server-side rendering keeps the UI and backend in one cohesive app.
  • PostgreSQL — the primary database for organizations, projects, environments, applications, deployments, provider settings, AI routing, and audit data.
  • Redis — deployment queue and cache. It serializes work so deployments do not overload the server.
  • Traefik — reverse proxy and load balancer. It routes public traffic to both the Skitflow dashboard and the applications you deploy.

Docker Swarm by default

Skitflow runs as a Docker Swarm cluster by default. Start on a single node and add more whenever you need to: Swarm spreads services across nodes and reschedules them if one goes down, without changing how you deploy.

Replicated storage with LINSTOR

When you run more than one node, Skitflow can replicate volumes across them with LINSTOR, backed by DRBD. A service's data is kept in sync on another node ahead of time, so if a node fails, Swarm can reschedule the workload onto a node that already holds an up-to-date replica. See LINSTOR Distributed Storage.

Observability with ClickHouse

Runtime logs, distributed traces, route metrics, and resource metrics are collected by telemetry agents and stored in ClickHouse, a columnar engine built for high-volume telemetry. Human dashboards read from ClickHouse, and the AI Assistant can use the same operational context for diagnostics and proposals. See Observability.

AI Gateway

The AI Gateway is the routing and governance layer for Skitflow AI features. When enabled, Skitflow routes AI calls through a LiteLLM-compatible gateway instead of calling each provider directly from every feature.

The gateway provides:

  • Provider routing — route the organization default, Assistant, and Ask AI features to different providers or to the platform default model.
  • BYOK and platform models — tenants can use their own provider keys, while managed deployments can provide a platform fallback model.
  • Per-organization attribution — gateway traffic uses organization-scoped virtual keys so usage can be attributed and governed.
  • Usage and governance — operators can review usage and enforce budgets without exposing provider secrets.

If the gateway is disabled, Skitflow falls back to the direct provider configuration path. If the gateway is enabled but unavailable, AI features fail cleanly instead of hanging on a dead upstream.

AI Assistant

The AI Assistant is the product-facing assistant, not a separate "AI DevOps Agent" anymore. It uses the AI Gateway for model routing and can work with:

  • Docker Compose generation and deployment flows.
  • Compose review and security hardening.
  • Application, compose, database, backup, domain, and environment diagnostics.
  • Proposal-based operations that require explicit confirmation before mutation.
  • Observability and scoped operational context when available.

AI Code Review

Code Review runs as another governed AI workload on the Swarm runtime. It reviews pull requests and posts the result back to the forge:

  • Each review returns concrete findings on the changed code, along with a confidence score (N/5) so you can tell a strong signal from a weak one.
  • It connects to GitHub, GitLab, and Gitea repositories.
  • Code Review skills are reusable review policies — path-scoped, prioritized instructions your organization controls.
  • Model access goes through the AI Gateway like every other AI feature, so routing, keys, and usage stay governed in one place.

Together, these layers let Skitflow deploy applications, operate infrastructure, and route AI work through a controlled gateway rather than scattering provider calls across the product.

On this page