📄 SKILL.md

← Vault

name: comercialrs-lovable-vps-migration

description: Migração do ComercialRS de Lovable para deploy 100% VPS, incluindo configuração de Vite, Supabase, e Meta WhatsApp

ComercialRS: Lovable → VPS Migration

Contexto

Projeto ComercialRS (CRM de seguros) originalmente deployado via Lovable (lovable.dev). Backend: Supabase Cloud + Edge Functions + Node.js na VPS. Frontend: React + Vite.

Problema: .env com URLs Supabase conflitantes

O .env TEM duas URLs Supabase que DEVEM ser IGUAIS:

`bash

SUPABASE_URL="https://dauftiqcvgaydddoxqhh.supabase.co"

VITE_SUPABASE_URL="https://dauftiqcvgaydddoxqhh.supabase.co"

`

Erro crítico: Se SUPABASE_URL aponta pro servidor local (http://31.97.243.106:9999) e VITE_SUPABASE_URL aponta pro Cloud, o realtime WebSocket vai tentar conectar no servidor local via ws:// (HTTP inseguro) e será bloqueado por Mixed Content numa página HTTPS.同时 auth falha porque as credenciais estão num servidor e o frontend conecta no outro.

Regra de ouro: SUPABASE_URL e VITE_SUPABASE_URL SEMPRE o mesmo valor.

Lovable independence

O Lovable gerencia builds e deploys do frontend independently do dist/ local. Changes ao vite.config.ts e código fonte NÃO afetam comercialrs.rochasalesseguros.com.br automaticamente — precisam ser pushados pelo painel do Lovable.

Decisão arquitetural: Migrar 100% para deploy VPS, removendo Lovable completamente.

Estrutura do projeto

`

/var/www/comercialrs/

├── src/

│ ├── main.tsx

│ ├── root.html # Template HTML (NAO index.html)

│ ├── pages/Auth.tsx

│ └── components/

├── supabase/functions/ # Edge Functions (Deno)

├── dist/ # Build output

├── vite.config.ts

└── package.json

`

Vite config (funcionando)

Input do build é src/root.html (NAO index.html). O index.html na raiz é placeholder Lovable (245 bytes, sem script).

Build

`bash

cd /var/www/comercialrs && rm -rf dist && node ./node_modules/vite/bin/vite.js build && node scripts/post-build-fix.mjs

`

Nginx: Proxy AUTH para Supabase Cloud (CRÍTICO)

O nginx do ComercialRS inicialmente tinha /auth/v1/ apontando para GoTrue LOCAL na porta 9999 (herança do deploy original). Isso faz auth falhar mesmo com credenciais corretas.

Configuração CORRETA do nginx para Supabase Cloud:

`nginx

Proxy AUTH para Supabase Cloud

location /auth/v1/ {

proxy_pass https://dauftiqcvgaydddoxqhh.supabase.co/auth/v1/;

proxy_set_header Host dauftiqcvgaydddoxqhh.supabase.co;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header apikey ;

proxy_ssl_server_name on;

proxy_request_buffering off;

proxy_read_timeout 300;

}

Proxy REST API - Supabase Cloud

location /rest/v1/ {

proxy_pass https://dauftiqcvgaydddoxqhh.supabase.co;

proxy_set_header Host dauftiqcvgaydddoxqhh.supabase.co;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header apikey ;

proxy_ssl_server_name on;

proxy_request_buffering off;

proxy_read_timeout 300;

}

Proxy Storage - Supabase Cloud

location /storage/v1/ {

proxy_pass https://dauftiqcvgaydddoxqhh.supabase.co;

proxy_set_header Host dauftiqcvgaydddoxqhh.supabase.co;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header apikey ;

proxy_ssl_server_name on;

proxy_request_buffering off;

proxy_read_timeout 300;

}

Proxy Edge Functions - Supabase Cloud

location /functions/v1/ {

proxy_pass https://dauftiqcvgaydddoxqhh.supabase.co;

proxy_set_header Host dauftiqcvgaydddoxqhh.supabase.co;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header apikey ;

proxy_ssl_server_name on;

proxy_request_buffering off;

proxy_read_timeout 300;

}

`

Arquivo: /etc/nginx/sites-enabled/comercialrs.rochasalesseguros.com.br

Após mudar: sudo nginx -s reload

Supabase Anon Key Pode Expirar

A anon key (SUPABASE_PUBLISHABLE_KEY / VITE_SUPABASE_PUBLISHABLE_KEY) no .env PODE expirar se for regenerada no dashboard do Supabase.

Sintoma: Invalid API key no login, mesmo com credenciais corretas.

Solução:

1. Vai em https://supabase.com/dashboard/project/dauftiqcvgaydddoxqhh/settings/api

2. Copia a chave anon public atual

3. Atualiza no .env

4. Rebuild: cd /var/www/comercialrs && npm run build

5. nginx reload

Verificar key válida:

`bash

curl -s "https://dauftiqcvgaydddoxqhh.supabase.co/health" \

-H "apikey: "

Resposta esperada: {"status":"hey","data":{"version":"1.0.0"}}

`

VITE Env Vars São Baked no Bundle

As variáveis VITE_* são compiladas dentro do bundle no momento do npm run build. Mudar .env NÃO surte efeito imediato — é necessário rebuildar.

Fluxo:

1. npm run build → Vite embedding import.meta.env.VITE_* dos valores do .env no bundle

2. Bundle deployado no nginx (ou Lovable)

3. Navegador baixa bundle com keys já fixas

Regra: Após mudar .env, SEMPRE rebuildar antes de testar.

Testar Login via API (sem browser)

`bash

curl -s -X POST "https://comercialrs.rochasalesseguros.com.br/auth/v1/token?grant_type=password" \

-H "Content-Type: application/json" \

-H "apikey: " \

-d '{"email":"tecrochasales@gmail.com","password":"Rochasales2024"}'

`

Sucesso: Retorna {"access_token": "REDACTED", "user": {"id": "...", "email": "..."}}

Pending tasks