Deploy de projeto de IDE de navegador na Vercel ou Netlify

O caso óbvio é uma máquina em que instalar uma CLI é inconveniente ou proibido. Um Chromebook, um computador de laboratório ou um desktop corporativo bloqueado abrem uma aba, mas nem sempre permitem instalar Node.js, Git e a CLI do provedor. Um IDE de navegador já remove esses requisitos para editar. O deploy costuma ser o último passo que devolve o desenvolvedor ao terminal; mantê-lo na mesma aba fecha o ciclo: o projeto é editado, visualizado e publicado sem toolchain local. O segundo caso é velocidade. Uma landing page, um protótipo ou uma demonstração para cliente podem precisar de URL antes de precisarem de repositório ou pipeline de CI. O painel do navegador publica o snapshot atual e informa onde ele está no ar. Essa conveniência tem um limite. Isto é um upload direto, não um pipeline de deploy. Ele não observa branch, não roda testes nem promove builds entre ambientes; isso pertence à integração Git do provedor ou ao CI. O caminho do navegador serve para a primeira URL, não para todo o processo de release.

O diálogo Deploy é uma camada fina de controle sobre duas APIs de provedor. Ao clicar em Deploy now, o GB Coder monta o mesmo pacote de arquivos do Download ZIP. Esse detalhe importa: não existe um segundo caminho de empacotamento que possa omitir uma folha de estilo ou esquecer uma biblioteca externa. Um projeto simples vira index.html, style.css, script.js e um README. Um projeto React ou Vue vira uma árvore no formato Vite, com index.html, package.json, vite.config.js, .gitignore, um README e fontes em src/. O resumo do pacote mostra o número exato de arquivos e o tamanho descompactado antes de qualquer coisa sair da aba. A Vercel recebe os arquivos como JSON inline no endpoint de deploy. A Netlify recebe um ZIP como corpo bruto da requisição. A Vercel cria ou serve o projeto; a Netlify publica os arquivos enviados como um deploy manual. Nenhum servidor da LadeStack fica no meio, e nenhuma CLI roda na sua máquina. O navegador é o cliente, o provedor é o host e o token é a única credencial. Um clique descreve a interface, não o trabalho: empacotamento, upload, processamento remoto e TLS ainda acontecem em sequência.

O pacote é diferente porque os dois tipos de projeto precisam de tratamento distinto. Um projeto HTML/CSS/JavaScript simples não tem package.json. A Vercel recebe a instrução de não usar framework e serve os arquivos como site estático. A Netlify publica o ZIP como está, o que também é correto para arquivos estáticos. Não há nada para instalar ou compilar, então o primeiro deploy costuma ser rápido. Um projeto React ou Vue inclui package.json gerado, configuração do Vite e fontes. Na Vercel, o provedor detecta o Vite, instala dependências, roda o build de produção e publica a saída. Esse é um build real na nuvem, não uma simulação no navegador, e por isso pode levar um minuto ou mais. A Vercel também usa as versões registradas no package.json, não o que estava carregado no editor. O deploy manual por ZIP da Netlify não executa um comando de build, então a mesma árvore de fontes Vite é publicada como foi enviada, sem compilação. Para React ou Vue na Netlify, use a integração Git do provedor; o caminho de um clique da Netlify publica apenas saída estática. Bibliotecas externas e configurações de injeção já estão no pacote. Se um build da Vercel depende de um pacote privado, um binário nativo ou um serviço que a imagem de build não alcança, o build falha mesmo que a prévia funcione localmente. Os logs mostram em qual caso você está.

Os dois provedores autenticam com um token de acesso pessoal. Não é a senha do provedor nem uma conta do GB Coder. O diálogo leva à página de tokens do provedor escolhido e explica o escopo em linguagem simples. Um token da Vercel pode publicar em todos os projetos que a conta ou o time alcançam; quando existir um token com escopo de time, use esse. Um token da Netlify age nos sites que a conta acessa, então trate-o como global, a menos que exista uma opção mais restrita. Crie o token para esse fim, dê a ele a menor vida útil possível e revogue-o quando o projeto não precisar mais. O GB Coder verifica se há um token e se o pacote cabe nos limites locais antes de habilitar Deploy now. O token fica na memória da aba por padrão. Remember on this device é opcional: em uma origem segura, o token é selado com AES-GCM antes de ser gravado no localStorage; caso contrário, o diálogo avisa que lembrar o armazenaria em texto puro. Escopo e revogação são os controles que mais importam.

Abra um projeto e escolha Deploy na barra de ferramentas; em telas estreitas, ele fica no menu de overflow. A Vercel vem selecionada por padrão; a Netlify está a um clique. O nome do projeto é preenchido a partir do projeto atual. O GB Coder passa para minúsculas, troca caracteres inválidos por hífens e mostra o hostname que vai solicitar, como seu-projeto.vercel.app. Cole o token, decida se quer lembrar e confira o resumo do pacote. Se o número de arquivos ou o tamanho passar do limite, o diálogo explica o problema e mantém o botão desativado. Clique em Deploy now. O provedor cria o projeto ou site, recebe o pacote e começa a processar o deploy. Quando o deploy fica pronto, a tela de sucesso mostra a URL pública, o número de arquivos, o tamanho enviado, o tempo decorrido e um QR code para abrir a página no celular. Copy URL e Visit site servem para a entrega, e Build logs abre a visualização de logs do próprio provedor. Nomes de site da Netlify são globais, então um nome pedido pode já estar em uso. O provedor então atribui outro, e o GB Coder informa o endereço que está realmente no ar, não o que você digitou.

