Dokploy, własny PaaS oparty na Docker Swarm

Dokploy, własny PaaS oparty na Docker Swarm

Dokploy instaluje na Twoim serwerze panel, który buduje aplikacje z repozytorium Gita albo z obrazu kontenera, wystawia je przez Traefika i wystawia certyfikaty. Bieżące wydanie to 0.30.2, opublikowane 18 sierpnia 2026 roku. Kod jest na Apache 2.0, poza katalogami o nazwie proprietary, które mają osobną licencję zabraniającą użycia produkcyjnego bez umowy handlowej.

Co instalator stawia na serwerze

Instalacja to jedno polecenie pobierające install.sh z domeny producenta, ale ten skrypt robi więcej, niż sugeruje jego długość. Zanim cokolwiek uruchomi, sprawdza, czy działasz jako root, czy system to Linux, czy nie jesteś wewnątrz kontenera oraz czy porty 80, 443 i 3000 są wolne. Przy zajętym którymkolwiek z tych portów kończy pracę błędem, zamiast próbować obejść problem.

Następnie instaluje Dockera w wersji przypiętej na 28.5.0 i na dystrybucjach z apt zakłada blokadę apt-mark hold na pakiety docker-ce, docker-ce-cli i docker-ce-rootless-extras. To decyzja producenta za Ciebie: Twój serwer przestaje dostawać aktualizacje Dockera z repozytorium systemowego, dopóki sam tej blokady nie zdejmiesz. Przy audycie bezpieczeństwa trzeba o tym pamiętać.

Potem skrypt wywołuje docker swarm leave --force, inicjuje nowy rój, tworzy sieć nakładkową dokploy-network i katalog /etc/dokploy z prawami 777. Adres rozgłoszeniowy roju wybiera z pierwszego prywatnego adresu na interfejsie spoza docker, br- i veth, a przy braku takiego adresu pyta o publiczny adres serwisy zewnętrzne w rodzaju ifconfig.io i icanhazip.com. Hasło do bazy i sekret uwierzytelniania trafiają do sekretów Dockera, nie do zmiennych środowiskowych.

# rdzen instalacji: baza, panel i proxy jako trzy osobne byty
docker service create \
  --name dokploy-postgres \
  --constraint 'node.role==manager' \
  --network dokploy-network \
  --env POSTGRES_USER=dokploy \
  --env POSTGRES_DB=dokploy \
  --secret source=dokploy_postgres_password,target=/run/secrets/postgres_password \
  --env POSTGRES_PASSWORD_FILE=/run/secrets/postgres_password \
  --mount type=volume,source=dokploy-postgres,target=/var/lib/postgresql/data \
  postgres:16

docker service create \
  --name dokploy \
  --replicas 1 \
  --network dokploy-network \
  --mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock \
  --mount type=bind,source=/etc/dokploy,target=/etc/dokploy \
  --publish published=3000,target=3000,mode=host \
  --update-parallelism 1 \
  --update-order stop-first \
  --constraint 'node.role == manager' \
  dokploy/dokploy:v0.30.2

# proxy startuje jako zwykly kontener, nie jako usluga roju
docker run -d --name dokploy-traefik --restart always \
  --network dokploy-network \
  -v /etc/dokploy/traefik/traefik.yml:/etc/traefik/traefik.yml \
  -v /etc/dokploy/traefik/dynamic:/etc/dokploy/traefik/dynamic \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -p 80:80/tcp -p 443:443/tcp -p 443:443/udp \
  traefik:v3.6.7

Zwróć uwagę na jeden szczegół z tego listingu: kontener panelu dostaje gniazdo /var/run/docker.sock w trybie do zapisu. Kto ma uprawnienia administratora w panelu, ma faktycznie roota na maszynie. To nie jest wada Dokploya, tylko cecha całej tej kategorii narzędzi, ale warto podejmować decyzje kadrowe ze świadomością tego faktu.

Licencja: Apache 2.0 i katalog proprietary

Tu jest najważniejsza rzecz w całym artykule, więc sprawdziłem ją z trzech stron.

Źródło pierwsze to plik licencyjny w repozytorium. Nazywa się LICENSE.MD, wielkimi literami razem z rozszerzeniem, więc narzędzia odpytujące o LICENSE albo LICENSE.md dostaną 404 i mogą uznać, że licencji nie ma. Jego treść dzieli repozytorium na dwie części. Wszystko, co leży w katalogu o nazwie /proprietary, podlega licencji z pliku LICENSE_PROPRIETARY.md. Cała reszta jest na Apache License 2.0.

Plik LICENSE_PROPRIETARY.md zawiera Dokploy Source Available License w wersji 1.0. Jej sedno: tego kodu wolno używać produkcyjnie tylko wtedy, gdy Ty lub podmiot, który reprezentujesz, zawarliście ważną umowę handlową z Dokploy i jej przestrzegacie. Wolno modyfikować i publikować łatki, ale prawa do tych modyfikacji zostają przy Dokploy, a korzystać z nich można wyłącznie posiadając tę licencję. Kopiowanie i modyfikowanie na potrzeby rozwoju i testów jest dozwolone bez subskrypcji. Kopiowanie, łączenie, publikowanie, rozpowszechnianie, sublicencjonowanie i sprzedaż są zabronione.

Źródło drugie to pola w rejestrze pakietów. Samej platformy w npm nie ma, bo rozprowadza się ją jako obraz kontenera. Są za to trzy pakiety pomocnicze i każdy deklaruje inną licencję: @dokploy/cli podaje MIT, @dokploy/sdk podaje ISC, @dokploy/mcp podaje Apache-2.0.

Źródło trzecie to zawartość opublikowanych paczek. Rozpakowałem wszystkie trzy. Każda zawiera prawdziwy skompilowany kod, odpowiednio w katalogach dist i build, więc żadna nie jest atrapą. Każda zawiera też plik licencyjny. I tu wychodzi rozjazd: @dokploy/sdk ma w package.json pole "license": "ISC", ale w paczce leży plik LICENSE z pełnym tekstem licencji MIT i nagłówkiem „Copyright (c) 2026 Dokploy”. Pole i plik mówią co innego. ISC jest domyślną wartością wstawianą przez npm przy braku deklaracji, więc najprawdopodobniej nikt tego pola nie ustawił, a plik jest tym, co obowiązuje. Jeśli prowadzisz listę licencji zależności, wpisz obie wartości z adnotacją.

Teraz konkret, który interesuje agencje. Katalogi proprietary istnieją i mają nazwane zawartości. Jest ich co najmniej dwa: apps/dokploy/server/api/routers/proprietary oraz packages/server/src/services/proprietary. Pod tymi ścieżkami leżą moduły license-key, sso, scim, audit-log, custom-role, forward-auth i whitelabeling.

Wniosek jest zaskakująco korzystny dla agencji i wart wyraźnego zapisania. Uruchamianie Dokploya dla klientów, hostowanie na nim cudzych aplikacji i pobieranie za to pieniędzy nie jest zabronione, bo rdzeń jest na Apache 2.0 bez klauzuli usługowej. To, czego nie wolno używać produkcyjnie bez umowy z Dokploy, to logowanie jednokrotne, SCIM, dziennik audytu, role o drobnej ziarnistości, uwierzytelnianie pośredniczące i etykietowanie własną marką. Klucz licencyjny sprawdzany jest przez punkty licenseKey.activate, licenseKey.validate i licenseKey.haveValidLicenseKey, a użytkownik ma w bazie flagę enableEnterpriseFeatures.

Dwa zastrzeżenia. Licencja mówi „jeśli taki katalog istnieje”, więc jego zawartość może rosnąć między wydaniami i przy każdej aktualizacji trzeba sprawdzić, czy funkcja, na której polegasz, nie przeniosła się za bramkę. Interfejs GitHuba raportuje dla tego repozytorium NOASSERTION i nazwę „Other”, więc automat zbierający metadane nie powie Ci nic sensownego. To sytuacja odwrotna niż w Coolify, gdzie jeden plik Apache 2.0 obejmuje całość i nie ma żadnego katalogu wydzielonego dla klientów komercyjnych.

Wersja, rytm wydań i pakiety npm

Wydanie 0.30.2 trafiło do npm 18 sierpnia 2026 roku o 21:42 UTC, a wpis w kanale wydań na GitHubie ma znacznik modyfikacji z 20 sierpnia, czyli notatki poprawiono po publikacji. Kanał wydań to znaczniki modyfikacji, nie daty premiery, i tak je tu czytam.

