Model: on-premise

EZD RP on-premise — instalacja we własnej infrastrukturze

On-premise: pełna kontrola nad infrastrukturą i konfiguracją EZD RP — kosztem zespołu IT i serwerów. Dla kogo ma sens, architektura referencyjna, ścieżka wdrożenia, koszty i ryzyka.

Stan na 2026-05-13 • Bazujemy na oficjalnych źródłach NASK / gov.pl

Wdrożenie on-premise oznacza pełną kontrolę nad infrastrukturą, konfiguracją i danymi EZD RP — kosztem konieczności utrzymania zespołu IT, serwerów i procedur operacyjnych (backup, monitoring, aktualizacje). Model preferowany w dużych jednostkach z złożonymi integracjami i restrykcyjną polityką bezpieczeństwa.

Kiedy on-premise jest najlepszy

  • Duża jednostka z własnym zespołem IT zdolnym utrzymać Kubernetes, bazy danych, monitoring
  • Złożone integracje z systemami dziedzinowymi wymagające pełnej kontroli nad API i kolejnością wywołań
  • Restrykcyjna polityka lokalizacji danych — np. wymóg przechowywania w serwerowni własnej (niektóre jednostki bezpieczeństwa, część szpitali wojewódzkich)
  • Plany rozwojowe wymagające customowych modułów lub bardzo specyficznych workflow
  • Skala — bardzo duże jednostki (>2000 użytkowników, miliony dokumentów rocznie) lepiej trzymają się w dedykowanej architekturze

Architektura referencyjna

Standardowa produkcyjna architektura EZD RP on-premise składa się z następujących warstw:

  1. Klaster Kubernetes (najczęściej RKE2) — minimum 3 węzły dla wysokiej dostępności (HA)
  2. Baza danych relacyjna — PostgreSQL lub MS SQL Server, najlepiej z replikacją
  3. Cache i kolejki — Redis (cache sesji, dane tymczasowe), RabbitMQ (komunikaty asynchroniczne)
  4. Repozytorium plików — NFS lub kompatybilny z S3 (np. MinIO) dla załączników i dokumentów
  5. Reverse proxy + SSL — nginx / HAProxy z certyfikatami (Let's Encrypt lub komercyjne)
  6. Backup — automatyczne kopie bazy + repozytorium z przetestowaną procedurą odtwarzania
  7. Monitoring — Prometheus + Grafana (lub równoważne), alerty na zdarzenia krytyczne
Jednowęzłowy Kubernetes — nie na produkcję
Oficjalne scenariusze NASK podkreślają, że jednowęzłowe środowisko Kubernetes nie jest zalecane produkcyjnie z uwagi na brak HA i odporności na awarię węzła. Minimum: 3 węzły (control plane + worker).

Etapy wdrożenia on-premise

  1. Audyt infrastruktury — co mamy, czego brakuje, plan zakupów
  2. Zakup / przygotowanie sprzętu — serwery, licencje OS, zasilanie, sieć
  3. Instalacja i konfiguracja warstwy bazowej — OS, sieć, storage, cluster Kubernetes
  4. Wdrożenie EZD RP — instalacja Helm chart / manifestów, konfiguracja secretów, certyfikatów
  5. Backup i monitoring — przed startem produkcyjnym, z testem odtwarzania
  6. Konfiguracja systemu — struktura, JRWA, role (jak w SaaS)
  7. Integracje — KSeF, e-Doręczenia, ePUAP, systemy dziedzinowe
  8. Szkolenia + start produkcyjny

Koszty on-premise (orientacyjnie)

PozycjaKoszt jednorazowyKoszt roczny
Sprzęt serwerowy (3-5 węzłów + storage)60-200 tys. złAmortyzacja 5 lat
Licencje OS / hypervisoraZmienneSubskrypcja
Wdrożenie warstwy bazowej (DevOps)30-80 tys. zł
Wdrożenie EZD RP (audyt + konfiguracja)40-150 tys. zł
Wsparcie / utrzymanie (zewn.)30-100 tys. zł
Zespół wewnętrzny (1-2 etaty IT)150-300 tys. zł

Łącznie pierwszy rok: 250-700 tys. zł zależnie od skali. Lata kolejne: 200-450 tys. zł rocznie. Porównanie z SaaS — sensowne dopiero przy dużej skali (>500 użytkowników) lub gdy organizacja już ma zespół IT.

Najczęstsze ryzyka on-premise

Co najczęściej idzie nie tak
  • Brak kompetencji Kubernetes po stronie wewnętrznej — uzależnienie od jednego dostawcy zewnętrznego
  • Pominięcie testu odtwarzania backup'ów — odkrycie problemu dopiero w awarii
  • Brak monitoring'u — incydenty wykrywane przez użytkowników, nie przez zespół IT
  • Próba uruchomienia jednowęzłowego K8s 'na próbę' i pozostawienie tego stanu
  • Niedoszacowanie kosztów utrzymania (po pierwszych 12 miesiącach często okazuje się, że SaaS byłby tańszy)
Źródła oficjalne
Konsultacja architektury on-premise

Pomożemy zaprojektować architekturę dopasowaną do skali, polityki bezpieczeństwa i kompetencji Waszego zespołu.

Umów konsultację

Najczęstsze pytania

Czy musimy mieć własną serwerownię?

Nie — można wynająć kolokację u operatora data center albo uruchomić w chmurze prywatnej (np. dedykowane VM-y u operatora). Kluczowe jest to, że klaster i konfiguracja są pod Waszą kontrolą.

Ile osób potrzebujemy do utrzymania?

Dla średniego wdrożenia: 1-2 osoby na stałe (DevOps + administrator EZD RP). Dla dużych — 3-5 osób w zespole. Często część kompetencji outsource'uje się do firm wsparcia.

Czy on-premise wyklucza KSeF i e-Doręczenia?

Nie — wszystkie standardowe integracje (KSeF, e-Doręczenia, ePUAP) działają identycznie jak w SaaS. Konfiguracja po stronie EZD RP jest taka sama.

Czytaj dalej

Wybór modelu
Modele wdrożenia EZD RP — SaaS, on-premise, Private SaaS
Trzy modele uruchomienia EZD RP — porównanie kosztów, czasu wdrożenia, możliwości integracji, zakresu kontroli i typowych ryzyk. Dla kogo SaaS, dla kogo on-premise, kiedy Private SaaS.
Infrastruktura
Wymagania sprzętowe EZD RP — Kubernetes, bazy, repozytoria
Komponenty wymagane do produkcyjnego uruchomienia EZD RP: klaster Kubernetes (RKE2), PostgreSQL/MS SQL, Redis, RabbitMQ, NFS/MinIO, backup. Minimalne, rekomendowane i konkretne konfiguracje dla 3 skal jednostek.
Model: SaaS
EZD RP SaaS — chmura zarządzana dla administracji
Model SaaS EZD RP — chmura zarządzana w ramach KPO. Dla kogo, jak uzyskać dostęp, jakie ma ograniczenia, co po stronie jednostki, a co po stronie dostawcy. Czas startu, koszty, SLA, odpowiedzialność za dane.