Zum Inhalt springen
APUNA — open by default

Technische Referenz für Entwickler und Evaluatoren. Methodik und Feldkontext findest du im Devlog.

Plattformarchitektur & Build-Pipeline

Offen als Standard · EU zuerst · ein Mensch gibt jede Änderung frei.

Prinzip 01
Alles läuft über standardisierte Verträge
Jede Komponente verbindet sich über einen standardisierten, versionierten Vertrag mit dem Rest. Keine Komponente greift direkt in die Daten einer anderen — daher kann jede einzelne ausgetauscht, geprüft oder unabhängig übergeben werden.
Prinzip 02
Sie besitzen den Code
Der Code, den wir liefern, bleibt Ihr Eigentum — Sie können ihn lesen, behalten und unabhängig betreiben. Lizensiert unter Apache-2.0, einer standardisierten freien Lizenz. Managed-Komponenten setzen wir nur dort ein, wo sie sich bewähren; alles andere ist Open Source und auf Ihre eigene Infrastruktur übertragbar.
Prinzip 03
EU zuerst · DE bevorzugt
Daten in der EU ansässig; Deutschland, wo technisch & finanziell vertretbar.
Prinzip 04
Ein Mensch entscheidet
Das Sicherheitsnetz steckt in der Architektur: keine Agenten-Änderung geht ohne menschliche Freigabe live.
ADer Stack

Der vollständige Stack ist öffentlich einsehbar — jede Abhängigkeit, jede Version. github.com/apuna-dev/core

BSouveränitäts-Zonierung
Deutschland — bevorzugt

Wo technisch & finanziell vertretbar: GCP Frankfurt · OSS rückholbar auf deutsche Infrastruktur (z. B. Hetzner) · die Kundin betreibt den offenen Kern auf eigener Infrastruktur.

Europa — Standard

Cloudflare EU-Datenlokalisierung · Brevo (FR) · Workspace EU-Region · EU-ansässige Inferenz. Nichts verlässt die EU ohne benannten Grund.

US-Anbieter

Nur mit EU-Datenlokalisierung und einem offenen Ausstiegspfad eingesetzt. Ehrlicher Vorbehalt: Anbieter mit US-Sitz bedeuten Zugriff durch US-Behörden — abgemildert durch Speicherung in der EU-Region und das Recht, jede Schicht auf EU-Infrastruktur zurückzuholen.

CPlatzierung — eine Architektur, drei Substrate

Die Souveränitäts-Zonierung beantwortet, welche Jurisdiktion; die Platzierung beantwortet, wessen Hardware. Weil jede Schicht hinter dem OpenAPI-Vertragsbus liegt, ist das Substrat ein Regler, keine Neuschreibung — der Vertrag ist die Invariante, und dasselbe ausgelieferte System läuft an einem von drei Orten, pro Workload danach gewählt, wessen Eigenschaften passen.

Stufe 01 · eigenes Metall
Apuna Bare Metal

Ubuntu-Services-Ebene — k3s, PostgreSQL, MinIO (S3), Ory/Zitadel, Observability. AMD 7500X3D · RTX 5090 · 64 GB DDR5 als Inferenz-Ebene — Open-Weight-Modelle via Ollama, auf dem Gerät.

Am besten für: souveräne & sensible Datenverarbeitung, Dauerlast-Inferenz, Dev/Test. Am souveränsten, kein Egress, am günstigsten bei Dauerlast.

Stufe 02 · managed · Standard
Cloudflare + GCP Frankfurt

Die vier managed Säulen tragen die öffentliche Oberfläche, Lastspitzen und E-Mail — der gekaufte Wert ist übertragene Betriebsverantwortung, nicht rohe Rechenleistung.

Am besten für: die öffentliche SLA-Oberfläche, Verfügbarkeitszusagen, E-Mail-Zustellbarkeit, schwankende Nachfrage. Sie kaufen den Pager, nicht den Server.

Stufe 03 · Kunden-Cloud
Die AWS / Azure / GCP der Kundin

Container → EKS/ECS · Postgres → RDS · OIDC föderiert zum IdP · Objekte → S3 · IaC zielt um · Claude → Bedrock. Das Ergebnis wird neu deployt, nicht neu geschrieben.

Am besten für: Kundinnen mit bestehender Cloud-Bindung oder eigener Residenzvorgabe. Das System landet in ihrem Konto, ihrem Perimeter, ihren Schlüsseln.

Zwei ehrliche Grenzen

Frontier-Reasoning ist immer ein gehosteter Aufruf — Claude ist Closed-Weight und wird per API erreicht (Agent Platform oder Bedrock in der AWS der Kundin), egal wo der Rest läuft; AMD 7500X3D + RTX 5090 bedient die Open-Weight-Stufe via Ollama, der Vertragsbus routet dazwischen. Und produktive E-Mail braucht auf jedem Substrat ein Relay — Zustellbarkeit ist ein IP-Reputationsspiel, das ein selbstgehosteter Mailserver verliert. Alles andere lässt sich wirklich verschieben.

