name: supabase-self-hosted-vps-debug

description: Debug Supabase self-hosted (Docker) on VPS — pg_hba.conf, SERVICE_ROLE_KEY JWT, Kong JWT stripping, Edge Function inline verification

category: supabase

Supabase Self-hosted (Docker) Debug

Debug do Supabase self-hosted em VPS (Docker Compose) — focado em erros de autenticação PostgreSQL e JWT.

Stack atual (VPS 31.97.243.106)

Stack atual (VPS 31.97.243.106)

Docker Compose em /docker/deploy-vps/. Containers:

• - deploy-vps-kong-1 — API gateway (⚠️ pode estar Exited — se morto, usar Nginx como proxy direto)
• - deploy-vps-auth-1 — GoTrue (autenticação) — IP 172.23.0.3, porta 9999
• - deploy-vps-rest-1 — PostgREST — exposto em 0.0.0.0:3002 no host
• - deploy-vps-db-1 — PostgreSQL 15 — IP 172.23.0.2
• - deploy-vps-functions-1 — Deno Edge Functions — IP 172.23.0.5, porta 3000
• - deploy-vps-storage-1 — Storage API (⚠️ pode estar Exited)
• - deploy-vps-studio-1 — Studio (⚠️ pode estar Restarting)

Atenção: deploy-vps-db-1 pode estar "Exited" — verificar com docker ps -a e iniciar com docker start deploy-vps-db-1.

Credenciais

• - POSTGRES_PASSWORD: Rochasales2024
• - JWT_SECRET: kETxz0JNJhJyg5UYxbd8zG6g2v9kXTYZGjY+3v7LUKI=
• - ANON_KEY: eyJ_REDACTED_SUPABASE
• - SERVICE_ROLE_KEY: JWT assinado com JWT_SECRET, role=supabase_admin, is_super_admin=true

SSH

`bash

sshpass -p "Marcia19671951@" ssh -o StrictHostKeyChecking=no root@31.97.243.106

`

Casos comuns de falha (Jun 2026)

GoTrue dando 502 — "hostname resolving error (lookup db on 127.0.0.11:53: server misbehaving)"

Sintomas: docker logs deploy-vps-auth-1 mostra hostname resolving error (lookup db on 127.0.0.11:53: server misbehaving) e container reinicia em loop.

Causa 1 — Banco desligado: deploy-vps-db-1 pode estar no estado "Exited" (foi desligado manualmente ou por OOM killer). GoTrue não consegue resolver db.

Diagnóstico: docker ps -a --filter 'name=deploy-vps' --format '{{.Names}} {{.Status}}'

Solução: docker start deploy-vps-db-1

Causa 2 — Docker network sandbox com defeito: Containers conectados à rede mas sem IP (NetworkSettings.Networks mostra IP vazio). Afeta todos os containers.

Diagnóstico: docker inspect deploy-vps-auth-1 --format '{{range .NetworkSettings.Networks}}{{.IPAddress}} {{end}}' retorna "invalid IP" ou string vazia.

Solução: systemctl restart docker (reinicia o daemon Docker e os network sandboxes). Após o restart, verificar IPs: docker network inspect deploy-vps_default --format '{{range .Containers}}{{.Name}} {{.IPv4Address}}\n{{end}}'. Recriar containers que não recuperarem IP: docker rm -f && docker run -d ...

Causa 3 — Container em rede errada: Auth está em deploy-vps_default mas banco em root_default (redes Docker separadas).

Diagnóstico: docker inspect deploy-vps-db-1 --format '{{range .NetworkSettings.Networks}}{{.NetworkID}} {{end}}' mostra rede diferente do auth.

Solução: Conectar o auth na rede do banco via docker network connect (pode falhar com "network sandbox not found" se o sandbox já estiver quebrado — usar systemctl restart docker primeiro).

Kong Exited (código 137) — API 502 sem GoTrue

Sintomas: Todos os endpoints /auth/v1/, /rest/v1/ etc. retornam 502.

Causa: deploy-vps-kong-1 está morto ( Exit 137) e sem config (/tmp/kong.yml: Permission denied).

Solução alternativa (sem Kong): Configurar Nginx no host como proxy direto pros containers. Editar /etc/nginx/sites-enabled/rochasales.conf:

`

location /auth/v1/ {

proxy_pass http://:9999; # GoTrue — IP verificado com docker inspect

proxy_http_version 1.1;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_read_timeout 86400;

}

location /rest/v1/ {

proxy_pass http://127.0.0.1:3002; # PostgREST exposto na porta 3002 do host

}

location /functions/v1/ {

proxy_pass http://:3000; # Edge Functions

}

`

Depois: nginx -t && nginx -s reload

IPs conhecidos (podem mudar após restart Docker):

• - deploy-vps-db-1: 172.23.0.2
• - deploy-vps-auth-1: 172.23.0.3
• - deploy-vps-functions-1: 172.23.0.5
• - deploy-vps-rest-1: 172.23.0.4 (exposto em 0.0.0.0:3002 no host)

GoTrue missing environment variables

