Slik selvhoster du DocuSeal i 2026: signeringslenker, SMTP og revisjonsdata

De fleste installasjonsnotater for DocuSeal stopper etter den første sidelastingen. Det er for tidlig: E-postlenker peker til localhost, eller proxy-headere gjør at sikre informasjonskapsler ikke fungerer. En nyttig produksjonstest stiller høyere krav — last opp en mal, plasser felt, send en signeringsforespørsel, fullfør den og last ned både det signerte dokumentet og revisjonsinformasjonen.

DocuSeals rolle er enkel: dokumentsignering med et reviderbart signeringsspor. Den operative avgrensningen omfatter mer enn webprosessen, så avhengighetene, den lagrede tilstanden og den offentlige ruten må navngis eksplisitt før ekte data tas i bruk.

Produksjonsoppsettet for DocuSeal

Tegn tre grenser rundt DocuSeal: inngående trafikk til port 3000, persistent tilstand og støttende krav. Containeren kan erstattes, men de to andre trenger tydelige eiere. Nettverkskontrakten for DocuSeal er SMTP samt persistent database- og fillagring. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi DocuSeal en begrenset tjenestekredential.

Diagrammet er komplett når en ren klient kan laste opp en mal, plassere felt, sende en signeringsforespørsel, fullføre den og laste ned både det signerte dokumentet og revisjonsinformasjonen. Registrer tidsbruk og ressursdata for dokumentlagring, PDF-behandling, e-postlevering, samtidige signatarer og databasetransaksjoner. Hvis transaksjonen mislykkes, viser den første grensen som ikke oppfører seg som dokumentert, om du bør undersøke ruting, lokal kapasitet eller en støttetjeneste.

Utform gjenoppretting av DocuSeal før lansering

Beskytt tilstanden til DocuSeal før du optimaliserer containeren. Det nødvendige settet består av database, signerte filer, maler og revisjonshendelser. Monter /data før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Hvis flere lagringssystemer må være konsistente, dokumenterer du rekkefølgen for å sette skriving på pause og ta sikkerhetskopier.

Oppbevar kopier utenfor distribusjonsserveren, og krypter materiale som inneholder legitimasjon eller privat innhold. Gjenopprettingen er vellykket når maler, innsendinger, signerte filer og revisjonshendelser er tilbake, og en fullført innsending fortsatt kan verifiseres. Forskjellen mellom et persistent mount og en uavhengig kopi er forklart i persistent lagring og snapshots.

Lukk midlertidig tilgang til oppsettet

Trusselmodeller handlingen DocuSeal utfører, ikke bare innloggingsskjemaet. Den største risikoen her er å endre SECRET_KEY_BASE eller å behandle en filkopi som en komplett revisjonssikkerhetskopi. Implementer denne avgrensningen: begrens administrasjon av maler, beskytt signatardata og angi den eksterne HTTPS-verten før du sender lenker.

Generer SECRET_KEY_BASE én gang, hold den utenfor Git og bevar den sammen med gjenopprettingsmanifestet, fordi endring av den kan ugyldiggjøre kryptert eller signert applikasjonstilstand. Ikke løs et tillatelsesproblem ved å kjøre containeren som root eller montere verten bredt. Ressursbegrensninger hører også hjemme i sikkerhetsutformingen når dokumentlagring, PDF-behandling, e-postlevering, samtidige signatarer og databasetransaksjoner kan utløses av brukere.

Registrer en kjent god DocuSeal-distribusjon

Gjør DocuSeals smoke-test om til en repeterbar release-kommando eller en kort runbook. Resultatet må demonstrere dette utfallet: last opp en mal, plasser felt, send en signeringsforespørsel, fullfør den og last ned både det signerte dokumentet og revisjonsinformasjonen. Registrer applikasjonsversjonen, containerens digest, rutevertsnavnet og identifikatoren for testdataene sammen med resultatet.

Kjør den samme kontrollen etter et vanlig bytte av container og etter at database, signerte filer, maler og revisjonshendelser er gjenopprettet et annet sted. Gjenopprettingen er vellykket når maler, innsendinger, signerte filer og revisjonshendelser er tilbake, og en fullført innsending fortsatt kan verifiseres. Sammenlign tidsbruk og forbruk knyttet til dokumentlagring, PDF-behandling, e-postlevering, samtidige signatarer og databasetransaksjoner. En stor endring bør undersøkes selv når den siste handlingen fortsatt er vellykket.

Test deretter en kontrollert feil: nekt testidentiteten tilgang til SMTP samt persistent database- og fillagring midlertidig. Bekreft at DocuSeal viser feilen og går tilbake til normal drift uten destruktive manuelle endringer. Bevar bare det nødvendige, redigerte loggutdraget. Denne kontrollen i fire deler dekker oppstart, persistens, gjenoppretting og feilhåndtering.

Et Docker-grunnoppsett for DocuSeal

Start DocuSeal på en måte som holder ruten privat frem til bootstrap er fullført.

