Shai-Hulud 2.0, Digitale Souveränität, Meeting Kultur, Schweiz und Cloud, Google TPUs, Multi Region in AWS, Root Cause Analysis und mehr – #214

Willkommen zu allesnurgecloud.com – Ausgabe #214

Der Shopify Black Friday Live Tracker hat es wieder in sich – ich hoffe, er geht jetzt auch noch ein paar Tage danach. Du kannst Flipper spielen, es gibt Eastereggs und natürlich kann man checken, wieviel Shopify Kunden aktuell einkaufen, was sie ausgeben und von wo auf der Welt – und es gibt technische Einblicke auf einem Screen am Schreibtisch. Requests und Traffic am Edge, Kafka Messages pro Sekunden und vieles mehr. Total abgefahren und beeindruckend – wie lange man alleine damit beschäftig ist, sowas zu bauen? Im ersten Flipper Versuch hab ich 1,2 Mio. Punkte gesammelt, du?

Bei openPetition gibt es eine Online Petition zum Thema „Anerkennung von Open-Source-Arbeit als Ehrenamt in Deutschland“ – und ja, da muss ja fast erstmal unterschreiben, auch wenn etwas unklar ist, wie sowas gemessen und organisiert werden soll. Aber da finden sich bestimmt Mittel und Wege.

Simon hatte mich darauf hingewiesen, dass das Nextcloud Ionos Angebot von der letzten Woche doch nur ein Lockangebot war – und man nach Ablauf der ersten Monate doch normal pro User bezahlt. Kennst du andere Angebote, wo dies nicht so ist?
Oder gar andere NextCloud Angebote?

Ach und, für die SciFi Nerds – Voyager 1 ist nach 50 Jahren kurz davor, einen ganzen Licht-Tag von der Erde entfernt zu sein. Also nur noch 18.250 Jahre, bis sie dann ein Licht-Jahr entfernt ist. So ungefähr.

Happy Bootstrapping Podcast

In der aktuellen Podcast Folge 149 spreche ich mit Campus Founders CEO Oliver Hanisch über das Startup und KI Ökosystem in Heilbronn, warum man nach 15 Jahren im Silicon Valley nach Heilbronn umzieht, wie die Campus Founders das lokale Startup Ökosystem supporten und warum man ein großes Ticket in das Raketen Startup HyImpulse investiert hat – Hör gerne mal in Folge 149 rein (Spotify / Apple).

Wenn dir die Podcast Folgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).

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:

623 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address
Diese E-Mail ist bereits registriert.
The security code entered was incorrect
Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.

Shai-Hulud 2.0: 27.000 GitHub-Repos kompromittiert, 1.000+ npm-Pakete infiziert

Shai-Hulud schlägt erneut zu – nur zwei Monate nach der ersten Welle hat der npm-Wurm am 24. November zurückgeschlagen. HelixGuard meldete als erste Sicherheitsfirma die Kompromittierung von über 1.000 npm-Paketen innerhalb weniger Stunden – diesmal mit dem theatralischen Titel „The Second Coming“.

Die betroffenen Pakete lesen sich wie ein Who’s Who der JavaScript-Welt: Zapier, AsyncAPI, PostHog, Postman und Browserbase. Die Malware tarnt sich als Bun-Runtime-Installation via setup_bun.js und führt dann bun_environment.js aus – eine über 10 MB große, obfuskierte Payload. Diese lädt das Open-Source-Tool TruffleHog herunter und missbraucht es, um die lokale Maschine nach NPM-Tokens, AWS/GCP/Azure-Credentials und Environment-Variablen zu durchsuchen.

Die Malware erstellt über 27.000 GitHub-Repositories mit der Beschreibung „Sha1-Hulud: The Second Coming“ – allerdings cross-victim, was bedeutet, dass Secrets von Opfer A im Repository von Opfer B landen. Wiz Research identifizierte bereits 775 kompromittierte GitHub-Tokens, 373 AWS-Credentials und 300 GCP-Credentials. Zusätzlich installiert die Malware eine GitHub Actions Backdoor, die beliebigen Code-Ausführung ermöglicht.