A barra de progresso passa por empacotamento, upload, build, proteção e pronto. Na Netlify, o rótulo de build representa o processamento do provedor, não um comando de build. É um relatório do cliente, não uma previsão do provedor. A porcentagem avança nas duas primeiras etapas e fica abaixo de 100 enquanto o provedor conclui o trabalho remoto. Isso é intencional: o trabalho remoto pode levar um tempo imprevisível, e uma barra que disparasse para 99% estaria mentindo. O GB Coder consulta o provedor a cada segundo e meio e atualiza a mensagem quando o estado muda. Uma requisição de upload tem timeout de dois minutos. O painel para de esperar após três minutos de polling do deploy e aponta para o dashboard, porque o deploy pode terminar mesmo quando o navegador já parou de olhar. Cancelar, fechar o diálogo ou pressionar Escape aborta a requisição em andamento e o loop de polling. Se o provedor já aceitou o deploy, o deploy pode continuar do lado dele; confira o dashboard antes de assumir que cancelar equivale a rollback. Os logs do provedor são a fonte autoritativa quando um deploy falha.

Deploy again volta ao formulário; não reenvia o último pacote imediatamente. Isso é útil quando o projeto mudou, o nome precisa de ajuste ou o token expirou. A partir daí, Vercel e Netlify seguem rotas diferentes para o mesmo endereço. A Vercel cria um deploy para o projeto nomeado e aponta para produção. Deploys repetidos com o mesmo nome atualizam esse projeto, e o alias de produção é preferido em relação à URL específica do deploy, então o endereço compartilhado costuma continuar estável. A Netlify precisa de um site id para atualizar um site existente em vez de criar outro. O GB Coder guarda esse id no localStorage, vinculado ao nome sanitizado do site. Se você limpar o armazenamento do navegador, trocar de navegador, mudar o nome ou excluir o site na Netlify, o próximo deploy não encontra o site antigo e cria um novo. Por isso, renomear um projeto na Netlify pode deixar o site anterior na conta. Os dois provedores mantêm histórico de deploys, domínios personalizados, controles de acesso e rollback nos próprios dashboards; o painel do GB Coder expõe apenas o upload e a URL pública. Todo deploy aqui é de produção; não há branch preview nem seletor de ambiente.

Dois limites são aplicados antes de a requisição sair da aba: 900 arquivos e 64 MB de conteúdo descompactado. Eles ficam abaixo dos tetos dos provedores para que um upload enorme não falhe no meio de uma sessão de navegador. Um site com muita mídia deve manter imagens e vídeos grandes em um CDN ou no Git, não dentro do pacote do projeto. Os erros são separados por causa. Um 401 significa token recusado; um 403 geralmente indica falta de permissão na conta ou no time; um 413 ou 429 significa payload grande demais ou limite de taxa do provedor; um 422 indica projeto rejeitado como inválido; um 5xx costuma ser temporário. Na Vercel, uma falha de build de framework é diferente: o upload funcionou e o build falhou, então leia os logs em vez de colar um token novo. Um build da Vercel que precisa de variáveis de ambiente é outra fronteira. O diálogo não tem editor de variáveis. Defina os valores nas configurações do projeto da Vercel e faça o deploy de novo; o primeiro build pode falhar antes de o projeto existir. O caminho ZIP manual da Netlify não tem etapa de build, então isso não se aplica ali. Um limite de polling de três minutos não é um deploy falho, apenas uma espera que falhou.

O caminho do deploy é direto: o navegador chama api.vercel.com ou api.netlify.com com o seu token. Não há proxy que armazene a credencial, e nenhuma conta LadeStack é necessária para usar o painel. Tokens ficam só na sessão por padrão e são selados com AES-GCM apenas quando você opta por lembrar um em uma origem segura. Isso protege contra um token legível em backup de perfil ou pacote de suporte, mas não contra código malicioso na mesma origem enquanto a aba está aberta. Use o token mais restrito disponível, defina expiração e revogue-o no provedor quando o trabalho terminar. A propriedade segue o token: o projeto ou site é criado na conta do provedor que o possui, sob os termos, cotas, logs e cobrança desse provedor. O GB Coder continua local-first, mas o deploy é uma exportação explícita do projeto para o provedor. O provedor recebe o código do site, e o resultado é uma URL HTTPS pública por padrão; proteção por senha, SSO e domínios personalizados são recursos do provedor. Guarde um ZIP ou uma cópia no GitHub se o perfil do navegador for o único outro lugar onde o projeto existe.

Use este caminho quando a tarefa é colocar um site pequeno no ar rápido: landing page, portfólio, demonstração de aula, protótipo para revisão de cliente ou página de documentação estática. Também serve quando o projeto já vive no GB Coder e a alternativa é exportar um ZIP, abrir um terminal e configurar uma CLI em uma máquina que não é sua. Ele não serve para monorepo, aplicação renderizada no servidor com banco de dados, build que exige credenciais de registro privado, time que lança por branch previews e aprovações, ou ativos acima dos limites de upload. Esses são trabalhos da integração Git do provedor, de um pipeline de CI ou de um ambiente desktop. As duas abordagens podem conviver: rascunhe e itere no navegador, envie o código ao GitHub quando ele merecer histórico e deixe o CI publicar o build de produção. Uma rotina prática: teste a prévia na largura de celular, confira o resumo do pacote, faça o deploy, abra a URL em um segundo dispositivo e guarde o log do build. Para experimentar, abra o painel de projetos em /app/projects, crie ou abra um projeto e escolha Deploy. A referência de configuração está na documentação.