BLUE OCEAN AI Technology
EN DE
Blue Ocean AI Technology – Technical Architecture

Technical Architecture Design

AI Agents as “Managed Service” (Enterprise Edition)

As of: April 2026

Model: Managed Service Provider (MSP) / Single-Tenant

Focus: 100% Data Isolation, IaC Automation, Zero-Downtime Deployments, GDPR Compliance.

1. Executive Summary & Control Plane vs. Tenant

The foundation of Blue Agency relies on the strict separation of central agency infrastructure (Control Plane) and isolated client environments (Tenant Nodes). Instead of a multi-tenant database, each client receives a dedicated Hetzner VM (Single-Tenant). This guarantees the highest data security, predictable costs, and enterprise compliance, as a data leak between clients is technically impossible.

2. High-Level Architecture

The diagram visualizes the separation between central management and client servers.

High-Level Architecture
🛠️ Show Source Code for the Diagram (Mermaid) 
graph TD
    subgraph Control Plane [Blue Agency Central Infrastructure]
        GitHub[GitHub: Repo & Actions]
        Grafana[Grafana / Prometheus: Monitoring]
        Loki[Loki: Central Logging]
        Uptime[Uptime Kuma: Alerting]
    end

    subgraph Internet & DNS [Routing & Security]
        CF[Cloudflare: DNS & DDoS Protection]
    end

    subgraph Tenant Nodes [Hetzner Cloud - Isolated Client Servers]
        NodeA[Server: Client A\nIP: 116.x.x.1]
        NodeB[Server: Client B\nIP: 116.x.x.2]
        NodeC[Server: Client C\nIP: 116.x.x.3]
    end

    Developer((Developer)) -->|Push Code| GitHub
    GitHub -->|1. IaC: Creates Server| NodeC
    GitHub -->|2. CI/CD: Deploy Code| NodeA
    GitHub -->|2. CI/CD: Deploy Code| NodeB
    
    CF -->|Traffic agent.client-a.blueagency.io| NodeA
    CF -->|Traffic agent.client-b.blueagency.io| NodeB
    
    NodeA -.->|Sends Metrics & Logs| Grafana
    NodeB -.->|Sends Metrics & Logs| Grafana
    NodeA -.->|Sends Logs| Loki

3. The Tenant Architecture (“AI Employee” Server)

Each client receives a Hetzner Cloud instance (e.g., CX32) with a hardened Docker Compose stack that isolates and securely orchestrates all required system components.

3.1. Components within a Client Server