Timing und Fehler: Die Attacke erfolgte kurz vor npm’s Token-Deadline am 9. Dezember. Der wurmartige Selbstreplikations-Mechanismus hatte jedoch Bugs – bei vielen automatisch verbreiteten Paketen fehlte die 10 MB Payload bun_environment.js, sodass nur der harmlose Loader übrig blieb. Aikido bestätigt, dass mittlerweile die meisten Pakete zurückerobert wurden.

Manche betroffene Firmen haben einen Incident Report zum Thema veröffentlich – beispielsweise listet PostHog alle betroffenen Pakete, Postman hier ebenfalls. Patient Zero soll „AsyncAPI“ gewesen sein, danach ging es relativ schnell weiter. Akido listet hier 492 betroffene Pakete auf und gibt diverse Handlungsempfehlungen. Unter anderem soll man alle GitHub, npm, Cloud und CI/CD secrets rotieren, MFA aktivieren oder das Hauseigene Tool „Safe Chain“ verwenden – das kannte ich jetzt noch nicht.

Shai-Hulud Returns: Over 1K NPM Packages and 27K+ Github Repos infected via Fake Bun Runtime Within Hours


Digitale Souveränität gescheitert? Balanceakt bei OVH

Digitale Souveränität wird zur juristischen Falle – OVHcloud aus Frankreich steckt in einer Zwickmühle, die zeigt, wie fragil europäische Datensouveränität wirklich ist. Stefan Krempl berichtet bei heise.de über einen Präzedenzfall mit globaler Tragweite.

Der Fall: Ein kanadisches Gericht in Ontario fordert von OVHcloud die Herausgabe von Bestands- und Metadaten, die mit vier IP-Adressen verknüpft sind – für Ermittlungen der Royal Canadian Mounted Police (RCMP). Das Problem: Die Daten liegen auf Servern in Frankreich, Großbritannien und Australien. Richterin Heather Perkins-McVey argumentiert mit „virtueller Präsenz“: Da OVH weltweit agiere, unterliege es kanadischer Gerichtsbarkeit – unabhängig vom Serverstandort.

Und jetzt kommts: Das französische Blockadegesetz (Loi nr. 68-678) verbietet unter Strafandrohung (6 Monate Haft, 90.000 Euro Strafe) die Datenherausgabe an ausländische Behörden ohne offiziellen Rechtshilfeweg. Ignoriert OVH das kanadische Gericht, droht Missachtung der Justiz in Ontario – Ringelpietz, also.

Das franz. Wirtschaftsministerium und Justizministerium haben nun protestiert und eine „beschleunigte Bearbeitung“ über den offiziellen Rechtshilfeweg angeboten. OVH hat die Daten bereits gesichert – aber Kanada beharrt auf direkter Herausgabe. Ende Oktober hat OVH Berufung eingelegt, ein Urteil steht aus.

Die IronieUS-Hyperscaler wie AWS, Microsoft und Google lachen sich ins Fäustchen – diesmal steht die europäische Konkurrenz bei der Datensouveränität mit dem Rücken zur Wand, nicht sie. Der rechtlich interessante Fall zeigt, dass „europäische Cloud“ noch lange keine Garantie für Datensouveränität ist, wenn Gerichte einfach auf „virtuelle Präsenz“ pochen können. Bin mal gespannt, wie das ausgeht.

Das OpenSource Betriebssystem GrapheneOS hat jedenfalls direkt Konsequenzen gezogen und Frankreich bzw. OVH den Rücken gekehrt. Die Argumentation dazu kannst du bei Mastodon nachlesen (oder hier bei Golem.de).

Kanadisches Gericht: OVHcloud aus Frankreich muss Nutzerdaten herausgeben


Anzeige

