← Blog
Self-hosting11 min czytania

AFFiNE — Notion i Miro w jednym, na własnym serwerze

Dokumenty i tablica scalone w jedno płótno, dane na własnym dysku, wersja na własny serwer. Zanim jednak postawisz to w firmie, trzeba przeczytać trzy pliki licencyjne — bo dają trzy różne odpowiedzi na to samo pytanie.

Obietnica jest kusząca i sformułowana wprost już w opisie repozytorium: może być coś więcej niż Notion i Miro. Dokumenty, tablica bez granic i tabele w jednym narzędziu, z danymi na własnym dysku i możliwością postawienia całości na swoim serwerze.

Dla polskiej firmy, która co miesiąc płaci za Notiona i osobno za Miro, a przy okazji zastanawia się, gdzie właściwie leżą notatki z projektów klientów, to brzmi jak rozwiązanie dwóch problemów naraz.

Zabrałem się więc do sprawdzania i po drodze natrafiłem na coś, czego nie spodziewałem się w projekcie o siedemdziesięciu tysiącach gwiazdek: trzy dokumenty licencyjne w jednym repozytorium, dające trzy różne odpowiedzi na pytanie, czy wolno mi to uruchomić w firmie. Temu poświęcę najwięcej miejsca, bo przy narzędziu do samodzielnego hostowania to jest pytanie pierwsze, nie ostatnie.

Czym jest AFFiNE

Najpierw rzeczowo, bo produkt jest dobry i nie chcę, żeby to zginęło.

Kluczowy pomysł polega na tym, że dokumenty i tablica są scalone, a nie sąsiadują. Na płótnie bez granic można położyć dowolny blok: tekst, karteczkę, osadzoną stronę internetową, bazę danych z wieloma widokami, odnośnik do innej strony, figurę, a nawet slajdy. To nie jest edytor z dodaną tablicą ani tablica z polem tekstowym — to jedna przestrzeń, w której ten sam blok da się obejrzeć raz jako akapit dokumentu, raz jako element diagramu.

Reszta obrazu:

  • Podejście „najpierw lokalnie" — dane leżą na twoim dysku, a nie w chmurze, przy jednoczesnej synchronizacji i pracy równoczesnej w czasie rzeczywistym.
  • Klienty na wiele platform obok wersji przeglądarkowej.
  • Wbudowany asystent AI zamieniający konspekt na slajdy, artykuł na mapę myśli i notatki na plan zadań.
  • Osobny silnik edytora rozwijany jako niezależny projekt, na którym stoi całość — jeśli myślisz o budowaniu własnego narzędzia z blokami, warto o tym wiedzieć.

Stan projektu

72 426 gwiazdek, 5261 forków, historia od lipca 2022, commity z dnia powstania tego tekstu. Projekt żyje intensywnie: od początku sierpnia znalazłem sześćdziesiąt sześć commitów merytorycznych, a wśród nich takie, które wprost dotyczą samodzielnego hostowania — poprawka ustawiająca właściwy typ wdrożenia dla usług. Ktoś tej ścieżki pilnuje, a nie tylko o niej pisze.

728 otwartych zgłoszeń to liczba duża, ale przy tej skali i przy produkcie o takim zakresie funkcji nieodbiegająca od normy.

Które wydanie właściwie wziąć

Tu potrzebna jest uwaga, bo pierwsze spojrzenie na listę wydań może zmylić w drugą stronę niż zwykle — nie na „projekt martwy", ale na „wszystko świeże".

Gałąź domyślna nazywa się canary, a wydania sypią się codziennie — z ostatniego tygodnia mam po jednym na dzień. Tylko że to wszystko są wydania przedpremierowe. Ze stu ostatnich pozycji stabilnych jest osiemnaście, a najnowsza z nich to v0.27.4 z 18 sierpnia 2026.