GoTrue morre com "required key GOTRUE_SITE_URL missing value" se faltarem variáveis. Variáveis mínimas necessárias:

`bash

docker run -d --name deploy-vps-auth-1 \

--network deploy-vps_default \

-e GOTRUE_API_HOST=0.0.0.0 \

-e GOTRUE_API_PORT=9999 \

-e API_EXTERNAL_URL=https://rochasalesseguros.com.br \

-e GOTRUE_DB_DRIVER=postgres \

-e 'GOTRUE_DB_DATABASE_URL=postgres://supabase_auth_admin:postgres@db:5432/postgres' \

-e GOTRUE_DB_SCHEMA=auth \

-e GOTRUE_DB_SEARCH_PATH=auth,public \

-e GOTRUE_SITE_URL=https://rochasalesseguros.com.br \

-e GOTRUE_JWT_SECRET= \

-e GOTRUE_JWT_EXP=3600 \

-e GOTRUE_MAILER_AUTOCONFIRM=true \

-e GOTRUE_DB_MIGRATIONS_PATH=/usr/local/etc/gotrue/migrations \

--restart unless-stopped \

supabase/gotrue:v2.99.0

`

"password authentication failed for user 'postgres'" (SQLSTATE 28P01)

Causa: pg_hba.conf usa scram-sha-256 mas o banco não tem senha configurada para o postgres via SRP/GoTrue.

Solução: Alterar pg_hba.conf para trust. Mas há uma pegadinha crítica:

> ⚠️ A imagem supabase/postgres:15.1.0.117 tem DOIS arquivos pg_hba.conf:

> - /var/lib/postgresql/data/pg_hba.conf → regenerado a cada restart (não mexer)

> - /etc/postgresql/pg_hba.conf → é o que vale, mas não está em bind mount

Solução permanente: Adicionar bind mount no docker-compose.yml:

`yaml

services:

db:

volumes:

- ./data/db/pg_hba.conf:/etc/postgresql/pg_hba.conf:ro

`

Sem isso, qualquer docker compose down && up -d reverte a alteração.

SERVICE_ROLE_KEY dando "Invalid number of parts: Expected 3 parts; got 1"

Causa: A chave estava guardada como texto plano (o JWT_SECRET em si), não como JWT.

Solução: Gerar um JWT properly assinado:

`python

import hmac, hashlib, base64, json, time

secret = "kETxz0JNJhJyg5UYxbd8zG6g2v9kXTYZGjY+3v7LUKI="

payload = {

"iss": "supabase", "ref": "rochasales", "role": "supabase_admin",

"iat": 1780425523, "exp": 1783017523,

"is_super_admin": True, "email": "service_role@rochasales"

}

header = {"alg": "HS256", "typ": "JWT"}

payload_b64 = base64.urlsafe_b64encode(json.dumps(payload).encode()).rstrip(b'=').decode()

header_b64 = base64.urlsafe_b64encode(json.dumps(header).encode()).rstrip(b'=').decode()

sig = hmac.new(secret.encode(), f"{header_b64}.{payload_b64}".encode(), hashlib.sha256).digest()

sig_b64 = base64.urlsafe_b64encode(sig).rstrip(b'=').decode()

token = f"{header_b64}.{payload_b64}.{sig_b64}"

print(token)

`

No .env: SERVICE_ROLE_KEY=eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9... (JWT completo)

Kong removendo assinatura JWT

Kong transforma JWTs de service role em tokens de 1 parte (sem assinatura real) ao passar pelo /auth/v1/user. Não tentar борьбы с Kong — usar verificação inline de JWT no Edge Functions (Web Crypto API).

Verificações úteis

`bash

Status dos containers

docker ps --format "table {{.Names}}\t{{.Status}}" | grep deploy

Logs do auth

docker logs deploy-vps-auth-1 --tail 50

Logs do rest

docker logs deploy-vps-rest-1 --tail 50

Ver pg_hba.conf que vale

docker exec deploy-vps-db-1 bash -c 'cat /etc/postgresql/pg_hba.conf | grep -v "^#" | grep -v "^$"'

Testar conexão ao banco

docker exec deploy-vps-db-1 psql -U postgres -d postgres -c "SELECT version();"

Reiniciar só um container

docker restart deploy-vps-functions-1

Reiniciar todos

cd /docker/deploy-vps && docker compose down && docker compose up -d

`

Volumes Docker (importante!)

• - DB data: volume anônimo Docker (não é bind mount) — reinícios não perdem dados, mas docker compose down pode resetar se não houver docker-compose.yml com volume named
• - Edge Functions: volume named rochasales_functions montando /opt/rochasales/supabase/functions → /home/deno/functions — não se perde com restart

Supabase Cloud vs Self-hosted neste projeto

• - Supabase Cloud (projeto dauftiqcvgaydddoxqhh) — REST API, Auth, Storage para DocCorretor e ComercialRS
• - Supabase Self-hosted (VPS) — Kong, Auth, PostgREST, Edge Functions para rochasalesseguros.com.br

Ambos compartilham o mesmo projeto Cloud — mudanças na AUTH ou chaves afetam os dois sistemas.