Ever Gauzy — otwarty ERP, CRM i HRM z time trackingiem

Pytanie wraca u klientów regularnie i zawsze w tej samej formie: czy da się mieć jeden system zamiast pięciu abonamentów? Rejestracja czasu pracy w jednym narzędziu, faktury w drugim, projekty w trzecim, CRM w czwartym, wnioski o urlop w arkuszu. Każde z nich kosztuje za użytkownika, żadne nie rozmawia z pozostałymi, a raport wymagający danych z dwóch źródeł powstaje ręcznie.

Ever Gauzy (github.com/ever-co/ever-gauzy) jest odpowiedzią o bardzo dużym zasięgu — platformą łączącą ERP, CRM, kadry, rekrutację, zarządzanie projektami i monitorowanie czasu pracy w jednym systemie, z licencją otwartą jako opcją domyślną.

To jednak kategoria, w której obietnica open source bywa myląca, bo oszczędność na abonamentach zamienia się w rachunek za utrzymanie. Dlatego w tym wpisie dwie rzeczy stawiam przed opisem funkcji: co dokładnie trzeba uruchomić i co dokładnie mówi licencja.

Stan projektu

Dane z API GitHuba na 10 października 2026:

• 4382 gwiazdki i 878 forków, repozytorium założone 2 czerwca 2019 — siedem lat rozwoju,
• push w dniu pisania tego tekstu, a wersja 111.41.0 wyszła dwa dni wcześniej,
• tempo wydań jest przy tym nietypowe: 111.40.13, 111.40.14, 111.40.15 i 111.41.0 ukazały się w ciągu dwóch dni. To projekt wydający po kilka razy dziennie,
• 458 otwartych zgłoszeń, kod w TypeScripcie, rozmiar repozytorium 262 megabajty,
• rozwijany przez Ever Co. LTD jako część większej rodziny produktów tej firmy.

Aktywność jest tu poza dyskusją — po serii projektów, które w tej sesji odpadły z powodu zastoju, Gauzy wygląda jak przeciwieństwo tego problemu. Warto natomiast zwrócić uwagę, co ta aktywność oznacza w praktyce: przy kilku wydaniach dziennie „najnowsza wersja" nie jest punktem odniesienia, a obrazy Dockera budowane automatycznie z czoła gałęzi głównej to nie to samo co wydanie przetestowane.

Licencja: trzy poziomy i próg miliona dolarów

Interfejs GitHuba pokazuje przy tym projekcie AGPL-3.0 i jest to prawda, ale niepełna. Oprogramowanie jest dostępne na trzech licencjach, a plik licencyjny opisuje je precyzyjnie:

• Community Edition — AGPL-3.0, wariant domyślny. Obowiązuje wtedy, gdy nie masz podpisanej żadnej z pozostałych umów,
• Small Business — do wykupienia przez firmy, których roczny przychód nie przekracza miliona dolarów, i do użycia dla jednej posiadanej firmy,
• Enterprise — dla firm o przychodzie powyżej miliona dolarów, z użyciem dla nieograniczonej liczby posiadanych firm.

Różnica praktyczna jest opisana jednym zdaniem: przy licencji komercyjnej Twój kod źródłowy, wraz ze zmianami, pozostaje zamknięty. Przy Community Edition — nie, i to jest sedno decyzji.

Trzeba przy tym zrozumieć, co AGPL znaczy dokładnie w tym przypadku, bo to nie jest zwykłe copyleft. Sam plik licencyjny wylicza warunki i jeden z nich jest kluczowy: gdy zmodyfikowana wersja jest używana do świadczenia usługi przez sieć, kompletny kod źródłowy tej zmodyfikowanej wersji musi zostać udostępniony.

Przełóżmy to na naszą pracę. Wdrażamy Gauzy dla klienta, dopisujemy moduł pod jego proces, stawiamy to na serwerze i dajemy dostęp jego pracownikom. To jest świadczenie usługi przez sieć zmodyfikowaną wersją — a więc obowiązek udostępnienia kodu naszych zmian tym użytkownikom. Wyjścia są dwa: publikujemy modyfikacje na AGPL albo kupujemy licencję komercyjną w poziomie odpowiadającym przychodowi klienta.

Jest tu też opcja, którą warto znać i o której mało kto pamięta: projektom niekomercyjnym i otwartym Ever Co. oferuje bezpłatnie licencję Enterprise oraz darmowy hosting, po spełnieniu kryteriów opisanych w dokumentacji projektu. Jeśli klient jest fundacją albo stowarzyszeniem, to jest pierwsza rzecz do sprawdzenia.