Rytm jest gęsty. Dziesięć wydań widocznych w kanale rozkłada się między 7 lipca a 20 sierpnia 2026 roku, przy czym trzy z nich, 0.29.8, 0.29.9 i 0.29.10, mają ten sam znacznik z 7 lipca. Dalej: 0.29.11 z 9 lipca, 0.29.12 z 13 lipca, 0.29.13 z 21 lipca, 0.29.14 z 6 sierpnia, 0.30.0 z 14 sierpnia, 0.30.1 z 18 sierpnia. Wersja główna wciąż zaczyna się od zera, co przy tym tempie oznacza, że zmiany łamiące zgodność mieszczą się w wydaniu poprawkowym.

W samym repozytorium jest rozjazd zakresów, który ugryzie Cię przy pierwszej próbie budowania ze źródeł. Główny package.json wymaga w polu engines Node w wersji ^24.4.0 i pnpm >=9.12.0, ale pakiety @dokploy/api i @dokploy/schedules wymagają pnpm >=10.22.0. Pole packageManager w korzeniu ustawia pnpm@10.22.0, więc realnym minimum jest to wyższe. Zakres z korzenia jest po prostu nieaktualny.

Uwaga na pakiety npm, bo jeden z nich nie pochodzi od projektu.

Nieoznaczony zakresem pakiet dokploy to wygenerowany przez Speakeasy klient trzeciej strony, ostatnio publikowany 21 października 2025 roku, z jedną zależnością zod w zakresie ^3.20.0 i bez pola license. Adres repozytorium z jego metadanych przekierowuje dziś na inne konto, LukasParke/Dokploy-ts-sdk. Nie jest to pakiet producenta i nie należy go instalować w przekonaniu, że nim jest.

Osobna pułapka przy czytaniu zależności: nie przypisuj rdzeniowi tego, co ciągną moduły chmurowe. Pakiet @dokploy/api zależy od inngest w wersji 3.40.1 i od redis 4.7.0, a @dokploy/schedules od bullmq 5.67.3 i ioredis 5.4.1. Standardowa instalacja z install.sh nie uruchamia ani Redisa, ani tych dwóch usług. Rdzeń panelu, czyli @dokploy/server, w ogóle nie ma pola license w swoim package.json, ale nie jest publikowany w npm, więc obowiązuje go licencja repozytorium.

Traefik w środku i domyślna konfiguracja

Odpowiedź na pytanie o warstwę pośredniczącą brzmi: Traefik, nie Caddy. Konfiguracja generowana jest z kodu, nie z szablonu tekstowego, więc można ją przeczytać dokładnie.

Zaczynając od wersji obrazu: mamy dwie różne liczby u producenta. Skrypt install.sh serwowany z dokploy.com uruchamia traefik:v3.6.7, a stała TRAEFIK_VERSION w kodzie wydania 0.30.2 ma domyślną wartość 3.6.25 i można ją nadpisać zmienną środowiskową o tej samej nazwie. Świeża instalacja i ponowna inicjalizacja proxy z panelu mogą więc postawić inną wersję Traefika. Podaję obie i zaznaczam rozbieżność.

# /etc/dokploy/traefik/traefik.yml, tak jak generuje go wydanie 0.30.2
global:
  sendAnonymousUsage: false
providers:
  swarm:
    exposedByDefault: false
    watch: true
  docker:
    exposedByDefault: false
    watch: true
    network: dokploy-network
  file:
    directory: /etc/dokploy/traefik/dynamic
    watch: true
entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"
    http3:
      advertisedPort: 443
    http:
      tls:
        certResolver: letsencrypt
api:
  insecure: true
certificatesResolvers:
  letsencrypt:
    acme:
      email: test@localhost.com
      storage: /etc/dokploy/traefik/dynamic/acme.json
      httpChallenge:
        entryPoint: web

Trzy rzeczy z tego pliku wymagają Twojej reakcji po instalacji. api.insecure ustawione na true włącza interfejs programistyczny Traefika bez uwierzytelniania; port 8080 nie jest domyślnie publikowany, ale przełącznik w panelu potrafi go wystawić i wtedy dostęp do niego ma każdy. Adres pocztowy w konfiguracji ACME to test@localhost.com, czyli wartość zastępcza, więc nie dostaniesz ostrzeżeń o wygasających certyfikatach. Wyzwanie jest wyłącznie typu HTTP, co oznacza brak certyfikatów wieloznacznych z tego rozwiązywacza bez dodatkowej konfiguracji.

Anonimowa telemetria Traefika jest wyłączona, co jest dobrą decyzją domyślną i rzadko spotykaną.

Wiele serwerów, Swarm i pojedynczy punkt awarii

