Kako samostalno hostati HedgeDoc 2026.: WebSockets, OAuth i učitane datoteke

Postoje dvije verzije „pokretanja HedgeDoca”: postoji container ili usluga doista obavlja svoj posao. Važna je samo druga verzija. Dokaz za to jest stvaranje bilješke, istodobno uređivanje iz dva preglednika, učitavanje slike i autentikacija putem odabranog providera.

HedgeDoc služi toj namjeni: Markdown bilješkama za suradnju u stvarnom vremenu. Implementacija mora očuvati dijelove koji omogućuju takvo ponašanje; port, volume i certifikat ulazni su elementi, a ne rezultat.

Sigurnosno kopirajte stanje koje HedgeDoc ne može ponovno stvoriti

Definirajte ciljnu točku oporavka i ciljno vrijeme oporavka za HedgeDoc s obzirom na bazu podataka, učitane datoteke i konfiguraciju autentikacije. Montirajte /hedgedoc/public/uploads prije bootstrapiranja, zapišite bezopasne ogledne podatke i zamijenite container kako biste dokazali da je ta putanja doista trajna. Named volume rješava trajnost nakon redeploya; ne rješava kompromitaciju ni gubitak poslužitelja.

Izgradite čisto okruženje za restore, upotrijebite istu fiksiranu verziju aplikacije i dokažite da su se bilješke, revizije, korisnici i učitane datoteke vratili te da dva preglednika mogu surađivati na obnovljenoj bilješci. Zabilježite naredbe, ispravke vlasništva i proteklo vrijeme. Vodič za sigurnosne kopije koristan je standard: sigurnosnoj se kopiji vjeruje nakon restorea, a ne nakon uploada.

Odvojite HedgeDoc od njegovih ovisnosti

Health procesa i health proizvoda dvije su odvojene stvari za HedgeDoc. Port 3000 može odgovarati dok transakcija iz korisničke perspektive i dalje ne uspijeva. Mrežni ugovor za HedgeDoc čine Postgres te opcionalni OAuth i SMTP provideri. Privatne endpointe držite na internom DNS-u, dopustite samo potrebne odlazne pozive i dodijelite HedgeDocu ograničene ovlasti servisnog credentiala.

Ovu provjeru spremnosti koristite nakon značajnih promjena konfiguracije: stvorite bilješku, istodobno je uredite iz dva preglednika, učitajte sliku i autentificirajte se putem odabranog providera. Skupe vanjske provjere držite izvan liveness probeova kako ispad providera ne bi uzrokovao restart loop. Pri radu na kapacitetu pratite WebSocket connections, upise u bazu podataka, učitane medije i povijest dokumenata; to bolje odražava stvarno opterećenje HedgeDoca nego zahtjevi za stranicama.

Pet provjera jačih od health statusa containera

Pretvorite smoke test za HedgeDoc u ponovljivu release naredbu ili kratki runbook. Njegov izlaz mora dokazati sljedeći rezultat: stvorite bilješku, istodobno je uredite iz dva preglednika, učitajte sliku i autentificirajte se putem odabranog providera. Uz rezultat zabilježite verziju aplikacije, digest containera, hostname rute i identifikator testnih podataka.

Istu provjeru pokrenite nakon uobičajene zamjene containera te nakon restorea baze podataka, učitanih datoteka i konfiguracije autentikacije u drugom okruženju. Restore je uspio kada se bilješke, revizije, korisnici i učitane datoteke vrate te dva preglednika mogu surađivati na obnovljenoj bilješci. Usporedite vrijeme i potrošnju povezane s WebSocket connections, upisima u bazu podataka, učitanim medijima i poviješću dokumenata; velika je promjena vrijedna istrage čak i kada završna radnja i dalje prolazi.

Zatim izvedite siguran kvar: privremeno uskratite testnom identitetu pristup Postgresu te opcionalnim OAuth i SMTP providerima. Potvrdite da HedgeDoc prijavljuje grešku i vraća se u normalno stanje bez destruktivnih ručnih izmjena. Sačuvajte samo nužni, redigirani isječak loga. Ovaj gate iz četiri dijela pokriva pokretanje, trajnost, oporavak i obradu kvarova.

Pokrenite HedgeDoc bez skrivanja važnih dijelova

Minimalna je naredba korisna kada otkriva čime će platforma kasnije upravljati.

docker run -d \
  --name hedgedoc \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v hedgedoc-data:/hedgedoc/public/uploads \
  -e CMD_SESSION_SECRET=replace-with-a-long-random-value \
  -e CMD_DOMAIN=app.example.com \
  -e CMD_PROTOCOL_USESSL=true \
  -e CMD_DB_URL=postgres://hedgedoc:replace-password@postgres.internal:5432/hedgedoc \
  quay.io/hedgedoc/hedgedoc:latest

Ovdje port 3000 ostaje privatan za host, a svaka je potrebna putanja eksplicitno navedena. Dodajte provjerene postavke povezivanja za Postgres te opcionalne OAuth i SMTP providere; za privatne servise koristite privatna imena. Pokretanje provjerite i putem logova i pomoću provjere specifične za aplikaciju: stvorite bilješku, istodobno je uredite iz dva preglednika, učitajte sliku i autentificirajte se putem odabranog providera. Nakon provjere fiksirajte verziju imagea kako rutinska zamjena ne bi neprimjetno promijenila ponašanje.

Nemojte HedgeDocu dati cijeli host