Osobno — i to jest istotne przy wdrożeniach pod marką klienta — znaki towarowe. Ever® jest zarejestrowanym znakiem towarowym, Gauzy™ znakiem towarowym, a licencja mówi wprost, że wolno ich używać tylko za pisemną zgodą i nie wolno ich używać do promowania produktów konkurencyjnych. Licencja na kod nie jest licencją na nazwę.

Drobiazg porządkowy, na który natrafiłem: README odsyła do pliku LICENSE.md, którego w repozytorium nie ma. Faktyczne pliki to LICENSE z pełnym tekstem AGPL-3.0 oraz LICENSES.md z opisem trzech poziomów. Odnośnik jest martwy, treść jest — trzeba tylko wiedzieć, gdzie szukać.

Dziesięć składników infrastruktury

To jest sekcja, którą przeczytałbym pierwszą, gdybym rozważał to wdrożenie — i jednocześnie ta, której w opisach takich platform zwykle brakuje.

Konfiguracja demonstracyjna uruchamia trzy kontenery: API, interfejs webowy i bazę danych. Po niej łatwo wyrobić sobie fałszywe przekonanie, że to niewielki system.

Konfiguracja produkcyjna uruchamia natomiast dziesięć składników infrastruktury obok samej aplikacji:

• PostgreSQL — baza główna, oraz Pgweb jako klient webowy do niej,
• OpenSearch jako silnik wyszukiwania, wraz z OpenSearch Dashboards i Dejavu — dwoma osobnymi interfejsami do niego,
• MinIO — magazyn obiektów zgodny z S3,
• Jitsu — silnik zbierania danych, otwarty odpowiednik Segmenta,
• Redis — pamięć podręczna, używana także przez Jitsu,
• Cube — warstwa semantyczna obsługująca raporty, pulpity i analitykę,
• Zipkin — rozproszone śledzenie żądań.

Każdy z tych elementów jest uzasadniony funkcją, którą obsługuje, i żaden nie jest tam bez powodu. Ale trzeba to nazwać po imieniu: wdrożenie Gauzy to nie postawienie aplikacji, a postawienie i utrzymywanie małej platformy danych. To dziesięć rzeczy do monitorowania, dziesięć do aktualizowania i dziesięć, które mogą się zepsuć w sposób wymagający wiedzy o nich, a nie o Gauzy.

Autorzy sami zresztą zalecają Kubernetes zamiast Dockera Compose do obciążeń produkcyjnych — co jest dodatkowym sygnałem o skali przedsięwzięcia. Do tego dochodzi ostrzeżenie o budowaniu lokalnym, opisanym w dokumentacji jako proces skrajnie długi, bo buduje całą platformę.

Praktyczny wniosek: to jest wdrożenie dla klienta, który ma administratora albo płaci za utrzymanie. Argument „zaoszczędzimy na abonamentach" trzeba przeliczyć wraz z kosztem serwera zdolnego unieść ten zestaw i godzinami na jego pilnowanie.

Druga ścieżka, o której łatwo nie zauważyć

Powyższe dotyczy pełnej platformy — ale dokumentacja opisuje jeszcze jedną drogę i jest ona zakopana w środku README, choć dla większości klientów będzie właściwa. Gauzy Server to pojedyncza paczka zawierająca API, bazę SQLite (albo połączenie z zewnętrznym PostgreSQL-em) i serwowanie interfejsu, opisana wprost jako zalecana dla organizacji małych i średnich.

Do tego dochodzą dwie aplikacje desktopowe:

• Gauzy Desktop App — wszystko w jednym: interfejs, API i baza SQLite lokalnie, z możliwością podłączenia do zewnętrznej bazy albo do zewnętrznego API. Wariant do szybkiego wypróbowania albo do pracy w układzie klient-serwer bez przeglądarki,
• Gauzy Desktop Timer App — wyłącznie rejestracja czasu i aktywności, przeznaczona dla pracowników, których pozostałe funkcje platformy nie interesują.

To zmienia rachunek istotnie i warto o tym wiedzieć przed odrzuceniem całego pomysłu: między „dziesięć składników infrastruktury na Kubernetesie" a „nie da się" jest jeszcze jedna paczka serwerowa z SQLite albo pojedynczą bazą PostgreSQL. Cena to brak wyszukiwania pełnotekstowego, warstwy analitycznej i magazynu obiektów — czyli części raportów i funkcji pomocniczych. Dla firmy dziesięcioosobowej rozliczającej czas pracy to zwykle wymiana korzystna.

Sposoby wdrożenia