Co więcej, stabilne wydania przychodzą falami: po v0.26.3 z 25 lutego 2026 nastąpiła pięciomiesięczna przerwa, a potem trzy wydania w ciągu tygodnia w lipcu. Praktyczny wniosek dla kogoś, kto to hostuje: pilnuj znaczników stabilnych i licz się z tym, że między nimi bywają długie okresy bez aktualizacji, mimo codziennego strumienia wydań rozwojowych. Wdrażanie canary na serwer, na którym pracuje zespół, to proszenie się o kłopoty.

Czego wymaga samodzielne hostowanie

Zanim przejdę do licencji, konkret techniczny, bo wpływa na koszt wdrożenia. Zajrzałem do przykładowej konfiguracji serwera i do schematu bazy, żeby nie zgadywać.

Serwer to aplikacja w Node z warstwą GraphQL i gniazdami sieciowymi do pracy równoczesnej. Potrzebuje PostgreSQL-a i Redisa, opcjonalnie serwera poczty wychodzącej. I tu detal, który potrafi zaskoczyć przy hostingu zarządzanym: schemat bazy wymaga rozszerzenia pgvector. Nie każda usługa zarządzanego PostgreSQL-a je udostępnia, a bez niego migracje nie przejdą — warto to sprawdzić przed wybraniem dostawcy bazy, nie po.

Druga rzecz jest ważniejsza i dotyczy obietnicy prywatności. Przykładowa konfiguracja pokazuje, że funkcje asystenta AI wymagają kluczy do zewnętrznych dostawców — w pliku wzorcowym wymienione są trzy różne usługi. Znaczy to, że model „dane zostają na twoim dysku" obowiązuje dla dokumentów i synchronizacji, ale nie dla tego, co wyślesz do asystenta. Włączając AI, wysyłasz treść notatek do zewnętrznego dostawcy, na własnym kluczu i własną odpowiedzialność.

Nie jest to zarzut — tak działa dziś każde narzędzie z asystentem, który nie chodzi lokalnie. Ale jeśli argumentem za wdrożeniem było „nasze dane nie wychodzą poza firmę", to funkcje AI trzeba z tego argumentu wyłączyć albo wyłączyć je same. Dobra wiadomość: skoro klucze podaje się osobno, ich niepodanie jest prostym i pewnym sposobem, by ta ścieżka pozostała zamknięta.

Trzy pliki, trzy odpowiedzi

A teraz część, dla której warto ten wpis przeczytać do końca. Przytaczam ustalenia po kolei, bo dopiero razem tworzą obraz.

Dokument pierwszy — główny plik licencji. Mówi on, że treść w katalogach zaplecza oraz w katalogu modułów natywnych podlega osobnej licencji zdefiniowanej w pliku wewnątrz katalogu serwera, komponenty zewnętrzne — swoim własnym licencjom, a wszystko poza tymi katalogami jest dostępne na licencji MIT. Innymi słowy: front na MIT, a serwer — czyli dokładnie to, co się hostuje — pod inną licencją.

Dokument drugi — ta osobna licencja serwera. Jest to licencja nazwana wydaniem korporacyjnym i jej treść jest jednoznaczna: oprogramowanie może być używane produkcyjnie tylko wtedy, gdy masz ważną subskrypcję wydania korporacyjnego na właściwą liczbę stanowisk. Modyfikowanie i publikowanie poprawek jest dozwolone, ale prawa do tych poprawek pozostają przy wydawcy, a korzystać z nich można również tylko w ramach subskrypcji. Kopiowanie i modyfikowanie na potrzeby rozwoju i testów nie wymaga subskrypcji. Kopiowanie, publikowanie, rozprowadzanie, udzielanie dalszych licencji i sprzedawanie — zabronione.

Dokument trzeci — zastrzeżenie wewnątrz tej samej licencji serwera. I tu robi się ciekawie, bo licencja sama się ogranicza: obowiązuje wyłącznie w tej części oprogramowania, która nie jest rozprowadzana jako wydanie społecznościowe. Wszystko, co jest rozprowadzane jako wydanie społecznościowe albo podawane do przeglądarki jako obraz, czcionka, arkusz stylów czy kod skompilowany do JavaScriptu, jest objęte licencją MPL 2.0.

