# 07 · Publicar

Chegou a hora de colocar o app no ar. O fluxo é direto: você gera o **build** (que já é o seu teste de compilação), sobe o código no **GitHub** e roda **`fayz deploy`** — um comando que faz a autenticação, conecta o projeto na plataforma e publica numa URL própria. Ao fim deste passo você tem um link `https://<seu-app>.live.fayz.ai` que qualquer pessoa abre.

Os comandos `fayz` abaixo rodam via `npx @fayz-ai/cli <comando>` (sem instalar nada global); os exemplos usam a forma curta `fayz` para ficar legível.

{% steps %}

{% step title="Build + teste de compilação" %}
Gere o build de produção. Ele é o seu **teste de compilação**: se o Vite empacota o app sem erro, o código está íntegro para publicar.

```bash
npm run build
```

Saída real:

```
vite v5.4.21 building for production...
✓ 34 modules transformed.
dist/index.html                   0.40 kB │ gzip:  0.27 kB
dist/assets/index-tn0RQdqM.css    0.00 kB │ gzip:  0.02 kB
dist/assets/index-BERJrSU-.js   143.00 kB │ gzip: 46.00 kB
✓ built in 274ms
```

O resultado é uma pasta `dist/` pronta para servir. Em seguida, rode o doctor para validar o manifesto uma última vez:

```bash
fayz doctor
```

```
⚠ plugins referenced by manifest are resolved by the platform bundle, not public npm packages: dashboard

0 error(s), 1 warning(s)
```

{% callout type="tip" %}
✓ Você deve ver: `✓ N modules transformed` e `✓ built in …` no build, e `0 error(s)` no doctor. O aviso sobre plugins resolvidos pelo bundle da plataforma é **esperado** — não é um erro. Se o build falhar, é aqui que você descobre, antes de subir qualquer coisa.
{% /callout %}
{% /step %}

{% step title="Push no GitHub" %}
Seu app é o seu repositório. Antes de commitar, adicione a pasta `.fayz/` ao `.gitignore` — ela guarda o vínculo local do deploy (`.fayz/project.json`) e **não deve ir para o repositório**. O scaffold ainda não cobre isso, então faça manualmente:

```bash
# na raiz do app, garanta que .fayz/ está ignorado
echo ".fayz/" >> .gitignore
```

Agora inicialize o repositório e faça o primeiro commit:

```bash
git init
git add .
git commit -m "feat: meu app Fayz"
```

Crie o repositório remoto — pela CLI do GitHub ou pelo site — e faça o push:

```bash
# com a gh CLI
gh repo create minha-loja --private --source=. --push

# ou, se você criou o repo pelo site:
git remote add origin https://github.com/<voce>/minha-loja.git
git push -u origin main
```

{% callout type="tip" %}
✓ Você deve ver: `.fayz/` listado no `.gitignore` **antes** do primeiro `git add`, e o repositório no GitHub com o seu código — sem a pasta `.fayz/`. Confira no site do GitHub que ela não aparece.
{% /callout %}
{% /step %}

{% step title="Autentique com `fayz login`" %}
O deploy precisa de um token de acesso. Gere um em **Fayz → Configurações → Tokens de acesso** — ele vem com o prefixo `fayz_`. (O acesso de deploy está em rollout para a rede de desenvolvedores convidados.)

```bash
fayz login
```

Cole o token quando pedido. Saída real:

```
✓ Token salvo em ~/.fayz/credentials.json (permissão 0600).
  fayz_xxx…xxx
  O token será validado no primeiro deploy (nenhuma chamada de rede foi feita agora).
```

O login é local: ele só grava o token com permissão `0600` e o valida mais tarde, no primeiro deploy. Comandos úteis:

```bash
fayz login --status   # mostra o token mascarado, se já houver um
fayz logout           # remove o credentials.json
```

Em CI ou máquinas efêmeras, use a variável de ambiente `FAYZ_TOKEN` em vez do `fayz login` — a CLI a lê direto.

{% callout type="tip" %}
✓ Você deve ver: `✓ Token salvo em ~/.fayz/credentials.json`. O `fayz login --status` deve mostrar o token mascarado. Nenhuma chamada de rede acontece no login — a validação fica para o deploy.
{% /callout %}
{% /step %}

