Własny hosting

Możesz uruchomić workbench Oloproof na własnym serwerze: lokalnie, w chmurze prywatnej lub u kanadyjskiego dostawcy chmury. Pakiet w deploy/self-hosted/ uruchamia te same dwa obrazy co oloproof.com (web i worker) oraz PostgreSQL, pobierane po digeście. Twoje dane zostają tam, gdzie go uruchomisz, i nic nie jest wysyłane do Oloproof.

Wymagania

• Jeden host z Linuksem, Docker Engine i wtyczką Compose. 4 GB pamięci i 2 procesory wystarczą dla zespołu; worker ma limit 1,5 GB, a web 768 MB.
• Miejsce na dysku dla PostgreSQL. Każde wysłane uruchomienie jest tam przechowywane.
• Reverse proxy dla HTTPS (Caddyfile.example to działający przykład; nginx też się nada).
• Dostęp do ghcr.io/etobicoke/oloproof albo obrazy skopiowane do własnego rejestru.

Instalacja

cd deploy/self-hosted
sh generate-env.sh          # writes .env and fills every secret

Ustaw w .env zmienne OLOPROOF_WEB_IMAGE, OLOPROOF_WORKER_IMAGE (oba digesty ...@sha256:) i OLOPROOF_PUBLIC_URL oraz co najmniej jeden sposób logowania: pocztę dla kont z hasłem (OLOPROOF_MAIL_FROM z OLOPROOF_SMTP_URL lub OLOPROOF_RESEND_API_KEY) albo dostawcę OAuth. Bez tego web nie wystartuje. Następnie uruchom:

docker compose --env-file .env up -d
curl -fsS http://127.0.0.1:3000/api/health

Usługa migrate aktualizuje bazę danych, zanim wystartują web i worker. Rejestracja odbywa się na zaproszenie, wystawiane za pomocą OLOPROOF_OPERATOR_TOKEN (deploy/README.md, „Signup”).

Konfiguracja

.env.example wymienia każdą zmienną czytaną przez web i workera, każdą oznaczoną jako wymagana, generowana lub opcjonalna. Pusta zmienna opcjonalna wyłącza swoją funkcję. Zachowaj wygenerowane sekrety: nowe hasło bazy danych odcina dostęp do bazy, a nowy klucz podpisu zaczyna nowego sygnatariusza. Pakiet na własnym hostingu nie ma rozliczeń, więc każda przestrzeń robocza ma miesięczne limity przypadków planu darmowego; zwiększ OLOPROOF_FREE_TIER_PUSHED_MONTHLY i OLOPROOF_FREE_TIER_MANAGED_MONTHLY dla swojego zespołu.

Domyślnie bez ruchu wychodzącego

Stos nie wysyła telemetrii i nie wywołuje żadnej usługi Oloproof. Łączy się z siecią tylko w tym, co włączysz: poczta (przekaźnik SMTP w Twojej sieci lub Resend), logowanie OAuth, Turnstile i dostawcy modeli, dla których przestrzeń robocza przechowuje klucz. Bez żadnego z nich działa bez trasy na zewnątrz. Dla hosta odizolowanego od sieci skopiuj trzy obrazy do własnego rejestru i wskaż go w zmiennych obrazów. Konta z hasłem potrzebują poczty, więc w odizolowanej sieci ustaw OLOPROOF_SMTP_URL na przekaźnik wewnątrz niej.

Kopie zapasowe

sh backup.sh /srv/backups/oloproof

backup.sh zapisuje skompresowany pg_dump w wybranym katalogu. Zaplanuj go przez cron lub timer systemd i samodzielnie kopiuj katalog poza hosta. Skrypt pokazuje polecenie przywracania.

Zrzut nie zawiera .env, a .env zawiera OLOPROOF_CONTENT_KEY i pozostałe wygenerowane sekrety: bez niego przywrócona baza nie odczyta zaszyfrowanej treści. Zrób kopię .env przy jego utworzeniu i po każdej zmianie, osobno od zrzutów i offline (menedżer haseł lub zaszyfrowany dysk), nigdy obok nich.

Aktualizacje

Wpisz dwa digesty nowego wydania do .env, a następnie uruchom:

sh upgrade.sh /srv/backups/oloproof

Skrypt robi kopię zapasową, pobiera, migruje i restartuje web oraz workera. Spodziewaj się krótkiej przerwy. Aby się wycofać, wpisz poprzednie digesty i przywróć wykonaną kopię.

Co jest obsługiwane

• Jeden host. Nie ma wysokiej dostępności: stos jest tak dostępny jak jego maszyna.
• Dane znajdują się tam, gdzie go uruchomisz. Oloproof nie przechowuje żadnych Twoich danych.
• Brak wydań bez przestojów. Te należą wyłącznie do usługi hostowanej.
• Pakiet jest sprawdzany przez deploy/self-hosted/check.sh, który uruchamia go pod własną nazwą projektu, czeka na /api/health, pobiera strony publiczne i go usuwa.