Como fazer self-hosting do Baserow em 2026: dados, URLs e backups em um só lugar

Um container do Baserow pode estar em estado saudável enquanto a tarefa que importa para os usuários está quebrada. No Baserow, essa falha oculta geralmente ocorre quando a URL pública muda depois que os usuários geraram links de compartilhamento e callback. Este guia considera “criar um banco de dados e uma view, importar um CSV, editar linhas em duas sessões e fazer upload de um arquivo antes de reiniciar a stack all-in-one” como teste de aceitação e estrutura a implantação a partir desse resultado.

O Baserow tem uma função específica na stack: bancos de dados no estilo Airtable baseados em Postgres e Redis. Portanto, a questão em produção não é se a porta 80 responde uma vez, mas se o estado, as dependências e o endereço público continuam consistentes após um restart, uma atualização e uma restauração.

Do que o Baserow depende

A saúde do processo e a saúde do produto são coisas diferentes no Baserow. A porta 80 pode responder enquanto a transação voltada ao usuário ainda falha. O requisito de runtime local é ter memória suficiente para o Postgres, o Redis, o backend e os workers incluídos. Mantenha o ciclo de vida explícito para que mover o Baserow entre hosts não altere o comportamento silenciosamente.

Use este exercício de prontidão após mudanças significativas de configuração: crie um banco de dados e uma view, importe um CSV, edite linhas em duas sessões e faça upload de um arquivo antes de reiniciar a stack all-in-one. Mantenha verificações externas dispendiosas fora das probes de liveness para que uma indisponibilidade do provedor não cause um loop de restart. O trabalho de capacity planning deve acompanhar o Postgres, o Redis, os workers do Celery, a quantidade de linhas, o tamanho das importações e o número de editores simultâneos incluídos, pois isso representa melhor a pressão real sobre o Baserow do que as requisições de página.

Uma baseline Docker para o Baserow

O comando a seguir torna visível o limite do container sem fingir provisionar todos os serviços externos.

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

Antes de abrir o ingress, inspecione o ambiente resolvido, os mounts e o listener. Confirme o requisito local antes da exposição: memória suficiente para o Postgres, o Redis, o backend e os workers incluídos. Um lançamento bem-sucedido termina quando você consegue criar um banco de dados e uma view, importar um CSV, editar linhas em duas sessões e fazer upload de um arquivo antes de reiniciar a stack all-in-one, e não quando docker ps imprime Up.

Domínios, proxy headers e porta 80

Exponha um hostname HTTPS para o Baserow e mantenha a porta 80 bruta privada. Defina BASEROW_PUBLIC_URL como a origin externa exata. Isso impede que navegadores e clientes de API descubram dois endereços concorrentes.

A partir de um cliente limpo, execute a transação conhecida como válida e inspecione a primeira requisição que falhar. Use o guia de domínio personalizado quando houver problemas de DNS ou TLS. Considere “a URL pública muda depois que os usuários geraram links de compartilhamento e callback” um diagnóstico separado da aplicação quando a rota já estiver comprovadamente correta.

Faça backup do estado que o Baserow não consegue recriar

Defina o recovery point e o recovery time do Baserow considerando toda a árvore /baserow/data e exports lógicos periódicos do banco de dados. Monte /baserow/data antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para provar que esse caminho é realmente persistente. Um volume nomeado resolve a persistência durante redeploys; não resolve comprometimento ou perda do servidor.

Crie um ambiente de restauração limpo, use a mesma versão fixada da aplicação e prove que tabelas, views, usuários, automações e arquivos retornam a partir do backup completo de /baserow/data. Registre os comandos, as correções de ownership e o tempo decorrido. O guia de backup oferece um padrão útil: um backup só é confiável depois da restauração, não depois do upload.

Não dê ao Baserow acesso ao host inteiro

Modele as ameaças considerando as ações executadas pelo Baserow, e não apenas o formulário de login. Aqui, o erro de maior risco é usar a imagem all-in-one sem um plano de backup para os serviços incluídos. Implemente este limite: desative o registro quando apropriado, preserve SECRET_KEY e limite as views públicas compartilhadas aos dados pretendidos.

Gere SECRET_KEY uma única vez, mantenha-a fora do Git e preserve-a com o manifesto de recuperação, pois alterá-la 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 o Postgres, o Redis, os workers do Celery, a quantidade de linhas, o tamanho das importações e os editores simultâneos incluídos podem ser acionados pelos usuários.

Logs que respondem à próxima pergunta

Um health check ocioso diz pouco sobre o Baserow. Monitore o Postgres, o Redis, os workers do Celery, a quantidade de linhas, o tamanho das importações e os editores simultâneos incluídos; depois, gere alertas com base no sintoma percebido pelos usuários: falha na ação “criar um banco de dados e uma view, importar um CSV, editar linhas em duas sessões e fazer upload de um arquivo antes de reiniciar a stack all-in-one”. Mantenha o liveness local e barato; permita que o readiness informe migrações ou inicialização sem provocar uma tempestade de restarts.

A área de maior risco em uma atualização é o fato de a imagem all-in-one mover vários serviços em conjunto; por isso, as migrações do banco de dados e da aplicação precisam ser ensaiadas com base em snapshots. Leia as release notes, crie um snapshot do estado, faça o deploy da versão de destino sobre uma cópia restaurada e repita a ação de aceitação. Se a URL pública mudar depois que os usuários geraram links de compartilhamento e callback, correlacione a requisição do cliente com o primeiro log relevante da aplicação, em vez de excluir o estado ou adicionar redirects às cegas.

Cinco verificações mais fortes que a saúde do container

Antes da chegada dos usuários reais, crie uma release worksheet para o Baserow. Ela deve indicar a imagem fixada, a porta 80, a origin canônica, os caminhos persistentes e o responsável por garantir memória suficiente para o Postgres, o Redis, o backend e os workers incluídos. Anexe o resultado esperado desta transação: criar um banco de dados e uma view, importar um CSV, editar linhas em duas sessões e fazer upload de um arquivo antes de reiniciar a stack all-in-one.

Use a worksheet depois de uma substituição normal e depois de uma restauração limpa. A recuperação só será aceita se tabelas, views, usuários, automações e arquivos retornarem a partir do backup completo de /baserow/data. Colete também um breve trace de recursos que cubra o Postgres, o Redis, os workers do Celery, a quantidade de linhas, o tamanho das importações e os editores simultâneos incluídos; mantenha-o junto da release para que futuras mudanças de capacidade sejam comparadas com a mesma carga de trabalho.

Inclua uma falha controlada: envie uma entrada inofensiva próxima do limite de recursos ou de formato associado a este limite: a URL pública muda depois que os usuários geraram links de compartilhamento e callback. Confirme que o Baserow relata o problema no limite correto, restaure a condição válida e execute a transação novamente. Isso verifica a visibilidade dos erros, não apenas o sucesso, e impede que uma interface com aparência saudável esconda um worker, callback ou conexão de banco de dados quebrados.

Conecte o Baserow ao ciclo de vida do Dockup

O deployment do Baserow em um clique do Dockup deve tornar a substituição segura: a rota continua apontando para a porta 80, os secrets não são embutidos na imagem e os caminhos persistentes são restaurados no novo container. O mesmo deployment pode ser executado no compute do Dockup ou em uma máquina conectada.

Conclua o trabalho específico da aplicação confirmando o requisito local — memória suficiente para o Postgres, o Redis, o backend e os workers incluídos —, aplicando o endereço público canônico e executando esta verificação de aceitação: criar um banco de dados e uma view, importar um CSV, editar linhas em duas sessões e fazer upload de um arquivo antes de reiniciar a stack all-in-one. Adicione o resultado da restauração ao runbook antes da chegada dos usuários reais.

Perguntas frequentes

O que o Baserow precisa para um deployment em produção?

Encaminhe o container do Baserow na porta 80 por meio de uma origin HTTPS. O requisito de runtime local é ter memória suficiente para o Postgres, o Redis, o backend e os workers incluídos. Não considere o Baserow pronto até conseguir criar um banco de dados e uma view, importar um CSV, editar linhas em duas sessões e fazer upload de um arquivo antes de reiniciar a stack all-in-one.

Quais dados do Baserow devem fazer parte de um backup?

Persista /baserow/data e inclua toda a árvore /baserow/data e exports lógicos periódicos do banco de dados no mesmo manifesto de recuperação. Uma restauração limpa do Baserow só será aprovada quando tabelas, views, usuários, automações e arquivos retornarem a partir do backup completo de /baserow/data.

O Baserow precisa de HTTPS atrás de um reverse proxy?

Use HTTPS para a origin pública do Baserow e mantenha a porta 80 na rota interna. Aplique corretamente a configuração do Baserow: defina BASEROW_PUBLIC_URL como a origin externa exata. No Baserow, o HTTPS protege credenciais ou conteúdo dos usuários durante o trânsito e mantém consistente o comportamento do cliente sensível à origin.

Como testar uma atualização do Baserow?

Restaure o estado atual do Baserow em um deployment isolado, aplique a versão candidata e repita sua transação de aceitação. Dê atenção especial ao fato de a imagem all-in-one mover vários serviços em conjunto; por isso, as migrações do banco de dados e da aplicação precisam ser ensaiadas com base em snapshots. Mantenha a imagem anterior do Baserow até entender os limites da migração de dados e do rollback.