Przy pełnej platformie projekt dostarcza nietypowo dużo gotowych ścieżek: moduły Terraform i wykresy Helm w osobnych repozytoriach, gotowe konfiguracje Kubernetesa używane przez samych autorów, konfiguracje dla platformy aplikacyjnej DigitalOcean wraz z gotowym przepływem CI, wdrożenie na zwykłą instancję wirtualną przez SSH — również z gotowym przepływem — oraz projekt oparty na Pulumi, obsługujący klastry AWS EKS, ECS na EC2 i Fargate wraz z bazą PostgreSQL w wariancie bezserwerowym. Jest też wdrożenie jednym kliknięciem u zewnętrznego dostawcy.

Projekt Pulumi jest przy tym oznaczony jako praca w toku, a wykresy Helm i moduły Terraform żyją w osobnych repozytoriach — czyli przed wyborem tej ścieżki warto sprawdzić, kiedy były ostatnio ruszane.

Domyślne zabezpieczenie warte skopiowania

W instrukcji produkcyjnej jest fragment, który zasługuje na wyróżnienie i na przeniesienie do własnych projektów. Przed uruchomieniem trzeba ustawić cztery sekrety — do tokenów dostępu, odświeżania, weryfikacji oraz sesji — z zaleceniem wygenerowania ich poleceniem openssl rand -hex 64. A potem następuje zdanie, które czyni z tego realne zabezpieczenie:

API odmawia startu na dostarczonych, pustych albo domyślnych sekretach. Uzasadnienie jest podane wprost: wspólne wartości domyślne pozwalają każdemu podrobić tokeny uwierzytelniające i sesje.

Porównajmy to z tym, co spotyka się częściej: system startuje z sekretem changeme, wypisuje ostrzeżenie w logu, którego nikt nie czyta, i pracuje tak przez dwa lata. Odmowa startu zamienia problem z bezpieczeństwem w problem z wdrożeniem — a ten drugi zawsze zostaje rozwiązany, bo bez niego nic nie działa. To jest wzorzec, który warto stosować w każdym projekcie mającym sekret w konfiguracji.

Co właściwie dostajesz

Zakres jest szeroki i lepiej patrzeć na niego grupami niż na listę kilkudziesięciu pozycji:

• Kadry i czas pracy — rejestr pracowników i współpracowników wraz ze stawkami, wdrażanie nowych osób, karty czasu pracy, monitorowanie czasu i aktywności, wnioski o czas wolny z zatwierdzaniem, grafiki i terminy,
• Sprzedaż i relacje z klientami — kontakty z podziałem na klientów i szanse sprzedażowe, lejki sprzedażowe, oferty, kosztorysy,
• Finanse — fakturowanie, rozliczenia, płatności, zarządzanie przychodami i kosztami, wielowalutowość,
• Projekty — projekty i zadania, cele oraz wskaźniki z rezultatami kluczowymi,
• Rekrutacja — system śledzenia kandydatów wraz z rozmowami,
• Magazyn i wyposażenie — stany magazynowe oraz rejestr sprzętu z jego współdzieleniem,
• Struktura organizacji — obsługa wielu organizacji, działów i zespołów, dostawców, role i uprawnienia, strony publiczne organizacji i pracowników,
• Reszta — baza wiedzy, historia i szablony wiadomości, import i eksport danych, raporty i analityka, wiele języków, kilka motywów wizualnych.

Do tego bezgłowe API z publiczną dokumentacją oraz integracje z zewnętrznymi narzędziami do rejestracji czasu pracy, a osobno aplikacje desktopowe do liczenia czasu w dwóch wariantach interfejsu. Ten ostatni element jest w praktyce ważniejszy, niż wygląda na liście: rejestracja czasu bez aplikacji na komputerze pracownika jest rejestracją, o której pracownik zapomina.

Wersja hostowana przez producenta istnieje, ale dokumentacja opisuje ją jako wersję alfa w trybie testowym, z zaleceniem ostrożnego korzystania. To uczciwe i zarazem mówiące o dojrzałości produktu jako usługi.

Monitorowanie pracowników: decyzja, nie funkcja

Jedna rzecz z opisu aplikacji do rejestracji czasu wymaga osobnego akapitu, bo dokumentacja podaje ją jako zaletę, a w polskich realiach jest to zagadnienie kadrowo-prawne. Aplikacja liczy czas pracy wraz ze zrzutami ekranu i monitorowaniem aktywności.

