Willkommen zu allesnurgecloud.com – Ausgabe #216
Bisher sind Google, AWS, Azure und Cloudflare online – und ich hoffe das bleibt auch so. In den React Server Components gibt es nämliche neue DoS und Source Code Exposure Lücken und ich hoffe, ihr. habt euren Code eh schon gepatched (CVE-2025-55184, CVE-2025-67779 & CVE-2025-55183). Diesmal ist es aber keine 10,0 sondern zweimal CVSS 7.5 und einmal 5.3.
Im Engineering Kiosk Podcast Adventskalender gibt es aktuell kurze Episoden, jeden Tag bis zum 24.12. In Folge #233 durfte ich 10 Minuten zum Thema „Trust Battery“ beisteuern – hör doch gerne mal rein und schick mir Feedback zur Folge.
Ach und dann hat mir ein Leser eine smarte Steckdose von meinem Amazon Wunschzettel geschickt – leider war keine Notiz dabei. Vielen, vielen Dank erst mal, und meld dich doch gerne mal per Mail, damit ich weiß, wem ich das zu verdanken hab 🙂
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 151 spreche ich mit Konstantin Singer, der Vollzeit beim Daimler arbeitet und nebenher das Digital Detoxing Device „Zenbox“ entwickelt hat. Die Zenbox hilft beim Einhalten der Bildschirmzeit durch einen weiteren Layer – man muss zur Box laufen um Änderungen zu machen. Super interessant – dank KI stand ein erster Prototyp schon nach 3 Stunden. Überrraschend für mich war, dass er schon einen größeren B2B Kunden für das Device hat. Am Ende der Folge gibt’s einen Gutschein Code, falls du dir oder der Familiy für Weihnachten wa gutes tun willst – hör gerne mal rein in Folge 150 (Spotify / Apple).
Wenn dir die Podcast Folgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).
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.
allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:
BMI-Gutachten: US-Behörden haben Zugriff auf EU Cloud-Daten
Ein bislang unveröffentlichtes Gutachten der Uni Köln, das im Auftrag des Bundesinnenministeriums erstellt wurde, ist nun via IFG-Anfrage öffentlich geworden – und bestätigt, was viele bereits vermuteten. Wie heise online berichtet, haben US-Behörden weitreichenden Zugriff auf Daten in europäischen Rechenzentren.
Die rechtliche Grundlage: Der Stored Communications Act (erweitert durch den Cloud Act) sowie FISA Section 702 ermöglichen US-Behörden, Cloud-Anbieter zur Datenherausgabe zu verpflichten. Der entscheidende Punkt: Nicht der physische Speicherort zählt, sondern wer die Kontrolle über die Daten hat. Selbst Daten in deutschen Rechenzentren, die über deutsche Tochtergesellschaften verwaltet werden, unterliegen dem Zugriff – sofern eine US-Muttergesellschaft dahintersteht.
Die US-Jurisdiktion kann auch rein europäische Unternehmen treffen, wenn diese relevante Geschäftsverbindungen in die USA unterhalten. Selbst Verschlüsselung schützt nicht zwingend – das US-Prozessrecht kann Anbieter zur Datenaufbewahrung verpflichten, technische Zugangssperren riskieren erhebliche Bußgelder.
Dennoch argumentieren einige Rechtsanwälte, dass ein DSGVO-konformer Einsatz, beispielsweise von Microsoft 365, weiterhin möglich sei – das „abstrakte Risiko“ begründe keine automatische Unzuverlässigkeit. Andere Experten sehen das anders.
Wird jetzt in Summe nichts überraschendes sein, für diejenigen, die das Thema schon länger verfolgen. Witzig ist ja auch, dass jeder Landes-Datenschützer das alles wieder anders sehen kann.
Gutachten: US-Behörden haben weitreichenden Zugriff auf europäische Cloud-Daten
10 Jahre Let’s Encrypt: 10 Mio Zertifikate am Tag
Am 14. September 2015 stellte Let’s Encrypt sein erstes öffentlich vertrauenswürdiges Zertifikat aus. Zehn Jahre später ist die gemeinnützige CA die größte der Welt – und Josh Aas blickt im Jubiläumsartikel auf beeindruckende Zahlen zurück.
Bereits im März 2016 wurde das millionste Zertifikat ausgestellt, im September 2018 erreichte man erstmals eine Million Zertifikate pro Tag. 2020 knackte Let’s Encrypt die Milliarden-Marke, und Ende September 2025 wurden erstmals über 10 Millionen Zertifikate an einem einzigen Tag ausgestellt. Die Marke von einer Milliarde aktiver Websites soll bald erreicht werden.
Der eigentliche Erfolg zeigt sich aber nicht in Zertifikatszahlen, sondern in der HTTPS-Verbreitung: Von unter 30% auf rund 80% global, in den USA sogar 95%. Das dauerte etwa fünf Jahre – ein messbarer Security-Impact.
Technische Wachstumsschmerzen gab es reichlich: 2021 mussten die Datenbank-Server massiv aufgerüstet werden. Das interne Netzwerk wurde von Gigabit auf 25-Gig Ethernet umgestellt, weil die Synchronisation der Datenbank-Instanzen sonst nicht mehr hinterherkam.
Besonders gewürdigt werden die fünf initialen Sponsoren – Mozilla, EFF, Cisco, Akamai und IdenTrust. Letztere ermöglichten den Start durch ihre Cross-Signatur, ohne die Let’s Encrypt nicht hätte launchen können.
10 Years of Let’s Encrypt Certificates
Anzeige
Cloud Exit mit „We Manage“ – 80 % Kosten gespart bei Everysize.com
Als everysize mit seiner Cloud-Infrastruktur an Grenzen stieß, fand das Unternehmen in We Manage den idealen Partner.
Das Ergebnis: 80% Kostenreduktion bei gleichzeitiger Leistungssteigerung.
„Der Profi-Sysadmin, den ich inhouse bräuchte, der aber bei mir zu wenig zu tun hätte,“ beschreibt Mitgründer Eugen Falkenstein treffend die Rolle von We Manage für sein Unternehmen.
Durch maßgeschneiderte IT-Operations, 24/7-Monitoring und Cloud-Migration befreite sich everysize vom teuren AWS-Vendor-Lock-in. Die Serverkosten sanken von 50.000 auf nur 10.000 Euro jährlich – bei höherer Zuverlässigkeit und Agilität.
Brauchst du Hilfe bei Cloud-Optimierung oder IT-Operations?
Lies die vollständige Case Study und erfahre, wie auch dein Unternehmen von We Manage profitieren kann – buch dir jetzt einen Termin zum Kennenlernen.
zur Case Study: Warum everysize die AWS Public Cloud hinter sich lässt
Datenbank-Migrationen: Index-Änderung killt Produktion
Der verlinkte Incident Report von Railway zeigt ein klassisches Problem: Eine Index-Erstellung auf einer Tabelle mit 1 Milliarde Datensätzen ohne CONCURRENTLY-Option führte zu einem 30-minütigen Totalausfall. Der exklusive Table-Lock blockierte alle Queries, PgBouncer überlastete die Connection-Limits, und selbst Admin-Zugriff war nicht mehr möglich.
Honeycomb hatte im Juni 2024 ein identisches Problem – dort war es eine ENUM-Änderung in MySQL, die unerwartet einen Full Table Rewrite auslöste. Ihre Analyse ist besonders lesenswert: Statt Schuldzuweisungen führten sie einen Migration-Linter ein, der riskante Patterns wie ALGORITHM=COPY automatisch erkennt. Jede Migration muss nun explizit den Algorithmus-Typ angeben – INSTANT oder INPLACE sind erlaubt, COPY erfordert eine dokumentierte Ausnahme.
Für MySQL existieren bewährte Alternativen: GitHubs gh-ost und Perconas pt-online-schema-change ermöglichen Schema-Änderungen ohne Locks. Beide Tools erstellen eine Shadow-Table, kopieren Daten inkrementell und führen am Ende einen atomaren Swap durch. GitHub betreibt damit 300TB MySQL-Daten produktiv, wie ich in Ausgabe 131 beschrieben hatte.
Was kann man bei PostgreSQL machen?
- CREATE INDEX CONCURRENTLY: Baut den Index in mehreren Phasen im Hintergrund auf – dauert länger, blockiert aber keine laufenden Lese- oder Schreiboperationen auf der Tabelle.
- ALTER TABLE … ADD COLUMN: Neue Spalten werden nur im System-Katalog registriert, ohne bestehende Zeilen anzufassen – nahezu instantan, auch bei sehr großen Tabellen.
- pg_repack: Externes Tool, das Tabellen und Indizes online reorganisiert, indem es eine Schattenkopie erstellt und Änderungen per Trigger synchronisiert – ideal gegen Table Bloat ohne Downtime.
- pgroll: Neueres Tool von Xata für versionierte Schema-Migrationen, das alte und neue Schema-Versionen parallel bedient – ermöglicht schrittweises Umschalten der Clients ohne Ausfall.
Railways Maßnahmen – CI-Enforcement für CONCURRENTLY, angepasste PgBouncer-Limits und reservierte Admin-Connections – sind solide, aber reaktiv. Der Honeycomb-Ansatz mit präventivem Linting erscheint allerdings etwas nachhaltiger und greift früher im Prozess ein
Incident Report: October 28th, 2025
Transparent Leadership: Gute Manager machen sich überflüssig
Der Autor kqr beschreibt in verlinkten Blogartikel über Leadership-Stile, warum ihm das populäre Konzept des „Servant Leadership“ nie ganz behagte – und schlägt eine Alternative vor.
Das Problem mit Servant Leadership in der Praxis: Manager räumen ihren Teams alle Hindernisse aus dem Weg, ähnlich wie „Helikopter-Eltern“, die ihren Kindern jeden Stein vom Weg fegen (im englischen sind es übrigens „Curling-Eltern“, wusste ich nicht). Kurzfristig fühlt sich das für alle gut an. Langfristig wird der Manager zum überarbeiteten Single Point of Failure, und wenn er geht, weiß niemand mehr, wie man mit den Hindernissen umgeht, die vorher unsichtbar beseitigt wurden.
Der Autor propagiert stattdessen „Transparent Leadership“: Menschen coachen statt Probleme für sie lösen, methodisches Problemlösen beibringen, Werte und Prinzipien erklären damit Teams eigenständig aligned entscheiden können, direkte Verbindungen schaffen statt sich als Mittelsmann zu positionieren – und sich letztlich selbst überflüssig machen.
Was tun, wenn man sich überflüssig gemacht hat? Nicht neue Bürokratie erfinden oder Status-Reports einfordern, sondern wieder an technischen Problemen arbeiten. Das hält die Skills frisch und bringt mehr Respekt vom Team als Paper-Shuffling.
Die Parallele zur Erziehung ist kein Zufall: „Teach a man to fish“ funktioniert in beiden Kontexten.
Transparent Leadership Beats Servant Leadership
Multi-Region-Architektur: Lehren aus dem AWS-Outage
Am 20. Oktober 2025 legte ja bekanntlich ein DynamoDB-DNS-Problem die AWS-Region us-east-1 lahm – Disney+, Reddit, Lyft waren betroffen. In einem ausführlichen Engineering-Artikel erklärt Warren Parad von Authress, warum ihr Auth-Service trotzdem online blieb.
Die Kernaussage ist ernüchternd, aber vermutlich wenig bekannt: AWS Lambda und API Gateway bieten jeweils nur 99,95% SLA – für ein Five-Nines-Ziel (99,999%) reicht das mathematisch nicht aus. Parad rechnet vor, dass Komponenten unter 99,7% Reliability für kritische Pfade schlicht nicht nutzbar sind, egal wie oft man Retries einbaut.
Was hat Authress konkret umgesetzt? DNS-basiertes Failover via Route 53 mit Custom Health-Endpoints, die nicht nur Erreichbarkeit prüfen, sondern Datenbank, Queue und Business-Logik validieren. Dazu Edge Computing via CloudFront mit automatischem Failover auf bis zu drei Regionen, Incremental Rollouts in Customer Buckets zur Blast-Radius-Begrenzung, und Anomaly Detection auf Basis der „Authorization Ratio“ statt simpler HTTP-Statuscodes.
Wichtig und zu beachten: Selbst ohne direkte us-east-1-Abhängigkeit können Ausfälle dort Auswirkungen haben – zentrale AWS-Dienste wie IAM, CloudFront und Certificate Manager haben dort ihre Control Planes und können Auswirkungen auf eigene Rollouts und Deployments haben, selbst wenn man in us-east-1 keine Ressourcen provisioniert.
How when AWS was down, we were not
IBM kauft Confluent: 6,4 Milliarden für die Firma hinter Kafka
Nach Red Hat und HashiCorp setzt IBM seinen Einkaufsbummel fort: Für 6,4 Milliarden Dollar (31$ pro Aktie, All-Cash-Deal) übernimmt Big Blue nun Confluent, die Firma hinter Apache Kafka. Die Transaktion soll Mitte 2026 abgeschlossen sein, Confluent soll als eigenständige Marke unter IBM weitergeführt werden.
Jay Kreps, CEO und Kafka-Miterfinder, betont in seiner Mitteilung an die Mitarbeiter die strategische Logik: IBM sehe dieselbe Zukunft – Unternehmen, die auf kontinuierlicher, event-getriebener Intelligenz basieren. Daten müssten frei und zuverlässig durch alle Geschäftsbereiche fließen, und genau diese „connective layer“ werden definieren, wie Firmen in den kommenden Jahrzehnten operieren.
IBM verfolgt damit konsequent seine Hybrid-Cloud-Strategie. Die Kombination aus Red Hat (Kubernetes, OpenShift), HashiCorp (Terraform, Vault) und nun Confluent (Kafka, Event Streaming) ergibt ein umfassendes Portfolio für Enterprise-Infrastruktur. Kreps hebt IBMs „long history of supporting open source“ hervor – ob das nach den HashiCorp-Lizenzquerelen und den RHEL-Kontroversen alle so sehen, steht auf einem anderen Blatt.
Für Confluent-Kunden ändert sich kurzfristig nichts. Spannend wird, wie IBM die Kafka-Plattform mit watsonx und den AI-Initiativen verzahnt.
Architectural Debt: Technische Schulden nur Spitze des Eisbergs
Als Entwickler frustrierten uns technische Schulden – und Schätzungen, die als Deadlines behandelt wurden. Als Enterprise-Architekt, so Frederick Vanbrabant in seinem Blogartikel, sind es immer noch dieselben Themen. Nur betreffen „Architectural Debt“ eben nicht nur den Code.
In Organisationen mit hunderten Applikationen kann sich ein EA nicht mehr darum kümmern, wie die Software intern funktioniert. Der Fokus liege auf Integration Patterns, Datenflüssen, Redundanzen zwischen Systemen und dem unvermeidlichen Vendor Lock-in. Diese Schulden auf dem Application Layer treiben direkt die Betriebskosten und verlangsamen Delivery.
Spannender wird es auf dem Business Layer: Wer ist Owner eines Prozesses, wenn etwas schiefgeht? Welche Abteilungen sind voneinander abhängig? Veraltete Prozessdokumentation ist unangenehm für neue Mitarbeiter – richtig teuer wird es, wenn ein Auditor sie liest. Schulden hier multiplizieren die Probleme auf dem operativen Layer.
Am kritischsten ist der Strategy Layer: Falsch definierte Business Capability Maps oder unvollständige Frameworks führen dazu, dass man die Strategie für die nächsten 3-5 Jahre auf falschen Annahmen aufbaut. Das blockiert Transformationsprojekte und lässt schlechte Langzeitstrategien attraktiv erscheinen.
Der Vorteil von Enterprise-Architekten: Sie haben Zeit und Zugang, um diese Schulden sichtbar zu machen – mit Dashboards und PowerPoints statt mit God-Classes, die refactored werden müssen.
Architectural debt is not just technical debt
120fps Pinball im Browser: Shopifys BFCMShowcase
Das Engineering-Team von Shopify hat für Black Friday Cyber Monday 2025 ihren bekannten Live-Globe – der Echtzeit-Verkäufe weltweit visualisiert – in eine spielbare Pinball-Maschine verwandelt. Senior Engineer Daniel Beauchamp investierte 400 Stunden in das Projekt, das bei 120fps im Browser läuft. Überleg mal, die willst eine Public Black Friday Demo bauen und schätzt deinem Chef 400 Stunden dafür – das sind immerhin 50PT.
Der Tech-Stack: three.js mit react-three-fiber, „zustand“ für State Management, Server-Sent Events für Echtzeit-Daten. Jeder Bogen auf dem Globus repräsentiert eine echte Bestellung – Sekunden nach dem Kauf sichtbar. Spannend war die Physik-Entscheidung: Das Team wechselte von Rapier 3D zu Rapier 2D, was den Physics-Step von 2ms auf 0,2ms reduzierte. Rampen funktionieren über ein Sensor-System, das Collider aktiviert und deaktiviert – „a carefully orchestrated dance“.
Die 86 dynamischen Lichter wären mit klassischem Forward-Rendering unmöglich gewesen. Stattdessen nutzt das Team eine Mask-Texture, bei der der R-Channel die Light-ID kodiert. Das Dot Matrix Display rendert 128×32 Pixel Sprite-Sheets über einen Custom Shader.
Besonders witzig: Minigames reagieren auf Echtzeit-Events wie „First Sale“ oder Meilensteine bei 10K, 100K, 1M Orders. Das Ganze läuft auch in AR via @react-three/xr – mit nur 100 Zeilen Code. Hast du mal gespielt?
Zum dritten Mal wurde der Globe auch auf der Las Vegas Sphere gezeigt.
Behind the build: 2025’s BFCM globe in a pinball machine
Leser Antwort zum 8 Stunden Mythos
Zum „8 Stunden Mythos Artikel von letzter Woche habe ich folgende E-Mail Antwort von Wolfgang erhalten:
Ich habe vor ein paar Jahren mal von Cal Newport das Buch „Konzentriert arbeiten: Regeln für eine Welt voller Ablenkungen“ gelesen. Newport nennt für Wissensarbeiter täglich maximal 4h für konzentriertes Arbeiten. Inhaltlich kommt Newport aus der Ecke „weg mit (digitaler) Ablenkung“ (gibt dazu eine Reihe mehr Bücher von ihm) und nicht von „Selbstoptimierung“, wie so viele andere Autoren.
Ok, das Buch „konzentriert Arbeiten“ kannte ich noch nicht, ist von 2027 und hat auf Amazon 682 Bewertungen zu 4,4 Sternen – ist ab sofort auf meiner Wunschliste.
Ich selbst verdiene mein Geld mit dem Schreiben von Security-Konzepten und RZ-Dokumentation im Umfeld BSI Grundschutz. Länger als zweieinhalb bis drei Stunden schaffe ich da nicht am Stück, wenn ich wirklich neuen Text erstellen muss. Korrekturlesen oder Layout-Arbeiten brauchen weniger Konzentration, da geht mehr. Wenn ich nach den ersten zweieinhalb Stunden eine längere Pause mache, kann ich am selben Tag nochmal ein zweites Mal zweieinhalb Stunden „ran klotzen“. Dank Home Office ist das mit einer längeren Pause zwischendrin gut machbar, und rund ums Haus habe ich dann auch ausreichend Ablenkung mit Garten und meiner „Garagenschreinerei“ 🙂
Ok, ich kann nachvollziehen, dass man hier auf jeden Fall auch eine Pause braucht – und stimmt, im Home Office mach ich als auch mal längere Pausen oder geh bei einem Telefon Termin an die frische Luft zum Telefonieren.
Bezahlt werde ich als Freiberufler nach geleisteten Stunden, liefern muss ich aber „nur“ fertige Dokumente. Ich gestalte also meinen Tag i. d. R. so, dass ich etwa drei Stunden für konzentrierte Schreibarbeit einplane und die restliche Zeit für etwas „leichtere“ Kost, Telefonkonferenzen, Gespräche mit Admins zu technischen Details, die zu dokumentieren sind u. ä.
Und Wolfang dann weiter:
Meine Frau arbeitet für ein Online-Magazin, die berichtet ähnliches: wenn sie selbst Artikel schreibt, gehen ca. 3h am Stück konzentrierte Arbeit. Als deutscher Ableger eines UK-Magazins hat sie auch allerlei Übersetzugsarbeit zu tun, wo mittlerweile KI gut mithilft und man „nur noch“ korrekturlesen und ein paar sperrig übersetzte Passagen in lesbares Deutsch bringen muss. Damit – und mit Telefonaten/Interviews – verbringt sie dann den restlichen Arbeitstag.
Ja, prima – vielen Dank für die Einsendung – gerne mehr davon. Und klar, der 8 Stunden Mythos Artikel ist ja nicht so gemeint, dass man nur 4 Stunden Arbeitet, sondern dass für den Teil der Wissensarbeit irgendwann die Brain Power erschöpft ist.
Wolfang stellt das auch nochmal separat klar, dass der Arbeitstag in Summe dann trotzdem deutlich länger sein kann.
Vielen Dank, dass ich es reinpacken durfte.
8-Stunden-Mythos: Was Wissensarbeiter wirklich leisten können
Schmunzelecke
Mit dem Cloudflare Error Page Generator kannst du individuelle Cloudflare Error Pages für deine App erstellen – damit sieht es immer so aus, als sei Cloudflare schuld. In der Regel stößt das ja auf mehr Verständnis, als wenn es bei dir selbst knallt. Witzige Idee und leider was dran!
Auf dieser Page siehst du, wie Gemini 3 die Hacker News Frontpage in 10 Jahren prophezeit. In dieser Iteration sind auch die Pages dahinter von der AI erstellt worden. Sind witzige Sachen dabei, beispielsweise:
- How to Build a Faraday Cage for Your Bedroom
- EU passes „Right to Human Verification“ Act
- Google kills Gemini Cloud Services (killedbygoogle.com)
- …
Alternativ kann man auch einfach „Black Mirror“ schauen.
💡 Link Tipps aus der Open Source Welt
Keep – Die Open-Source AIOps Plattform
Keep ist eine Open-Source AIOps- und Alert-Management-Plattform, die sich als zentrale Schaltstelle für komplexe Monitoring-Umgebungen positioniert. Mit über 11k GitHub Stars und der kürzlich angekündigten Übernahme durch Elastic gewinnt das Projekt zusätzlich an Bedeutung.
Features:
- Single Pane of Glass: Zentrale Ansicht für alle Alerts mit CQL (Common Expression Language) für Advanced Querying
- 110+ Integrationen: Bidirektionale Verbindungen zu Monitoring-Tools, IRM, Ticketing und CMDB-Systemen
- Workflow Engine: YAML-basierte Automatisierung à la GitHub Actions mit UI
- AIOps 2.0: KI-gestützte Alert-Korrelation, Deduplication und Incident-Summarization
- Multi-Backend AI Support: OpenAI, Anthropic, DeepSeek, Ollama, Gemini und weitere
- Alert Enrichment: Automatische Anreicherung mit Context aus verschiedenen Quellen
- Noise Reduction: Rule-based Grouping und Filtering zur Alert-Fatigue-Reduzierung
Deployment-Optionen:
- Open Source: Self-hosted mit vollem Feature-Set (außer Enterprise AIOps)
- Cloud: Managed Service ab Free Trial
- Enterprise: On-Prem oder Cloud mit Advanced AI Features
Die Elastic-Übernahme macht absolut Sinn – Keep ergänzt perfekt Elastics Observability-Stack. Die bidirektionalen Integrationen und der Workflow-Ansatz lösen echte Pain Points in heterogenen Monitoring-Landschaften. Besonders cool: Die YAML-Workflows mit UI machen Automatisierung auch für weniger Code-affine Teams zugänglich.
Hast du Keep gekannt oder gar im Einsatz? Schreib mir gerne, wie das so tut bei euch.
https://github.com/psviderski/uncloud
Keksly – Leichtgewichtiges Cookie Consent Banner
Keksly ist eine Zero-Dependency Cookie-Consent-Lösung, die sich durch ihren Service-basierten Ansatz von der Konkurrenz abhebt. Statt vage Kategorien wie „Marketing“ oder „Statistik“ zeigt Keksly konkret, welche Services genutzt werden – transparent und GDPR-konform.
Features:
- Google Consent Mode v2: Native Unterstützung mit automatischem Mapping zu GCM-Signalen
- Service-basierter Consent: Nutzer stimmen konkreten Services zu (Google Analytics, Facebook Pixel)
- Automatisches Script-Blocking: Third-Party-Scripts werden bis zur Zustimmung blockiert
- Zero Dependencies: Keine externen Abhängigkeiten, nur Vanilla JavaScript
- Vollständig anpassbar: Farben, Fonts, Texte und Position konfigurierbar
- Responsive Design: Optimiert für Mobile und Desktop
- GDPR-konform: Opt-in by Default, klare Service-Beschreibungen
Auf der keksly.eu Website findest du einen Online-Konfigurator für deinen Cookie Banner.
Endlich mal ein Cookie-Banner, der den User ernst nimmt! Der Service-basierte Ansatz ist deutlich transparenter als die üblichen „Wir nutzen Cookies für bessere Performance“-Floskeln. Mit unter 10KB und ohne Dependencies perfekt für performance-bewusste Projekte – und dazu noch Open Source.
https://github.com/speetzial/Keksly
❓ 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: