Huginn: älteres Ruby-on-Rails-Tool für Personal-Automation, RSS, Scraping, Notifications

Was ist Huginn?

Huginn ist eine Open-Source-Plattform für Personal-Automation, 2013 von Andrew Cantino gestartet, benannt nach einem der zwei Raben des nordischen Gottes Odin (Huginn = „Gedanke"). Die Position im Markt ist nischiger als die anderen Tools in der Vergleichsliste: Huginn ist explizit für einzelne User oder kleine Gruppen gebaut, die Web-basierte Daten überwachen, RSS-Feeds verarbeiten, Web-Sites scrapen oder Notifications koordinieren wollen.

Die Plattform läuft als Ruby-on-Rails-Anwendung auf eigenem Server – Self-Hosting ist der einzige Pfad, einen kommerziellen Cloud-Service gibt es nicht. Setup-Voraussetzungen: Ruby 3.x, Rails 7.x, MySQL oder Postgres als Datenbank, optionales Redis für Background-Jobs. Stand Mai 2026 ist Huginn unter aktiver Wartung (regelmässige Security-Updates, weniger Feature-Releases), die Codebase älter als die jüngeren Konkurrenten, aber stabil.

Huginn organisiert Workflows als „Agents" und „Scenarios". Ein Agent ist ein wiederverwendbarer Baustein mit einem klar definierten Zweck: Website-Scraper, RSS-Reader, E-Mail-Sender, Twitter-Watcher, Webhook-Receiver, Zeitplaner. Agents kommunizieren via Events – ein Agent gibt ein Event aus, andere Agents reagieren darauf. Ein Scenario fasst mehrere Agents zu einer thematischen Einheit zusammen (z.B. „Job-Listings überwachen": ein Scraper-Agent zieht Daten von Job-Boards, ein Filter-Agent filtert relevante, ein Mailer-Agent sendet Notifications).

Kommerziell ist Huginn MIT-lizenziert – vollständig kostenlos, ohne Embedded-Restriktionen. Es gibt keinen Cloud-Anbieter, kein Marketing-Team, kein VC-Funding. Die Community ist klein aber aktiv (GitHub-Repo mit 40.000+ Sternen). Updates kommen sporadisch, Security-Fixes regelmässig.

Für eine CH-Treuhand ist Huginn realistisch eher ein Werkzeug für Power-User in IT-Funktion: Web-Scraping für Konkurrenz-Beobachtung, RSS-Aggregation für Branchen-News, Notification-Loops für interne Alerts. Als Haupt-Workflow-Plattform für Mandanten-Operationen ist Huginn untermotorisiert; die Konnektoren-Auswahl ist klein, die UI altmodisch, die Multi-User-Funktionalität rudimentär.

Warum es wichtig ist

Huginn ist die längste produktive Self-Host-Workflow-Plattform am Markt – gestartet 2013, also vor n8n, Activepieces, Windmill, Pipedream und Temporal. Wer eine bewährte, ressourcen-arme Lösung für kleine Web-Monitoring-Setups braucht, findet in Huginn eine zuverlässige Option. Die Plattform läuft seit Jahren stabil, der Code ist gut dokumentiert, die Community kennt die Fälle.

Für kleine Setups sind drei realistische Hebel zu sehen. Erstens – Konkurrenz-Beobachtung. Ein Treuhand-Büro will wissen, wann Konkurrenten neue Service-Pakete veröffentlichen oder ihre Preise ändern. Mit Huginn lassen sich 10-20 Konkurrent-Websites täglich gescrapt, geänderte Inhalte werden über den „Change Detector Agent" identifiziert und per Mail oder Slack gemeldet. Das gleiche könnte man in n8n bauen, aber Huginns Scraper-Agents sind explizit für diesen Use-Case optimiert.

Zweitens – RSS- und News-Aggregation. Ein Treuhand-Büro abonniert 50-100 RSS-Feeds (BFE, BAG, EFD, SECO, Fachverbände). Mit Huginn werden die Feeds gepollt, gefiltert nach Schlagworten (MWST, GwG, BVG, Lohnänderungen), und Treffer landen in einer internen Mail oder einem Notion-Workspace. Funktional ähnlich wie ein Feedly-Setup, aber selbst gehostet und mit Filter-Logik.

Drittens – Personal-Automation für einzelne Mitarbeitende. „Wenn die Wettervorhersage Regen meldet, sende mir um 8:00 eine Mail." „Wenn auf hetzner.cloud ein neuer Server-Typ verfügbar wird, melde mir das." „Wenn der Bitcoin-Kurs unter X fällt, sende Telegram-Nachricht." Diese kleinen, persönlichen Automatisierungen sind in Huginn idiomatisch.

Die Kehrseite ist klar: Huginn ist kein Tool für den Treuhand-Mainstream. Multi-User-Berechtigungen sind rudimentär, die UI sieht aus wie 2014, die Konnektor-Auswahl ist klein (50-100 Agent-Typen vs. 600+ Nodes bei n8n), die Lernkurve ist eigenwillig (Agent-und-Event-Modell ist anders als bei den anderen Tools). Wer „den modernen IFTTT-Ersatz" sucht, geht zu n8n oder Activepieces; wer einen schlanken, jahrelang bewährten Web-Monitor will, hat in Huginn die richtige Wahl.

Wie es funktioniert

Ein Huginn-System organisiert Workflows um zwei Konzepte: Agents und Events. Ein Agent ist eine Konfiguration eines Agent-Typs (z.B. „Website Agent", „Weather Agent", „Email Agent") mit spezifischen Optionen (URL, Schedule, Filter-Patterns, Templates). Ein Agent kann periodisch laufen (z.B. alle 30 Minuten) oder durch ein Event eines anderen Agents getriggert werden.

Events sind JSON-Objekte, die zwischen Agents fliessen. Wenn ein Website Agent eine geänderte Seite findet, erzeugt er ein Event mit Inhalten. Andere Agents (Filter Agent, Email Agent) sind als „Receiver" dieser Events konfiguriert und reagieren darauf. Das Event-Modell ist klassisches Pub-Sub: ein Agent kann von beliebig vielen anderen empfangen.

Die wichtigsten Agent-Typen: Website Agent (HTML scrapen mit CSS-Selektoren oder XPath), RSS Agent (RSS/Atom-Feeds pollen), Twitter Agent (Tweets überwachen – historisch wichtig, mit X/Twitter-API-Änderungen 2023 limitiert), Email Agent (Mails senden), Webhook Agent (HTTP-Triggers), Trigger Agent (Filter mit regulären Ausdrücken), Liquid Templating Agent (Output-Transformation), Schedule Agent (zeitgesteuerte Trigger), DataOutputAgent (RSS-Feed aus Agent-Outputs erzeugen – nützlich für Re-Publishing).

Ein typisches Scenario „Konkurrenz-Beobachtung": (1) Schedule Agent triggert täglich um 06:00. (2) Website Agent 1-5 ziehen je eine Konkurrenten-Website. (3) Trigger Agent filtert geänderte Inhalte (Diff gegen letzte Version). (4) Liquid Templating Agent formatiert die Treffer als Mail-Body. (5) Email Agent sendet die Zusammenfassung an die Geschäftsleitung. Im Background läuft das auf einem 1-vCPU-Server mit minimalem Ressourcen-Verbrauch.

Die Architektur ist Ruby-on-Rails mit DelayedJob für Background-Verarbeitung. Datenbank: MySQL oder Postgres. Optional: Redis für Sidekiq als Job-Queue (statt DelayedJob). Ein Single-Server-Setup deckt typisch Hunderte Agents ab; die Skalierung erfolgt vertikal (mehr CPU/RAM) oder horizontal (mehrere Worker-Prozesse).

Die UI ist HTML+jQuery-basiert, ohne moderne SPA-Architektur. Agents werden in einer Tabelle aufgelistet, Konfiguration via Web-Form, Events in einer Liste mit Suchfunktion. Multi-User-Berechtigungen sind grob: Admin sieht alles, normale User nur ihre eigenen Agents. Keine granularen Berechtigungen wie bei n8n Enterprise.

Für Code-Erweiterungen gibt es das „Custom Event Agent" (Ruby-Code im Agent) und das „JavaScript Agent" (mini-JS-Sandbox). Beide sind machbar, aber nicht so komfortabel wie Code-Nodes in n8n oder Code-Pieces in Activepieces.

Huginn Self-Hosted in 5 Schritten

1. 01Ruby 3.x und Rails 7.x auf Server installieren (typisch über rbenv/rvm), Postgres oder MySQL als DB, Redis für Sidekiq als Job-Queue.
2. 02Huginn-Repo von GitHub klonen, bundle install für Dependencies, rails db:setup für Schema-Setup, Admin-User via Rake-Task anlegen.
3. 03Reverse-Proxy konfigurieren: Nginx oder Caddy mit TLS vor Huginn, HTTP-Auth über Rails-Devise oder OAuth-Bridge für Mehr-User-Setup.
4. 04Erstes Scenario bauen: Schedule Agent als Trigger, Website Agent für Scraping, Trigger Agent für Filter, Email Agent für Notification.
5. 05Monitoring einrichten: Sidekiq-Web-UI für Job-Queue-Health, Rails-Logs in Loki, Slack-Alert bei Sidekiq-Failure-Rate > 5% via Custom-Webhook-Agent.

Wann Huginn einsetzen

Huginn ist die richtige Wahl, wenn (a) der Hauptzweck Web-Monitoring, RSS-Aggregation oder Personal-Notifications ist, (b) das Team Ruby-Erfahrung hat (für Setup und Troubleshooting), (c) Self-Hosting unter MIT-Lizenz wichtig ist und (d) der Komfort einer modernen UI nicht oberste Priorität hat.

Konkrete Fälle: tägliche Konkurrenz-Website-Beobachtung mit Change-Detection, RSS-Aggregation aus 50+ Quellen mit Keyword-Filter, Wetter-, Krypto- oder Boersen-Trigger für persönliche Benachrichtigungen, Job-Listing-Monitoring (Indeed, LinkedIn, Branchen-Boards), interne Notification-Loops für Operations-Teams (z.B. „melde mir, wenn ein Mandant 90 Tage überfällig ist").

Für Einzelpersonen oder kleine Teams (1-5 Mitarbeiter) mit Ruby-Erfahrung ist Huginn eine sehr ressourcen-arme Wahl. Ein 1-vCPU-Server reicht für Hunderte Agents, der jährliche Server-Cost liegt bei CHF 50-100. Die Plattform läuft seit Jahren stabil ohne Wartung, Security-Updates kommen regelmässig vom GitHub-Maintainer-Team.

Für historische Power-User-Setups, die seit 2014-2016 in Huginn investiert haben, ist ein Wechsel zu n8n selten lohnend – die Migration der Agents wäre aufwändig, der Funktions-Gewinn marginal. Wer bereits Huginn produktiv betreibt, kann es weiter nutzen.

Für Treuhand-Mandate ohne Web-Monitoring-Bedarf ist Huginn falsch. Mandanten-Triage, Rechnungs-Sortierung, MWST-Sammeln sind keine Huginn-Use-Cases.

Wann NICHT

Huginn ist die falsche Wahl für Treuhand- oder KMU-Operations-Workflows. Keine fertigen Konnektoren für Bexio, HubSpot, Slack, Stripe oder Microsoft 365. Wer Mandanten-Operations automatisieren will, ist mit n8n, Activepieces oder Make produktiver – Huginns Agent-Modell ist nicht auf SaaS-App-Integration optimiert.

Ungeeignet ist Huginn für Teams ohne Ruby-Erfahrung. Setup, Updates, Performance-Troubleshooting verlangen Rails-Knowhow. Wer kein DevOps-Team mit Ruby-Hintergrund hat, kommt mit Docker-Compose von n8n oder Activepieces schneller voran.

Nicht passend ist Huginn für Multi-User-Setups mit granularen Berechtigungen. Die Permissions sind grob (Admin vs. normaler User), Audit-Logs sind rudimentär, SSO ist nicht eingebaut. Für Treuhand-Setups mit Compliance-Anforderungen ist Huginn unteritbordert.

Für komplexe AI-Workflows mit LLM-Calls, Embeddings und Vector-Stores ist Huginn ungeeignet. Es gibt zwar ein „WebRequestAgent" für beliebige HTTP-Calls (also auch OpenAI- oder Anthropic-APIs), aber die Komfort-Schicht fehlt. n8n, Activepieces oder Windmill sind dort produktiver.

Für hohes Workflow-Volumen (Tausende Events/Stunde) ist Huginn nicht optimiert. Die Single-Rails-Process-Architektur mit DelayedJob skaliert in den Bereich Hunderte Events/Minute; für mehr wird es mühsam, mehrere Worker-Prozesse zu koordinieren.

Für Workflow-Versionierung mit Git ist Huginn nicht ausgelegt. Agents werden in der Datenbank gespeichert, Export/Import als JSON ist möglich, aber kein nativer Git-Sync. Wer Workflows als Code mit CI/CD halten will, ist mit Windmill, Temporal oder modernen n8n-Workflow-Exports besser bedient.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Huginn on GitHub – MIT source and documentation · 2026-05
2. Huginn wiki – agents and scenarios · 2026-05
3. Huginn installation guide · 2026-04
4. Huginn agent reference · 2026-04