self hosted: Vercel e Supabase no produto, VPS só no job de GPU

No meio do Autocut, Thiago pede um botão que leve direto para a revisão final. Regenerar o preview o devolve para a revisão. No meio dessa briga com o fluxo, ele vira para o Gabriel e fecha o desenho de hospedagem: self hosted do app inteiro fica de fora. Vercel e Supabase carregam o produto. A VPS existe só para o job que precisa de GPU.

Se a VPS der problema, o produto continua: cai só a chamada do Pod, porque o app, o banco e o render não moram na mesma máquina.

Self hosted do app inteiro é o que ele recusa

No meio da tela do Autocut:

É vercel, né, ô Gabriel? Porque não adianta confiar em VPS. Terceiriz o BOPRO é muito barato para você ficar cuidando do self hosted, entendeu?

Vercel é o vercel da fala. Terceiriz o BOPRO é terceiriza: para ele, é barato. O app fica na Vercel. O banco fica no Supabase. Ele quase abre uma exceção e corta o próprio exemplo:

Tipo, se fosse um sistema interno, sei lá, eu tenho um hospital e tem um sistema interno no hospital, quem sabe, entendeu? Mas mesmo assim eu já fiz sistema para hospital e acabei usando Versel também. Hoje em dia, cara, tipo, Versel Subabase e e é nós.

Versel é Vercel. Subabase é Supabase.

Ele não vê vantagem em ficar dono da máquina do produto quando terceirizar o app e o banco é barato.

Tipo, não vejo vantagem em em fazer meu self host de tipo sendo que é barato.

A VPS entra só no job que chama o RunPod

O Autocut precisa renderizar vídeo. Esse pedaço não vai para a Vercel nem para o Supabase. Aí entra a VPS para rodar o RunPod, chamar a API do RunPod e renderizar.

Isso aí só vale a pena, por exemplo, eu vou ter que ter uma VPS para ficar rodando R pod, para ficar chamando a P do Rod para ficar renderizando o vídeo. Isso aí eu vou precisar. Eu não vou usar Versel nem supa base. Por quê? Porque fica muito mais barato, entendeu?

R pod e a P do Rod são o RunPod. Versel de novo é Vercel. Supa base é Supabase. O job de GPU na Vercel ou no Supabase sai mais caro, no recorte que ele fez, e por isso a VPS existe para chamar o RunPod e renderizar. Isso aparece também em identidade visual instagram.

Na mesma live ele também travou no teste de integração do slider de capa, outra briga, outro post. Foi o mesmo caminho de vibe coding para refinar o briefing em vez de rerrolar o mesmo prompt.

Se a VPS cai, só cai a chamada do Pod

Ele nomeia os 3 e recusa deixar tudo na VPS no mesmo fôlego:

Então eu vou precisar dos três, mas não que eu vou deixar tudo hospedado na na VPS, entendeu? Eu eu eu acabo criando contingência, sacou? Já pensou dá problema na VPS, cair tudo? Não, se dá problema na VPS só vai cair a chamada do Pod. O restante tudo tá funcionando, sacou?

Pod, nessa fala, é o RunPod. A live não mostra a VPS caindo. Ele descreve o desenho: se der problema na VPS, o produto na Vercel e no Supabase segue, e o que para é a chamada do Pod. Isso aparece também em query params. Foi o mesmo caminho de documentacao tecnica.

:::comparacao rotulo: A CONTINGÊNCIA titulo_a: Tudo na VPS texto_a: Self hosted do app inteiro. Dá problema na VPS, cai tudo titulo_b: Vercel, Supabase e VPS só no job texto_b: Dá problema na VPS, só cai a chamada do Pod ::: O mesmo problema apareceu em [supabase self hosted](/supabase-self-hosted-com-vibe-coding).

No vibe coding, desenhe os 3 antes da próxima feature

Amanhã, no vibe coding de um produto com um job pesado, comece pelos 3. Vercel no app, Supabase no banco, VPS só no job que precisa de GPU. Se o job cair, o restante precisa continuar. No vibe coding do Autocut, a próxima feature do app não precisa subir na mesma caixa do render. O que precisa continuar se a máquina do job cair fica na Vercel e no Supabase. O que só a VPS faz mais barato é chamar o RunPod e renderizar o vídeo.

A live fechou o desenho no meio de um botão de revisão. Dá para assistir à live e ouvir o "É vercel, né, ô Gabriel?" e a contingência: se a VPS cai, só cai o Pod.