Você descreveu uma página, o Figma Make a construiu e o preview está do jeito certo. Aí você bate na parede em que todo frontend gerado bate: ele vive no link da Figma, e no momento em que você quer um banco de dados atrás dele, um login na frente ou o seu próprio domínio em volta, precisa do código num lugar que você controla.
O Figma Make exporta um projeto React e Vite comum, e um servidor MCP deixa o assistente já aberto no seu editor enviar esse build direto para o seu próprio backend — sem CI, sem FTP, sem upload pela dashboard.
Este guia leva um app de registro de passeios de um prompt vazio no Figma Make até um endereço HTTPS no ar. Medido em 23 de setembro de 2026, o passo de deploy inteiro — três arquivos, de uma pasta local a uma URL funcionando — levou 9,4 segundos.
Prefere assistir?
O mesmo caminho em vídeo: um prompt vira um site no Figma Make, o código é baixado e o servidor MCP o coloca num endereço no ar. Cinco minutos, nenhum pipeline de deploy.
O que o servidor MCP realmente entrega?
Ele dá ao assistente do seu editor mãos no seu backend, de modo que “faça o deploy disto” vira uma frase em vez de um pipeline. MCP — o Model Context Protocol — é a forma padrão de um cliente de IA falar com um sistema externo, e a Back4app publica um servidor para ele no npm.
A versão 0.1.9 expõe 11 tools. Quatro delas importam aqui: deploy_web_hosting_files envia uma pasta, list_cloud_code_and_web_hosting_files mostra o que já está lá, activate_web_hosting devolve um subdomínio público e get_parse_app diz ao assistente em qual app ele está trabalhando.
As demais são o que torna isso mais do que um upload de arquivos. call_parse_server_rest_api cria classes e registros no banco de dados, e deploy_cloud_code_files envia funções do lado do servidor. A mesma conexão que publica o seu frontend pode dar a ele um backend depois, sem uma segunda ferramenta.
Como gerar o site no Figma Make?
Digite o que você quer na caixa de prompt da tela inicial da Figma e pressione Make a file. Para este guia, o prompt pediu um rastreador de passeios de cachorro que registra data, duração, distância e uma nota, lista os passeios anteriores e soma a semana.
O Make escolheu a própria direção visual — uma paleta quente de caderno de campo, títulos em serifa —, escreveu o componente React e pré-carregou cinco passeios de exemplo para que o resultado fosse legível de imediato. Levou menos de dois minutos do prompt ao preview funcionando.
Um badge vermelho 1 error apareceu abaixo do chat. Clicar em Fix for me é a atitude honesta aqui, e neste caso o Make leu a própria saída e informou que o erro estava obsoleto — a correção já estava no código e o hot reload do preview tinha guardado em cache a versão antiga.
Fique de olho no contador de créditos enquanto trabalha. O plano Starter da Figma permite 500 créditos de IA por mês com um teto de 150 por dia; a geração mais aquele único follow-up somaram 38 créditos, o que deixa espaço para cerca de quatro apps deste tamanho num dia.
Como tirar o código de lá?
Mude a chave de exibição de Preview para Code e clique no ícone de download acima da lista de arquivos. Você recebe um zip do projeto inteiro, não um pacote de HTML — este tinha 28 KB.
Dentro há um projeto de frontend comum: React 19, Vite 8 e Tailwind CSS v4, com os componentes em src/App.tsx. Os plugins de Vite da própria Figma estão quase todos limitados a apply: 'serve', então eles rodam o servidor de desenvolvimento e somem dos builds de produção.
Essa é a parte que vale internalizar. Nada na saída é proprietário, e é exatamente por isso que ela pode ser hospedada em qualquer lugar — e por isso que o resto deste guia é igual para um site que você escreveu à mão.
O que mudar antes de fazer o build?
Abra .figma/make/site.json e confira dois campos, porque os padrões vão custar caro. Todo projeto gerado vem com "robots": { "index": false }, e o título da página cai para a string literal Figma Make App.
Isso não é cosmético. Com index deixado em false, um build de produção emite um robots.txt com Disallow: / e uma tag <meta name="robots" content="noindex, nofollow"> — então um site cujo deploy você faz esperando tráfego pede, em silêncio, que todo crawler o ignore.
{
"title": "Biscuit's Walks",
"description": "Track and log your dog's walks…",
"robots": { "index": true }
}Com o título definido e a indexação habilitada, o build deixa de gerar o robots.txt e a página servida volta com o título Biscuit's Walks. Defina os dois antes do primeiro deploy, não depois.
Como fazer o build?
Instale e faça o build com os dois comandos que o projeto já espera. O Node 22 está fixado no .mise.toml do projeto, e o Vite cuida do resto.
npm install
npm run buildO build de produção cai em dist/ e é pequeno: index.html com 0,84 kB, uma folha de estilos com 8,81 kB e um bundle JavaScript de 229,49 kB que, com gzip, fica em 71,57 kB. Três arquivos, e nada para configurar — a configuração do Vite já resolve o caminho base para /, que é o que servir da raiz de um domínio exige.
Como conectar o servidor MCP?
Você precisa de uma account key. Na dashboard da Back4app, abra o menu do avatar, escolha Account Settings, depois a aba Account Keys, digite um nome e pressione Enter. A chave aparece na lista e vale por dois anos.
Então aponte o seu editor para o servidor. A configuração tem o mesmo formato em todo cliente MCP — Cursor, Claude Code, VS Code — e o pacote é baixado sob demanda, então não há nada para instalar antes.
{
"mcpServers": {
"back4app": {
"command": "npx",
"args": [
"-y",
"@back4app/mcp-server-back4app@latest",
"--account-key",
"YOUR_ACCOUNT_KEY"
]
}
}
}Como fazer o deploy?
Peça. Com o servidor conectado e o build concluído, a instrução é uma frase — nomeie a pasta e o app, e deixe o assistente chamar deploy_web_hosting_files.
Faça o deploy da pasta dist para o web hosting do meu app blog-demo.
A tool envia os arquivos em lotes de cinco, cria uma release e devolve o que fez. Três arquivos subiram como release v2 em 9,4 segundos, cada um com seu checksum e versão — index.html, a folha de estilos com hash e o bundle com hash, com a estrutura de assets/ preservada.
Depois peça o endereço. activate_web_hosting devolveu um subdomínio em 813 ms, e esse é o deploy inteiro: duas frases, nenhuma dashboard, nenhum pipeline.
Funcionou de verdade?
Sim — o site publicado é servido corretamente e se comporta como o preview se comportava. Todo arquivo voltou por HTTPS exatamente com o tamanho em bytes que o build produziu: 848 B de HTML, 229.499 B de JavaScript, 8.818 B de CSS, com a página intitulada Biscuit's Walks.
Mais importante: é um aplicativo funcionando, não uma captura de tela. Registrar um passeio de 42 minutos e 3,1 km moveu a lista de cinco entradas para seis e recalculou o painel semanal de 55 para 97 minutos e de 3,6 para 6,7 km.
Recarregue a página, porém, e ela volta para cinco. O estado vive na memória do React, que é exatamente a fronteira em que o Figma Make para — e a razão pela qual a próxima seção importa mais do que o deploy importou.
Quais limites vale a pena conhecer?
Três, todos verificáveis em um minuto e nenhum deles bloqueante. O subdomínio do plano Free é um preview: activate_web_hosting devolve um nome com prefixo preview- junto com um timestamp expiresAt exatamente 60 minutos à frente. Isso é uma janela para compartilhar, não hospedagem — um subdomínio permanente ou o seu próprio domínio exige um plano pago.
Segundo, não há fallback de single-page app. Uma requisição para um caminho sem arquivo correspondente devolve HTTP 403 com o corpo {"error":"unauthorized"} em vez de reescrever para index.html. Apps de uma única view como este não são afetados; um router precisa de rotas em hash ou de uma camada de rewrite na frente.
Terceiro, tudo é servido com cache-control: public, max-age=0 e um ETag fraco, incluindo assets com hash no conteúdo que poderiam ser cacheados com segurança por um ano. A revalidação é barata, mas você não recebe o cache de asset imutável para o qual os nomes de arquivo foram projetados.
O que vem depois?
Dê a ele um banco de dados, usando a conexão que você já tem. O app atualmente esquece todo passeio ao recarregar porque nada os está armazenando, e o mesmo servidor MCP que acabou de fazer o deploy do frontend pode resolver isso sem uma segunda integração.
call_parse_server_rest_api cria uma classe e escreve registros; deploy_cloud_code_files envia funções do lado do servidor que rodam onde um navegador não alcança. Do lado do assistente é a mesma conversa: peça uma classe Walk, depois peça que o app a leia e escreva.
Essa ordem é o argumento real para fazer o deploy aqui em vez de deixar o site num link gerado. O frontend e os dados acabam num só lugar, atrás de uma conta, alcançáveis de um editor — e o passo de “uma página que parece certa” para “um app que lembra” deixa de ser uma migração.