I dokument czwarty, czyli plik README. Ten mówi rzecz najprostszą z możliwych: wydanie społecznościowe jest wersją obecnie dostępną i jest darmowe do samodzielnego hostowania na licencji MIT, a wydanie korporacyjne nie zostało jeszcze opublikowane.

Jak to czytać

Zestawmy to. Plik README twierdzi, że dzisiejsza wersja jest darmowa do hostowania na MIT i że wydanie korporacyjne jeszcze nie istnieje. Licencja serwera twierdzi, że produkcyjne użycie wymaga subskrypcji — ale sama zaznacza, że nie dotyczy tego, co rozprowadzane jest jako wydanie społecznościowe, i przypisuje takim częściom MPL 2.0, nie MIT. Główny plik licencji kieruje cały katalog serwera do tej licencji, bez rozróżniania, co jest wydaniem społecznościowym, a co nie.

Najbardziej prawdopodobna intencja jest moim zdaniem czytelna i życzliwa dla użytkownika: to, co dziś pobierasz, jest wydaniem społecznościowym, więc licencja korporacyjna cię nie dotyczy. Za taką wykładnią stoi nie tylko README, ale i całe zachowanie projektu — oficjalna dokumentacja samodzielnego hostowania, oficjalny obraz kontenera, przyciski wdrażające jednym kliknięciem u dwóch dostawców i commity naprawiające właśnie tę ścieżkę. Nikt nie utrzymuje z takim staraniem drogi, której zamierza zabronić.

Problem polega na tym, że tej wykładni nie da się wyprowadzić z samych plików licencyjnych. Żaden z nich nie mówi, które konkretnie pliki w repozytorium należą do wydania społecznościowego, a które nie — a cała konstrukcja opiera się dokładnie na tym rozróżnieniu. Dodatkowo dwa dokumenty podają dla tej samej treści dwie różne licencje: README mówi MIT, licencja serwera mówi MPL 2.0. To licencje o istotnie różnych skutkach, bo MPL nakłada obowiązki przy rozprowadzaniu zmodyfikowanych plików, których MIT nie zna.

Nie jest to wpis prawniczy i nie rozstrzygnę tego za nikogo. Powiem natomiast, co bym zrobił: przed wdrożeniem produkcyjnym w firmie poprosiłbym wydawcę o pisemne potwierdzenie, że obecna wersja jest wydaniem społecznościowym i pod jaką licencją, a odpowiedź zachowałbym w dokumentacji projektu. Jedna wiadomość, a zdejmuje z tematu całą niepewność. Do użytku prywatnego albo w środowisku rozwojowym i testowym pytanie w ogóle nie powstaje — licencja serwera zwalnia te przypadki wprost.

Jedna rzecz jest natomiast jasna niezależnie od wykładni i warto ją znać: rozprowadzanie własnej odmiany serwera jest zabronione. Jeżeli twój plan brzmiał „weźmiemy to, zmienimy i zaoferujemy klientom jako własne narzędzie", zderzy się on z tekstem licencji korporacyjnej wprost. Podobnie umowa dla współtwórców, którą trzeba podpisać przed pierwszym zgłoszeniem zmiany, przenosi prawa do wkładu na wydawcę — co jest spójne z modelem, ale bywa przedmiotem firmowej polityki.

Dlaczego mimo wszystko warto

Rozpisałem się o licencji, więc dla równowagi: to jest naprawdę dobry produkt i przy właściwych zastrzeżeniach bardzo wartościowy.

Model „najpierw lokalnie" ma dla polskiej firmy konkretną wartość wykraczającą poza wygodę. Notatki z projektów klientów, nazwiska, ustalenia handlowe — wszystko to zostaje na twoim dysku i twoim serwerze, a nie w cudzej chmurze poza Unią. To odejmuje z tematu cały rozdział rozważań o przekazywaniu danych do państw trzecich, który przy amerykańskich narzędziach do notatek wraca przy każdym audycie.

Scalenie dokumentów z tablicą jest zaś rozwiązaniem, którego naprawdę nie ma gdzie indziej w tej formie. Kto prowadził projekt w dwóch narzędziach — ustalenia w jednym, diagram w drugim — zna koszt tego rozdzielenia: dwa źródła prawdy, które rozchodzą się w drugim tygodniu.