Buchtipp: „DevOps: Wie IT-Projekte mit einem modernen Toolset und der richtigen Kultur gelingen“

Der Buchtipp von heute ist „DevOps: Wie IT-Projekte mit einem modernen Toolset und der richtigen Kultur gelingen“ von Sujeevan Vijayakumaran. Endlich mal ein deutschsprachiges DevOps-Buch, das nicht nur übersetzt klingt, sondern von jemandem geschrieben wurde, der die Praxis kennt.

Sujeevan hat in zahlreichen Projekten selbst erlebt, was funktioniert – und was eben nicht. Das merkt man dem Buch an. Statt theoretischem Overhead bekommt man hier handfeste Tipps: Wie baut man schlanke Build-Prozesse? Wie kriegt man CI/CD vernünftig hin? Wie überwacht man seine Dienste, ohne im Alert-Chaos zu versinken?

Was mir besonders gefällt: Das Buch deckt die gesamte Bandbreite ab – von der Zusammenarbeit im Team über automatisierte Qualitätssicherung bis hin zu Monitoring und Observability. Und ja, auch Sicherheit und Compliance kommen nicht zu kurz.

Perfekt für alle, die DevOps nicht nur als Buzzword kennen, sondern wirklich verstehen und umsetzen wollen.

P.S.: Sujeevan liest selber den Newsletter und kriegt nun beim Lesen bestimmt rote Backen, alles Absicht ;). Seinen Podcast „TILpod“ mit Co-Host Dirk findest du hier und seine Firma „Friday Deployments“ hier.

Buchtipp: „DevOps: Wie IT-Projekte mit einem modernen Toolset und der richtigen Kultur gelingen“


Meeting-Produktivität: 37% aller Meetings starten zu spät

Meetings kosten deutsche Unternehmen Millionen – und die meisten wissen nicht, wie man sie richtig macht. Erik Pfannmöller von der Culture Code Foundation erklärt im Podcast bei digital kompakt, warum Meetings einer der größten Produktivitätshebel sind und welche Best Practices wirklich funktionieren.

Die erschreckenden Zahlen37% aller Meetings starten durchschnittlich 10 Minuten und 40 Sekunden zu spät – das summiert sich auf 4 Arbeitstage pro Jahr, in denen Mitarbeitende nur rumsitzen. Dazu kommt: 11 Stunden pro Woche verbringen wir in Meetings, davon wird ein Drittel als völlig unnötig empfunden. Der finanzielle Impact ist gigantisch, wenn man sich die Stundensätze gut bezahlter Manager ansieht.

Die Grundregeln für Organisatoren: „Should it be a meeting?“ – diese Frage sollte immer zuerst gestellt werden. Die Two-Pizza-Rule besagt: maximal 5-8 Teilnehmende, sonst wird’s keine Diskussion mehr, sondern eine Präsentation. Ohne Agenda kein Meeting – und zwar mit klarem Goal, Agenda mit Zeitangaben und Vorbereitung. Pfannmöller empfiehlt, 50% der Meetingzeit für Vorbereitung einzuplanen. Ein weiteres Tabu: „No oral update meetings“ – mündliche Updates dauern 4x länger als schriftliche.

Die Umsetzung: Bei One-on-Ones helfen gemeinsame digitale Notizen (reverse chronologisch sortiert), die beide vorab befüllen. Meetings sollten pünktlich starten (nicht „akademisches Viertel“), 10% der Zeit für Zusammenfassung reservieren und entweder alle physisch oder alle virtuell ablaufen – Hybrid schafft „Bürger zweiter Klasse“.

Die wichtigste Kulturregel: „No Agenda, no Meeting“ konsequent durchsetzen – das finde ich ja super, Erik dazu:

Kultur ist das schlechteste akzeptierte Verhalten in einer Firma. Wenn es akzeptiert wird, dass es Meetings ohne Agenda gibt, dann wird es zum Standard

