Como fazer self-host do Langflow em 2026: flows, acesso à API e estado persistente

Trate o Langflow como um sistema pequeno, não como uma imagem Docker. O objetivo do Langflow para o usuário é claro: um visual LLM workflow builder que expõe flows como APIs; o deployment só é aceitável quando você consegue criar um flow com uma credencial de provider, executá-lo no editor, chamar sua API e verificar a resposta após um restart do serviço.

Essa distinção identifica o modo de falha que os operadores encontram depois dos testes locais: um secret muda após o restart ou as dependências dos componentes estão ausentes. Ela também torna o plano de backup e upgrade específico o suficiente para ser testado.

Defina primeiro o que significa sucesso para o Langflow

Não deixe que a imagem do Langflow escolha acidentalmente a arquitetura de produção. A imagem fornece um processo na porta 7860; storage, routing e requisitos externos ainda precisam de lifecycles definidos deliberadamente. O contrato de rede do Langflow é o Postgres para estado durável, além das credenciais do model provider. Mantenha endpoints privados em DNS interno, permita apenas as chamadas de saída necessárias e forneça ao Langflow uma credencial de serviço com escopo limitado.

O deployment está pronto para testes mais profundos quando consegue criar um flow com uma credencial de provider, executá-lo no editor, chamar sua API e verificar a resposta após um restart do serviço. Acompanhe a transação nos logs e monitore a execução dos componentes, a latência do modelo, as chamadas de API paralelas, o parsing de arquivos e a quantidade de conexões com o banco de dados. Essas observações mostram se a topologia atual isola o componente correto.

Inicie o Langflow com defaults observáveis

Mantenha a invocação inicial do Langflow reproduzível o suficiente para ser revisada em um pull request.

docker run -d \
  --name langflow \
  --restart unless-stopped \
  -p 127.0.0.1:7860:7860 \
  -v langflow-data:/app/langflow \
  -e LANGFLOW_SECRET_KEY=replace-with-a-long-random-value \
  langflowai/langflow:latest

Não dependa de latest depois que existirem dados reais. Registre o digest em funcionamento, o usuário do container e as permissões do mount. Acompanhe o log da aplicação durante um teste completo — criar um flow com uma credencial de provider, executá-lo no editor, chamar sua API e verificar a resposta após um restart do serviço — e registre quaisquer migrations antes de colocar a rota atrás de tráfego de produção.

Teste o Langflow de fora do servidor

Trate a URL externa do Langflow como uma configuração que deve sobreviver a redeploys. Primeiro, defina o endereço público usado pelos clientes da API e pelos callbacks de autenticação; depois, encaminhe o hostname para a porta 7860, mantendo intactos 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 — um secret muda após o restart ou as dependências dos componentes estão ausentes — deve ser investigada no Langflow, no estado dele ou na workload, e não na automação de certificados.

Separe containers substituíveis de dados persistentes

Uma imagem de container pode ser baixada novamente; flows, banco de dados, API keys e arquivos enviados não podem. Faça o mount de /app/langflow antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para comprovar que esse caminho é realmente persistente. Inspecione o mount efetivo em vez de confiar no nome de um arquivo do Compose e verifique se o usuário do runtime pode gravar onde o Langflow espera.

Escolha a retenção e um destino externo ao host, depois ensaie a recuperação sem tocar na produção. O exercício só é aprovado quando flows, usuários, credenciais e arquivos retornam, e um cliente de API existente consegue executar o flow restaurado. Para estados baseados em banco de dados, combine snapshots do storage com exports consistentes com a aplicação, conforme descrito em point-in-time recovery versus snapshots.

Decisões de segurança específicas do Langflow

Não herde as premissas de segurança de um tutorial local. A preocupação específica do Langflow é expor a criação de flows e as provider keys armazenadas sem autenticação. Por isso, em produção, proteja o builder, limite o escopo do acesso à API e mantenha as credenciais dos modelos em storage criptografado no servidor.

Trate LANGFLOW_SECRET_KEY de acordo com a função que ele desempenha no Langflow: mantenha valores sensíveis fora do Git, documente os efeitos da rotação e nunca substitua um exemplo público em produção. Limite o acesso ao filesystem e à rede, proteja os endpoints de setup e defina limites de upload, requisições ou execução para a execução dos componentes, a latência do modelo, as chamadas de API paralelas, o parsing de arquivos e a quantidade de conexões com o banco de dados.

Capacidade e verificações de upgrade

A primeira métrica operacional útil para o Langflow é verificar se ele consegue criar um flow com uma credencial de provider, executá-lo no editor, chamar sua API e verificar a resposta após um restart do serviço. Combine isso com sinais de saturação da execução dos componentes, da latência do modelo, das chamadas de API paralelas, do parsing de arquivos e da quantidade de conexões com o banco de dados. Um probe que verifica apenas o processo não deve chamar dependências caras nem reiniciar o container porque um upstream ficou temporariamente indisponível.

Trate os upgrades como alterações de dados, porque os pacotes de componentes, as migrations do banco de dados e os flows serializados podem mudar entre releases do Langflow. Fixe as versões, ensaie o procedimento em um estado restaurado e mantenha a imagem anterior disponível até que um rollback continue válido. Quando um secret muda após o restart ou as dependências dos componentes estão ausentes, preserve os logs anteriores ao restart; eles geralmente contêm a mensagem causal.

Registre um deployment do Langflow conhecido por funcionar

Transforme o smoke test do Langflow em um comando de release reproduzível ou em um runbook curto. A saída deve demonstrar este resultado: criar um flow com uma credencial de provider, executá-lo no editor, chamar sua API e verificar a resposta após um restart do serviço. 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 substituição rotineira do container e depois de restaurar flows, banco de dados, API keys e arquivos enviados em outro local. A restauração foi bem-sucedida quando flows, usuários, credenciais e arquivos retornam, e um cliente de API existente consegue executar o flow restaurado. Compare o tempo e o consumo relacionados à execução dos componentes, à latência do modelo, às chamadas de API paralelas, ao parsing de arquivos e à quantidade de conexões com o banco de dados; uma mudança significativa merece investigação mesmo quando a ação final continua sendo aprovada.

Depois, exercite uma falha segura: negue temporariamente à identidade de teste o acesso ao Postgres para o estado durável, além das credenciais do model provider. Confirme que o Langflow sinaliza a falha e retorna ao funcionamento normal sem edições manuais destrutivas. Preserve apenas o trecho de log necessário, com dados redigidos. Esse gate em quatro partes cobre startup, persistência, recuperação e tratamento de falhas.

O que o Dockup deve automatizar para o Langflow

A camada de plataforma do Langflow consiste na porta 7860, ingress, TLS, configuração do runtime, storage e reachability das dependências. O Dockup pode reproduzir esses componentes na própria infraestrutura ou em um servidor conectado pelo cliente.

Depois, o operador conclui a camada do produto: definir o endereço público usado pelos clientes da API e pelos callbacks de autenticação; aplicar esta regra de acesso — proteger o builder, limitar o escopo do acesso à API e manter as credenciais dos modelos em storage criptografado no servidor —; e executar “criar um flow com uma credencial de provider, executá-lo no editor, chamar sua API e verificar a resposta após um restart do serviço”. Registrar esse teste junto com o deployment evita confundir o provisioning automatizado com a prontidão da aplicação.

Perguntas frequentes

O que o Langflow precisa para um deployment de produção?

Encaminhe o container do Langflow na porta 7860 por meio de uma única origem HTTPS. O requisito de rede de suporte é o Postgres para estado durável, além das credenciais do model provider. Não considere o Langflow pronto até conseguir criar um flow com uma credencial de provider, executá-lo no editor, chamar sua API e verificar a resposta após um restart do serviço.

Quais dados do Langflow devem fazer parte de um backup?

Persista /app/langflow e inclua flows, banco de dados, API keys e arquivos enviados no mesmo manifesto de recuperação. Uma restauração limpa do Langflow só é aprovada quando flows, usuários, credenciais e arquivos retornam, e um cliente de API existente consegue executar o flow restaurado.

O Langflow exige HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do Langflow e mantenha a porta 7860 na rota interna. Aplique corretamente a configuração do Langflow: defina o endereço público usado pelos clientes da API e pelos callbacks de autenticação. Para o Langflow, o HTTPS protege credenciais ou conteúdo dos usuários durante o trânsito e mantém consistente o comportamento dos clientes sensível à origem.

Como testar um upgrade do Langflow?

Restaure o estado atual do Langflow em um deployment isolado, aplique a versão candidata e repita sua transação de aceitação. Preste atenção especial, porque os pacotes de componentes, as migrations do banco de dados e os flows serializados podem mudar entre releases do Langflow. Mantenha a imagem anterior do Langflow até entender os limites da migração de dados e do rollback.