To jest funkcja, którą wolno wdrożyć, ale nie wolno wdrożyć po cichu. Monitorowanie pracownika jest w Kodeksie pracy uregulowane osobno: wymaga określenia celu, zakresu i sposobu w regulaminie pracy albo obwieszczeniu, poinformowania pracowników przed wprowadzeniem, oznaczenia monitorowanych zasobów oraz zachowania zasady adekwatności — środek ma odpowiadać celowi. Zrzuty ekranu stanowisk pracy to przy tym forma daleko idąca, bo mogą objąć treści prywatne i dane osób trzecich, a same nagrania są danymi osobowymi z własnym okresem retencji.

Praktyczna reguła, którą stosowałbym przy takim wdrożeniu: rejestrację czasu włączamy, a zrzuty ekranu traktujemy jako osobną decyzję klienta, podjętą z jego działem kadr i prawnikiem, a nie jako domyślne ustawienie z instrukcji instalacji. To nie jest porada prawna — to wskazanie, że w tym miejscu konfiguracji technicznej kończy się nasza rola, a zaczyna cudza odpowiedzialność, o której klient musi wiedzieć, że ją podejmuje.

Stos technologiczny i co z niego wynika dla nas

Platforma stoi na TypeScripcie z NestJS na serwerze i Angularze na kliencie, w monorepozytorium zarządzanym przez Nx i Lernę, z interfejsem opartym na szablonie administracyjnym ngx-admin.

Dla naszego zespołu to jest informacja rozstrzygająca o zakresie usługi, jaką możemy sensownie zaoferować. Wdrożenie, konfiguracja, integracja przez API i utrzymanie — tak. Ale dopisanie modułu wymaga kompetencji w Angularze i NestJS, a nie w Laravelu i Reakcie. Przy wycenie prac programistycznych trzeba to powiedzieć klientowi wprost, zamiast odkrywać po podpisaniu umowy.

Warstwa dostępu do danych jest przy tym ciekawa i nieco niepokojąca: w stosie są jednocześnie TypeORM, MikroORM i Knex. Trzy narzędzia do tego samego w jednym projekcie zwykle znaczą migrację w toku — coś, o czym warto wiedzieć, zanim zaczniemy pisać kod dotykający bazy.

Podobnie ostrożnie traktowałbym obietnicę obsługi wielu baz danych. Dokumentacja wymienia SQLite, PostgreSQL, MySQL, MariaDB, CockroachDB, MS SQL, Oracle i MongoDB, ale z dopiskiem „z minimalnymi zmianami" — a przy zaleceniu produkcyjnym wskazującym PostgreSQL. Czytam to jako: PostgreSQL jest ścieżką przetestowaną, a reszta jest możliwa.

Pułapki

• AGPL-3.0 z klauzulą sieciową. Zmodyfikowana wersja świadcząca usługę przez sieć rodzi obowiązek udostępnienia kodu modyfikacji. Przy wdrożeniu z dopisanym modułem to jest decyzja, nie szczegół,
• Licencje komercyjne są rozdzielone progiem miliona dolarów przychodu, a cennik jest po stronie producenta — do wyceny projektu potrzebna jest rozmowa z nim,
• Znaki towarowe wymagają pisemnej zgody i nie wolno ich używać do promowania produktów konkurencyjnych,
• Dziesięć składników infrastruktury w pełnej konfiguracji produkcyjnej. Konfiguracja demonstracyjna z trzema kontenerami nie mówi prawdy o koszcie utrzymania,
• Monitorowanie ze zrzutami ekranu wymaga w Polsce zapisów w regulaminie pracy, poinformowania pracowników i oceny adekwatności,
• Autorzy zalecają Kubernetes do produkcji — czyli wdrożenie na jednym serwerze z Dockerem Compose jest ścieżką odradzaną,
• Kilka wydań dziennie i obrazy budowane z czoła gałęzi głównej. Przypnij konkretną wersję i nie aktualizuj automatycznie,
• 458 otwartych zgłoszeń i repozytorium ważące 262 megabajty,
• Trzy narzędzia dostępu do danych naraz — sygnał migracji w toku,
• Obsługa wielu baz „z minimalnymi zmianami" to nie to samo co obsługa przetestowana; produkcyjnie PostgreSQL,
• Angular i NestJS — dostosowanie kodu wymaga innych kompetencji niż nasz stos,
• Budowanie lokalne jest opisane jako skrajnie długie, więc do prób używa się obrazów gotowych,
• Wersja hostowana przez producenta jest w alfie, z zaleceniem ostrożności.

Gdzie to ma sens

