Como hospedar o DocuSeal por conta própria em 2026: links de assinatura, SMTP e dados de auditoria
Hospede o DocuSeal por conta própria com portas corretas, armazenamento persistente, HTTPS, secrets, backups e verificações de upgrade. Aprenda a corrigir links de e-mail que apontam para localhost.
A maioria das notas de instalação do DocuSeal termina no primeiro carregamento da página. Isso é cedo demais: os links de e-mail apontam para localhost ou os proxy headers fazem os secure cookies falharem. Um teste de produção útil é mais exigente: fazer upload de um template, posicionar os campos, enviar uma solicitação de assinatura, concluí-la e baixar o documento assinado e as informações de auditoria.
O papel do DocuSeal é simples: assinatura de documentos com um histórico de assinaturas auditável. Seu limite operacional inclui mais do que o processo web, portanto a dependência, o estado armazenado e a rota pública precisam ser definidos explicitamente antes que dados reais cheguem.
A arquitetura de produção do DocuSeal
Defina três limites ao redor do DocuSeal: entrada na porta 3000, estado durável e requisitos de suporte. O container pode ser substituído, mas os outros dois precisam de responsáveis explícitos. O contrato de rede do DocuSeal é SMTP, além de banco de dados e armazenamento de arquivos duráveis. Mantenha endpoints privados no DNS interno, permita apenas as chamadas de saída necessárias e forneça ao DocuSeal uma credencial de serviço com escopo limitado.
O diagrama estará completo quando um cliente limpo puder fazer upload de um template, posicionar os campos, enviar uma solicitação de assinatura, concluí-la e baixar o documento assinado e as informações de auditoria. Colete dados de tempo e de recursos para o armazenamento de documentos, processamento de PDF, entrega de e-mails, signatários simultâneos e transações do banco de dados. Se a transação falhar, o primeiro limite que não se comportar conforme documentado indicará se é preciso investigar o roteamento, a capacidade local ou um serviço de suporte.
Planeje a restauração do DocuSeal antes do lançamento
Proteja o estado do DocuSeal antes de otimizar o container. O conjunto necessário inclui o banco de dados, arquivos assinados, templates e eventos de auditoria. Monte /data antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para comprovar que esse caminho é realmente persistente. Se vários armazenamentos precisarem permanecer consistentes, documente a ordem em que as gravações são pausadas e os backups são realizados.
Mantenha cópias fora do servidor de deployment e criptografe o material que contenha credenciais ou conteúdo privado. A recuperação será bem-sucedida quando templates, submissões, arquivos assinados e eventos de auditoria forem restaurados e uma submissão concluída continuar verificável. A diferença entre um mount persistente e uma cópia independente é explicada em armazenamento persistente e snapshots.
Feche o acesso temporário de configuração
Faça o threat modeling da ação executada pelo DocuSeal, não apenas do seu formulário de login. Aqui, o erro de alto risco é alterar SECRET_KEY_BASE ou tratar uma cópia de arquivo como um backup completo da auditoria. Implemente este limite: restrinja a administração de templates, proteja os dados dos signatários e defina o host HTTPS externo antes de enviar links.
Gere SECRET_KEY_BASE uma única vez, mantenha-o fora do Git e preserve-o com o recovery manifest, pois alterá-lo pode invalidar o estado criptografado ou assinado da aplicação. Não resolva um erro de permissão executando o container como root ou montando o host de forma ampla. Os limites de recursos também fazem parte do design de segurança quando usuários podem acionar armazenamento de documentos, processamento de PDF, entrega de e-mails, signatários simultâneos e transações do banco de dados.
Registre um deployment conhecido como funcional do DocuSeal
Transforme o smoke test do DocuSeal em um comando de release reproduzível ou em um runbook curto. A saída deve demonstrar este resultado: fazer upload de um template, posicionar os campos, enviar uma solicitação de assinatura, concluí-la e baixar o documento assinado e as informações de auditoria. Registre a versão da aplicação, o digest do container, o hostname da rota e o identificador dos dados de teste junto com o resultado.
Execute a mesma verificação após uma troca rotineira de container e depois de restaurar o banco de dados, arquivos assinados, templates e eventos de auditoria em outro local. A restauração terá sido bem-sucedida quando templates, submissões, arquivos assinados e eventos de auditoria forem restaurados e uma submissão concluída continuar verificável. Compare o tempo e o consumo relacionados ao armazenamento de documentos, processamento de PDF, entrega de e-mails, signatários simultâneos e transações do banco de dados; uma grande alteração merece investigação mesmo quando a ação final ainda é concluída com sucesso.
Em seguida, exercite uma falha segura: negue temporariamente à identidade de teste o acesso ao SMTP, ao banco de dados durável e ao armazenamento de arquivos. Confirme que o DocuSeal exibe a falha e retorna ao funcionamento normal sem edições manuais destrutivas. Preserve apenas o trecho de log necessário e com dados redigidos. Esse gate em quatro partes cobre inicialização, persistência, recuperação e tratamento de falhas.
Uma base Docker para o DocuSeal
Inicie o DocuSeal de modo que a rota permaneça privada até a conclusão do bootstrap.
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
Se o processo entrar em loop, compare o usuário esperado pela imagem com o proprietário de cada caminho montado. Se permanecer em execução, teste a porta 3000 localmente e passe diretamente ao workflow: faça upload de um template, posicione os campos, envie uma solicitação de assinatura, conclua-a e baixe o documento assinado e as informações de auditoria. Fixe a versão da imagem somente depois que essa verificação end-to-end for aprovada e registre a configuração exata junto ao serviço.
Evite que o sucesso do proxy oculte uma falha da aplicação
Trate a URL externa do DocuSeal como uma configuração que deve sobreviver aos redeploys. Primeiro, defina o host da aplicação e as configurações de HTTPS antes de enviar links de assinatura; depois, encaminhe o hostname para a porta 3000 preservando o host e o scheme originais.
O checklist de reachability do deployment pode comprovar que as requisições entram no container. Depois disso, a falha conhecida — os links de e-mail apontam para localhost ou os proxy headers fazem os secure cookies falharem — deve ser investigada no DocuSeal, no estado armazenado ou na carga de trabalho, e não na automação de certificados.
Ensaie a alteração de risco do DocuSeal
Um container em estado saudável é necessário, mas não suficiente. O indicador de nível de serviço é a conclusão bem-sucedida de “fazer upload de um template, posicionar os campos, enviar uma solicitação de assinatura, concluí-la e baixar o documento assinado e as informações de auditoria”, enquanto os sinais prováveis de pressão são o armazenamento de documentos, processamento de PDF, entrega de e-mails, signatários simultâneos e transações do banco de dados.
O change control é importante porque as migrações do banco de dados e a continuidade de SECRET_KEY_BASE precisam ser testadas, pois apenas os arquivos assinados não reconstroem o histórico de auditoria. Preserve a imagem antiga, teste as migrações em um estado copiado e documente se o rollback é compatível depois que o schema for alterado. Se os links de e-mail apontarem para localhost ou os proxy headers fizerem os secure cookies falharem, diagnostique o primeiro limite que diferir do ambiente funcional.
Conecte o DocuSeal ao ciclo de vida do Dockup
A camada de plataforma do DocuSeal é composta pela porta 3000, ingress, TLS, configuração de runtime, armazenamento e reachability das dependências. O Dockup pode reproduzir essas partes na própria infraestrutura ou em um servidor conectado pelo cliente.
Depois, o operador conclui a camada do produto: defina o host da aplicação e as configurações de HTTPS antes de enviar links de assinatura; aplique esta regra de acesso — restrinja a administração de templates, proteja os dados dos signatários e defina o host HTTPS externo antes de enviar links —; e execute “fazer upload de um template, posicionar os campos, enviar uma solicitação de assinatura, concluí-la e baixar o documento assinado e as informações de auditoria”. Registrar esse teste junto ao deployment evita confundir o provisionamento automatizado com a prontidão da aplicação.
Perguntas frequentes
O que o DocuSeal precisa para um deployment de produção?
Encaminhe o container do DocuSeal na porta 3000 por meio de uma única origem HTTPS. O requisito de rede de suporte é SMTP, além de banco de dados e armazenamento de arquivos duráveis. Não considere o DocuSeal pronto até conseguir fazer upload de um template, posicionar os campos, enviar uma solicitação de assinatura, concluí-la e baixar o documento assinado e as informações de auditoria.
Quais dados do DocuSeal devem fazer parte de um backup?
Persista /data e inclua o banco de dados, arquivos assinados, templates e eventos de auditoria no mesmo recovery manifest. Uma restauração limpa do DocuSeal só será aprovada quando templates, submissões, arquivos assinados e eventos de auditoria forem restaurados e uma submissão concluída continuar verificável.
O DocuSeal exige HTTPS atrás de um reverse proxy?
Use HTTPS para a origem pública do DocuSeal e mantenha a porta 3000 na rota interna. Aplique corretamente a configuração do DocuSeal: defina o host da aplicação e as configurações de HTTPS antes de enviar links de assinatura. No DocuSeal, o HTTPS protege credenciais ou conteúdo do usuário durante o trânsito e mantém consistente o comportamento do cliente sensível à origem.
Como testar um upgrade do DocuSeal?
Restaure o estado atual do DocuSeal em um deployment isolado, aplique a versão candidata e repita sua transação de aceitação. Preste atenção especial, pois as migrações do banco de dados e a continuidade de SECRET_KEY_BASE precisam ser testadas, já que apenas os arquivos assinados não reconstroem o histórico de auditoria. Mantenha a imagem anterior do DocuSeal até entender os limites de migração de dados e rollback.