Dokploy stoi na Docker Swarm, a nie na zwykłym Dockerze, i to ma konsekwencje w obie strony.

Po stronie plusów: dodanie kolejnej maszyny jest przewidziane w produkcie, nie doklejone. W bazie jest tabela server z polami ipAddress, port, username domyślnie root, sshKeyId, serverType w wartościach deploy albo build, buildsConcurrency domyślnie 1 oraz enableDockerCleanup domyślnie wyłączone. Konfiguracja metryk siedzi w kolumnie metricsConfig typu jsonb, z polami refreshRate, port, token, retentionDays, cronJob i progami thresholds.cpu oraz thresholds.memory. Interfejs udostępnia server.setup, server.validate, cluster.addWorker, cluster.addManager, cluster.getNodes i swarm.getNodeApps. Osobny typ build pozwala odsunąć budowanie obrazów od maszyn obsługujących ruch, co przy jednym serwerze bywa różnicą między działającą a zamulającą się stroną.

Po stronie minusów, i to jest rzecz do napisania wprost: panel nie jest wysoko dostępny. Usługa dokploy startuje z --replicas 1 i ograniczeniem node.role == manager, aktualizuje się w trybie stop-first, a jej baza to pojedyncza usługa dokploy-postgres z wolumenem lokalnym na tej samej maszynie zarządzającej. Jeśli ten węzeł padnie, tracisz panel i bazę stanu razem z nim. Aplikacje rozłożone na węzłach roboczych będą działać dalej, dopóki rój utrzymuje kworum menedżerów, ale nie wdrożysz nowej wersji, nie odczytasz logów przez panel i nie zmienisz domeny.

Jeśli szukasz platformy, w której to dostawca dba o wysoką dostępność warstwy sterowania, patrz raczej na Render, Railway albo Fly.io. Dokploy daje Ci kontrolę i rachunek za serwer, ale odpowiedzialność za ciągłość panelu zostaje po Twojej stronie.

Kopie zapasowe i odtwarzanie po awarii

Wbudowane kopie zapasowe baz danych są konkretne i mają czytelny model. Tabela backup ma pola schedule z wyrażeniem cron, enabled, database, prefix, serviceName, destinationId, keepLatestCount, includeEncryptionKey domyślnie włączone oraz backupType w wartościach database albo compose. Cel kopii opisuje tabela destination z polami accessKey, secretAccessKey, bucket, region, endpoint, provider i additionalFlags, czyli dowolny magazyn zgodny z S3.

Wyliczenie databaseType obejmuje postgres, mariadb, mysql, mongo, libsql oraz web-server. Dwie obserwacje z tej listy. Wartość web-server to kopia bazy samego Dokploya, dostępna też ręcznie przez backup.manualBackupWebServer, więc stan panelu można wywieźć poza serwer. Redisa na tej liście nie ma, mimo że Dokploy potrafi go tworzyć i zarządzać nim; dla wolumenów istnieje osobny mechanizm z punktami volumeBackups.create i volumeBackups.runManually.

Czego kopia bazy nie obejmuje, jest równie ważne. Cała warstwa plików leży w /etc/dokploy i wypada poza tym mechanizmem. Znajdziesz tam podkatalogi traefik, traefik/dynamic, traefik/dynamic/certificates, logs, applications, compose, ssh, monitoring, registry, schedules, volume-backups, volume-backup-lock i patch-repos. Plik acme.json z certyfikatami też tam jest.

# co naprawde trzeba zabrac z serwera, zeby odtworzyc calosc
tar czf dokploy-etc-$(date +%F).tar.gz /etc/dokploy

# zrzut bazy panelu wprost z uslugi roju, bez pomocy panelu
CID=$(docker ps -q -f name=dokploy-postgres)
docker exec "$CID" sh -c \
  'pg_dump -U dokploy -d dokploy -Fc -f /tmp/dokploy.dump'
docker cp "$CID":/tmp/dokploy.dump ./dokploy.dump

# odtworzenie na czystej instalacji: format custom idzie przez pg_restore
docker exec -i "$CID" pg_restore -U dokploy -d dokploy --clean --if-exists \
  < ./dokploy.dump

Te trzy polecenia nie są funkcją produktu, tylko czymś, co musisz sobie zorganizować sam. Nazwy w nich są prawdziwe: usługa nazywa się dokploy-postgres, użytkownik i baza to dokploy, hasło leży w sekrecie Dockera zamontowanym pod /run/secrets/postgres_password. Jeśli chcesz zrozumieć różnicę między formatem custom a zwykłym zrzutem tekstowym, zajrzyj do artykułu o PostgreSQL, bo w trakcie awarii to zła pora na naukę.