Wie ich baue — für Entwickler und Evaluatoren

Kontrakt vor Code · Agenten schlagen vor, ein Mensch entscheidet · reproduzierbar, nachvollziehbar, umkehrbar.

Entwicklungs-Pipeline

Vertrag vor Code · Agenten schlagen vor, ein Mensch entscheidet · reproduzierbar, nachvollziehbar, umkehrbar.

DVom Vertrag zu Care — der Kreislauf
  1. 01

    Vertrag zuerst

    Jedes Feature beginnt als OpenAPI-Vertrag und abgegrenztes Briefing. Der Vertrag ist die Spezifikation — der Code folgt ihm, interne Komponenten eingeschlossen.

  2. 02

    Agentischer Build

    Claude-Code-Agenten erzeugen kleine, atomare Pull Requests gegen den Vertrag und seine Tests. Schmale Diffs, jeder einzeln prüfbar.

    Claude Code · Agent Platform authGitHubOpenAPI tests
  3. 03

    /meeting — menschliche Freigabe, auf echten Geräten

    Keine Agenten-Änderung wird zusammengeführt, ohne dass ein Mensch den atomaren PR über die Geräteflotte prüft und testet — Desktop, Laptop, Tablet, Smartphone — und die Änderung so sieht, wie ein Nutzer sie sehen wird.

    AMD 7500X3D + RTX 5090MacBook Air M4iPad AiriPhone 17 Pro
    Ein Mensch entscheidet — by design. Die täglichen Arbeitsgeräte dienen zugleich als erster Hardware-Prüfstand, und AMD 7500X3D + RTX 5090 (64 GB DDR5) betreibt Open-Weight-Modelle lokal via Ollama — diese Inferenz bleibt auf dem Gerät. Diese Freigabe ist nicht verhandelbar und wird niemals wegautomatisiert.
  4. 04

    Continuous Integration

    Lint · Typecheck · OpenAPI-Konformität · Unit & Integration · SAST/DAST-Sicherheitsscan — die Zero-Trust-, Break-it-first-Haltung im Gate.

    GitHub ActionsOpenAPI conformanceSAST · DAST
  5. 05

    Infrastruktur als Code

    Cloudflare und GCP deklarativ bereitgestellt — reproduzierbar, nachvollziehbar und rückholbar auf EU-/deutsche Infrastruktur durch einen Zielwechsel, nicht durch eine Neuschreibung.

    OpenTofuOCI images
  6. 06

    Deployment — isoliert pro Mandant

    Die statische Website und die dynamischen Edge-Routen gehen über die Kette unten live; schwerere Dienste deployen nach Cloud Run / GKE in GCP Frankfurt. Ein isolierter Build pro Kunde, übergeben zum Betrieb auf eigener Infrastruktur.

    GitHubGitHub ActionsWranglerCloudflare Pages / Workers
  7. 07

    Beobachten

    OpenTelemetry → Prometheus / Grafana; Live-Dashboards an die Kundin geliefert; Incidents in den direkten Kanal geleitet.

    OpenTelemetryGrafanaBrevo channel
  8. 08

    Care-Kreislauf

    Automatisierung übernimmt die deterministischen ~80 % der Wartung; Menschen treffen die Ermessensentscheidungen; die Nutzung wird pro Mandant gemessen für eine ehrliche Durchreich-Abrechnung — und fließt zurück in den Vertrag.

EOpen-Source-Haltung

Managed nur, wo es sich rechtfertigt — überall sonst offen, jederzeit rückholbar.

Vier managed Säulen tragen, was sie am besten können: Cloudflare (Edge), GCP (schweres Compute & Daten, Frankfurt), Brevo (EU-Kommunikation), Google Workspace (internes Büro). Jede andere Schicht ist Open Source, und jede managed Abhängigkeit behält einen OSS-, EU-hostbaren Ausstieg — so ist keine Schicht ein Lock-in, und die Kundin besitzt den Kern stets unter Apache-2.0.

Managed Drittanbieter (EU-lokalisiert)
Open Source · selbst hostbar
Menschlicher Entscheidungspunkt
Klartext

Cloudflare, Google und der GitHub-Code-Host haben ihren Hauptsitz in den USA; das wird benannt, nicht verschwiegen. EU-Datenlokalisierung, ein gepflegter Open-Source-Ausstieg auf jeder Schicht und eine verteilte Git-Historie, die sich mit einem einzigen Befehl wegspiegeln lässt, bedeuten: Die Ansässigkeit ist heute durchgesetzt und die Rückholung morgen verfügbar — dasselbe Prinzip wie das Produkt: offen als Standard, zuverlässig per Abonnement und umkehrbar by design.

Der VDMA-Praxistag-Bericht zeigt dieselben Schichten an einem realen Predictive-Maintenance-Einsatz — Abschnitt D zu Agent-Anforderungen, Abschnitt F zur Referenzarchitektur.

VDMA Praxistag KI — Architekturbericht aus der Praxis

Apuna · Plattformarchitektur & Pipeline · 18. Juni 2026