Em uma plataforma SaaS multi-tenant, oferecer domínio personalizado para cada cliente parece, à primeira vista, uma funcionalidade simples.
Na prática, é uma daquelas implementações que envolvem várias camadas importantes de arquitetura: DNS, SSL, roteamento na borda, segurança, identificação do tenant, redirects, headers confiáveis e automação de provisionamento.
No Bom Appetite, esse desafio apareceu de forma muito clara.
A plataforma precisava permitir que cada restaurante pudesse operar com seu próprio domínio ou subdomínio personalizado, mantendo a experiência totalmente integrada: cardápio, checkout, área do cliente, pedidos e demais fluxos públicos funcionando dentro do domínio do próprio estabelecimento.
Ou seja, o cliente acessa algo como:
pedidos.restaurante.com.br e a plataforma precisa entender automaticamente qual restaurante está sendo acessado, carregar a identidade correta, preservar o domínio na navegação e entregar tudo com HTTPS ativo.
O desafio técnico
O Bom Appetite utiliza uma arquitetura moderna baseada em aplicação web, Firebase Hosting e uma camada multi-tenant própria.
O problema é que, em plataformas como Firebase Hosting, cada domínio customizado normalmente precisa passar por um processo individual de validação, associação e configuração de certificado.
Para um site único, isso funciona muito bem.
Mas para uma plataforma SaaS, onde cada restaurante pode ter seu próprio domínio, esse fluxo começa a virar um gargalo operacional.
Imagine depender de uma configuração manual no hosting a cada novo cliente, a cada troca de domínio, a cada subdomínio adicional ou a cada ajuste de DNS.
Esse modelo não escala bem.
Além disso, para uma operação SaaS madura, o ideal é que a plataforma consiga controlar esse fluxo de ponta a ponta: validar o domínio, emitir SSL, rotear a requisição, identificar o tenant e manter a experiência final funcionando de forma transparente para o cliente.
Foi aí que entraram Cloudflare for SaaS e Cloudflare Workers.
A solução: Cloudflare for SaaS + Worker Origin + Firebase Hosting
A arquitetura implementada no Bom Appetite usa a Cloudflare como camada de entrada para os domínios personalizados dos tenants.
Em vez de cadastrar cada domínio diretamente no Firebase Hosting, os domínios dos restaurantes passam pela Cloudflare, que assume o papel de gerenciar DNS, certificados SSL/TLS e roteamento dos custom hostnames.
O fluxo funciona de forma simplificada assim:
Domínio personalizado do restaurante
↓
Cloudflare for SaaS
↓
Fallback origin
↓
Cloudflare Worker
↓
Firebase Hosting
↓
Aplicação Bom Appetite O Cloudflare for SaaS recebe o domínio customizado do restaurante e direciona a requisição para uma fallback origin controlada pela plataforma.
Essa fallback origin aciona um Cloudflare Worker, que funciona como uma camada inteligente de roteamento na borda.
O Worker recebe a requisição original, preserva o domínio usado pelo cliente e encaminha a chamada para o hosting nativo da aplicação.
Com isso, o Firebase continua recebendo a requisição por um domínio técnico válido da aplicação, enquanto o Bom Appetite consegue saber qual foi o domínio real acessado pelo usuário.
Essa diferença é essencial.
O domínio técnico serve para entregar a aplicação.
O domínio personalizado serve para identificar o tenant e manter a experiência do cliente final.
Segurança no roteamento
Um dos pontos mais importantes dessa implementação foi garantir que o domínio original do tenant fosse preservado de forma segura.
Não basta simplesmente confiar em um header enviado na requisição.
Headers podem ser manipulados se não houver uma camada de validação.
Por isso, o Worker adiciona um header interno autenticado, conhecido apenas pela infraestrutura da plataforma. A aplicação só aceita o domínio encaminhado quando esse segredo interno é validado.
Na prática, isso evita que uma requisição externa tente simular o domínio de outro tenant apenas manipulando headers.
Esse cuidado é fundamental em uma plataforma multi-tenant.
Quando vários clientes compartilham a mesma base de aplicação, a resolução correta e segura do tenant é uma parte crítica da arquitetura.
SSL automático para os domínios dos clientes
Outro ganho importante foi a gestão automática dos certificados SSL/TLS pela Cloudflare.
Ao conectar um domínio personalizado, a Cloudflare assume a emissão, instalação e renovação dos certificados, permitindo que o restaurante tenha HTTPS ativo no próprio domínio sem que a operação precise configurar certificado manualmente no hosting da aplicação.
Isso melhora muito a experiência de implantação.
Para o cliente, o processo fica mais simples.
Para a plataforma, a operação fica mais segura e escalável.
E para o produto, isso permite oferecer uma experiência mais profissional: cada restaurante pode divulgar seu próprio domínio, com segurança, identidade própria e navegação consistente.
O que essa arquitetura trouxe para o Bom Appetite
Com essa implementação, o Bom Appetite passou a ter uma base muito mais robusta para trabalhar com domínios personalizados.
Entre os principais ganhos estão:
domínios personalizados por restaurante;
SSL/TLS gerenciado automaticamente pela Cloudflare;
roteamento seguro na borda;
menor dependência de configuração manual no hosting;
resolução correta do tenant pelo domínio acessado;
mais controle sobre redirects e experiência de navegação;
base escalável para onboarding de novos clientes;
arquitetura mais preparada para crescimento SaaS.
Esse tipo de entrega é importante porque reduz atrito operacional.
Em vez de tratar cada novo domínio como uma configuração especial, a plataforma passa a ter um fluxo mais padronizado, seguro e automatizável.
Muito além de uma configuração de DNS
Por fora, a funcionalidade parece simples:
“O restaurante quer usar o próprio domínio.”
Mas por trás disso existe uma arquitetura inteira garantindo que tudo funcione corretamente.
É preciso pensar em:
como o domínio será validado;
como o SSL será emitido;
como o tráfego será roteado;
como o tenant será identificado;
como evitar spoofing de headers;
como preservar redirects no domínio correto;
como manter a aplicação desacoplada do domínio técnico;
como escalar esse processo para novos clientes.
Esse é o tipo de detalhe que diferencia uma plataforma funcional de uma plataforma realmente preparada para crescer.
Qualidade técnica como parte do produto
No Bom Appetite, tratamos infraestrutura e arquitetura como parte da experiência do produto.
Uma plataforma para restaurantes não pode depender apenas de boas telas.
Ela precisa ser confiável, rápida, segura e preparada para operar em cenários reais: múltiplos clientes, múltiplos domínios, diferentes configurações de DNS, SSL automático, checkout funcionando corretamente e identidade preservada para cada restaurante.
Essa implementação com Cloudflare for SaaS reforça justamente essa direção.
O objetivo é oferecer aos restaurantes uma solução com aparência simples por fora, mas com uma fundação técnica sólida por dentro.
Porque, no final, uma boa plataforma SaaS precisa esconder a complexidade do cliente, não empurrar essa complexidade para ele.
Bom Appetite: tecnologia para restaurantes com base SaaS real
O Bom Appetite segue evoluindo como uma plataforma completa para restaurantes que querem vender, operar e se relacionar com seus clientes de forma mais profissional.
A integração com Cloudflare for SaaS é mais uma etapa nessa evolução.
Ela permite que cada restaurante tenha mais autonomia de marca, mais segurança e uma presença digital mais profissional, enquanto a plataforma mantém uma arquitetura escalável e preparada para crescimento.
Na Marrs Studio, esse é o tipo de solução que buscamos construir: produtos digitais bem desenhados, tecnicamente sólidos e pensados para operar no mundo real.
Não apenas sistemas que funcionam.
Mas plataformas que conseguem crescer.
