# Lovable na AWS: site em S3 e CloudFront com domínio e HTTPS

> Como tirar um site feito no Lovable da hospedagem dele e rodar na AWS: GitHub, bucket S3 privado, CloudFront com OAC, HTTPS pelo ACM e Route 53.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Rede, IA
- URL: https://pages.formacaoaws.com.br/blog/lovable-na-aws-s3-e-cloudfront/
- Aula de origem: "Deploy na AWS com IA: Projeto do Lovable em Produção (S3, CloudFront)" (https://www.youtube.com/watch?v=sT3s34j5LKw)

Publicar o site feito no Lovable no endereço dele deixa a infraestrutura fora do seu controle. Aqui eu levo o projeto para a AWS: do GitHub até o site no ar, num bucket privado do S3 servido pelo CloudFront, com domínio próprio, HTTPS e cache.

A aula foi publicada em 9 de janeiro de 2026. A tela de criação da distribuição do CloudFront tinha mudado pouco antes, então confira os nomes dos planos e os limites na [página de preços do CloudFront](https://aws.amazon.com/cloudfront/pricing/).

## Por que sair da hospedagem do Lovable

Eu estava gerando páginas com o Lovable a partir das que já rodavam no WordPress, e precisei publicá-las com domínio personalizado e controle meu. O Lovable até publica, e dá para configurar domínio próprio, mas a página demorou para carregar. Por padrão, ali você não tem cache habilitado: pode até haver uma CDN, mas a estrutura não está sob o seu controle.

O projeto que o Lovable gera é só front-end: JavaScript, TypeScript, CSS e React, sem back-end. Quem só tem arquivos estáticos pode ficar no S3, servido por uma CDN (o CloudFront) para chegar o mais perto possível do usuário e com cache configurável.

**Fluxo:** GitHub (projeto clonado) → Build (npm run build) → Amazon S3 (bucket privado) → Amazon CloudFront (OAC, cache e HTTPS) → Route 53 (domínio próprio)

O plano free do CloudFront cobre esse caso: na tela de criação, 100 GB por mês de transferência, 1 milhão de requisições e 5 GB de armazenamento no S3. Na gravação eu falei "1 TB" por engano e corrigi na hora: são 100 GB. É o valor da aula, não uma tabela atual.

## Passo 1: conecte o Lovable ao GitHub e clone

No Lovable, abra **Settings**, vá em **GitHub** e conecte sua conta. Com a conta conectada, o projeto vai para um repositório seu. O meu ficou privado.

Depois, clone o repositório na sua máquina:

```bash
git clone <endereço-do-repositório>
```

Troque o endereço pelo do seu repositório.

## Passo 2: rode o projeto localmente

Dentro da pasta clonada:

```bash
npm install
npm run dev
```

Você precisa ter o npm instalado. O `npm run dev` mostra um endereço local: clique nele e o site abre, rodando na sua máquina.

## Passo 3: crie o bucket no S3

No console da AWS, abra o S3 e crie um bucket para hospedar o projeto. Dei só um nome e mais nada: ele nasce privado, e é assim que deve ficar. Se eu mandasse o endereço do bucket para você, você não conseguiria acessar o conteúdo.

## Passo 4: crie a distribuição no CloudFront

Em **CloudFront**, crie uma nova distribuição:

1. **Plano.** Escolha entre free, pro, business e premium, ou pay as you go. Usei o free.
2. **Nome e domínio.** Dei o nome `pages-v4` e informei o domínio que está no Route 53. A tela confere se o domínio existe, e eu completei o endereço do site (`pages-v4.` mais o domínio).
3. **Origem.** Escolha **Amazon S3** e selecione o bucket que você criou.
4. **Acesso privado.** Marque **Allow private S3 bucket access to CloudFront**.

![Na origem S3, a caixa Allow private S3 bucket access to CloudFront marcada, com as configurações recomendadas de origem e de cache](https://pages.formacaoaws.com.br/blog/assets/posts/lovable-na-aws-s3-e-cloudfront/cloudfront-acesso-privado-ao-bucket.webp)

Essa caixa antes era manual. Ela cria uma relação de confiança entre a distribuição e o bucket por meio do **OAC, o Origin Access Control**: a AWS cria o OAC e coloca no bucket uma policy dizendo que essa distribuição pode ler os arquivos dele. Conheça o que acontece por baixo, porque no dia em que um agente de IA mexer no projeto você precisa saber o que ele está tocando.

Na mesma tela, deixe o cache habilitado. O WAF já vem ligado por padrão, com uma proteção mínima que atende o caso.

> **Importante:** mantenha o bucket privado e deixe só o OAC liberar a leitura. Tornar o bucket público para servir o site abre os arquivos para qualquer um. Veja o passo a passo oficial em [restringir o acesso a uma origem do S3](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html).

## Passo 5: certificado HTTPS e a página inicial

Para o domínio abrir com HTTPS você precisa de um certificado. Se o domínio está no Route 53, a própria tela resolve: mandei criar um certificado wildcard, que vale para qualquer subdomínio. Ela provisiona o certificado no ACM, grava as entradas de validação no Route 53 e espera o certificado ficar emitido. Foi rápido.

Como o projeto é uma aplicação React, falta dizer qual é a página inicial. Abra a distribuição, vá em **Settings**, **Edit**, preencha **Default root object** com `index.html` e salve.

Com isso, a AWS está pronta para receber o site.

## Passo 6: aponte o domínio no Route 53

No Route 53, na zona do domínio, crie duas entradas para o mesmo subdomínio, as duas do tipo **alias** para o CloudFront:

- **Tipo A**, para tráfego IPv4.
- **Tipo AAAA**, para tráfego IPv6.

Em cada uma, escolha o destino CloudFront e selecione a distribuição que você criou, pelo domain name dela. Atenção para não pegar a distribuição de uma versão anterior: eu tinha a v2 e precisava da v4.

## Passo 7: faça o build e envie para o bucket

Até aqui o bucket está vazio. O caminho manual é rodar o build do projeto e fazer um `sync` do resultado com o bucket pelo AWS CLI, com as credenciais já configuradas na máquina.

Eu pedi isso ao Kiro CLI, o agente de IA da AWS, que incorporou o Amazon Q CLI. O prompt: o projeto da pasta é em React, leia o README, faça o build e suba no bucket, passando o nome dele e o profile que ele pode usar. Ele rodou `npm install`, depois `npm run build`, conferiu se o bucket existia e fez o upload.

Ao fim, o Kiro respondeu assim:

```text
Build realizado: O projeto React foi compilado com sucesso usando npm run build
Upload completo: Todos os arquivos foram enviados para o bucket site-lovable-imersao-aws-com-ia

Arquivos enviados:
- index.html (página principal)
- assets/index-VsOiyv2s.css (estilos)
- assets/index-DtyqJ3gk.js (JavaScript)
- Todas as imagens dos depoimentos
- Imagens da arquitetura do projeto
- favicon.ico, robots.txt, placeholder.svg

O site agora está disponível no bucket S3 e será servido através do CloudFront
que você já tem configurado com OAC. O CloudFront vai distribuir o conteúdo
globalmente com baixa latência.
```

O ponto que eu quero que você leve: ele ia configurar o bucket como site estático, e eu o corrigi na hora, avisando que não era necessário porque o conteúdo sai pelo CloudFront, já configurado com OAC para esse bucket. Se eu pedisse só "suba para o S3", a IA prepararia o S3 para hospedar conteúdo estático e eu teria que torná-lo público, o que abriria problema de segurança. Se você não conhece a AWS, vai deixando a IA decidir do jeito dela. Por isso o conhecimento vem antes.

## Passo 8: teste o site

Abra o endereço do subdomínio em uma aba nova. Meu site carregou com domínio personalizado, com HTTPS e bem mais rápido que na hospedagem do Lovable. Para ver se o cache funciona, olhe os cabeçalhos da resposta da página nas ferramentas de desenvolvedor do navegador: o `X-Cache` mostrou "Hit from cloudfront".

![Cabeçalhos da resposta da página: Server AmazonS3 e X-Cache com Hit from cloudfront](https://pages.formacaoaws.com.br/blog/assets/posts/lovable-na-aws-s3-e-cloudfront/hit-from-cloudfront.webp)

## Checklist

- Conecte o projeto do Lovable ao GitHub e clone o repositório.
- Rode `npm install` e `npm run dev` para ver o site local.
- Crie um bucket no S3 e mantenha-o privado.
- Crie a distribuição no CloudFront com o bucket como origem e a caixa de acesso privado (OAC) marcada.
- Crie o certificado wildcard pela tela da distribuição, se o domínio está no Route 53.
- Defina `index.html` como Default root object.
- Crie as entradas alias A e AAAA no Route 53 apontando para a distribuição certa.
- Faça o build, envie para o bucket e confirme o `X-Cache: Hit from cloudfront`.
- Confira planos e limites do CloudFront na página oficial de preços.

O Lovable resolve a criação da página, e a AWS resolve onde ela roda: bucket privado, cache, HTTPS e domínio seus, no plano gratuito para um site estático como esse.