Så self-hostar du DocuSeal 2026: signeringslänkar, SMTP och auditdata
Self-hosta DocuSeal med rätt portar, beständig lagring, HTTPS, hemligheter, säkerhetskopior och kontroller vid uppgraderingar. Lär dig åtgärda när e-postlänkar pekar på localhost.
De flesta installationsanteckningar för DocuSeal slutar efter den första sidladdningen. Det är för tidigt: e-postlänkar kan peka till localhost eller så kan proxyheaders göra att säkra cookies misslyckas. Ett användbart produktionstest ställer högre krav — ladda upp en mall, placera ut fält, skicka en signeringsförfrågan, slutför den och ladda ner både det signerade dokumentet och auditinformationen.
DocuSeals roll är enkel: dokumentsignering med en spårbar signeringshistorik. Den operativa omfattningen inkluderar mer än webbprocessen, så beroenden, lagrat tillstånd och den publika routen måste namnges uttryckligen innan riktiga data tas emot.
DocuSeals produktionsarkitektur
Dra tre gränser runt DocuSeal: ingress till port 3000, beständigt tillstånd och stödkrav. Containern kan bytas ut, men de två andra behöver tydliga ägare. DocSeals nätverkskontrakt består av SMTP samt beständig databas- och fillagring. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge DocuSeal en avgränsad service credential.
Diagrammet är komplett när en ren klient kan ladda upp en mall, placera ut fält, skicka en signeringsförfrågan, slutföra den och ladda ner både det signerade dokumentet och auditinformationen. Samla in tids- och resursdata för dokumentlagring, PDF-bearbetning, e-postleverans, samtidiga signerare och databastransaktioner. Om transaktionen misslyckas visar den första gräns som inte beter sig enligt dokumentationen om du ska undersöka routing, lokal kapacitet eller en stödtjänst.
Designa återställningen av DocuSeal före lansering
Skydda DocuSeals tillstånd innan du optimerar containern. Det som krävs är databas, signerade filer, mallar och audit-händelser. Montera /data före bootstrap, skriv ofarliga testdata och byt ut containern för att bevisa att sökvägen faktiskt är beständig. Om flera lagringsplatser måste vara synkroniserade ska du dokumentera i vilken ordning skrivningar pausas och säkerhetskopior tas.
Förvara kopior utanför deploymentsservern och kryptera material som innehåller credentials eller privat innehåll. Återställningen är lyckad när mallar, inskickade dokument, signerade filer och audit-händelser återkommer och ett slutfört inskickat dokument fortfarande kan verifieras. Skillnaden mellan en beständig montering och en fristående kopia beskrivs i beständig lagring och snapshots.
Stäng tillfällig åtkomst för installationen
Gör en threat model av den åtgärd som DocuSeal utför, inte bara av inloggningsformuläret. Det största risktagandet här är att ändra SECRET_KEY_BASE eller att betrakta en filkopia som en komplett audit-backup. Implementera följande gräns: begränsa malladministration, skydda signerarens data och ange den externa HTTPS-värden innan du skickar länkar.
Generera SECRET_KEY_BASE en gång, håll den utanför Git och bevara den tillsammans med återställningsmanifestet, eftersom en ändring kan göra krypterat eller signerat applikationstillstånd ogiltigt. Lös inte ett behörighetsfel genom att köra containern som root eller genom att montera värden brett. Resursbegränsningar hör också till säkerhetsdesignen när användare kan utlösa dokumentlagring, PDF-bearbetning, e-postleverans, samtidiga signerare och databastransaktioner.
Dokumentera en fungerande DocuSeal-deployment
Gör DocuSeals smoke test till ett repeterbart releasekommando eller en kort runbook. Resultatet måste visa följande: ladda upp en mall, placera ut fält, skicka en signeringsförfrågan, slutför den och ladda ner både det signerade dokumentet och auditinformationen. Dokumentera applikationsversion, container digest, route-hostnamn och testdataidentifierare tillsammans med resultatet.
Kör samma kontroll efter ett vanligt containerbyte och efter att databas, signerade filer, mallar och audit-händelser har återställts någon annanstans. Återställningen är lyckad när mallar, inskickade dokument, signerade filer och audit-händelser återkommer och ett slutfört inskickat dokument fortfarande kan verifieras. Jämför tidsåtgång och resursförbrukning för dokumentlagring, PDF-bearbetning, e-postleverans, samtidiga signerare och databastransaktioner; en stor förändring bör undersökas även om den slutliga åtgärden fortfarande lyckas.
Testa sedan ett säkert fel: neka tillfälligt testidentiteten åtkomst till SMTP samt beständig databas- och fillagring. Bekräfta att DocuSeal visar felet och återgår till normalt läge utan destruktiva manuella ändringar. Spara endast det nödvändiga, redigerade loggutdraget. Denna grind i fyra delar täcker uppstart, beständighet, återställning och felhantering.
En Docker-baslinje för DocuSeal
Starta DocuSeal på ett sätt som håller routen privat tills bootstrap är klar.
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
Om processen startar om i en loop ska du jämföra den användare som imagen förväntar sig med ägaren till varje monterad sökväg. Om den fortsätter köra testar du port 3000 lokalt och går sedan direkt vidare till arbetsflödet: ladda upp en mall, placera ut fält, skicka en signeringsförfrågan, slutför den och ladda ner både det signerade dokumentet och auditinformationen. Versionslås imagen först när end-to-end-kontrollen har godkänts, och dokumentera den exakta konfigurationen bredvid tjänsten.
Låt inte en fungerande proxy dölja fel i applikationen
Behandla den externa DocuSeal-URL:en som konfiguration som ska överleva redeployments. Ange först applikationsvärd och HTTPS-inställningar innan du skickar signeringslänkar; routa sedan värdnamnet till port 3000 med ursprunglig host och scheme intakta.
Checklistan för reachability vid deployment kan bevisa att förfrågningar når containern. Därefter ska det kända felet — att e-postlänkar pekar till localhost eller att proxyheaders gör att säkra cookies misslyckas — undersökas i DocuSeal, dess tillstånd eller dess workload, inte i certifikatautomatiseringen.
Repetera den riskfyllda DocuSeal-ändringen
En grön container är nödvändig men inte tillräcklig. Tjänstens SLI är att “ladda upp en mall, placera ut fält, skicka en signeringsförfrågan, slutföra den och ladda ner både det signerade dokumentet och auditinformationen” lyckas, medan de sannolika belastningssignalerna är dokumentlagring, PDF-bearbetning, e-postleverans, samtidiga signerare och databastransaktioner.
Change control är viktigt eftersom databas-migreringar och kontinuitet för SECRET_KEY_BASE måste testas, eftersom signerade filer ensamma inte återskapar audit-historiken. Bevara den gamla imagen, testa migreringar på en kopia av tillståndet och dokumentera om rollback stöds efter att schemat har flyttats. Om e-postlänkar pekar till localhost eller proxyheaders gör att säkra cookies misslyckas ska du diagnostisera den första gräns som skiljer sig från den fungerande miljön.
Koppla DocuSeal till Dockups livscykel
Plattformslagret för DocuSeal består av port 3000, ingress, TLS, runtime-konfiguration, lagring och nåbarhet till beroenden. Dockup kan återskapa dessa delar för sin egen infrastruktur eller för en server som kunden ansluter.
Därefter slutför operatören produktlagret: ange applikationsvärd och HTTPS-inställningar innan signeringslänkar skickas; tillämpa denna åtkomstregel — begränsa malladministration, skydda signerarens data och ange den externa HTTPS-värden innan länkar skickas; och kör “ladda upp en mall, placera ut fält, skicka en signeringsförfrågan, slutför den och ladda ner både det signerade dokumentet och auditinformationen”. Om testet dokumenteras tillsammans med deploymenten undviker man att blanda ihop automatiserad provisionering med att applikationen är redo.
Vanliga frågor
Vad behöver DocuSeal för en produktionsdeployment?
Routa DocuSeal-containern på port 3000 via en HTTPS-origin. Nätverkskravet för stöd är SMTP samt beständig databas- och fillagring. Förklara inte DocuSeal redo förrän du kan ladda upp en mall, placera ut fält, skicka en signeringsförfrågan, slutföra den och ladda ner både det signerade dokumentet och auditinformationen.
Vilka DocuSeal-data ska ingå i en säkerhetskopia?
Gör /data beständig och inkludera databas, signerade filer, mallar och audit-händelser i samma återställningsmanifest. En ren DocuSeal-återställning är godkänd först när mallar, inskickade dokument, signerade filer och audit-händelser återkommer och ett slutfört inskickat dokument fortfarande kan verifieras.
Kräver DocuSeal HTTPS bakom en reverse proxy?
Använd HTTPS för den publika DocuSeal-originen och håll port 3000 på den interna routen. Tillämpa DocuSeal-inställningen korrekt: ange applikationsvärd och HTTPS-inställningar innan du skickar signeringslänkar. För DocuSeal skyddar HTTPS credentials eller användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.
Hur bör en DocuSeal-uppgradering testas?
Återställ det aktuella DocuSeal-tillståndet i en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptanstest. Var särskilt uppmärksam eftersom databas-migreringar och kontinuitet för SECRET_KEY_BASE måste testas, eftersom signerade filer ensamma inte återskapar audit-historiken. Behåll den föregående DocuSeal-imagen tills gränserna för datamigrering och rollback är klarlagda.