Skip to content

Criador de apps com IA e Vercel: deploy na sua conta

Criador de apps com IA com Vercel: o que a integração resolve

Sim, dá. Um projeto gerado no Zugo pode ser publicado na sua própria conta da Vercel em vez de ficar só no endereço seu-slug.zugo.run. A geração continua acontecendo no Zugo e consome créditos. O deploy, a hospedagem, o domínio e a fatura passam a ser administrados por você, dentro do painel da Vercel.

O que a integração com a Vercel faz de fato?

Ela muda o dono da infraestrutura. O Zugo continua sendo o lugar onde o projeto nasce e é ajustado por descrição em português, e a Vercel passa a ser o lugar onde o resultado roda, com as suas variáveis, os seus domínios e o seu histórico de deploys.

Enquanto o projeto vive em seu-slug.zugo.run, quem responde por certificado, disponibilidade e endereço é a plataforma. Depois que ele passa a rodar na sua conta, essa responsabilidade atravessa a mesa: configuração, monitoramento e cobrança da hospedagem viram trabalho seu.

Essa troca compensa para quem já tem conta, time ou política de infraestrutura montada na Vercel. Para quem só precisa de um link no ar até sexta-feira, a publicação nativa do Zugo entrega o mesmo endereço visível ao visitante sem abrir nenhuma conta nova.

Quando vale publicar na Vercel e quando não vale?

Vale quando existe um motivo concreto para a hospedagem ser sua. Auditoria interna, exigência do jurídico, um domínio corporativo que já aponta para lá, um time que acompanha todos os projetos em um painel só: são razões reais, e todas terminam no mesmo pedido, que é controle.

Não vale quando o motivo é a sensação de parecer mais profissional. Com domínio próprio conectado, o visitante vê o mesmo nome nos dois cenários. A diferença fica nos bastidores, e bastidores só valem o custo de manutenção quando alguém de fato entra neles.

Um caso intermediário aparece bastante: você começa no .zugo.run para validar a ideia e migra depois, quando o projeto vira produto. Essa ordem funciona bem porque o trabalho de configurar hospedagem acontece uma vez, quando já existe algo que merece o esforço.

Como é o caminho do projeto até a sua conta?

O percurso tem quatro etapas, e a ordem importa mais que os detalhes de tela.

Primeiro você constrói e edita dentro do Zugo até o resultado estar firme. Cada construção passa por uma verificação em sandbox antes de ser entregue, então o que chega até você já abriu pelo menos uma vez. Uma falha aparece como falha, e não disfarçada de projeto pronto.

Segundo, você conecta a conta da Vercel e autoriza o envio. Terceiro, o projeto sai do Zugo e entra no seu painel como qualquer outro deploy seu. Quarto, você aponta o domínio, define variáveis de ambiente e passa a acompanhar as builds do lado de lá.

O ponto que costuma surpreender é que a edição continua no Zugo. Você descreve a mudança em português, gera a nova versão e envia de novo. O painel da Vercel guarda o histórico, mas não é ali que você reescreve a seção de preços.

Quanto custa em créditos enviar o projeto para a Vercel?

Nada. Créditos são a moeda da geração, não da publicação. Esta é a tabela completa.

Ação no Zugo Créditos
Construção de um site, app ou jogo 6
Edição sobre um projeto existente 3
Plataforma multipágina, três primeiras páginas 12
Cada página adicional da plataforma 3
Construção no modo Hi-Fi 12
Edição no modo Hi-Fi 6
Publicar em seu-slug.zugo.run 0
Enviar o projeto para a sua conta da Vercel 0

O plano gratuito inclui 5 créditos, ou seja, menos que uma construção inteira, que sai por 6. Ele serve para conhecer a ferramenta, não para terminar um projeto. O Pro custa $25 por mês com 200 créditos, e o Business custa $99 por mês com 800 créditos.

Traduzindo os 200 créditos do Pro em trabalho: dá cerca de 16 plataformas multipágina, ou 33 construções avulsas, ou 66 edições ao longo do mês. A conta muda se você usar o modo Hi-Fi, que dobra o preço de cada ação. O custo da hospedagem na Vercel é separado e definido por eles.

O que acontece com o endereço .zugo.run depois do envio?

Ele continua existindo, e isso é mais útil do que parece. Ter dois endereços apontando para o mesmo projeto dá uma forma barata de separar problema de código de problema de configuração quando algo para de abrir.

Se a versão no .zugo.run carrega e a da Vercel não, a falha está no ambiente, no domínio ou em uma variável que ficou para trás. Se as duas quebram do mesmo jeito, o problema está no projeto, e o conserto é uma edição no Zugo.

Para busca, escolha uma versão canônica assim que o projeto virar definitivo. Duas cópias indexadas do mesmo conteúdo dividem sinais entre si sem ganhar nada em troca. Quem publica na própria conta normalmente quer que a canônica seja o domínio próprio.

Vercel e GitHub resolvem o mesmo problema?

Não. São peças diferentes que costumam ser confundidas porque aparecem juntas.

Peça Do que ela cuida Onde fica
Zugo Geração e edição por descrição Na plataforma
GitHub Exportação do código-fonte No seu repositório
Vercel Deploy e hospedagem Na sua conta
Domínio próprio O endereço permanente No seu registrador

Quem quer ler e alterar o código à mão precisa do GitHub. Quem quer que o site rode na infraestrutura da empresa precisa da Vercel. Muita gente conecta os dois, porque exportar o código sem ter onde hospedá-lo resolve metade do problema.

Se o projeto também vai guardar dados, receber pagamento ou disparar e-mail, o conjunto cresce: Supabase para banco, login e arquivos, Stripe para cobrança e assinatura, Resend para os e-mails e Google Analytics para as visitas. Vale planejar esse desenho junto, e não um pedaço por semana.

Onde essa integração encontra os limites?

Três, ditos sem enfeite.

O Zugo não substitui um time de desenvolvimento em um produto complexo. Publicar na Vercel não muda isso: regra de negócio muito específica se afina com edições sucessivas, e em algum ponto sai mais barato exportar pelo GitHub e continuar à mão. Quando o assunto é jogo, o resultado é 2D e roda no navegador.

A verificação em sandbox confirma que a construção sobe. Ela não olha a sua conta da Vercel, nem as suas variáveis de ambiente, nem se o domínio foi apontado para o lugar certo. Essa parte vive do seu lado e quem revisa é você.

Publicar na própria conta adiciona uma superfície de manutenção. Fatura, limites de uso e alertas passam a ser seus. Para um time com processo, isso é exatamente o que se quer. Para uma pessoa sozinha validando uma ideia, é trabalho que ainda não precisa existir.

Por onde começar?

Construa e ajuste primeiro, migre a hospedagem depois. É a ordem que evita configurar infraestrutura para um projeto que ainda vai mudar de rumo na segunda semana, e ela custa menos tempo em qualquer cenário.

Quando o conteúdo estiver firme, conecte a conta, envie o projeto e aponte o domínio antes de divulgar o link. Se quiser entender as peças vizinhas, exportar o código do projeto explica o que sai junto no repositório, como publicar um projeto cobre o caminho curto sem conta externa e criador de apps com IA e GitHub mostra o outro lado da mesma integração.

Dá para testar o fluxo inteiro em zugo.dev com o plano gratuito, usando um dos 25 modelos prontos como ponto de partida, e decidir onde hospedar quando já houver o que hospedar.

← Todos os artigos