Runtime das Edge Functions do Supabase: o que muda com o Deno na Cloudflare?

Se você usa Supabase Edge Functions, esta notícia importa porque elas rodam no Supabase Edge Runtime, compatível com Deno. A chegada da equipe do Deno à Cloudflare levanta dúvidas sobre quem manterá essa tecnologia no longo prazo. Por ora, o Supabase diz que não é preciso migrar. Se seu projeto não usa Edge Functions, este anúncio não exige mudanças no Postgres, Auth ou Storage.

O tema importa principalmente para quem mantém webhooks de pagamento, validação de permissões, envio de e-mails, processamento de dados ou integrações com APIs dentro de Edge Functions. Se seu projeto usa apenas Postgres, Auth, Storage ou um frontend e não depende dessas funções, o anúncio não exige migrar esses serviços.

A resposta prática por enquanto: se você usa Edge Functions, acompanhe os avisos do Supabase e saiba quais funções são críticas. Não há necessidade de migrar hoje. Se você não usa Edge Functions, não precisa mudar sua aplicação por causa deste anúncio.

Em 9 de outubro, a equipe do Deno anunciou que vai se juntar à Cloudflare. O runtime não será desligado de imediato: por mais um ano, o time promete lançar atualizações mensais com correções de bugs e segurança. Depois desse período, a empresa encerra o desenvolvimento próprio do runtime Deno, que continuará aberto para manutenção da comunidade ou de outros responsáveis.

O serviço Deno Deploy tem outro prazo: continuará funcionando por seis meses antes de ser encerrado, com apoio de migração para clientes pagantes que forem para o Cloudflare Workers. Já o registro de pacotes JSR continuará ativo, com a infraestrutura transferida para a Cloudflare. São produtos diferentes: o fim do Deno Deploy não desliga as Edge Functions hospedadas pelo Supabase.

A Cloudflare diz que vai combinar o trabalho do Deno em celld com o runtime workerd, usado nos Workers, para facilitar a execução e a hospedagem própria de aplicações distribuídas. Isso explica a mudança de foco: a equipe deixa de manter um runtime e um serviço de hospedagem independentes para trabalhar numa plataforma compartilhada.

O runtime Deno não será desligado ao fim de um ano. O que termina, segundo o anúncio, é o desenvolvimento pela equipe original. O código continuará aberto.

As Edge Functions são pequenos trechos de TypeScript executados no servidor. A documentação do Supabase descreve o Supabase Edge Runtime como compatível com Deno. É essa camada de execução, e não o banco de dados, que conecta o anúncio ao projeto de quem usa Supabase.

O Supabase opera a própria infraestrutura para hospedar as funções e não depende do serviço Deno Deploy. Por isso, o encerramento do Deno Deploy não equivale ao desligamento das funções do Supabase. O ponto a acompanhar é como o runtime usado por elas será mantido no futuro.

Se o código de uma função chama serviços do Google, como login, Maps ou Sheets, a integração não é desativada por essa mudança. Ela continua funcionando na estrutura atual; vale apenas registrar que a chamada roda dentro de uma Edge Function e acompanhar as orientações futuras do Supabase.

Sim, mas ela ainda não está pronta para qualquer projeto de produção. Em resposta a uma pergunta na comunidade do Supabase, Mark Burggraf, engenheiro da empresa, disse que não há necessidade de migrar as Edge Functions agora. Ele afirmou que o Supabase vai seguir trabalhando no runtime durante a transição e pretende oferecer um caminho de migração para o Compute antes do fim da janela de suporte do Deno.

A página oficial do Supabase apresenta o Compute como uma nova opção para executar serviços e workloads junto ao banco de dados, com suporte anunciado a Node, Deno e contêineres. No momento, o produto está em alfa privada, tem acesso restrito e não deve ser usado para atender aplicações de produção. O comentário de Burggraf também diz que ainda não existe um cronograma público de migração.

Isso coloca a situação em perspectiva: existe um plano em construção, mas não há um botão de migração disponível para todos nem uma data pública para mudar as funções existentes. A resposta honesta hoje é acompanhar os avisos oficiais, sem parar de desenvolver nem fazer uma mudança preventiva às pressas.

O Supabase diz que não é preciso migrar as Edge Functions hoje. O Compute está em alfa privada e ainda não tem um cronograma público de migração.

Se um agente de IA montou seu app, talvez você nem saiba se ele criou Edge Functions ou colocou chamadas a serviços externos direto no frontend. Faça um inventário primeiro. Isso ajuda a entender o que existe sem alterar código nem iniciar uma migração antes da hora.

• Procure a pasta supabase/functions no repositório e anote o nome e a finalidade de cada função.
• Identifique quais funções recebem pagamentos, webhooks, dados pessoais ou chamadas que precisam de chaves secretas.
• Confira se o código está versionado no GitHub e se você consegue testar uma função localmente com o Supabase CLI.
• Anote integrações, dependências e variáveis de ambiente pelo nome. Nunca copie os valores das chaves para um prompt de IA ou para um repositório público.
• Acompanhe a documentação e os anúncios do Supabase antes de decidir sobre qualquer migração. Quando houver um caminho público, teste primeiro em um ambiente separado.

Sem alterar arquivos, liste as Supabase Edge Functions deste projeto. Para cada uma, informe o arquivo, a finalidade, os serviços externos usados, os nomes das variáveis de ambiente necessárias (nunca revele seus valores) e os testes existentes. Não migre nada; indique apenas o que eu deveria validar quando o Supabase publicar um plano de migração.

Ainda não. Um passo a passo completo seria prematuro enquanto o Compute está em alfa privada e o Supabase não publicou a sequência de migração. Por enquanto, esta notícia traz um checklist útil para desenvolvedores independentes e para quem usa ferramentas de IA para montar aplicações. Quando os requisitos e comandos de migração estiverem disponíveis, aí sim faz sentido criar um tutorial separado, testado do começo ao fim.

Para quem está começando um app com Supabase, a mudança não é motivo para trocar de banco ou abandonar as Edge Functions. Para quem já mantém um produto em produção, o melhor preparo é saber quais funções são críticas, manter o código e os testes acessíveis e esperar instruções oficiais antes de mover qualquer coisa.