Za HedgeDoc vrijedna površina nužno nije landing page. Glavna je pogreška upotreba oglednog session secreta ili nenamjerno dopuštanje anonimnog stvaranja bilješki. Tome se suprotstavite namjerno: koristite stabilan session secret, odlučite je li anonimno stvaranje bilješki prihvatljivo i ograničite pristup privatnim bilješkama.

Generirajte CMD_SESSION_SECRET kao dugu nasumičnu vrijednost; njegova rotacija obično poništava sesije ili tokene, stoga planirajte utjecaj na korisnike umjesto da je nazivate migracijom enkripcije. Koristite neprivilegiranog korisnika containera kada ga image podržava i nemojte montirati nepovezane credentiale. Ograničenja ratea ili veličine primijenite na ingressu, gdje nepouzdani rad može trošiti WebSocket connections, upise u bazu podataka, učitane medije i povijest dokumenata.

Testirajte HedgeDoc izvan poslužitelja

Odaberite konačni hostname za HedgeDoc prije nego što korisnici spreme callbackove ili client postavke, a zatim postavite CMD_DOMAIN i CMD_PROTOCOL_USESSL za javni URL. Platformska ruta treba završiti TLS i usmjeriti promet na privatni port 3000.

Transakciju prihvaćanja pokrenite izvana. Ako klijent uopće ne dolazi do HedgeDoca, za provjere DNS-a i certifikata koristite kontrolni popis za SSL validaciju. Ako zahtjev dolazi do HedgeDoca, ali uređivanje u stvarnom vremenu ne funkcionira jer su WebSockets ili postavke domene pogrešne, prestanite mijenjati proxy redirecte i umjesto toga provjerite granicu specifičnu za aplikaciju.

Upravljajte HedgeDocom prema njegovom stvarnom uskom grlu

Nakon svake implementacije koristite stvaranje bilješke, istodobno uređivanje iz dva preglednika, učitavanje slike i autentikaciju putem odabranog providera kao smoke test za HedgeDoc. Prateće metrike su WebSocket connections, upisi u bazu podataka, učitani mediji i povijest dokumenata; postavite alert tamo gdje se ti resursi približavaju točki koja narušava korisničku radnju.

Glavni rizik promjene jest činjenica da migracije baze podataka HedgeDoca, OAuth postavke te promjene plugina ili renderera zahtijevaju staged release. Siguran release počinje od snapshot-a iz kojeg je moguć restore i provjerava svaku jednosmjernu promjenu stanja prije preusmjeravanja prometa. Kada uređivanje u stvarnom vremenu ne funkcionira jer su WebSockets ili postavke domene pogrešne, ne uklanjajte neuspjeli container dok ne pročitate njegovu konfiguraciju i prvu grešku.

Gdje Dockup uklanja posao za HedgeDoc

Dockup može preuzeti zamjenjive dijelove platforme: usmjeriti promet na port 3000, izdati domenu i certifikat, ubaciti secretove, priključiti trajnu pohranu te povezati HedgeDoc s upravljanim ili privatno priključenim servisima. To može učiniti na infrastrukturi Dockupa ili na poslužitelju koji priključite.

Posao prihvaćanja HedgeDoca i dalje ostaje eksplicitan. Nakon one-click deploymenta postavite CMD_DOMAIN i CMD_PROTOCOL_USESSL za javni URL, povežite i testirajte Postgres te opcionalne OAuth i SMTP providere i pokrenite ovaj scenarij: stvorite bilješku, istodobno je uredite iz dva preglednika, učitajte sliku i autentificirajte se putem odabranog providera. Ta je podjela namjerna: Dockup uklanja repetitivno postavljanje infrastrukture bez pretvaranja da se uloge aplikacije, credentiali providera ili pravila restorea biraju sami.

Često postavljana pitanja

Što je HedgeDocu potrebno za produkcijsku implementaciju?

Usmjerite HedgeDoc container na portu 3000 kroz jedan HTTPS origin. Prateći mrežni zahtjev čine Postgres te opcionalni OAuth i SMTP provideri. Nemojte HedgeDoc smatrati spremnim dok ne možete stvoriti bilješku, istodobno je urediti iz dva preglednika, učitati sliku i autentificirati se putem odabranog providera.

Koji podaci HedgeDoca pripadaju sigurnosnoj kopiji?

Očuvajte /hedgedoc/public/uploads i u isti recovery manifest uključite bazu podataka, učitane datoteke i konfiguraciju autentikacije. Čisti restore HedgeDoca uspješan je samo kada se bilješke, revizije, korisnici i učitane datoteke vrate te dva preglednika mogu surađivati na obnovljenoj bilješci.

Zahtijeva li HedgeDoc HTTPS iza reverse proxya?

Koristite HTTPS za javni HedgeDoc origin, a port 3000 zadržite na internoj ruti. Ispravno primijenite postavku HedgeDoca: postavite CMD_DOMAIN i CMD_PROTOCOL_USESSL za javni URL. Za HedgeDoc HTTPS štiti credentiale i sadržaj korisnika tijekom prijenosa te osigurava dosljedno ponašanje klijenta ovisno o originu.

Kako treba testirati nadogradnju HedgeDoca?

Vratite trenutačno stanje HedgeDoca u izoliranu implementaciju, primijenite kandidatsku verziju i ponovite njegovu transakciju prihvaćanja. Obratite posebnu pozornost jer migracije baze podataka HedgeDoca, OAuth postavke te promjene plugina ili renderera zahtijevaju staged release. Zadržite prethodni image HedgeDoca dok ne razumijete granice migracije podataka i rollbacka.