Bitdoze opublikował 29 września 2026 obszerną recenzję EmDash CMS — 34 minuty czytania, pierwsza część serii pięciu artykułów. Autor sprawdził wersję 1.0.1 na Cloudflare Workers i na własnym serwerze z Node.js, a potem zestawił swoje wnioski z kwietniowymi opiniami krytyków. Poniżej najważniejsze punkty i to, jak zgadzają się z moim doświadczeniem z emdashcms.pl.
Stan projektu po pół roku
Recenzja podaje twarde liczby z września 2026: około 13 tys. gwiazdek na GitHubie, ponad 175 kontrybutorów, 126 tys. pobrań pakietu `emdash` miesięcznie z npm i około 37 wydań między 0.1.0 a 1.0.1. Autor docenia dojrzałość procesu wydawniczego: podpisane commity opiekunów, provenance w npm i atestacje SLSA.
Jako dowód skali przywołuje blog Cloudflare, przeniesiony na EmDash 12 sierpnia 2026: stałe 850 zapytań na sekundę, skoki ponad 5000, około 70% trafień w cache, P95 poniżej 500 ms. Od razu jednak dodaje ważne zastrzeżenie: to nie jest typowe wdrożenie. Blog Cloudflare działa na Postgresie przez Hyperdrive, z cache obiektów w KV i Workers Cache, a nie na D1, z którego korzysta większość stron.
Dwa rodzaje wtyczek
Recenzja dobrze tłumaczy coś, co łatwo przeoczyć: EmDash ma wtyczki natywne (działają w procesie strony z pełnym dostępem, dla zaufanego kodu) i wtyczki w sandboxie (z manifestem uprawnień, np. content:read, email:send). Izolacja jest wymuszana technicznie — na Cloudflare przez Dynamic Workers, na Node przez proces workerd — z twardymi limitami: 50 ms CPU, 128 MB pamięci, 30 s czasu działania.
Potwierdzam z praktyki: na emdashcms.pl obie oficjalne wtyczki (formularze i webhooki) działają natywnie, bo tak są skonfigurowane w starterze. Sandbox trzeba włączyć świadomie.
Kiedy EmDash, a kiedy nie
Autor przytacza listę z oficjalnej dokumentacji. EmDash ma sens, jeśli wszystkie cztery warunki są spełnione:
- strona jest zbudowana w Astro,
- redaktorzy potrzebują panelu w przeglądarce, a nie plików w repozytorium,
- chcesz mieć CMS i stronę w jednym wdrożeniu,
- zespół jest w stanie utrzymać bazę danych i storage mediów.
Werdykty dla poszczególnych grup: dla agencji „warunkowe tak”, dla deweloperów Astro „tak”, dla uciekinierów z WordPressa „warunkowo” (motyw i zachowanie wtyczek trzeba zbudować od nowa), a dla samotnego blogera — tylko jeśli potrzebuje panelu admina, planowania publikacji lub współredaktorów. W przeciwnym razie statyczne Astro z markdownem jest prostsze i tańsze.
Pułapki, które trafiły także mnie
Najcenniejsza część recenzji to lista „footgunów” — rzeczy, które bolą dopiero w produkcji. Kilka z nich przerobiłem na własnej skórze:
Migracje przy pierwszym zapytaniu. Bitdoze zaznacza, że w domyślnym trybie migracje bazy wykonują się automatycznie przy pierwszym requeście po deployu, i radzi sprawdzać je wcześniej przez npx emdash migrate --check. U mnie, przy aktualizacji o około 45 wydań, pierwsze wejście na stronę główną trwało 33 sekundy.
„Przypnij co najmniej 0.37”. Autor zaleca wersję co najmniej 0.37, bo wcześniejsze miały m.in. problem ze skanowaniem setek tysięcy wierszy D1 przy czyszczeniu mediów. emdashcms.pl działał do niedawna na… 0.0.3 — ^0.0.3 w package.json blokuje dokładnie tę jedną wersję i nigdy się sam nie zaktualizuje.
Workers Cache i nieaktualne strony. Recenzja opisuje, jak zalogowany redaktor może dostać z cache wersję strony dla anonimowego gościa, bo odpowiedzi bez jawnego Cache-Control są cache'owane heurystycznie. Rada: na własnych trasach zawsze ustawiać nagłówki jawnie. U mnie problem z cache był inny, ale z tej samej rodziny — mój edge cache ignorował query string, więc wyszukiwarka pokazywała każdemu wyniki pierwszego zapytania.
Backupy. Recenzja opisuje automatyczne snapshoty JSON i ostrzega, że przy publicznym buckecie R2 z ustawionym publicUrl dostępne są również pliki backupów. Dorzucę swoje: na Cloudflare wrangler d1 export nie działa dla bazy EmDasha, bo indeks wyszukiwania używa tabel FTS5. Przed deployem zostaje Time Travel w D1.
Klucz szyfrowania. EMDASH_ENCRYPTION_KEY trzeba trzymać poza backupem bazy (np. w menedżerze haseł). Przywrócenie bazy bez klucza oznacza, że ustawienia wtyczek z sekretami stają się nieczytelne.
Endpoint `/health` kłamie. Odpowiedź 200 dowodzi tylko, że Astro obsługuje zapytania — nie mówi nic o bazie, storage'u ani migracjach. Jako bramkę po deployu autor proponuje listę kontrolną: migracje, publiczna strona, logowanie do admina, upload mediów, publikacja szkicu, zaplanowane zadania.
Koszty
Recenzja zestawia trzy ścieżki: darmowy plan Workers (podstawowa strona, bez wtyczek w sandboxie, limit 5000 transformacji obrazów miesięcznie), płatny Workers (około 5 dolarów miesięcznie, z sandboxem — autor zaznacza, że cenę trzeba zweryfikować) oraz VPS za około 4–5 euro (pełna kontrola, ale backupy, aktualizacje i uptime są na twojej głowie).
Ważna uwaga, którą mogę potwierdzić liczbami: EmDash renderuje strony na serwerze, więc każde trafienie bez cache to zapytania do D1. W moim benchmarku właśnie te zapytania odpowiadały za większość czasu odpowiedzi. „Skaluje się do zera, więc jest za darmo” działa dla małego bloga, ale dla ruchliwej strony warto policzyć zapytania, a nie zakładać.
Werdykt recenzji
Bitdoze podsumowuje, że EmDash jest polecany zespołom pracującym w Astro, które chcą prawdziwego CMS-a i są gotowe utrzymywać bazę danych, ale nie jest jeszcze zamiennikiem WordPressa dla stron zależnych od wtyczek. Autor zaznacza, że to znacznie lepsza pozycja niż w kwietniu.
Do plusów zalicza nowatorski model bezpieczeństwa wtyczek, realny dowód skali, jedno wdrożenie dla strony i CMS-a, wbudowany MCP i przenośne adaptery bazy i storage'u. Do minusów: mały ekosystem, obowiązki operacyjne, ograniczenie do Astro, dojrzewający panel admina, breaking changes w serii 0.x i brak skonfigurowanej poczty na Workers (bez niej nie działają magic linki ani zaproszenia).
Mój komentarz
To najrzetelniejsza recenzja EmDasha, jaką czytałem — autor oddziela architekturę od marketingu i opisuje koszty operacyjne, o których premierowe artykuły milczą. Z perspektywy pół roku z emdashcms.pl podpisuję się pod głównym wnioskiem: EmDash to dobry CMS dla ludzi, którzy lubią Astro i nie boją się infrastruktury. Najwięcej problemów miałem nie z samym EmDashem, tylko z rzeczami dookoła: cache, backupem, wersjonowaniem i tym, co naprawdę jest wdrożone na produkcji.
Po lekturze dopisałem sobie jedno zadanie: recenzja wymienia trigger cron (* * * * *) jako potrzebny m.in. do zaplanowanych publikacji na Workers, a w konfiguracji emdashcms.pl go nie ma. Sprawdzę to, zanim zaplanuję pierwszy wpis.
Brak komentarzy