• Firma usługowa rozliczająca się z czasu pracy. To jest scenariusz, pod który ta platforma została napisana: pracownicy i współpracownicy ze stawkami, karty czasu pracy, faktury wystawiane z tych kart. Agencja, studio, zespół rozproszony,
• Klient z wymogiem trzymania danych u siebie. Kadry, stawki i dane klientów w jednym systemie na własnym serwerze to argument, który przy niektórych branżach rozstrzyga o wyborze,
• Organizacje niekomercyjne. Bezpłatna licencja Enterprise wraz z hostingiem zmienia cały rachunek — warto sprawdzić kryteria przed rozważaniem czegokolwiek innego,
• Wdrożenie na czystej konfiguracji, bez modyfikacji kodu. Konfiguracja, integracje przez API i utrzymanie mieszczą się w Community Edition bez trudnych pytań licencyjnych — bo nie modyfikujemy programu,
• Punkt odniesienia przy projektowaniu własnego systemu. Lista modułów jest dobrą listą kontrolną tego, o co zapomnieliśmy zapytać klienta.

Gdzie bym tego nie proponował: małej firmie bez administratora — dziesięć składników infrastruktury zje oszczędność na abonamentach w pierwszym kwartale. I wszędzie tam, gdzie klient potrzebuje jednej funkcji: jeśli chodzi wyłącznie o rejestrację czasu albo wyłącznie o faktury, wdrożenie całej platformy ERP jest odpowiedzią na inne pytanie.

Podsumowanie

• Bardzo szeroki zakres w jednym systemie — kadry z czasem pracy, CRM, finanse, projekty, rekrutacja, magazyn,
• Projekt aktywny ponad przeciętną: siedem lat, push codziennie, po kilka wydań dziennie,
• Licencja ma trzy poziomy, a domyślnym jest AGPL-3.0 z klauzulą sieciową,
• Próg miliona dolarów przychodu rozdziela licencję dla małych firm od korporacyjnej,
• Licencja komercyjna zachowuje Twój kod zamknięty — to jest jej główna wartość,
• Projekty niekomercyjne i otwarte mogą dostać Enterprise oraz hosting bezpłatnie,
• Konfiguracja produkcyjna to dziesięć składników infrastruktury, nie jedna aplikacja,
• API odmawia startu na domyślnych sekretach — wzorzec do skopiowania,
• Gauzy Server to pojedyncza paczka zalecana dla małych i średnich organizacji — realna alternatywa dla pełnej platformy,
• Zrzuty ekranu w rejestracji czasu to decyzja kadrowo-prawna klienta, nie ustawienie domyślne,
• Angular i NestJS, więc dostosowywanie kodu to inne kompetencje niż nasze,
• Przypnij wersję i nie polegaj na obrazach z czoła gałęzi głównej,
• Znaki towarowe są chronione osobno od licencji na kod.

Licencja: Ever Gauzy jest udostępniony w trzech wariantach, a domyślnym — obowiązującym każdego, kto nie podpisał umowy komercyjnej — jest Community Edition na AGPL-3.0. To najsilniejszy copyleft w powszechnym użyciu i przy platformie biznesowej jego skutki są bardzo konkretne. Samo korzystanie z niezmodyfikowanego systemu nie rodzi obowiązków publikacyjnych, ale klauzula sieciowa obejmuje sytuację, w której zmodyfikowana wersja świadczy usługę przez sieć — czyli typowe wdrożenie u klienta z dopisanym modułem. Wtedy kod modyfikacji trzeba udostępnić użytkownikom tej usługi albo przejść na licencję odpłatną. Te są dwie i rozdziela je próg miliona dolarów rocznego przychodu: Small Business dla firm poniżej tego progu i jednej posiadanej spółki, Enterprise powyżej i dla nieograniczonej liczby spółek; w obu przypadkach kod klienta, wraz ze zmianami, pozostaje zamknięty. Ever Co. zastrzega przy tym wprost, że dysponuje prawami do wszystkich składników platformy i może według własnego uznania zezwalać na tworzenie zamkniętych modułów łączonych dynamicznie w czasie działania — co jest istotne, bo oznacza, że droga do rozszerzeń bez otwierania kodu istnieje, ale prowadzi przez zgodę producenta, nie przez samą licencję. Osobno i niezależnie od kodu chronione są znaki towarowe Ever® i Gauzy™: ich użycie wymaga pisemnej zgody i jest wykluczone w promocji produktów konkurencyjnych, więc wdrożenie pod marką klienta wymaga sprawdzenia, jak nazywamy to, co dostarczamy. Warto też odnotować gest w drugą stronę: projektom niekomercyjnym i otwartym producent oferuje licencję Enterprise oraz hosting bezpłatnie, po spełnieniu opublikowanych kryteriów — to realna ścieżka, o którą warto zapytać, zanim rozważy się cokolwiek innego.