Tenant Architecture
🛠️ Show Source Code for the Diagram (Mermaid) 
graph TD
    subgraph Hetzner Server: Client A
        Traefik[Traefik Reverse Proxy\n+ Let's Encrypt SSL]
        
        subgraph Docker Network [Isolated Network]
            Dashboard[Client Dashboard\nFrontend App]
            FastAPI[AI Backend\nFastAPI / Python]
            DB[(PostgreSQL + pgvector\nVector Database)]
            Redis[(Redis\nCache & Task Queue)]
            Celery[Celery Worker\nBackground Tasks]
        end
        
        Traefik -->|UI / Dashboard| Dashboard
        Traefik -->|API Requests| FastAPI
        Dashboard -->|REST API| FastAPI
        FastAPI <--> DB
        FastAPI <--> Redis
        Redis <--> Celery
        Celery <--> DB
    end
    
    User((User / Admin)) -->|HTTPS| Traefik
    FastAPI -->|Direct LLM Calls| Gemini((Google Gemini API))

3.2. Technical Specifications

  • Traefik: Reverse Proxy for SSL certificates and traffic routing.
  • Client Dashboard: White-label web app for client management of prompts, agents, and history.
  • FastAPI (AI Core): Python center for RAG pipelines (Retrieval-Augmented Generation) and direct Google Gemini API connection.
  • Redis & Celery: Asynchronous processing of long LLM requests to avoid webhook timeouts.
  • PostgreSQL + pgvector: Central database for user data and vector embeddings (RAG knowledge base).

4. Phase 1: Bootstrap Strategy (Clients 1-5)

To efficiently use the initial budget for product quality (the AI agent), complex infrastructure scripts are avoided for the first clients. Enterprise security (Single-Tenant) is fully maintained; only the server creation is done manually. Deployment is professionally automated via GitHub Actions from Day 1.

4.1. Flowchart Phase 1 (Semi-Automated)

Bootstrap Pipeline
🛠️ Show Source Code for the Diagram (Mermaid) 
sequenceDiagram
    participant Admin as System Admin
    participant Hetzner as Hetzner Cloud (UI)
    participant Dev as Developer
    participant GitHub as GitHub (Repo & Actions)
    participant Server as Client Server

    Note over Admin,Hetzner: 1. Manual Infrastructure (Once per client)
    Admin->>Hetzner: Click server in dashboard (2 min)
    Hetzner-->>Admin: IP Address & Root Access
    Admin->>GitHub: Save IP & SSH keys as Secret
    Admin->>Server: Initial Docker installation (SSH)
    
    Note over Dev,Server: 2. Automated Deployment (Ongoing)
    Dev->>GitHub: Push Update (e.g., Release v1.1)
    activate GitHub
    GitHub->>GitHub: Build Docker Image (GHCR)
    GitHub->>Server: Connect via SSH
    activate Server
    Server->>Server: docker compose pull && up -d
    Server-->>GitHub: Deployment successful
    deactivate Server
    GitHub-->>Dev: Pipeline "Passed" ✅
    deactivate GitHub

4.2. Focus in Phase 1

  • Infrastructure: Manual creation of Hetzner servers in the web interface. Saves development costs for Terraform.
  • Deployment: Use of a simple GitHub Actions pipeline. A push to the main branch automatically updates the client’s server.
  • Monitoring: Use of “Uptime Kuma” on a €3 server for simple ping monitoring (alert on failure), instead of complex Grafana setups.

5. Phase 2 & 3: Scaling & Full Automation (From Client 6)

As soon as recurring revenue (MRR) is secured, the system will be fully automated to eliminate manual friction points.

5.1. Rollout Process (Fully Automated)

🛠️ Show Source Code for the Diagram (Mermaid) 
sequenceDiagram
    participant Dev as Developer
    participant GitHub as GitHub (Repo & Actions)
    participant Hetzner as Hetzner API (Terraform)
    participant Server as Client Server (Ansible)

    Dev->>GitHub: Push Update (e.g., Release v2.1)
    activate GitHub
    GitHub->>GitHub: Builds & stores Docker Image
    
    alt New Client
        GitHub->>Hetzner: Terraform: Create VM & Firewalls
        Hetzner-->>GitHub: Return IP Address
        GitHub->>Server: Ansible: Initialize OS & Docker
    end

    GitHub->>Server: Ansible: Connect via SSH
    activate Server
    Server->>Server: docker compose up -d (Zero-Downtime Reload)
    Server-->>GitHub: Deployment successful
    deactivate Server
    deactivate GitHub

5.2. Infrastructure & Configuration Management

  • Terraform (IaC): Communicates with the Hetzner API for the fully automated creation of the VM, Cloud Firewall, and Storage Volumes.
  • Ansible: Handles server hardening (Fail2Ban, SSH keys) and the secure rollout of container configurations (incl. secret management via GitHub).

6. Security & Backups

  • Network Security: Cloudflare DNS, strict Hetzner Cloud Firewall (only Port 80/443 & dedicated agency SSH access).
  • Backup Strategy:
    1. Daily Hetzner Image Snapshots.
    2. Encrypted PostgreSQL dumps (every 4 hours) to an external Hetzner Storage Box.
    3. Automatic mirroring of vector database volumes.

7. Monitoring & Logging (Phase 3)

Proactive monitoring via the Control Plane:

  • Loki / Promtail: Centralization of logs from all decentralized tenant containers.
  • Prometheus: Monitoring of system resources (RAM, CPU, Disk) with automated alerting.
  • Grafana: Analysis of application metrics (LLM Token Usage, API Response Times from Gemini).

8. Summary of Resources

Initially required Control Plane infrastructure:

  • GitHub: SaaS for code, CI/CD pipelines, and Container Registry (GHCR).
  • Management Node (Hetzner CPX31): Hosts Grafana, Prometheus, Loki (relevant from Phase 2).
  • Backup Storage (Hetzner Storage Box): Central, secure archive for client database dumps.

Technisches Architektur-Design

KI-Agenten als “Managed Service” (Enterprise Edition)

Stand: April 2026

Modell: Managed Service Provider (MSP) / Single-Tenant

Fokus: 100% Datenisolation, IaC-Automatisierung, Zero-Downtime Deployments, DSGVO-Konformität.

1. Executive Summary & Control Plane vs. Tenant

Das Fundament der Blue Agency beruht auf der strikten Trennung von zentraler Agentur-Infrastruktur (Control Plane) und isolierten Kunden-Umgebungen (Tenant Nodes). Anstatt einer Multi-Tenant-Datenbank erhält jeder Kunde eine dedizierte Hetzner-VM (Single-Tenant). Dies garantiert höchste Datensicherheit, planbare Kosten und Enterprise-Compliance, da ein Datenleck zwischen Kunden technisch ausgeschlossen ist.

2. High-Level Architektur

Das Diagramm visualisiert die Trennung zwischen zentraler Verwaltung und Kunden-Servern.

High-Level Architektur
🛠️ Quellcode für das Diagramm (Mermaid) anzeigen 
graph TD
    subgraph Control Plane [Blue Agency Zentral-Infrastruktur]
        GitHub[GitHub: Repo & Actions]
        Grafana[Grafana / Prometheus: Monitoring]
        Loki[Loki: Zentrales Logging]
        Uptime[Uptime Kuma: Alerting]
    end

    subgraph Internet & DNS [Routing & Security]
        CF[Cloudflare: DNS & DDoS Protection]
    end

    subgraph Tenant Nodes [Hetzner Cloud - Isolierte Kunden-Server]
        NodeA[Server: Kunde A\nIP: 116.x.x.1]
        NodeB[Server: Kunde B\nIP: 116.x.x.2]
        NodeC[Server: Kunde C\nIP: 116.x.x.3]
    end

    Entwickler((Entwickler)) -->|Push Code| GitHub
    GitHub -->|1. IaC: Erstellt Server| NodeC
    GitHub -->|2. CI/CD: Deploy Code| NodeA
    GitHub -->|2. CI/CD: Deploy Code| NodeB
    
    CF -->|Traffic agent.kunde-a.blueagency.io| NodeA
    CF -->|Traffic agent.kunde-b.blueagency.io| NodeB
    
    NodeA -.->|Sendet Metriken & Logs| Grafana
    NodeB -.->|Sendet Metriken & Logs| Grafana
    NodeA -.->|Sendet Logs| Loki

3. Die Tenant-Architektur (“KI-Mitarbeiter” Server)

Jeder Kunde erhält eine Hetzner Cloud Instanz (z.B. CX32) mit einem gehärteten Docker Compose Stack, der alle benötigten Systemkomponenten isoliert und sicher orchestriert.

3.1. Komponenten innerhalb eines Kunden-Servers

Tenant-Architektur
🛠️ Quellcode für das Diagramm (Mermaid) anzeigen 
graph TD
    subgraph Hetzner Server: Kunde A
        Traefik[Traefik Reverse Proxy\n+ Let's Encrypt SSL]
        
        subgraph Docker Network [Isoliertes Netzwerk]
            Dashboard[Client Dashboard\nFrontend App]
            FastAPI[KI Backend\nFastAPI / Python]
            DB[(PostgreSQL + pgvector\nVector Database)]
            Redis[(Redis\nCache & Task Queue)]
            Celery[Celery Worker\nBackground Tasks]
        end
        
        Traefik -->|UI / Dashboard| Dashboard
        Traefik -->|API Requests| FastAPI
        Dashboard -->|REST API| FastAPI
        FastAPI <--> DB
        FastAPI <--> Redis
        Redis <--> Celery
        Celery <--> DB
    end
    
    User((User / Admin)) -->|HTTPS| Traefik
    FastAPI -->|Direct LLM Calls| Gemini((Google Gemini API))

3.2. Technische Spezifikationen

  • Traefik: Reverse Proxy für SSL-Zertifikate und Traffic-Routing.
  • Client Dashboard: White-Label Web-App zur Kundenverwaltung von Prompts, Agenten und Historie.
  • FastAPI (KI Core): Python-Zentrale für RAG-Pipelines (Retrieval-Augmented Generation) und direkte Google Gemini API Anbindung.
  • Redis & Celery: Asynchrone Verarbeitung langer LLM-Anfragen zur Vermeidung von Webhook-Timeouts.
  • PostgreSQL + pgvector: Zentrale Datenbank für Nutzerdaten und Vektor-Embeddings (RAG-Wissensdatenbank).

4. Phase 1: Bootstrap-Strategie (Kunde 1-5)

Um das initiale Budget effizient für die Produktqualität (den KI-Agenten) zu nutzen, wird bei den ersten Kunden auf komplexe Infrastruktur-Skripte verzichtet. Die Enterprise-Sicherheit (Single-Tenant) bleibt vollständig gewahrt, lediglich die Server-Erstellung erfolgt manuell. Das Deployment ist ab Tag 1 professionell über GitHub Actions automatisiert.

4.1. Ablaufplan Phase 1 (Semi-Automatisiert)

Bootstrap Ablaufplan
🛠️ Quellcode für das Diagramm (Mermaid) anzeigen 
sequenceDiagram
    participant Admin as System-Admin
    participant Hetzner as Hetzner Cloud (UI)
    participant Dev as Entwickler
    participant GitHub as GitHub (Repo & Actions)
    participant Server as Kunden-Server

    Note over Admin,Hetzner: 1. Manuelle Infrastruktur (Einmalig pro Kunde)
    Admin->>Hetzner: Server im Dashboard klicken (2 Min)
    Hetzner-->>Admin: IP-Adresse & Root-Zugang
    Admin->>GitHub: IP & SSH-Keys als Secret speichern
    Admin->>Server: Docker initial installieren (SSH)
    
    Note over Dev,Server: 2. Automatisches Deployment (Laufend)
    Dev->>GitHub: Push Update (z.B. Release v1.1)
    activate GitHub
    GitHub->>GitHub: Baut Docker Image (GHCR)
    GitHub->>Server: Verbinde via SSH
    activate Server
    Server->>Server: docker compose pull && up -d
    Server-->>GitHub: Deployment erfolgreich
    deactivate Server
    GitHub-->>Dev: Pipeline "Passed" ✅
    deactivate GitHub

4.2. Fokus in Phase 1

  • Infrastruktur: Manuelle Erstellung der Hetzner-Server im Web-Interface. Spart Entwicklungskosten für Terraform.
  • Deployment: Nutzung einer simplen GitHub Actions Pipeline. Ein Push in den main-Branch aktualisiert automatisch den Server des Kunden.
  • Monitoring: Einsatz von “Uptime Kuma” auf einem 3€-Server für simples Ping-Monitoring (Alarm bei Ausfall), anstatt komplexer Grafana-Setups.

5. Phase 2 & 3: Skalierung & Full-Automation (Ab Kunde 6)

Sobald wiederkehrende Umsätze (MRR) gesichert sind, wird das System zur Beseitigung manueller Reibungspunkte vollautomatisiert.

5.1. Rollout-Prozess (Voll-Automatisiert)

🛠️ Quellcode für das Diagramm (Mermaid) anzeigen 
sequenceDiagram
    participant Dev as Entwickler
    participant GitHub as GitHub (Repo & Actions)
    participant Hetzner as Hetzner API (Terraform)
    participant Server as Kunden-Server (Ansible)

    Dev->>GitHub: Push Update (z.B. Release v2.1)
    activate GitHub
    GitHub->>GitHub: Baut & speichert Docker Image
    
    alt Neuer Kunde
        GitHub->>Hetzner: Terraform: Erstelle VM & Firewalls
        Hetzner-->>GitHub: IP-Adresse zurück
        GitHub->>Server: Ansible: Initialisiere OS & Docker
    end

    GitHub->>Server: Ansible: Verbinde via SSH
    activate Server
    Server->>Server: docker compose up -d (Zero-Downtime Reload)
    Server-->>GitHub: Deployment erfolgreich
    deactivate Server
    deactivate GitHub

5.2. Infrastructure & Configuration Management

  • Terraform (IaC): Kommuniziert mit der Hetzner API für das vollautomatisierte Erstellen der VM, Cloud Firewall und Storage Volumes.
  • Ansible: Übernimmt die Server-Härtung (Fail2Ban, SSH-Keys) und das sichere Ausrollen der Container-Konfigurationen (inkl. Secret Management via GitHub).

6. Security & Backups

  • Netzwerksicherheit: Cloudflare DNS, strikte Hetzner Cloud Firewall (nur Port 80/443 & dedizierter Agentur-SSH-Zugriff).
  • Backup-Strategie:
    1. Tägliche Hetzner Image-Snapshots.
    2. Verschlüsselte PostgreSQL-Dumps (alle 4 Stunden) auf eine externe Hetzner Storage Box.
    3. Automatische Spiegelung der Vektordatenbank-Volumes.

7. Monitoring & Logging (Phase 3)

Proaktives Monitoring über die Control Plane:

  • Loki / Promtail: Zentralisierung der Logs aller dezentralen Tenant-Container.
  • Prometheus: Überwachung von Systemressourcen (RAM, CPU, Festplatte) mit automatisiertem Alerting.
  • Grafana: Auswertung von Applikations-Metriken (LLM Token Usage, API Response Times von Gemini).

8. Zusammenfassung der Ressourcen

Initial benötigte Control Plane-Infrastruktur:

  • GitHub: SaaS für Code, CI/CD Pipelines und Container Registry (GHCR).
  • Management Node (Hetzner CPX31): Hostet Grafana, Prometheus, Loki (relevant ab Phase 2).
  • Backup Storage (Hetzner Storage Box): Zentrales, sicheres Archiv für Kundendatenbank-Dumps.