Willkommen zu allesnurgecloud.com – Ausgabe #242
Nagelsmann weg, Fable 5 wieder da. Allerdings lassen sich die Sicherheitsmechanismen des Modells noch immer umgehen. In einem Blogartikel zeigt Alex Armbruster, wie einfach das geht. Schon probiert? Ansonsten soll GLM-5.2 zumindest das Niveau von Opus 4.8 bei der Schwachstellensuche erreichen, und spätestens ab dann muss man sich damit beschäftigen.
Versteckt in einem unscheinbaren Absatz ihres Reformpakets will die Bundesregierung laut einem ZEIT-Kommentar das Informationsfreiheitsgesetz aushöhlen — künftig nur noch für natürliche Personen mit vagem „berechtigtem Interesse“, mit Schwärzungen bis in die Führungsebene und Gebühren jenseits des 500-Euro-Deckels; der DJV nennt es schlicht die „Abschaffung der Informationsfreiheit“.
Der Layofftranslator übersetzt CEO-Layoff-Statements in die Realität – hier am Beispiel den Elastic Entlassungen aus der letzten Woche (gibt es auch zu Cloudflare oder auch für Amazon) – kannte ich bisher nicht, danke für die Einsendung!
Und wie du schon weißt, baue ich aktuell mit Statuswerk eine komplett in Deutschland betriebene Statuspage – alle Daten, E-Mail und SMS bleiben hierzulande. Fokus nur darauf, dafür richtig und fair bepreist. Auf die Warteliste eintragen – Launch Ende Juni mit Early-Bird.
So, und nun viel Spaß mit der neuen Ausgabe
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 179 habe ich mit Alex Pohl gesprochen – hauptberuflicher Schriftsteller, der unter Pseudonymen wie Oliver Moros, L.C. Frey und Rita Hansen über drei Millionen Bücher verkauft hat. Seine Thriller-Reihe „Edel und Stein“ bringt er komplett im Self-Publishing heraus, und wir reden über sein Geschäftsmodell als Ein-Personen-Verlag, Pseudonyme als Risikostreuung und warum er auf maximale Unabhängigkeit statt maximalen Gewinn setzt. Gerne kannst du die Folge auf YouTube schauen oder wie immer bei Spotify, Apple und allen anderen Playern anhören.
Wenn dir die Podcastfolgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).
So, nun endlich die News der Woche in der Übersicht:
- US Supreme Court kippt die Basis für US-Clouds
- Claude Code: Verstecktes Fingerprinting entdeckt
- bunny.net: Gratis-DNS und neuer Security-Report
- x402 für alles: Cloudflares Bezahl-Gateway
- Fintech Engineering Handbook
- 1 Mio. Requests/s: Zalandos Client-Side Loadbalancer
- Cloudflare: Boot-Reihenfolge deklarieren statt raten
- Website im Favicon: 212 Byte HTML
Support the Newsletter
Übrigens kannst Du meine Arbeit nun auf Patreon supporten, mir ein Bier ausgeben oder mal auf meiner Amazon-Wunschliste vorbeischauen – Danke! Falls du Interesse hast, im Newsletter oder Podcast Werbung zu buchen, kannst du das auf passionfroot machen oder mir einfach ne E-Mail als Antwort auf den NL schicken.
Auf allesnurgecloud.com findest Du vorherige Ausgaben und den RSS-Feed.
Vielen Dank für Dein Interesse und wie immer freue ich mich über Feedback und Weiterempfehlungen.
US Supreme Court kippt die Basis für US-Clouds
Seit Jahren warnt Max Schrems, die Rechtsgrundlage für EU-US-Datentransfers sei ein Kartenhaus — jetzt ist es eingestürzt, und ausgerechnet nicht durch den EuGH, sondern durch den US Supreme Court selbst. noyb beschreibt die Folgen, Golem liefert die deutsche Einordnung.
Im Urteil Trump v. Slaughter entschied das Gericht am Montag, die Unabhängigkeit der FTC sei verfassungswidrig — nach der unitary executive theory, wonach der Präsident alle Behörden kontrollieren muss. Dumm nur: Die EU stützt sich in ihrem Angemessenheitsbeschluss zum Data Privacy Framework 259 Mal auf genau diese „unabhängige“ FTC. Damit ist die dritte Neuauflage nach Safe Harbor und Privacy Shield faktisch entkernt. Schrems fordert einen geordneten Ausstieg aus der US-Cloud.
Bevor Panik ausbricht: Sofort ändert sich nichts. Der Beschluss bleibt formal gültig, bis die Kommission ihn zurücknimmt oder der EuGH ihn kippt, und die angekündigte noyb-Klage dürfte 2-3 Jahre dauern. Nicht-personenbezogene Daten fließen weiter, Art. 49 DSGVO deckt notwendige Einzelfälle. Der Haken: Auch wer auf Standardvertragsklauseln setzt, hängt am selben Tropf — die zugehörigen Impact Assessments verweisen ebenfalls auf US-Stellen wie das PCLOB.
Für mich ist das keine Überraschung, sondern die Fortsetzung dessen, was ich hier seit einer Weile begleite. Neu ist nur: Die Unsicherheit ist jetzt dauerhaft. Wer bisher gewartet hat, sollte anfangen, statt auf das nächste Abkommen zu hoffen, das der EuGH ohnehin wieder kassiert:
- DNS, CDN, Zertifikate und Mailversand lassen sich oft ohne großen Aufwand zu EU-Anbietern migrieren
- Nicht integrierte Dienste wie ein S3-Bucket für Bilder oder PDFs separat umziehen
- Sovereign-Cloud-Angebote nüchtern prüfen: technisch beeindruckend, gegen den Cloud Act hilft aber auch EU-Personal nicht
- Vertragslage und DTIAs dokumentieren, bevor die Kommission entscheidet
Hast du die Low-Hanging-Fruits schon migriert, oder wird weiter auf das nächste Abkommen gehofft?
Claude Code: Verstecktes Fingerprinting entdeckt
Die Aufregung war groß: Ein Reddit-Post warf Anthropic vor, „Spyware“ in Claude Code eingebaut zu haben. Der Entwickler thereallo hat die Binary auseinandergenommen — die Sache ist weniger dramatisch, aber trotzdem unschön.
Der Mechanismus greift nur, wenn man eine eigene ANTHROPIC_BASE_URL gesetzt hat, Claude Code also über einen fremden Proxy oder auf ein anderes Modell umbiegt, wie in Ausgabe #233 für Qwen und Kimi beschrieben. Dann prüft der Code die Timezone (Asia/Shanghai, Asia/Urumqi) und den Hostname gegen eine per XOR mit Schlüssel 91 verschleierte Liste — enthalten sind deepseek, zhipu, moonshot, baidu, alibaba und diverse Reseller-Domains. Das Ergebnis landet steganografisch im System-Prompt: mal ein Slash statt Bindestrich im Datum, mal eines von drei optisch identischen Unicode-Apostrophen in „Today’s date is“. Für normale Nutzer über api.anthropic.com passiert nichts.
Kein separater Heim-Funk also, sondern ein unsichtbares Wasserzeichen, das über die normale Anfrage bei Anthropic landet und dort Reseller-Proxys enttarnt — thereallo nennt es „a weird choice for a developer tool that asks for trust“. Genau das ist der wunde Punkt: Ein Tool mit Filesystem- und Shell-Zugriff, das Klassifizierungen heimlich in den Prompt schmuggelt, die Domain-Liste XOR-verschleiert und kein Wort in den Release Notes verliert — das erinnert an den „Undercover Mode“ aus dem Claude-Code-Leak in Ausgabe #230. Die Community war entsprechend gespalten, von „nothingburger“ bis „dystopischste Tech-Firma überhaupt“. Und weil sich der Check per Hostname-Wechsel trivial umgehen lässt, trifft er vor allem legitime Nutzer mit ungewöhnlichem Setup.
Immerhin: Anthropic hat gegenüber The Register reagiert. Claude-Code-Engineer Thariq Shihipar bezeichnet es als März-Experiment gegen Reseller-Missbrauch und Distillation, das man ohnehin habe entfernen wollen — der Code fliegt mit dem Juli-Release raus. Zur Frage, ob das je in den ToS stand, sagte man nichts.
Warum überhaupt der Aufwand? Ein HN-Thread zu Anthropics Vorwurf gegen Alibaba (angeblich rund 25.000 Fake-Accounts und 28,8 Mio. Abfragen) liefert den Kontext: Chinesische „Transfer Stations“ verkaufen Claude-Tokens laut ChinaTalk teils für 5 bis 10% des offiziellen Preises, finanziert über gepoolte Max-Accounts, Payment-Fraud und den Weiterverkauf von Reasoning-Traces als Trainingsdaten. Die Ironie dabei: Faktisch werden US-Tokens in China verramscht, was DeepSeek & Co. erst zu ihren Kampfpreisen zwingt.
Anthropic embedded spyware in Claude Code — and attempted to hide it from you
Anzeige
We Manage & KRUU: Cloud für unter 0,5 % des Umsatzes
Gemeinsam mit unserem Kunden KRUU – dem nach eigenen Angaben weltweit größten mobilen Fotoboxvermieter – haben wir eine ausführliche Case Study veröffentlicht (PDF).
5.000 Fotoboxen in neun EU-Ländern und den USA, bis zu 800 Versendungen pro Tag in der Hochsaison, über 99,99 % Server-Uptime – und das alles bei IT-Kosten von unter 0,5 % des Jahresumsatzes (inkl. We Manage). Statt auf AWS zu setzen, was laut KRUU-Gründer Philipp Schreiber „Faktor 10 bis 20 teurer“ wäre, haben wir eine Multi-Provider-Architektur aus Gridscale, Hetzner und DigitalOcean aufgebaut, die saisonal mitatmet und wirtschaftlich bleibt.
Was mich an der Zusammenarbeit nach 10 Jahren besonders freut: Philipp und ich kennen uns noch aus dem Heilbronner Nachtleben – und die Philosophie hat sich nie geändert. Stabile Technologien. Kein Overengineering. Kein Overprovisioning.
Wenn du auch ein skalierbares Setup ohne Hyperscaler-Preise suchst – oder schlicht ein Backup für dein Ein-Personen-DevOps-Team brauchst, dann lass uns kurz sprechen.
Die vollständige Case Study lesen
bunny.net: Gratis-DNS und neuer Security-Report
Während die halbe Branche Free-Tiers streicht und upmarket zieht, geht bunny.net den umgekehrten Weg: Der slowenische Edge-Anbieter macht Bunny DNS komplett kostenlos — keine Query-Fees, keine Per-Request-Abrechnung, bis zu 500 Domains pro Account, Smart Records und Health Monitoring inklusive.
DNS ist für bunny ohnehin die Routing-Engine hinter dem CDN (300.000 Domains, knapp 200 Milliarden Queries monatlich); der Gratis-Zug ist weniger Großzügigkeit als Strategie — ein Loss-Leader, von dem aus per 1-Click das CDN und Bunny Shield dazukommen. Substanzieller sind die leisen Verbesserungen: IPv6 im Dual-Stack ohne Konfiguration und DNSSEC mit NSEC Black Lies, das Zone-Walking verhindert, also Validierung ohne Offenlegung der Zonenstruktur.
Der Haken steht im Kleingedruckten: Ein Account-Minimum von 1 Dollar/Monat bleibt. Auf LowEndTalk merkte Nutzer emgh trocken an, „free“ heiße hier eben 1 Dollar für 500 Domains, bei Cloudflare koste es null. Geschenkt: Wer bunny schon nutzt, zahlt den Dollar ohnehin.
Parallel dazu erschien bunnys 2026 Edge Security Report — 149 Tage Telemetrie, 42,5 Milliarden Requests, knapp 5 Milliarden davon geblockt. Vier Befunde stechen heraus: Automatisierter Traffic ist zunehmend API-getrieben — curl, requests und der Go-HTTP-Client erzeugen zusammen mehr Volumen als alle deklarierten Bot-Kategorien, womit User-Agent-basierte Erkennung endgültig Makulatur ist. KI-Crawler haben klassische Suchmaschinen-Bots eingeholt, allein ByteDances Bytespider hält 48,1% des KI-Crawler-Traffics — passend zum Cloudflare-Beitrag weiter oben. Injection dominiert weiter die WAF-Blocks (OWASP A03), und Log4Shell feuert vier Jahre nach Disclosure munter weiter. Eine Layer-7-Attacke des Aisuru-Botnets erreichte zudem 16,5 Mio. Requests/s aus 392.000 IPs.
Dass der Report zugleich Werbung für Bunny Shield (Ausgabe #186) ist und der Volltext hinter einem Formular liegt, versteht sich. Die Lektion braucht ihn aber nicht: Wer Log4Shell nach vier Jahren offen hat, hat kein Threat-Intelligence-Problem, sondern ein Patch-Problem.
We’re making Bunny DNS free: because a faster internet won’t build itself
x402 für alles: Cloudflares Bezahl-Gateway
Zum zweiten „Content Independence Day“ zieht Cloudflare Bilanz: Eine Rückschau mit Zahlen zum vor einem Jahr ausgerufenen Crawler-Block (siehe Ausgabe #195) kommt zusammen mit der Ankündigung des Monetization Gateway.
Die Zahlen laut Cloudflare: über 50% des Traffics sind nicht-menschlich, 52% aller Crawler-Requests dienen dem KI-Training, gegenüber 22% im Frühjahr 2025. Einzelne Content-Kategorien hätten binnen eines Jahres bis zu 40% menschlichen Traffic verloren. Hauptkritikpunkt bleibt Google: Mit rund 88% des Referral-Traffics und einem Mixed-Use-Crawler, der Suche und KI-Zugriff vermischt, lasse sich das Such-Ökosystem kaum nutzen, ohne auch das Training zu füttern.
Das Monetization Gateway führt Pay-per-Crawl konsequent weiter: Statt nur Crawler abzukassieren, sollen Kunden jede Ressource hinter Cloudflare bepreisen können, von Webseiten über Datasets bis zu APIs und MCP-Tool-Calls. Abgewickelt wird über x402, das den lange vergessenen HTTP-Status 402 endlich nutzt, mit Settlement in Stablecoins (USDC, Open USD) in unter einer Sekunde. Der Käufer braucht keinen Account, die Zahlung selbst ist das Credential.
Die Erzählung ist verdächtig rund. Cloudflare beschreibt einen Markt, den es selbst gebaut hat, mit Daten aus dem eigenen Investor Day. Wer 20% des Webs kontrolliert, verdient an allen Seiten: erst der Schutz vor Crawlern, dann das Crawling-Tool selbst (Ausgabe #227), jetzt die Kasse dazwischen. Dass Lizenzeinnahmen die verlorenen Referral-Umsätze wohl nicht ersetzen, räumt Cloudflare selbst ein. Und ob Publisher tatsächlich in Stablecoins abgerechnet werden wollen, steht auf einem anderen Blatt.
Announcing the Monetization Gateway: charge for any resource behind Cloudflare via x402
Fintech Engineering Handbook
Geld-Software verzeiht nichts: ein Rundungsfehler, eine doppelt gebuchte Zahlung, ein verlorenes Event, und jemandem fehlt echtes Geld. Genau dagegen sammelt Voytek Pituła, Staff Engineer bei SwissBorg, in seinem frei verfügbaren Fintech Engineering Handbook die wichtigsten Muster – gebaut auf drei Prinzipien: kein erfundenes Geld, keine verlorenen Daten, kein Vertrauen.
Ein paar Nuggets, die auch abseits von Payments hängen bleiben:
- Nie Float für Geld. Beträge als Integer in der kleinsten Einheit speichern (ISO 4217 – nicht immer zwei Nachkommastellen!) und als String oder Integer serialisieren, nie als nackte JSON-Zahl, sonst holt einen die IEEE-754-Falle am Rand wieder ein.
- Balance wird nie gespeichert, sondern per Double-Entry aus unveränderlichen Bewegungen abgeleitet; Korrekturen laufen ausschließlich über Gegenbuchungen. Für den GDPR-Konflikt mit dem unveränderlichen Ledger: Crypto-Shredding, also PII pro Nutzer verschlüsseln und den Key löschen statt die Historie umzuschreiben.
- Webhooks sind nur ein Trigger, keine Wahrheit – den echten Zustand per API nachfragen, und für zuverlässige At-least-once-Zustellung Outbox oder CDC nutzen.
Vieles davon ist ehrlicherweise „nur“ solide Distributed-Systems-Hygiene: Idempotenz, Resumability („assume failure every two steps“), Reconciliation. Der Unterschied ist, dass hier jeder Cent zählt und die Disziplin erzwungen wird, die man sich anderswo gerne spart. Für die reine Ledger-Seite bleibt TigerBeetle (Ausgabe #168) die spezialisierte Antwort; das Handbook liefert das Drumherum. Sympathisch: Der Autor sagt selbst, fast alles beginne mit „it depends“, und nutzt KI nur zum Polieren.
1 Mio. Requests/s: Zalandos Client-Side Loadbalancer
Diese Geschichte kenne ich aus eigener Erfahrung, nur ein paar Nummern kleiner: ein geteilter Load Balancer im Hot Path, und bei jedem Latenz-Spike die Frage, ob’s am eigenen Code liegt oder an der Infrastruktur darunter. Zalando beschreibt das Ganze in einem lesenswerten Engineering-Post in einer ganz anderen Größenordnung.
Die Product Read API (PRAPI) liefert Millionen Requests pro Sekunde mit einstelliger Millisekunden-Latenz über 25 Märkte. Der Batch-Endpoint zerlegt eine Anfrage in bis zu 100 parallele Calls, jeder über Skipper, den geteilten Ingress-Router. Bei dieser 100-fachen Abhängigkeit gilt: „When Skipper sneezed, PRAPI got the flu.“ Trifft’s ganz gut.
Die Lösung ist ein prozessinterner Client-Side Load Balancer nur für den internen Fan-Out. Skipper bleibt am Edge, wo er stark ist. Wichtig war die Hash-Parität, also exakt derselbe Ring (xxHash64, 100 virtuelle Nodes), damit die Migration keine Caches spaltet.
Am meisten abgeholt hat mich der Teil zum Last-Signal: In-flight-Requests und Durchsatz taugen bei Cache-lastigem Traffic nichts. Erst occupancy, Arbeitssekunden pro Sekunde nach Little’s Law, zeigt die echte Auslastung, latenzgewichtet wie beim PEWMA-Verfahren aus Ausgabe #100.
Was am Ende dabei rauskam:
- über 1 Mio. Requests/s von Skipper genommen
- Skipper-Flotte von 50 auf 8 Pods, 450 auf 110 Dollar/Tag
- eigenes Cluster nochmal 25% kleiner, über 1.000 Dollar täglich gespart
- AZ-aware Routing nach explodierenden DynamoDB-Reads vorerst pausiert
Was ich am Post richtig gut finde, ist die Ehrlichkeit: Für die meisten lohnt sich das nicht, ein reifer Proxy wie Envoy oder Skipper liefert das fertig. Genau meine Haltung. Und die wertvollste Änderung war kein Algorithmus, sondern eine Log-Zeile mit Node-IP, die jahrelang versteckte Node-Freezes sichtbar machte. Wer die Routing-Entscheidung besitzt, besitzt auch den Pager. Baust du sowas selbst, oder bleibt’s beim fertigen Proxy?
Client-Side Load Balancing at a Million Requests Per Second
Cloudflare: Boot-Reihenfolge deklarieren statt raten
Ein simples Firmware-Update, und plötzlich brauchten einige Core-Server von Cloudflare vier Stunden zum Booten statt weniger Minuten. Giovanni Pereira Zantedeschi und Kollegen schildern im Cloudflare-Blog, wie aus einem geplanten Eintages-Rollout ein mehrtägiger Krampf wurde, und woran es lag.
Die Ursache ist fast schon komisch banal. Die betroffenen Bare-Metal-Server suchten beim Netzwerk-Boot stur jede verfügbare Schnittstelle nacheinander ab: erst IPv4-HTTPS, Timeout nach fünf Minuten, dann IPv4-iPXE, wieder Timeout, und so weiter, bis das funktionierende IPv6-HTTPS dran war. Macht rund 20 Minuten Wartezeit pro Boot. Da jedes Firmware-Update einen Reboot braucht und mehrere nacheinander liefen, summierte sich das auf knapp vier Stunden pro Server.
Die Lösung klingt trivial: die richtige Boot-Reihenfolge vorab deklarieren, statt das System raten zu lassen. In der Praxis stand dem einiges im Weg:
- Ein vom Hersteller fest verdrahtetes
Force Priority-Setting ließ sich erst mit einer neuen BIOS-Version überhaupt ändern. - Die relevante Datenstruktur wurde lazy geladen und war für die Scans unsichtbar, bis Vendor-Tokens sie hervorholten.
- Je nach NIC-Hersteller unterschieden sich die Interface-Strings, was nur über Wildcard-Matching zu bändigen war.
Dazu kam ein Validierungsschritt, der die Konfiguration nach jedem Firmware-Upgrade prüft und bei Bedarf neu setzt, denn UEFI-Updates werfen solche Einstellungen gerne wieder über Bord. Am Ende stehen drei Minuten statt vier Stunden, jeder Folge-Boot unter einer Minute statt zwanzig.
Wie tief man für solche Optimierungen in UEFI-Interna und Vendor-Eigenheiten graben muss, passt zu Ausgabe 206, in der Meltcloud zeigte, wie sich Bare-Metal-Boot cloud-nativ zähmen lässt. Cloudflare löst nur eine Scheibe davon — aber eine, die jeder kennt, der Hardware-Flotten selbst bootet.
How we reduced core unit boot time from hours to minutes
Website im Favicon: 212 Byte HTML
Ein Favicon ist eigentlich nur dieses kleine Icon im Browser-Tab, das man einmal hochlädt und dann vergisst. Tim Wehrle hat sich gefragt, ob darin auch eine ganze Website Platz hat, und das Experiment kurzerhand umgesetzt. Die Logik dahinter ist bestechend simpel: ein Favicon ist ein Bild, ein Bild sind Pixel, und Pixel sind Bytes.
Wehrle nimmt also das HTML seiner Mini-Seite, kodiert es als UTF-8 und schreibt die Bytes direkt in die RGB-Kanäle der Pixel: erstes Byte ins Rot des ersten Pixels, zweites ins Grün, drittes ins Blau, und so weiter. Vier vorangestellte Bytes speichern die Länge der Nutzlast, damit beim Auslesen klar ist, wo der echte Inhalt endet. Das Ergebnis sieht aus wie Bildrauschen, ist aber eine vollständige, sogar gestylte HTML-Seite, untergebracht in einem 9×9 Pixel großen Bild von 212 Byte. Kleiner als ein normales Favicon.
Zurücklesen übernimmt der Browser fast von selbst, indem er das Favicon lädt, auf ein Canvas zeichnet und die Pixel per JavaScript ausliest, rekonstruiert und dekodiert. Der Haken, den Wehrle selbst benennt — das Favicon enthält nur den Inhalt der Seite, nicht die Seite selbst. Ein kleiner Bootstrap-Loader bleibt also nötig.
Nützlich ist das natürlich nicht, schreibt Wehrle gleich dazu. Aber wer in Ausgabe 75 den 1-kB-Club und meine auf 968 Byte geschrumpfte CV-Seite mochte, wird auch hier seine Freude haben.
I Stored a Website in a Favicon
„Die Kochen auch nur mit Wasser“
Bei Supabase klemmt’s seit dem 30. Juni: In gleich 16 Regionen scheiterten Projekt-Erstellung, Restarts, Resizes und Branch-Provisioning an Kapazitätsengpässen — vier Tage später kämpft man laut Statuspage immer noch mit knappen Medium-Instanzen. Zwar heißt es durchgehend, laufende Projekte seien nicht betroffen, doch der Haken steht im Kleingedruckten: Sobald eine Instanz neu startet, restored oder ein DB-Upgrade fährt, ist auch bestehende Workload dran — und wer auf Postgres älter als 17.6.1.121 läuft, muss erst upgraden, um überhaupt wieder an passende Maschinentypen zu kommen.
Schmunzelecke
Bei scottymuirhead gibt es auf Instagram echt lustigen Remote Worker-Content – kann man sich mal reinziehen, hehe ( hier und da zum Beispiel)
Bin aus Versehen auf guthib.com gelandet – da könnte man sicher auch mehr draus machen.
💡 Link Tipps aus der Open Source Welt
nano – Leichtgewichtiges Open-Core SIEM in Rust
nano ist ein opinionated SIEM für Security Analysten, das Search, Detection und Triage in einem schlanken Stack vereint – ClickHouse für Events, PostgreSQL für State, eine eigene Pipe-Query-Sprache (nPL) und ein UI, das die Dichte eines Terminals hat.
Key Features:
- nPL Query Language: Piped Query-Syntax à la Splunk (
error | stats count by src_ip | where count > 10) – schneller als SQL, portabler als proprietäre Query-Sprachen - UDM oder OCSF: Wahlweise 75+ explizite Spalten im eigenen Unified Data Model oder im offenen OCSF-Schema – einmal bei Install wählen
- Detection Lifecycle: Rules durchlaufen Staging → Live → Alerting mit Match Counts, MITRE ATT&CK Tagging, Baseline Impact und Version History
- Ingestion: Vector-basiert mit VRL-Parsern – HTTP Push, Syslog, S3 Pull. Parser-Content separat unter Apache-2.0
- Marketplace: Out-of-the-box Enrichment Provider (Threat Intel, Identity, Asset Inventory, Geolocation) mit Coverage-Indikator über UDM-Felder
- Alerts: Lifecycle (new → triaged → resolved), Grouping, Dedup, Prevalence-basierte Noise Reduction
Stack: ClickHouse (Events, Daily Partitions, 90-Tage TTL), PostgreSQL (Metadata), Vector (Collection), React SPA. Minimum 2 vCPU, 4 GB RAM für ~10 GB/Tag Ingest. Install per One-Liner: curl -fsSL https://get.nano.rs | bash.
Open-Core Modell: Engine komplett AGPL-3.0. Cases, Incidents, AI Assistant (pivt), Risk Scoring und Auto-Tuning nur in der gehosteten Version.
Noch sehr früh (2 Monate alt, kein Release), aber konzeptionell durchdacht. Der Ansatz „Splunk-artige Analysten-UX in einem leichtgewichtigen, selbst hostbaren Stack“ trifft einen Nerv – nano fokussiert sich explizit auf Security Operations mit Detection Lifecycle und Enrichment Marketplace. Wer ein SIEM sucht, das nicht Elastic/Splunk-Kosten verursacht und trotzdem Analysten-tauglich ist, sollte nano im Auge behalten.
https://github.com/nano-rs/nano
TREK – Self-Hosted Reise-Planer mit Echtzeit-Kollaboration
TREK ist ein self-hosted Trip Planner mit interaktiven Karten, Budgets, Packlisten, Reisejournal und AI – alles in Echtzeit kollaborativ, als PWA installierbar, in 30 Sekunden deployed.
Key Features:
- Trip Planner: Tagesplanung mit Routen, POIs via Overpass/Mapbox GL, 3D-Karten mit Leaflet
- Echtzeit-Kollaboration: WebSocket-basierter Live-Sync – mehrere Nutzer planen gleichzeitig am selben Trip
- Kosten & Expense Splitting: Budget-Tracking mit Aufteilung zwischen Reisenden
- Atlas: Besuchte Länder und Regionen auf einer Weltkarte visualisieren (geoBoundaries-Daten)
- Journal: Reisetagebuch direkt in der App
- Packlisten, Vacay Planner, Wetter (Open-Meteo, kein API Key nötig)
- Auth: JWT, OAuth 2.1, OIDC, Passkeys (WebAuthn), TOTP MFA
- Admin Panel: Backups, Auto-Backup Schedule, User Management
- PWA: Installierbar auf iOS/Android als Fullscreen-App ohne App Store
Tech Stack: NestJS 11 Backend, React + Vite + Zustand Frontend, SQLite, TypeScript, Tailwind. Deployment via Docker, Docker Compose oder Helm Chart.
Eine durchdachte Alternative zu TripIt oder Wanderlog – komplett unter eigener Kontrolle. Die Echtzeit-Kollaboration und das Expense Splitting machen es besonders für Gruppenreisen praktisch. Mit 78 Releases und aktivem Development bereits sehr ausgereift für ein Self-Hosted-Projekt.
https://github.com/mauriceboe/TREK
❓ Feedback & Newsletter Abo
Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.
Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: