← Blog

Hospede o Metabase com Postgres

Railyard

21 de junho de 2026 · 7 min de leitura

Siga isso no seu próprio servidor. Comece grátis, sem cartão

A maioria das ferramentas de BI cobra por assento, o que transforma “deixa a equipe toda ver o dashboard” num item de custo que cresce cada vez que alguém novo precisa de acesso. O Metabase é uma analítica self-service open-source que faz o trabalho essencial, conectar um banco de dados, montar gráficos e dashboards, deixar pessoas não técnicas fazerem perguntas sem escrever SQL, sem cobrança por assento depois que estiver rodando no seu próprio servidor. Este guia monta tudo com seu próprio banco Postgres para guardar dashboards e perguntas, atrás do Caddy para o HTTPS, e depois mostra o caminho de um clique.

No final, você vai ter o Metabase rodando no seu próprio domínio, conectado ao próprio repositório de metadados, pronto para apontar para qualquer banco de dados ou warehouse que você realmente queira analisar.

O que você vai precisar

  • Um servidor. O Metabase em si é uma aplicação JVM com requisitos modestos para uma equipe pequena; um Hetzner CX23 (2 vCPUs, 4 GB de RAM, 40 GB NVMe) por €5,99/mês sem VAT roda o Metabase e seu próprio Postgres com folga. Uso mais pesado de dashboards ou conjuntos de resultados grandes pedem mais memória; um CX33 (4 vCPUs, 8 GB, €8,99/mês) é o próximo passo.
  • Um domínio ou subdomínio com um registro A de DNS apontado para o servidor (este guia usa bi.example.com).
  • Acesso SSH e cerca de 15 minutos.
  • Opcionalmente, o banco de dados ou warehouse que você realmente quer que o Metabase consulte. Este guia só configura o próprio banco de aplicação do Metabase; conectar sua fonte de dados real acontece de dentro do app depois do primeiro login.

Etapa 1: Provisione o servidor e aponte o DNS para ele

bi.example.com.  A  203.0.113.40
ssh root@203.0.113.40
apt update && apt upgrade -y

Etapa 2: Instale o Docker

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker
docker --version
docker compose version

Etapa 3: Escreva o arquivo de ambiente

mkdir -p /opt/metabase && cd /opt/metabase
DB_NAME=metabase
DB_USER=metabase
DB_PASSWORD=change-this-to-a-random-string

Essa senha é para o próprio banco Postgres do Metabase, o que guarda dashboards, perguntas salvas e contas de usuário, não a fonte de dados que você vai eventualmente conectar a ele.

Etapa 4: Escreva o arquivo Docker Compose

Este guia usa a release estável atual, Metabase v0.64.3.4, fixada explicitamente em vez de latest para que uma release upstream não relacionada não mude sua stack debaixo dos seus pés:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy-data:/data
      - caddy-config:/config

  metabase:
    image: metabase/metabase:v0.64.3.4
    restart: unless-stopped
    environment:
      MB_DB_TYPE: postgres
      MB_DB_HOST: db
      MB_DB_PORT: "5432"
      MB_DB_DBNAME: ${DB_NAME}
      MB_DB_USER: ${DB_USER}
      MB_DB_PASS: ${DB_PASSWORD}
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:3000/api/health || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 10

  db:
    image: postgres:18-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${DB_NAME}
      POSTGRES_USER: ${DB_USER}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - metabase-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${DB_USER} -d ${DB_NAME}"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  metabase-db-data:
  caddy-data:
  caddy-config:

MB_DB_TYPE, MB_DB_HOST, MB_DB_PORT, MB_DB_DBNAME, MB_DB_USER e MB_DB_PASS são as variáveis de ambiente exatas que a própria documentação do Metabase especifica para apontá-lo a um banco Postgres externo em vez do banco H2 embutido para o qual ele volta sem elas, que não é pensado para nada além de um teste rápido. Valide o arquivo:

docker compose config

Etapa 5: Escreva o Caddyfile

bi.example.com {
    reverse_proxy metabase:3000
}

Etapa 6: Suba a stack

docker compose up -d
docker compose ps

Você deve ver caddy, metabase e db todos running, com metabase reportando healthy assim que a própria inicialização terminar, o que leva um ou dois minutos no primeiro boot já que ele está inicializando o próprio schema de metadados no Postgres. Acompanhe os logs se estiver demorando mais:

docker compose logs -f metabase

Acesse https://bi.example.com; você deve cair no assistente de configuração inicial do Metabase com um certificado HTTPS válido.

Etapa 7: Termine a configuração e conecte uma fonte de dados real

O assistente de configuração cria sua conta de admin diretamente, sem senha padrão para trocar depois, do jeito que alguns apps self-hosted funcionam. Depois de entrar, adicione o banco de dados que você realmente quer analisar em Settings → Admin settings → Databases → Add a database. Essa é uma conexão separada do container Postgres da Etapa 4, que só guarda as próprias perguntas e dashboards do Metabase, não os seus dados.

Etapa 8: Faça backup do banco de metadados

Dashboards, perguntas salvas e contas de usuário vivem no container Postgres da Etapa 4, não nas fontes de dados que você conecta. Faça backup dele numa agenda:

docker compose exec -T db pg_dump -U ${DB_USER} ${DB_NAME} | gzip > /opt/metabase/backups/metabase-$(date +%F).sql.gz

Copie o arquivo para fora do servidor num cron job. Restaurar depois de uma instalação nova traz seus dashboards e perguntas de volta; suas fontes de dados reais não são afetadas de qualquer forma, já que não são guardadas aqui.

Etapa 9: Upgrades

docker compose pull metabase
docker compose up -d metabase

Confira as próprias release notes do Metabase antes de saltar por um número de versão maior; ele roda suas próprias migrações de banco de dados automaticamente na inicialização, e um backup da Etapa 8 antes disso é um seguro barato contra algo dar errado.

O caminho curto: faça com o Railyard

Tudo isso acima, os dois containers, o arquivo de ambiente, o proxy reverso, é o que o template de stack Metabase + Postgres do Railyard configura para você. Escolha no catálogo de templates: https://app.railyard.run/deploy?stack=metabase-postgres. O Railyard provisiona o Metabase e uma instância dedicada de Postgres juntos e liga a conexão automaticamente, então não há nada para conectar à mão. A mesma separação da Etapa 7 ainda se aplica: essa instância Postgres é o próprio repositório de metadados do Metabase, e seu warehouse ou banco de produção real é conectado separadamente em Settings → Databases depois do primeiro login. A partir daí, database backups rodam numa agenda e restauram com um clique.

Solução de problemas

O HTTPS nunca é emitido. O DNS ainda não está apontando para o servidor. dig +short bi.example.com deve retornar o IP do servidor.

O container do Metabase reinicia em loop logo depois de iniciar. Confira docker compose logs metabase primeiro em busca de um erro de conexão com o banco; a causa mais comum é MB_DB_PASS não corresponder ao que de fato está no ambiente do container db, geralmente porque o .env não estava presente ou nomeado corretamente quando a stack subiu pela primeira vez.

O primeiro login demora muito, ou dá timeout no navegador. O Metabase roda suas próprias migrações de schema contra o Postgres no primeiro boot, o que pode levar um ou dois minutos dependendo da velocidade do servidor. Confira se docker compose logs metabase ainda está progredindo em vez de parado antes de assumir que algo quebrou.

Os dashboards demoram para carregar. Isso é mais frequentemente a fonte de dados que o Metabase está consultando do que o Metabase em si; consultas grandes e sem índice contra um banco de produção vão ser lentas independente de quem está perguntando. Confira o desempenho da consulta contra o banco conectado real, e considere uma réplica de leitura para carga de relatório pesada se o próprio banco de produção estiver sob pressão.

Falta de memória num servidor pequeno. A JVM em que o Metabase roda tem necessidades reais de memória de base; um CX23 é suficiente para uma equipe pequena, mas se você também estiver rodando outros containers na mesma máquina, docker compose ps mostrando metabase como exited combinado com dmesg | grep -i "out of memory" confirma isso, e a correção é mais memória ou menos coisas compartilhando este servidor.

Perguntas frequentes

Posso conectar mais de um banco de dados? Sim, quantos você quiser, cada um configurado separadamente em Settings → Databases; o Metabase em si só precisa daquela única instância Postgres deste guia para o próprio armazenamento, independente de quantas fontes você conecta a ele.

O Metabase precisa de acesso à internet para rodar? Não, depois de instalado, ele roda inteiramente contra o próprio banco Postgres e qualquer fonte de dados que você conectar, sem dependência de saída para a operação do dia a dia.

Qual é a diferença entre a versão open-source e as pagas? A edição open-source cobre dashboards, perguntas, alertas e o construtor de consultas que este guia configura; os planos pagos do Metabase adicionam coisas como SSO, logs de auditoria e white-labeling voltados para organizações maiores, que este guia não precisa.

Pessoas não técnicas de fato conseguem usar isso sem aprender SQL? Esse é o recurso específico em torno do qual o Metabase é construído: o construtor de perguntas dele deixa alguém filtrar, agrupar e transformar dados em gráfico através de uma interface visual, com SQL disponível como opção para quem quiser, não como exigência.

Como isso é mais barato do que uma ferramenta de BI hospedada? O custo de uma ferramenta hospedada cobrada por assento cresce com quantas pessoas na empresa precisam de um dashboard; um CX23 por cerca de seis euros por mês custa o mesmo, seja com três pessoas ou trinta olhando para ele.

Posso rodar o Metabase sem Docker? Sim, ele também vem como um arquivo JAR simples que você roda direto com uma JVM, o que algumas equipes preferem num servidor que já gerencia deploys Java; a imagem Docker é o caminho que este guia e o template do Railyard usam, já que mantém a versão da JVM e as dependências fixadas junto com o próprio app em vez de depender do que já está instalado no host.

O Metabase dá a uma equipe dashboards self-service sem transformar “mais uma pessoa precisa de acesso” numa conversa de faturamento. A configuração aqui são dois containers, um arquivo de ambiente e um proxy reverso; a partir daí, é o mesmo construtor de perguntas e os mesmos dashboards, rodando num servidor com um custo mensal fixo em vez de um que escala com o número de pessoas.

Por que escolhem o Railyard para isso

  • Sua própria conta de cloud. Faça deploy no DigitalOcean, Hetzner, Vultr, AWS, OVHcloud, ou em qualquer servidor Linux via SSH, cobrado direto pelo seu provedor, sem markup.
  • Um preço fixo por equipe. O Free é grátis para sempre: um servidor mais um servidor de banco de dados, três apps, sem cartão. O Pro custa US$19 por mês para até cinco servidores e apps ilimitados. O Team custa US$49 por mês com servidores ilimitados. Sem cobrança por app, por deploy, por assento ou por gigabyte.
  • Templates de um clique. Faça deploy de apps open source, como bancos de dados, analytics e ferramentas de dev, no seu próprio servidor em um clique.
  • Bancos de dados gerenciados. Postgres, MySQL e Redis com backups programados, verificados por restauração, e recuperação point-in-time.
  • Push-to-deploy. Faça deploy a partir do GitHub, GitLab ou da CLI, com HTTPS automático e releases sem downtime.

Pule a configuração do servidor

Faça o deploy do Metabase com Postgres já ligado a partir do catálogo de templates do Railyard.

Plano grátis, sem cartão, e 14 dias de Pro para cada equipe nova. Um preço fixo por equipe.