Rachunek i porównanie z alternatywami

Wariant chmurowy producenta ma cennik renderowany po stronie serwera, więc dało się go odczytać bez przeglądarki. Plan Hobby kosztuje 4,50 dolara miesięcznie za serwer, obejmuje jeden serwer, jedną organizację, jednego użytkownika, dwa środowiska, jedną kopię wolumenu na aplikację, jedną kopię na bazę i jedno zadanie cykliczne na aplikację, ze wsparciem na Discordzie. Plan Startup startuje od 15 dolarów miesięcznie, obejmuje trzy serwery, trzy organizacje, nieograniczoną liczbę użytkowników, środowisk, kopii i zadań, podstawowe role Admin i Developer, dwuskładnikowe uwierzytelnianie oraz wsparcie pocztą i czatem. Kolejne serwery kosztują 4,50 dolara miesięcznie w obu planach. Plan Enterprise ma dwa warianty dostarczenia, chmurowy i na własnej infrastrukturze, i wycenia się przez kontakt z handlowcami. Istnieje też plan Agency wyłącznie na zapytanie.

Sprawdziłem arytmetykę tej drabinki, bo nie jest oczywista. Trzy serwery w planie Hobby to 13,50 dolara, a plan Startup z tymi samymi trzema serwerami kosztuje 15,00. Przy czterech serwerach Hobby wychodzi 18,00, a Startup 19,50. Za wyższy plan płacisz więc za zniesienie limitów, a nie za moc obliczeniową, i przy jednoosobowym użyciu Hobby zostaje tańszy niezależnie od liczby maszyn. Przełącznik rozliczenia rocznego jest opisany jako „Yearly (20% discount)”, ale kwoty roczne nie renderują się bez JavaScriptu. Z podanych 20 procent wychodzi 43,20 dolara rocznie dla Hobby i 144 dolary dla Startup, przy czym to mój rachunek, a nie liczba wydrukowana przez producenta. Odpowiedzi w sekcji pytań i odpowiedzi na tej stronie, w tym na pytanie „Do I need to provide my own server?”, także nie renderują się bez JavaScriptu, więc ich nie cytuję.

Teraz uczciwy rachunek za samodzielne hostowanie, z jawnymi założeniami. Załóżmy serwer o dwóch rdzeniach i 4 GB pamięci za 8 dolarów miesięcznie; to założenie, sprawdź u swojego dostawcy. Załóżmy dwie godziny miesięcznie na aktualizacje systemu, przeglądanie logów, sprzątanie po Dockerze i próbne odtworzenie kopii, wyceniane na 50 dolarów za godzinę; to również założenie i u Ciebie może być zerowe albo trzykrotnie wyższe.

Wniosek z tej tabeli jest taki, że samodzielne hostowanie nie jest darmowe, tylko przenosi koszt z faktury na Twój kalendarz. Piętnaście dolarów miesięcznie kupuje utrzymanie panelu, nie utrzymanie Twoich aplikacji, bo maszyny robocze zostają Twoje w obu wariantach.

Wobec konkurencji: Coolify jest najbliższym odpowiednikiem i różnice są konkretne, nie kosmetyczne. Coolify ma jednolitą licencję Apache 2.0 bez katalogu wydzielonego dla klientów komercyjnych, a jego wariant chmurowy kosztuje 5 dolarów miesięcznie za dwa serwery i 3 dolary za każdy kolejny. Dokploy ma bramkę licencyjną na funkcjach korporacyjnych, ale w zamian ma rój Dockera z pierwszorzędnym dodawaniem węzłów zarządzających i roboczych. Wybierając między nimi, wybierasz między prostszą licencją a wbudowanym klastrem.

Typowe błędy

Pierwszy to uruchomienie instalatora na maszynie, na której już działa rój Dockera. Skrypt wywołuje docker swarm leave --force bez pytania, a to niszczy istniejący klaster wraz z definicjami usług.

Drugi to npm install dokploy w przekonaniu, że instaluje się oficjalny klient. Ten pakiet pochodzi od osoby trzeciej, stoi na wersji 0.1.3 od października 2025 roku i nie ma pola licencji. Oficjalne pakiety mają zakres @dokploy.