{% step title="Inspecione com `fayz deploy --dry-run`" %}
Antes de subir de verdade, rode o dry-run. Ele lista exatamente o que seria enviado e qual seria o destino, **sem nenhuma chamada de rede**:

```bash
fayz deploy --dry-run
```

Saída real:

```
▸ Arquivos a enviar de minha-loja:
  app.manifest.json  (1087 B)
  index.html  (299 B)
  …
  Total: 13 arquivo(s), 7099 B.
  Destino: novo projeto 'minha-loja' (será criado no primeiro deploy)
  (dry-run — nenhuma chamada de rede foi feita)
```

O nome do projeto é derivado do campo `name` do seu `package.json`. Confira a lista e o destino antes de prosseguir.

{% callout type="tip" %}
✓ Você deve ver: a lista de arquivos com tamanhos, o `Total`, o `Destino: novo projeto '<nome>'` e a linha `(dry-run — nenhuma chamada de rede foi feita)`. Se o destino ou a contagem de arquivos surpreender, resolva antes do deploy real.
{% /callout %}
{% /step %}

{% step title="Publique com `fayz deploy`" %}
Agora suba de verdade:

```bash
fayz deploy
```

A CLI confirma o destino antes de agir (use `--yes` para pular a confirmação; em shell não interativo ela recusa rápido em vez de agir sozinha). No **primeiro deploy** ela cria o projeto na plataforma e grava `.fayz/project.json` com `{ projectId, name }`; nos deploys seguintes ela reusa esse arquivo, mandando para o mesmo projeto. O código sobe em lotes, a plataforma builda no servidor (install + Vite) e devolve a **URL final**:

```
🔗 https://minha-loja.live.fayz.ai
```

{% callout type="info" %}
**Acesso em rollout.** O `fayz deploy` está sendo liberado para a rede de desenvolvedores convidados. Se o deploy retornar um erro de autorização, seu token ainda **não** tem acesso de CLI liberado — fale com a gente na [comunidade](/pt-BR/docs/recursos/comunidade). O caminho de [host estático](/pt-BR/docs/deploy/estatico) coloca o mesmo app no ar enquanto isso.
{% /callout %}

{% callout type="tip" %}
✓ Você deve ver: a URL `https://<seu-app>.live.fayz.ai` no fim do deploy, e um `.fayz/project.json` novo na raiz (ignorado pelo git). Abra a URL — o app deve carregar igual ao `npm run preview`.
{% /callout %}
{% /step %}

{% /steps %}

## Você entregou?

Publicar não é só o comando passar — é o app funcionar para quem abre o link. Confira:

- **A URL abre** — `https://<seu-app>.live.fayz.ai` carrega sem tela em branco.
- **O fluxo principal funciona** — aquele um caminho essencial do seu produto vai do início ao fim.
- **Os dados persistem** — o que você cria numa sessão continua lá na próxima (Supabase conectado no [passo 05](/pt-BR/docs/tutorial/05-dados-reais-com-supabase)).

**Alternativa: host estático.** Prefere Vercel, Netlify ou Cloudflare Pages? O mesmo `dist/` sobe em qualquer host de arquivos — veja [Deploy estático](/pt-BR/docs/deploy/estatico).

## E agora?

Do zero ao ar: você gerou o app, entendeu a anatomia, aplicou a marca, ligou plugins, conectou um banco real, escreveu seu próprio plugin e publicou — tudo a partir do manifesto. Os próximos caminhos:

- Explorar o [catálogo de plugins](/pt-BR/docs/plugins) e montar o próximo produto.
- Transformar o app numa camada que um agente lê e opera em [IA · Seu app como camada de dados](/pt-BR/docs/ia/seu-app-como-camada-de-dados).
- Aprofundar plugins próprios em [Incubator](/pt-BR/docs/plugins-proprios/incubator).

---

[← Anterior: 06 · Seu próprio plugin](/pt-BR/docs/tutorial/06-seu-proprio-plugin) · [Voltar ao início do tutorial](/pt-BR/docs/tutorial)