30 września 2026 CMSWire — jeden z większych serwisów branżowych o systemach CMS — opisał premierę EmDash 1.0 ( artykuł Doma Nicastro ). Na pierwszy plan wysunął nie edytor ani wydajność, tylko zdecentralizowany rejestr wtyczek. Poniżej streszczam najważniejsze punkty i dodaję, jak to wygląda z perspektywy kogoś, kto prowadzi stronę na EmDashu.
Co weszło w 1.0
Według CMSWire EmDash 1.0 wychodzi z bety pół roku po premierze z 1 kwietnia 2026. Nadal jest darmowy, na licencji MIT, zbudowany na Astro i działa zarówno na Cloudflare Workers, jak i na zwykłym Node.js.
Artykuł opisuje model pracy w trzech rolach: deweloperzy budują stronę w Astro, redaktorzy pracują w panelu admina, a agenci AI korzystają z API, CLI i wbudowanego serwera MCP. Do tego opcjonalne mechanizmy wydajnościowe (cache obiektów w KV, adapter Hyperdrive do zewnętrznej bazy, Workers Cache) oraz EmDash Build — kreator stron oparty na AI, na razie w wersji alpha, skierowany do firm hostingowych i kreatorów stron.
Rejestr wtyczek na AT Protocol
To najciekawsza część. Rejestr jest zbudowany na AT Protocol, czyli protokole, na którym działa Bluesky. W praktyce wygląda to tak:
- Wydawca wtyczki ma własne, przenośne konto i to on podpisuje rekordy pakietu i kolejnych wydań. Rekordy są przechowywane na jego koncie, a nie w centralnym repozytorium.
- Przy instalacji EmDash sprawdza, czy pobrana paczka zgadza się z podpisanym rekordem: sumę kontrolną, nazwę, wersję, żądane uprawnienia i wymagane pochodzenie builda.
- Moderacja w domyślnym katalogu (z pomocą usługi etykietującej na Workers AI) może ukryć wtyczkę z katalogu, ale nie może podmienić jej wydania ani przejąć jej własności.
- Cloudflare udostępnił jako open source agregator, labeler i loader treści, więc każdy może postawić konkurencyjny katalog.
Na razie rejestr obsługuje tylko darmowe wtyczki. Płatne są w planach, w tym samym zdecentralizowanym modelu.
Dla porównania: w WordPressie katalog wtyczek to jedno miejsce kontrolowane przez jedną organizację. Spór wokół WP Engine w 2024 roku pokazał, że to realne ryzyko, a nie teoria. Model EmDasha jest bliższy temu, jak działa podpisywanie paczek w npm z provenance albo Sigstore: ufasz podpisowi wydawcy, a nie katalogowi.
Sandbox: wtyczka startuje bez żadnych uprawnień
Druga połowa historii to izolacja. CMSWire opisuje, że wtyczka w sandboxie startuje z dostępem tylko do własnego magazynu danych. Nie widzi treści, mediów, użytkowników, sekretów, systemu plików ani sieci. Każde dodatkowe uprawnienie musi zadeklarować w manifeście, a administrator musi je zatwierdzić. Przykład z artykułu: wtyczka do indeksowania wyszukiwania może dostać odczyt opublikowanych treści i prawo do łączenia się z jedną usługą wyszukiwania — ale nie może edytować wpisów ani łączyć się z innymi hostami.
Na Cloudflare każda taka wtyczka działa jako osobny Dynamic Worker, a na Node.js wewnątrz workerd, czyli otwartego runtime'u Workers.
Kontrast z WordPressem jest oczywisty: tam wtyczka działa w tym samym procesie PHP co cała strona i ma pełny dostęp do bazy, plików i sieci. Wtyczka do formularza kontaktowego może technicznie przeczytać nieopublikowane wpisy i wysłać je gdziekolwiek.
Jak to wygląda u nas
Tu muszę dodać zastrzeżenie, którego w artykule nie ma: sandbox jest opcjonalny. Na emdashcms.pl używamy dwóch oficjalnych wtyczek — formularzy i powiadomień webhook — i obie są zarejestrowane w zwykłej tablicy plugins, czyli działają natywnie, w procesie strony, z pełnym dostępem. Dokładnie tak jak w WordPressie. Żeby wtyczki trafiły do izolacji, trzeba je zarejestrować w sandboxed i dodać binding Worker Loader, który na Cloudflare — według recenzji Bitdoze — wymaga płatnego planu Workers.
Nie jest to zarzut wobec EmDasha — natywny tryb ma sens dla zaufanego kodu, a izolacja kosztuje (limity CPU, pamięci i zapytań). Ale „wtyczki w EmDash są bezpieczne z definicji” to uproszczenie. Bezpieczne są te, które świadomie uruchomisz w sandboxie, i tylko na tyle, na ile uważnie przeczytasz listę uprawnień przed kliknięciem „zatwierdź”.
Liczby i dowody
CMSWire podaje:
- ponad 175 kontrybutorów i 1800 commitów,
- tłumaczenia na 25 języków, ponad 800 osób na Discordzie,
- blog Cloudflare przeniesiony na EmDash w sierpniu 2026 — według artykułu obsługuje miliony odsłon tygodniowo i skoki do 5000 zapytań na sekundę,
- firmę Avulux, która przeniosła mikroserwis z WordPressa na EmDash w mniej niż dzień, korzystając z Agent Skills. Greg Barbosa z Avulux mówi, że WordPress stał się przeciwieństwem szybkiej i prostej w edycji strony, a EmDash dał im wspólną platformę dla deweloperów i marketingu.
Zastrzeżenia redakcji
Uczciwie trzeba oddać CMSWire, że artykuł nie jest laurką. Redakcja zaznacza, że dowody gotowości produkcyjnej pochodzą głównie od wczesnych użytkowników i od samego Cloudflare, a skuteczność modelu uprawnień zależy od tego, jak starannie administratorzy przeglądają prośby o dostęp.
Zgadzam się z tym. Mój benchmark EmDash kontra WordPress to jeden z niewielu niezależnych punktów danych — i wyszedł dla EmDasha niekorzystnie na czystym czasie przetwarzania, głównie przez opóźnienia zapytań do D1. Do tego, jak zauważa recenzja Bitdoze, blog Cloudflare osiąga swoje wyniki na Postgresie przez Hyperdrive i z kilkoma warstwami cache, czyli w konfiguracji, której typowa mała strona nie ma.
Podsumowanie
Zdecentralizowany rejestr z podpisanymi wydaniami i sandbox z jawnymi uprawnieniami to najpoważniejsza próba rozwiązania problemu bezpieczeństwa wtyczek, jaką widziałem w świecie CMS-ów. Ale to architektura, a nie gwarancja. Ekosystem jest jeszcze mały, płatnych wtyczek nie ma, a domyślna konfiguracja startera wcale nie wymusza sandboxa. Warto zajrzeć do własnego astro.config.mjs i sprawdzić, w której tablicy siedzą twoje wtyczki.
Brak komentarzy