Trzeci to używanie funkcji z katalogów proprietary na produkcji bez umowy z producentem. Logowanie jednokrotne, SCIM, dziennik audytu, drobnoziarniste role i etykietowanie własną marką są dostępne w kodzie i technicznie działają po aktywacji klucza, ale licencja wiąże użycie produkcyjne z umową handlową.

Czwarty to traktowanie zaplanowanej kopii bazy jako kopii całości. Poza tym mechanizmem zostaje cały katalog /etc/dokploy, w tym acme.json, klucze SSH do serwerów zdalnych i wygenerowane pliki Compose.

Piąty to założenie, że dodanie węzła roboczego czyni panel odpornym na awarię. Panel i jego baza są przypięte do węzła zarządzającego i mają po jednej replice.

Szósty to pozostawienie adresu test@localhost.com w konfiguracji ACME i włączonego api.insecure. Pierwsze odbiera Ci ostrzeżenia o wygasających certyfikatach, drugie otwiera interfejs Traefika, jeśli kiedykolwiek wystawisz port 8080.

Siódmy to rozdawanie kont administratora w panelu osobom, którym nie dałbyś roota na serwerze. Panel ma zamontowane gniazdo Dockera do zapisu, więc to jest dokładnie ten sam poziom dostępu.

Ósmy to przypinanie się do wersji Traefika z jednego źródła. Instalator i kod wydania podają dwie różne wersje, więc sprawdź, co faktycznie działa, poleceniem docker inspect dokploy-traefik.

FAQ

Czy wolno używać Dokploya komercyjnie, hostując aplikacje klientów?

Tak. Rdzeń jest na Apache 2.0, która nie zabrania oferowania produktu jako usługi ani pobierania za to opłat. Ograniczenie dotyczy tylko kodu z katalogów proprietary, czyli logowania jednokrotnego, SCIM, dziennika audytu, drobnoziarnistych ról, uwierzytelniania pośredniczącego i etykietowania własną marką. Ich użycie produkcyjne wymaga ważnej umowy z Dokploy Technology.

Czym Dokploy różni się od Coolify?

Trzema rzeczami. Dokploy stoi na Docker Swarm i ma wbudowane dodawanie węzłów zarządzających i roboczych, Coolify tego nie oferuje w takiej formie. Licencja Coolify jest jednolita, Apache 2.0 dla całości, Dokploy ma wydzielony katalog na licencji zastrzeżonej. Cenniki wariantów chmurowych liczą się inaczej: Dokploy 4,50 dolara za serwer, Coolify 5 dolarów za dwa serwery i 3 dolary za kolejny.

Czy Dokploy przetrwa awarię serwera, na którym stoi panel?

Nie w zakresie panelu. Usługa dokploy ma jedną replikę przypiętą do węzła zarządzającego, a jej baza PostgreSQL siedzi na wolumenie lokalnym tej samej maszyny. Aplikacje na węzłach roboczych działają dalej, dopóki rój ma kworum, ale wdrożeń nie zrobisz. Odtworzenie wymaga kopii bazy panelu i kopii katalogu /etc/dokploy.

Który pakiet npm jest oficjalny?

Oficjalne są @dokploy/cli, @dokploy/sdk i @dokploy/mcp, wszystkie w wersji 0.30.2, publikowane z konta siumauricio. Pakiet dokploy bez zakresu należy do osoby trzeciej. Sama platforma nie jest publikowana w npm, tylko jako obraz dokploy/dokploy.

Ile realnie kosztuje utrzymanie tego u siebie?

Przy założeniach z tabeli powyżej, czyli serwer za 8 dolarów i dwie godziny administrowania po 50 dolarów, wychodzi 108 dolarów miesięcznie, z czego 100 to Twój czas. Sam serwer to najmniejsza pozycja rachunku. Jeśli Twój czas jest tani albo już i tak utrzymujesz serwery, rachunek wygląda zupełnie inaczej.

Czy Dokploy używa Traefika, czy Caddy'ego?

Traefika. Instalator startuje kontener dokploy-traefik z obrazem traefik:v3.6.7, a stała TRAEFIK_VERSION w kodzie wydania 0.30.2 wskazuje 3.6.25. Konfiguracja główna leży w /etc/dokploy/traefik/traefik.yml, a reguły dynamiczne w /etc/dokploy/traefik/dynamic, obserwowanym na bieżąco.

Źródła: repozytorium Dokploy/dokploy, cennik producenta, metadane pakietu w npm.