„Kultur ist das schlechteste akzeptierte Verhalten in einer Firma“ – interessant, aber es stimmt. Ich hab im Podcast vieles gehört, dass ich schon kannte – aber es tut gut, es sich mal wieder in Erinnerung zu rufen. Teilweise finde ich das „Public Shaming“ übertrieben, wie er es beschreibt – manchmal weiß man sich vielleicht aber auch nicht anders zu helfen.

Die Parallelen zu Remote Work Best Practices aus Ausgabe 94 dem asynchronen Arbeiten bei Basecamp aus Ausgabe 160 sind jedenfalls da.
Interessant fand ich auch noch, dass man Meetings nicht „virtuell“ und „einige sitzen in einem Raum“ mischen sollte.

Meeting Mastery: Wie mache ich ein gutes Meeting?


Schweiz: Datenschützer empfehlen Cloud-Verbot für Behörden

Die Schweizer Datenschutzkonferenz Privatim hat in einer Resolution vom 18. November die Nutzung von US-Hyperscalern wie AWS, Google und Microsoft für eidgenössische Behörden massiv eingeschränkt – faktisch ein Verbot für SaaS-Lösungen wie Microsoft 365, sobald besonders schützenswerte Personendaten verarbeitet werden, wie heise.de berichtet. Anwendungen wie M365 dürften Ämter damit größtenteils nur noch als Online-Speicher verwenden.

Die Begründung ist umfassend: Fehlende Ende-zu-Ende-Verschlüsselung, mangelnde Transparenz globaler Anbieter, lange Subunternehmer-Ketten und einseitige Vertragsanpassungen führen zu erheblichem Kontrollverlust. Besondere Sorge bereitet der US Cloud Act, der amerikanische Anbieter zur Datenherausgabe verpflichten kann – selbst bei Speicherung in Schweizer Rechenzentren und ohne Einhaltung internationaler Rechtshilferegeln.

Das Fazit: Nutzung nur zulässig, wenn Behörden die Daten selbst verschlüsseln und der Cloud-Anbieter keinen Schlüsselzugang hat. Rechtsanwalt Martin Steiger merkt an, dass sinnvolle Cloud-Nutzung mit durchgehender Verschlüsselung kaum möglich sei – und dass die meisten Behördendaten ohnehin einer Geheimhaltungspflicht unterliegen.

Ob die Resolution Folgen hat, bleibt abzuwarten – ähnliche Empfehlungen deutscher Datenschutzbehörden zu Microsoft 365 hatten bisher wenig praktische Auswirkungen.

Schweiz: Datenschützer empfehlen breites Cloud-Verbot für Behörden


TPU Deep Dive: Googles Geheimwaffe gegen Nvidia

Google hat mit Gemini 3 bewiesen, dass TPUs auf Augenhöhe mit Nvidia spielen können – das aktuell leistungsstärkste KI-Modell wurde ausschließlich auf Google TPUs trainiert, nicht auf Nvidia-Hardware. Richard Jarc analysiert in einem ausführlichen Deep Dive auf Substack, warum TPUs der größte Wettbewerbsvorteil für Googles Cloud-Geschäft der nächsten Dekade sein könnten.

Der technische Kern ist die Systolic-Array-Architektur: Während GPUs Daten ständig zwischen Memory und Compute hin- und herschieben, fließen Daten im TPU wie Blut durch ein Herz – einmal laden, dann durch ein Gitter von Multiplikatoren durchreichen. Das Ergebnis: deutlich weniger HBM-Zugriffe und mehr Zyklen fürs eigentliche Rechnen.

Die Performance-Zahlen sind beeindruckend: Laut einem ehemaligen Google-Cloud-Mitarbeiter ist TPUv6 60-65% effizienter als Nvidia GPUs, mit bis zu 1.4x besserer Performance pro Dollar für passende Workloads. Das neue TPUv7 (Ironwood) liefert 4.614 TFLOPS versus 459 für TPUv5p – ein gewaltiger Sprung.

