Architektur & Ausführungsmodell — für IT-Administratoren, Sicherheitsexperten & Entwickler.
awaBerry arbeitet als Drei-Schichten-System. Der Geräte-Agent initiiert stets die ausgehende Verbindung zur Cloud-Schicht — es werden niemals eingehende Ports geöffnet, und kein Gerät ist für etwas erreichbar, das nicht über den awaBerry Access Broker authentifiziert wurde.
Vermittelt alle Verbindungen und speichert die Konfiguration. Authentifiziert jede Zugriffsanfrage. Fungiert als zentrale Steuerungsebene für Geräte-Registry, Projektkonfiguration, Zugriffsschlüssel und Ausführungsprotokolle.
Läuft als Hintergrunddienst auf jedem registrierten Rechner. Stellt einen ausgehenden HTTPS-Tunnel zur Cloud-Schicht her — öffnet niemals eingehende Ports. Führt Zugriffsanfragen aus, die durch die Berechtigungen des aktiven Projekts begrenzt sind.
Führen Automatisierungs- und Zugriffsanfragen direkt auf dem Gerät aus. Automatisierungsskripte, Datenverarbeitung und KI-generierte Pipelines laufen alle lokal — Daten transitieren keine awaBerry-Infrastruktur, es sei denn, sie werden explizit dorthin geleitet.
Drei Bereitstellungswege decken jedes Infrastrukturszenario ab. Jeder Onboarding-Pfad erzeugt einen registrierten Geräteeintrag im Dashboard mit einer eindeutigen Geräte-ID und verschlüsselten Tunnel-Zugangsdaten.
Am besten geeignet für: Bare Metal, SoC, kundenspezifische Hardware.
Kundenspezifischer Installer, der pro Gerät generiert wird — auf USB/SD-Karte flashen oder direkt bereitstellen.
Am besten geeignet für: Containerisierte Stacks, NAS, Server.
docker run mit dem awaBerry-Image — keine Änderung des Host-Betriebssystems erforderlich.
Am besten geeignet für: Bestehende laufende Maschinen.
Ein-Klick-Initialisierungsfluss vom Dashboard — keine Medienerstellung, keine manuelle Konfiguration.
Nach der Registrierung folgt jeder Sitzungstyp demselben Dreischrittmuster:
Wählen Sie die gewünschte Zugriffsmethode im awaBerry-Webportal — RDP, VNC, SSH, Zero-Trust Port Forwarding oder Dateibrowser. Die Sitzung wird bei Bedarf aktiviert; es bestehen keine dauerhaften Verbindungen.
Verbinden Sie sich über den Browser (SSH, Zero-Trust Port Forwarding, In-Browser-VNC) oder einen nativen Client (RDP, VNC mit Apple Screen Sharing / RealVNC / Remmina). Kein VPN-Client, keine Portkonfiguration.
Der gesamte Verkehr fließt durch den verschlüsselten Tunnel — niemals direkt zwischen Client und Gerät. Zero-Trust Port Forwarding Tunnel ordnen einen lokalen Port auf dem registrierten Gerät (z. B. ein Router-Admin-Panel) einer sicheren Tunnel-URL zu — sofort live, ohne Firewall-Änderungen.
Die zentrale architektonische Entscheidung der Smart Automation Platform ist eine strikte Trennung zwischen der Erstellung von Automatisierungslogik und deren Ausführung. Diese Trennung fördert sowohl Zuverlässigkeit als auch Kosteneffizienz.
Eine Eingabeaufforderung in einfacher Sprache wird von Gemini Pro (Reasoning-Modell) verarbeitet, das lokal über die Gemini CLI auf dem Gerät ausgeführt wird. Die KI analysiert die Umgebung, erkundet installierte Laufzeiten und Dateipfade, schreibt ein produktionsbereites Skript (Node.js, Python oder Bash), installiert erforderliche Abhängigkeiten und validiert die Ausführung — alles in einem einzigen Einrichtungslauf.
Token-Kosten: 7.000–18.000 Tokens, einmalig.
Das generierte Skript wird lokal auf dem Gerät gespeichert und über Cron, Systemd oder den Windows Task-Scheduler geplant. Jeder nachfolgende Lauf führt das eigenständige, deterministische Skript aus — keine KI ist beteiligt, keine Tokens werden verbraucht.
Optional kann Gemini Flash Lite die Ausführungsausgabe zusammenfassen (~100–500 Tokens pro Lauf).
Web Scraping & Browser-Automatisierung (Playwright, Puppeteer), Dokumentenverarbeitung (pdfplumber, pdf-parse), Legacy-UI-Automatisierung (pyautogui), Protokollüberwachung, Datenbankoperationen (pg_dump, SQLite, rclone, GPG), API- & Datenpipelines (feedparser, arxiv, SMTP), Gesundheitsdaten (hl7apy, fhirclient) und Dateisystemüberwachung (inotify, fs.watch).
Jede Zugriffsfreigabe — sei es für ein automatisiertes Skript, einen KI-Agenten oder einen menschlichen Benutzer — wird als Agentic API Projekt modelliert. Ein Projekt definiert Zielgeräte, Zugriffsmodus (Programmatisch oder Gemeinsam genutzter Benutzer), Berechtigungsstufe, Dateisystemumfang und Befehlsumfang. Bei der Erstellung generiert die Plattform einen eindeutigen Projektschlüssel und ein Projektgeheimnis.
Ein Skript, ein KI-Agent oder eine CI-Pipeline sendet eine POST-Anfrage an /api/v1/execute mit Projekt-Schlüssel + Geheimnis und einem Body, der den Befehl, das Zielgerät und alle Eingabedateien enthält. Das awaBerry API Gateway validiert Anmeldeinformationen, prüft den Befehl gegen die Zulassungsliste und prüft den Pfad gegen die Ordner-ACL, bevor es an den Geräte-Agenten weitergeleitet wird. Der Agent führt in einem abgegrenzten Kontext aus und gibt stdout, stderr und exit_code zurück.
Die Agentic API stellt eine Model Context Protocol (MCP) Server-Schnittstelle bereit, die es KI-Orchestrierungs-Frameworks (Claude, Gemini, benutzerdefinierte Agenten) ermöglicht, awaBerry als Tool-Anbieter zu registrieren. KI-Agenten können registrierte Geräte auflisten, zulässige Befehle ausführen, aus abgegrenzten Verzeichnissen lesen und in diese schreiben und Aufrufe über mehrere Maschinen in einer Pipeline verketten.
Für menschliche Benutzer (Support-Ingenieure, Auditoren, Kollaborateure): Erstellen Sie ein Projekt mit dem Modus "Gemeinsam genutzter Gerätezugriff", aktivieren Sie optionale Funktionen (Remote Desktop, Aktivierung des Zero-Trust Port Forwarding Ports), teilen Sie den Projektschlüssel und das Geheimnis (integrierter E-Mail-Entwurf verfügbar). Der Benutzer verbindet sich mit dem isolierten awaberry-Konto. Der Zugriff wird durch Löschen des Projekts beendet — sofort, vollständig, keine Bereinigung erforderlich.
Web-Dashboard (app.awaberry.com): Geräte-Registry, Projektkonfiguration, Zugriffsschlüssel, Ausführungsprotokolle.
awaBerry-Agent: einmal pro Gerät installieren; läuft als Hintergrunddienst.
Automatisierungsskripte: bei der Einrichtung generiert; geplant über den Betriebssystem-Task-Scheduler — keine laufende Wartung.
Gemini CLI: einmal pro Gerät mit Automatisierung installiert; nur während der Einrichtungsphasen verwendet.
Alle Zugriffsprojekte sind im Dashboard mit ihrer vollständigen Berechtigungskonfiguration sichtbar.
Ausführungsprotokolle werden pro Automatisierungslauf aufbewahrt.
Projektschlüssel können von einer einzigen Steuerungsebene aufgelistet, überprüft und widerrufen werden.
Es gibt keinen Zugriff außerhalb eines aktiven Projekts — es gibt keine dauerhaften Anmeldeinformationen oder Hintergrundsitzungen.
Agentic API: Standard-HTTPS-REST — Integration aus jeder Sprache oder CI/CD-Pipeline.
MCP-Server: Kompatibel mit Claude, Gemini und benutzerdefinierten Agentic-Frameworks.
Docker-Bereitstellung: Standardcontainer, komponierbar in bestehende Stacks.
Automatisierungsausgabe: Dateisystem, Webhooks, SMTP, REST-Endpunkte — jedes Ziel, das Ihr Workflow benötigt.
Die Architektur von awaBerry ist an der Integrationsschnittstelle bewusst einfach gehalten — HTTPS REST, Standard-Native-Clients, Prompts in einfacher Sprache — während sie die schwierigen Probleme intern löst: reine ausgehende Tunnelung, KI-gesteuerte Skriptgenerierung, granulare Berechtigungsdurchsetzung und Flottenweite Orchestrierung. Jede Komponente läuft dort, wo sie hingehört: Steuerung in der Cloud, Ausführung auf dem Gerät, Daten nirgendwo, wo sie nicht explizit hingeschickt wurden.