Para publicar uma aplicação web, compila-se o código em ficheiros estáticos, colocam-se num alojamento que os serve por HTTPS, dão-se a esse alojamento os segredos de que a app precisa e aponta-se um nome de domínio para ele. Com um criador de apps com IA, pode ficar logo no primeiro passo: o criador publica a app por si. Se preferir outro alojamento, exporte o código para o GitHub e ligue o repositório à Vercel ou à Netlify, ou corra-o no seu próprio servidor.
Este guia parte de uma app com backend Supabase, que é o que o Cadrant, o nosso criador, gera. Não indicamos preços de alojamentos de terceiros: mudam com frequência, por isso consulte as páginas dos fornecedores.
As três formas de publicar uma aplicação web criada com IA
Há três sítios onde alojar a app: o alojamento do próprio criador, um serviço como a Vercel ou a Netlify, ou um servidor que gere. Diferem sobretudo no que faz por si mesmo.
- O alojamento do criador. Clica em Publicar e a app fica online num endereço do criador ou no seu domínio. Nada para configurar além do domínio. O seu código fica dentro do circuito do criador.
- Um alojamento depois de exportar para o GitHub. Envia o código para um repositório do GitHub, liga o repositório a um alojamento e este compila e publica a cada envio. Controla as definições de build e as variáveis de ambiente.
- O seu próprio servidor. Aluga uma máquina virtual, instala um servidor web, copia os ficheiros compilados e gere o certificado e as atualizações. É o que dá mais controlo e mais trabalho.
| Opção | Como a app fica online | O que gere por si | Limites |
|---|---|---|---|
| Alojamento do criador (Cadrant) | Botão Publicar, endereço do criador ou o seu domínio | Os registos DNS do domínio, o projeto Supabase | Preso ao criador: sair implica exportar o código, o que exige o plano Pro no Cadrant |
| Vercel ou Netlify | Repositório ligado ao alojamento, publicação a cada envio | Repositório, definições de build, variáveis de ambiente, DNS, o plano do alojamento | Aplicam-se os limites do plano do alojamento, e o código é editado em dois sítios, a menos que o criador envie para o GitHub por si |
| O seu próprio servidor | Copia os ficheiros compilados para uma máquina que gere | Tudo: servidor, servidor web, renovação do certificado, atualizações de segurança, cópias de segurança, monitorização | Tempo. Compensa por conformidade ou requisitos especiais, raramente num primeiro lançamento |
O que implica realmente publicar
Publicar são quatro coisas: um build, a configuração de que a app precisa em execução, uma base de dados que fica onde está e um certificado HTTPS. O primeiro e o último são automáticos em qualquer alojamento moderno.
O build
Uma app React é escrita em ficheiros que um navegador não consegue executar diretamente. O passo de build compila-os em ficheiros HTML, JavaScript e CSS simples, normalmente numa pasta chamada dist ou build. O alojamento corre o comando de build (muitas vezes npm run build) e serve essa pasta.
Variáveis de ambiente e segredos
Há dois tipos de valores, e misturá-los é o erro de lançamento mais comum. Os valores públicos, como o URL do projeto Supabase e a sua chave pública (anon), seguem dentro da app e foram concebidos para ser visíveis. Os valores secretos, como uma chave secreta do Stripe ou a chave de um serviço de email, nunca devem estar no código da app nem em qualquer variável que o build exponha ao navegador. Pertencem ao lado do servidor.
Numa app criada com o Cadrant, os segredos ficam no separador Ambiente do painel Base de dados e são lidos por edge functions do Supabase, pelo que nunca fazem parte do pacote do frontend. Veja a documentação sobre variáveis de ambiente. Se publicar noutro sítio, o alojamento só lhe pede que volte a introduzir os valores públicos; os segredos ficam no Supabase. A Vercel refere que cada um dos seus ambientes (pré-visualização, produção) pode ter as suas próprias variáveis, e é assim que mantém as chaves de teste longe das reais.
A base de dados fica no Supabase
Mudar o frontend para outro alojamento não move os dados. A base de dados, as contas de utilizador e os ficheiros ficam no projeto Supabase, que está na sua própria conta Supabase. É por isso que mudar de alojamento leva minutos e não perde nada. Duas coisas a fazer depois de qualquer mudança de endereço: adicionar o novo domínio às definições de Auth e testar o início de sessão. A documentação do Supabase diz que o Site URL, que por omissão é localhost, deve ser alterado para o seu URL de produção, e que os URLs de redirecionamento formam uma lista de permissões a que os redirecionamentos do início de sessão têm de corresponder. Se não mexer nisto, os emails de confirmação e de redefinição de palavra-passe apontam para o sítio errado. Os detalhes estão no guia de URLs de redirecionamento do Supabase.
O certificado HTTPS
Os navegadores avisam os utilizadores para se afastarem de sites sem HTTPS, e o início de sessão não funciona bem sem ele. A Vercel, a Netlify e o Cadrant emitem e renovam o certificado por si assim que o domínio é verificado. No seu próprio servidor, instala e renova-o você, normalmente com uma ferramenta gratuita de uma autoridade de certificação, e tem de garantir que a renovação continua a funcionar.
Como ligar um domínio próprio
Ligar um domínio é adicionar registos DNS na empresa onde gere o domínio, para que o nome aponte para o seu alojamento. Cada alojamento indica os registos exatos; copie-os tal e qual em vez de os tirar de um tutorial.
- Compre o domínio se ainda não tiver um. Para ajuda a escolher o nome e a extensão, leia como escolher a extensão de um nome de domínio.
- Adicione o domínio nas definições do alojamento. O alojamento mostra então os registos a criar.
- Crie esses registos no seu fornecedor de DNS (o seu registador, a Cloudflare, etc.).
- Espere que o alojamento mostre o domínio como verificado, depois abra o site no domínio e teste o início de sessão.
Registo A ou CNAME
Um registo A aponta um nome para um endereço IP, e um registo CNAME aponta um nome para outro nome. A documentação da Vercel diz que um domínio apex como example.com se configura com um registo A e um subdomínio como app.example.com com um registo CNAME, e que cada projeto tem o seu próprio valor de CNAME. A documentação da Netlify recomenda, para o domínio apex, um registo ALIAS se o seu fornecedor de DNS o suportar, e um registo A caso contrário, mais um CNAME para o www. Os valores diferem consoante o alojamento e o projeto, por isso use os que aparecem no seu painel.
Domínio apex ou www
O domínio apex (ou raiz) é example.com, sem nada à frente. Um subdomínio é tudo o que vem à frente, como www ou app. Em DNS padrão, um CNAME não pode ficar no apex, e é por isso que as configurações apex usam registos A, ALIAS ou ANAME. A Netlify recomenda vivamente que faça de um subdomínio www o seu domínio principal, porque um apex como principal pode prejudicar o desempenho com alguns fornecedores de DNS. A documentação do próprio Cadrant dá o mesmo conselho: prefira um subdomínio como app.mysite.com para evitar os limites dos domínios raiz. Adicione as duas versões e redirecione uma para a outra, para que os visitantes cheguem à app de qualquer maneira.
Propagação do DNS
Uma alteração de DNS pode demorar de alguns minutos a um dia ou mais a chegar a toda a gente. A documentação da Netlify diz para contar até 48 horas. Acompanhe o progresso com uma ferramenta como o dnschecker.org ou o comando dig, e procure registos antigos em conflito no mesmo nome: um registo A ou CNAME antigo é a causa habitual de um domínio que nunca valida.
Como o Cadrant publica
O Cadrant publica a partir do botão Publicar: escolhe um slug para um endereço Cadrant como your-app.cadrant.app, ou seleciona um domínio próprio que tenha adicionado na secção Domínios. O alojamento HTTPS e um domínio próprio estão incluídos em todos os planos pagos, e uma app publicada não consome créditos.
Para um domínio próprio, o Cadrant mostra três registos DNS a criar no seu registador: um registo TXT que prova a titularidade, um CNAME que valida o certificado e permite a renovação automática, e um CNAME para o encaminhamento. Num domínio raiz, o registo de encaminhamento precisa de um ALIAS ou ANAME se o seu fornecedor o suportar. A validação demora de alguns minutos a algumas horas; um botão Atualizar refresca o estado. Voltar a clicar em Publicar substitui a versão em linha, e pode despublicar a qualquer momento. Os passos completos estão na documentação de publicação.
O limite a conhecer: este é o alojamento do criador. Se quiser o seu próprio alojamento, a exportação do código e o envio para o GitHub estão no plano Pro. Os preços estão na página de preços, e o próprio criador é descrito na página do criador de apps com IA.
Teste numa cópia de staging antes de mexer na app em linha
Uma cópia de staging é uma segunda publicação da app, com o seu próprio endereço e os seus próprios dados de teste, onde verifica uma alteração antes de os utilizadores reais a verem. Quando já houver pessoas a depender da sua app, teste primeiro aí.
Num alojamento, isto já vem incluído. A Vercel cria uma publicação de pré-visualização, com o seu próprio URL, para cada branch ou pull request, e permite atribuir um domínio de staging e variáveis de ambiente separadas. A sua documentação afirma que as pré-visualizações não usam as variáveis de produção, e que um build de produção pode também ficar retido até o promover. A Netlify oferece pré-visualizações de deploy semelhantes. O objetivo das variáveis separadas é ter um projeto Supabase separado para o staging, para que um teste nunca toque em clientes reais.
Num criador, a cópia de staging mais simples é um projeto duplicado ligado a um segundo projeto Supabase, publicado num segundo subdomínio como staging.oseudominio.com. Altere e teste aí, depois repita a alteração no projeto em linha. Custa um lugar de projeto, e as duas cópias podem divergir, por isso mantenha curta a lista de alterações. Aplique primeiro as alterações da base de dados ao staging e verifique as políticas como explicamos no nosso guia sobre a row level security do Supabase.
Como voltar atrás depois de uma má publicação
Voltar atrás é repor a app em linha na última versão que funcionava, e só é rápido se a versão anterior tiver sido guardada. Decida como o faria antes de precisar.
- No Cadrant. Cada prompt cria uma nova versão, guardada indefinidamente. Pode pré-visualizar qualquer versão anterior e reverter para ela. Reverter não apaga as versões seguintes, por isso pode voltar a avançar. Depois de reverter, clique em Publicar para pôr essa versão em linha. Reverter repõe a app, não os dados já alterados na base de dados. Veja a documentação sobre versões.
- Num alojamento. Os alojamentos guardam as publicações anteriores e podem reatribuir o domínio de produção a uma mais antiga, ou reverte o commit no Git e deixa o alojamento publicar de novo.
- No seu próprio servidor. Guarde a pasta do build anterior ao lado da atual e volte a ela.
Lista de verificação antes do lançamento
Antes de dizer a alguém que a app está em linha, verifique estes dez pontos. A maioria dos problemas de lançamento está nesta lista.
Para a parte da segurança em mais detalhe, veja o nosso guia sobre a segurança do vibe coding. Para comparar o que a app pode fazer antes de se comprometer com um criador, comece pela lista de criadores de apps com IA.