Das Adoptionsproblem bleibt das Ökosystem: CUDA ist in den Köpfen der KI-Ingenieure verankert, Multi-Cloud-Strategien erschweren den Wechsel. Doch für Inference-Workloads ist CUDA weniger kritisch – hier könnten TPUs ihren Footprint deutlich erweitern.

The chip made for the AI inference era – the Google TPU


Versteckte Abhängigkeiten: Wie der AWS-Ausfall incident.io traf

Pete Hamilton, CTO von incident.io, veröffentlicht ein bemerkenswertes Postmortem zum AWS us-east-1 Ausfall am 20. Oktober 2025. Obwohl incident.io bei Google Cloud gehostet ist, waren mehrere kritische Services betroffen – durch versteckte Drittanbieter-Abhängigkeiten.

Kaskade der Ausfälle: Der Telekommunikations-Provider für SMS und Telefon-Benachrichtigungen lief auf AWS. Die SAML-Authentifizierung fiel aus. Der Transkriptions-Provider für den AI-Notetaker Scribe war nicht erreichbar. Das allein wäre handhabbar gewesen – doch dann blockierte die Deployment-Pipeline: Das Golang-Base-Image lag auf Docker Hub, und Docker läuft auf AWS.

Das Team konnte keinen Code deployen, um SMS-Notifications zu deaktivieren. Der Versuch, auf Googles Docker-Mirror umzustellen, scheiterte – die Buildkite-Container brauchten selbst Docker-Images. Das interne Traffic-Management-Tool funktionierte nur für die Top-10-Kunden statt für alle. Die Kubernetes-Skalierung verschlimmerte die Lage durch PostgreSQL-Index-Bloat.

Lessons Learned: incident.io hat bereits alle Build-Abhängigkeiten zu GCP konsolidiert, Region-Switching für Scribe implementiert und arbeitet an Multi-Provider-Redundanz für Telekommunikation.

Normalerweise würde ich sagen, dass man solche Features im Feature-Flag System abschalten kann – hast du eines?
Auch das hat bei Incident.io nicht so richtig funktioniert laut dem Artikel.

Für eine kurze Zeit haben auch die Status-Pages nicht funktioniert – diese laufen nicht bei Google, was für Incident.io total richtig ist – aber bei Vercel, was wiederum AWS nutzt und eben kurz an der Stelle nicht funktioniert hat (Incident.io Statuspage).

Service disruption on October 20, 2025


AWS-Ausfall überstanden dank Multi-Region bei Ably

Paddy Byers, CTO von Ably, zeigt im Engineering Blog, wie eine echte Multi-Region-Architektur den AWS us-east-1 Ausfall am 20. Oktober ohne Kundenauswirkungen überstand – ein Kontrastprogramm zum incident.io Postmortem.

Die bestehende Infrastruktur in us-east-1 lieferte während des gesamten Ausfalls fehlerfreien Service weiter. Da jedoch die AWS Control Plane gestört war und keine zusätzliche Kapazität provisioniert werden konnte, änderte das Team um 12:00 UTC die DNS-Einträge – neue Verbindungen wurden nach us-east-2 geroutet, während bestehende Connections in us-east-1 unterbrechungsfrei weiterliefen. Ein routinemäßiger Eingriff, den Ably bei regionalen Störungen regelmäßig durchführt.

Der Latenz-Impact war kaum messbar: Der Worst-Case für Clients direkt neben us-east-1 betrug 12ms bei p50 – deutlich unter dem globalen Median von 40-50ms. Im Durchschnitt über alle US-Monitoring-Standorte lag der Unterschied bei nur 3ms, unterhalb typischer Varianzen und für Nutzer nicht wahrnehmbar.

Die Architektur dahinter basiert auf unabhängig operierenden Regionen, Latency-based DNS für automatische Routing-Anpassung und Client-SDKs mit automatischem Failover zu bis zu fünf globalen Endpoints. Diese letzte Verteidigungslinie wurde diesmal nicht aktiviert – aber sie existiert als Teil der Defense-in-Depth-Strategie.