Pułapki w jednym miejscu

  • Licencja serwera to nie MIT. Front i większość repozytorium tak, ale katalogi zaplecza i modułów natywnych podlegają osobnej licencji wydania korporacyjnego.
  • Trzy dokumenty dają trzy odpowiedzi. Przed wdrożeniem produkcyjnym poproś wydawcę o pisemne potwierdzenie i zachowaj je w dokumentacji projektu.
  • Rozwój i testy są jawnie zwolnione z wymogu subskrypcji — o ten przypadek nie trzeba pytać.
  • Rozprowadzanie własnej odmiany serwera jest zabronione wprost, niezależnie od tego, jak rozstrzygniesz resztę.
  • Nie wdrażaj gałęzi canary. Codzienne wydania to wydania przedpremierowe; szukaj znaczników stabilnych.
  • Stabilne wydania przychodzą falami, z przerwami sięgającymi pięciu miesięcy. Zaplanuj, co robisz w takim okresie z poprawkami bezpieczeństwa.
  • Umowa dla współtwórców przenosi prawa do wkładu na wydawcę. Jeśli twoja firma ma na to politykę, sprawdź ją przed pierwszym zgłoszeniem.
  • Baza wymaga rozszerzenia pgvector — sprawdź, czy twój dostawca zarządzanego PostgreSQL-a je udostępnia, bo bez niego migracje nie przejdą.
  • Asystent AI wysyła treść do zewnętrznych dostawców na twoich kluczach. Jeśli argumentem za wdrożeniem była prywatność, nie podawaj kluczy.
  • 728 otwartych zgłoszeń. Produkt o szerokim zakresie ma proporcjonalnie szeroką listę usterek.

Podsumowanie

AFFiNE jest jednym z najciekawszych otwartych narzędzi do pracy z wiedzą, jakie widziałem — i jednocześnie przypadkiem, w którym najważniejsza praca przed wdrożeniem nie polega na czytaniu dokumentacji technicznej, ale trzech plików licencyjnych.

  • Dokumenty i tablica naprawdę scalone — jedno płótno na bloki dowolnego rodzaju, w tym bazy z wieloma widokami i slajdy.
  • Dane na własnym dysku przy zachowaniu pracy równoczesnej w czasie rzeczywistym.
  • Oficjalna ścieżka samodzielnego hostowania, z obrazem kontenera i czynnie naprawianymi usterkami tej ścieżki.
  • Bardzo wysokie tempo rozwoju — codzienne wydania rozwojowe, sześćdziesiąt sześć commitów merytorycznych w ciągu miesiąca.
  • Osobny silnik edytora do wykorzystania we własnych projektach.
  • Licencja wymagająca decyzji, a nie przyjęcia założenia.

Na koniec o samej licencji, bo to jest tu podsumowanie właściwe. Repozytorium jest rozdzielone: część na MIT, część na licencji wydania korporacyjnego z wyłączeniem dla wydania społecznościowego, któremu ta sama licencja przypisuje MPL 2.0, przy README twierdzącym, że całość jest darmowa na MIT. GitHub raportuje przy tym repozytorium licencję jako nierozpoznaną i tym razem — inaczej niż w przypadku niektórych projektów, gdzie to tylko efekt dopisku — ma pełne prawo. Tego zestawu naprawdę nie da się sprowadzić do jednej nazwy.

Nie odbieram temu projektowi wartości; model open core jest legalny, powszechny i uczciwy, dopóki granica jest opisana. Tutaj granica jest opisana trzykrotnie i niespójnie, a to zupełnie inna sytuacja niż zła wola. Wnioskiem praktycznym nie jest więc „nie używaj", ale „ustal to na piśmie, zanim wdrożysz" — i traktuj tę jedną wiadomość do wydawcy jako część kosztu wdrożenia. Przy narzędziu, które ma przechowywać wiedzę twojej firmy na lata, to najtańsza inwestycja w całym projekcie.