Firebase 19/05/2026

Hosting grátis para página estática? Publique com Firebase e GitHub Actions

Esses dias eu estava navegando em redes sociais e comecei a ver vários posts sobre serviços para hosting grátis. Quase sempre o contexto era o mesmo: subir uma landing page, publicar uma vitrine rápida, colocar um MVP no ar ou mostrar alguma coisa gerada com IA.

No meio disso, lembrei de uma coisa bem simples: este próprio blog está publicado no Firebase e o deploy dele é feito via GitHub Actions.

Não é nenhuma arquitetura mirabolante. É só um site estático, com arquivos versionados no repositório e uma automação pequena para publicar quando entra alteração. Como eu já tinha esse fluxo funcionando aqui, resolvi montar um projeto separado só para demonstrar a ideia de forma mais limpa, sem misturar com a estrutura do blog.

Foi daí que nasceu o dataflow-monitor.

O repositório ficou público em marlonlp/dataflow-monitor e a aplicação publicada está em dataflow-monitor-mockup.web.app.

O que eu quis mostrar com esse exemplo

A proposta do dataflow-monitor não foi criar produto real, nem framework novo, nem template sofisticado demais. A ideia foi só mostrar um caso pequeno e fácil de reproduzir:

• uma página estática;
• sem backend;
• sem etapa de build;
• com deploy automático;
• e usando uma opção gratuita bem honesta para esse tipo de cenário.

Muita gente complica esse assunto logo no começo. Para uma página estática simples, nem sempre precisa.

O projeto

O dataflow-monitor foi feito só com HTML, CSS e JavaScript puro. A estrutura é pequena:

Foi intencional deixar assim.

Se eu quisesse, dava para montar o mesmo exemplo com React, build, pipeline maior e mais camadas. Mas aí o post começaria a falar de framework em vez de falar de publicação. O objetivo aqui é outro.

Por que eu gosto dessa abordagem

Quando a necessidade é publicar uma página estática, esse tipo de stack resolve bem:

• o código fica simples;
• o deploy fica versionado;
• não tem servidor para administrar;
• não precisa inventar uma estrutura maior do que o necessário;
• e o custo, para esse tipo de caso, tende a ser muito baixo ou até zero.

Eu usaria esse fluxo sem pensar muito para:

• landing page;
• portfólio;
• documentação simples;
• página institucional;
• mockup navegável;
• demo de front-end.

Se o projeto já pede backend próprio, autenticação mais séria, SSR ou build mais pesada, aí provavelmente não estamos mais falando do mesmo problema.

Onde entra o Firebase

Como o site é estático, o Firebase Hosting entra muito bem aqui. Ele entrega os arquivos, já resolve HTTPS, deixa a publicação simples e ainda combina bem com automação via GitHub.

No exemplo, a configuração principal ficou no firebase.json:

{
  "hosting": {
    "public": ".",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ]
  }
}

O ponto principal é o public: ".".

Como o projeto já está organizado na própria raiz, não houve motivo para criar dist, build ou qualquer outra pasta intermediária.

Também ficou um .firebaserc bem simples:

{
  "projects": {
    "default": "dataflow-monitor-mockup"
  }
}

Esse arquivo só associa a pasta local ao projeto certo no Firebase. Parece detalhe pequeno, mas ajuda a evitar confusão quando você trabalha com mais de um projeto.

Onde entra o GitHub Actions

A parte mais interessante, para mim, nem é o Hosting em si. É o fato de publicar sem depender de deploy manual toda vez.

No dataflow-monitor, o workflow ficou assim:

name: Deploy to Firebase on merge
'on':
  workflow_dispatch:
  push:
    branches:
      - master
jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: '24'
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT }}'
          channelId: live
          projectId: dataflow-monitor-mockup
          entryPoint: .
          repoToken: '${{ secrets.GITHUB_TOKEN }}'

O fluxo é bem direto:

• faz push na branch principal;
• o GitHub sobe o workflow;
• a action publica no Firebase;
• o site atualizado vai para o ar.

Como o projeto não tem build, o pipeline também não precisou de muita coisa. É praticamente checkout + deploy.

Como eu montaria isso do zero

Se você quiser reproduzir a ideia sem complicar demais, o caminho é mais ou menos este:

1. criar o projeto no Firebase;
2. habilitar o Hosting;
3. criar o repositório no GitHub;
4. preparar os arquivos estáticos localmente;
5. rodar firebase init hosting;
6. validar um firebase deploy manual;
7. criar a credencial para o GitHub Actions;
8. salvar essa credencial como secret no repositório;
9. adicionar o workflow de deploy.

O ponto que costuma gerar mais dúvida é a credencial usada pelo GitHub Actions. No exemplo, isso foi resolvido com a secret FIREBASE_SERVICE_ACCOUNT, que guarda o JSON da service account usada para publicar no Hosting.

Eu prefiro sempre validar primeiro com deploy manual. Se o firebase deploy funciona e o workflow falha depois, você já sabe que o problema está no pipeline ou nas permissões da conta usada no GitHub.

O que eu acho mais útil nesse exemplo

Para mim, o valor do dataflow-monitor não está no layout em si. Está no fato de ele mostrar um fluxo real sem muita distração em volta.

Você consegue abrir o repositório, olhar:

• o firebase.json;
• o .firebaserc;
• o workflow em .github/workflows/deploy-to-firebase.yaml;
• e depois comparar com a aplicação publicada.

Isso ajuda mais do que ficar só na teoria.

Onde eu tomaria cuidado

Mesmo sendo um fluxo simples, tem algumas coisas que vale observar:

• não colocar JSON de service account no repositório;
• não exagerar nas permissões da conta de deploy;
• não usar essa abordagem só porque é gratuita, se o projeto pede outra arquitetura;
• não transformar um site estático simples em uma stack maior do que o necessário.

Parece óbvio, mas é justamente nesses casos pequenos que a gente às vezes complica demais.

Fechando

A ideia deste post surgiu mais por contraste mesmo. Vi muita gente falando de hosting grátis em cenários envolvendo IA, páginas rápidas e MVPs visuais, e lembrei que eu já estava usando algo nessa linha no meu próprio blog fazia tempo.

No fim, o dataflow-monitor acabou servindo para isso: isolar a ideia em um projeto pequeno, público e fácil de inspecionar.

Se você precisa publicar uma página estática sem gastar tempo demais com infraestrutura, Firebase Hosting com GitHub Actions é uma combinação que vale olhar com calma.

Se quiser, no próximo passo eu posso detalhar a configuração da service account e da secret no GitHub usando exatamente esse mesmo exemplo.