AWS us-east-1 outage: How Ably’s multi-region architecture held up


Root Cause Analysis? You’re Doing It Wrong

Root Cause Analysis führt in die Irre – so lautet die provokante These von kqr in seinem Artikel „Root Cause Analysis? You’re Doing It Wrong„. Die weitverbreitete Methode basiert auf einem fundamental vereinfachten Weltmodell, das der Komplexität realer Systeme nicht gerecht wird und zu oberflächlichen Lösungen führt.

Das Kernproblem: Root Cause Analysis suggeriert, dass Unfälle auf eine einzelne Ursache zurückführbar sind. Die Realität zeigt jedoch, dass multiple Faktoren zusammenwirken müssen. Kqr demonstriert dies an einem Beispiel: Ein API-System fiel aus, weil Multi-Threading und PropertyVisitorAutowireMapping gleichzeitig aktiviert waren. Die „offizielle“ Analyse endete hier – doch die wirklich interessanten Fragen beginnen erst: Warum waren inkompatible Einstellungen überhaupt möglich? Warum fehlten Validierungen? Warum gab es keine Timeouts?

CAST als Alternative: Die Methode „Causal Analysis based on Systems Theory“ betrachtet Systeme ganzheitlich statt in isolierten Komponenten. Zentrale Konzepte sind Constraints (Verhaltensgrenzen), Controllers (die diese durchsetzen) und Hazards (gefährliche Systemzustände). Ein Unfall entsteht, wenn ein System in einem hazardous state auf ungünstige Umweltbedingungen trifft.

Human Error neu gedacht: Sobald „menschliches Versagen“ identifiziert wird, beginnt bei CAST erst die eigentliche Analyse. Die Frage lautet nicht „Wer?“, sondern „Welche Systemfaktoren führten zu dieser Entscheidung?“ – Mit Postmortems beschäftige ich mich aktuell viel, daher hab ich das Thema als mit dabei – beispielsweise in Ausgabe 178 über Blameless Postmortems und Ausgabe 189 zu Non-Prod Incidents.

Wenn du selber spannende Links zum Thema hast, gerne her damit.

Root Cause Analysis? You’re Doing It Wrong


GitLab 18.6 released – Fokus auf AI-Agenten für Workflows 🥱

GitLab 18.6 wurde am 20. November veröffentlicht und bringt über 20 Verbesserungen sowie 269 Community-Beiträge.

Highlight ist vor allem die neue UI – diese ist für alle Versionen sofort verfügbar und nutzt häufig eine side-by-side view – mir gefällt es!

AI & Automation

  • Security Analyst Agent – Jetzt als Foundational Agent verfügbar, auch für Self-Managed/Dedicated (Beta, nur Ultimate mit Duo Add-on)
  • Planner Agent – Standardmäßig im Agent-Dropdown, analysiert Work Items auf Group- und Project-Level (Beta, nur Duo Core/Pro/Enterprise)
  • GitLab MCP Server – Verbindet Claude Code, Cursor & Co. mit GitLab APIs (Beta)

Search & CI/CD

  • Exact Code Search – Zoekt-basierte Suche mit RegEx, instanzweit (Limited Availability)
  • CI/CD Components – können sich nun selber referenzieren – hilft vor allem beim Versionsmanagement / Releases
  • paralle.Matrics Variable– Dynamische 1-1 Dependencies in parallel:matrix (Beta)
  • Merge Requests Review Webhook – Es gibt nun Webhook Integrationen für Merge Request Reviews – kannst du nach Slack / Teams und Co schieben.

Es gab dann auch relativ schnell eine 18.6.1 Security Version – bitte direkt einspielen.

GitLab 18.6 released with new UI designed for productivity


Schmunzelecke