docker run -d \
  --name docuseal \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v docuseal-data:/data \
  -e SECRET_KEY_BASE=replace-with-a-long-random-value \
  docuseal/docuseal:latest

Hvis prosessen går i loop, sammenligner du brukerforventningen til imaget med eieren av hver monterte bane. Hvis den holder seg oppe, tester du port 3000 lokalt og går deretter direkte til arbeidsflyten: last opp en mal, plasser felt, send en signeringsforespørsel, fullfør den og last ned både det signerte dokumentet og revisjonsinformasjonen. Lås image-versjonen først etter at denne ende-til-ende-kontrollen er bestått, og registrer den nøyaktige konfigurasjonen sammen med tjenesten.

Hindre at proxy-suksess skjuler applikasjonsfeil

Behandle den eksterne DocuSeal-URL-en som konfigurasjon som skal overleve nye distribusjoner. Angi først applikasjonsverten og HTTPS-innstillingene før du sender signeringslenker. Ruter deretter vertsnavnet til port 3000 med opprinnelig host og scheme intakt.

Kontrollisten for tilgjengelighet etter distribusjon kan bekrefte at forespørsler kommer inn i containeren. Etter dette bør den kjente feilen — at e-postlenker peker til localhost eller at proxy-headere gjør at sikre informasjonskapsler ikke fungerer — undersøkes i DocuSeal, tilstanden eller arbeidsbelastningen, ikke i sertifikatautomatiseringen.

Øv på den risikable DocuSeal-endringen

En grønn container er nødvendig, men ikke tilstrekkelig. Tjenestenivåindikatoren er vellykket gjennomføring av «last opp en mal, plasser felt, send en signeringsforespørsel, fullfør den og last ned både det signerte dokumentet og revisjonsinformasjonen», mens de sannsynlige belastningssignalene er dokumentlagring, PDF-behandling, e-postlevering, samtidige signatarer og databasetransaksjoner.

Endringskontroll er viktig fordi databasemigreringer og kontinuitet for SECRET_KEY_BASE må testes, ettersom signerte filer alene ikke gjenskaper revisjonssporet. Bevar det gamle imaget, test migreringer på en kopi av tilstanden og dokumenter om tilbakerulling støttes etter at skjemaet er flyttet. Hvis e-postlenker peker til localhost eller proxy-headere gjør at sikre informasjonskapsler ikke fungerer, diagnostiserer du den første grensen som skiller seg fra det fungerende miljøet.

Knytt DocuSeal til livssyklusen i Dockup

Plattformlaget for DocuSeal består av port 3000, ingress, TLS, runtime-konfigurasjon, lagring og tilgjengelige avhengigheter. Dockup kan gjenskape disse delene for sin egen infrastruktur eller en server kunden kobler til.

Deretter fullfører operatøren produktlaget: angi applikasjonsverten og HTTPS-innstillingene før du sender signeringslenker; håndhev denne tilgangsregelen — begrens administrasjon av maler, beskytt signatardata og angi den eksterne HTTPS-verten før du sender lenker; og kjør «last opp en mal, plasser felt, send en signeringsforespørsel, fullfør den og last ned både det signerte dokumentet og revisjonsinformasjonen». Når denne testen registreres sammen med distribusjonen, unngår man å forveksle automatisert klargjøring med at applikasjonen er klar.

Vanlige spørsmål

Hva trenger DocuSeal for en produksjonsdistribusjon?

Ruter DocuSeal-containeren på port 3000 gjennom én HTTPS-opprinnelse. Nettverkskravet for støttetjenestene er SMTP samt persistent database- og fillagring. Ikke regn DocuSeal som klart før du kan laste opp en mal, plassere felt, sende en signeringsforespørsel, fullføre den og laste ned både det signerte dokumentet og revisjonsinformasjonen.

Hvilke DocuSeal-data hører hjemme i en sikkerhetskopi?

Gjør /data persistent, og ta med database, signerte filer, maler og revisjonshendelser i det samme gjenopprettingsmanifestet. En ren DocuSeal-gjenoppretting er bare vellykket når maler, innsendinger, signerte filer og revisjonshendelser er tilbake, og en fullført innsending fortsatt kan verifiseres.

Krever DocuSeal HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige DocuSeal-opprinnelsen, og behold port 3000 på den interne ruten. Bruk DocuSeal-innstillingen riktig: angi applikasjonsverten og HTTPS-innstillingene før du sender signeringslenker. For DocuSeal beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for konsistent klientatferd som er avhengig av opprinnelsen.

Hvordan bør en DocuSeal-oppgradering testes?

Gjenopprett den gjeldende DocuSeal-tilstanden i en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom, fordi databasemigreringer og kontinuitet for SECRET_KEY_BASE må testes, ettersom signerte filer alene ikke gjenskaper revisjonssporet. Behold det forrige DocuSeal-imaget til grensen for datamigrering og tilbakerulling er forstått.