Bei downdetectorsdowndetector.com gibt es nun ein Monitoring, für downdetector.com, dann gibt es da einen Downdetector für den ersten Downtdetector bei downdetectorsdowndetectorsdowndetector.com und dieser wird dann wieder von downdetectorsdowndetectorsdowndetectorsdowndetector.com überwacht – alles sind unabhängige Projekte, damit in der Kaskade auch wirklich nix schiefgeht 😉


💡 Link Tipps aus der Open Source Welt

NetNewsWire – RSS Reader für macOS und iOS

NetNewsWire ist ein kostenloser Open-Source Feed-Reader für macOS und iOS, der RSS, Atom, JSON Feed und RSS-in-JSON Formate unterstützt. Das Projekt hat eine lange Geschichte und wird aktiv von der Community entwickelt.

Features:

  • Multi-Format Support: RSS, Atom, JSON Feed und RSS-in-JSON
  • Native Apps: Optimierte Versionen für macOS und iOS
  • Sync-Optionen: iCloud-Sync und verschiedene Feed-Services
  • Reader View: Aufgeräumte Artikel-Darstellung
  • Widgets: iOS Home Screen Widgets
  • AppleScript Support: Automation auf macOS
  • Intents & Shortcuts: Integration mit iOS Shortcuts
  • Open Source: MIT-lizenziert mit aktiver Community

Installieren kannst du es einfach über Homebrew oder aus dem AppStore direkt.

Es gibt hier sehr viele RSS Feed leser, falls die Statisiken stimmen – mit was lest ihr denn eure Feeds und wie synced ihr den Status über die Devices? Mit dem Google Reader ja wohl nicht mehr, das waren noch Zeiten.

https://github.com/Ranchero-Software/NetNewsWire

PGEXT.CLOUD – PostgreSQL Extension Repository & Package Manager

PGEXT.CLOUD ist eine umfassende Plattform für das PostgreSQL Extensions-Ökosystem, die von PGSTY/VONNG entwickelt wird. Das Projekt bietet den größten Extension-Katalog mit über 437 Extensions als native Linux-Packages.

Features:

  • 437+ Extensions: Der umfangreichste PostgreSQL Extension-Katalog weltweit
  • Native Packages: RPM/DEB Packages für 14 Linux-Distributionen
  • PIG Package Manager: CLI-Tool für einfache Extension-Installation
  • PGDG-kompatibel: Drop-in Replacement für offizielle PostgreSQL Packages
  • CDN Distribution: Weltweite Verteilung via Cloudflare CDN
  • Multi-Version Support: PostgreSQL 13-18 auf EL8/9/10, Debian 12/13, Ubuntu 22/24
  • ARM Support: Volle Unterstützung für x86_64 und aarch64 Architekturen

Kategorien: TIME (TimescaleDB, pg_cron), GIS (PostGIS, H3), RAG (pgvector, vchord), FTS (pgroonga, zhparser), OLAP (DuckDB, Citus), Security, FDW, ETL und viele weitere.

Quick Start mit PIG:

# PIG CLI installieren
curl -fsSL https://repo.pigsty.io/pig | bash

# Repository einrichten
pig repo set

# PostgreSQL 18 installieren
pig install pg18

# Extension installieren
pig install pg_duckdb -v 18

Das Projekt wird von verschiedenen PostgreSQL-Distributionen wie Pigsty, Omnigres und AutoBase genutzt. Alle Packages sind reproduzierbar gebaut und unter Apache 2.0 lizenziert.Bei AutoBase ist We Manage übrigens Sponsor, unbedingt auschecken 😉

https://pgext.cloud

❓ 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:

623 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address
Diese E-Mail ist bereits registriert.
The security code entered was incorrect
Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.



Share

By About
Abonnieren
Benachrichtigen bei
guest

0 Comments
Älteste
Neueste Meistbewertet
Inline-Feedbacks
Alle Kommentare anzeigen

allesnurgecloud.com

© 2025 allesnurgecloud.com
0
Deine Meinung würde uns sehr interessieren. Bitte kommentiere.x