Builder Notes

Downloads protegidos com Supabase, Stripe, R2 e Cloudflare

Uma visão prática de como o ImgKit conecta login, checkout, acesso ao produto, arquivos privados e URLs de download assinadas.

Produtos digitais pagos precisam de uma base enfadonha, mas importante: os compradores devem conseguir pagar, entrar e baixar o arquivo certo sem expor um link ZIP público.

O ImgKit usa um padrão simples de downloads protegidos:

  1. O Supabase cuida do login.
  2. O Stripe cuida do checkout.
  3. O aplicativo registra o acesso ao produto.
  4. O R2 armazena os arquivos privados.
  5. O Cloudflare Functions retorna URLs assinadas de curta duração.

Por que downloads protegidos importam

Se um arquivo ZIP pago fica em uma pasta pública, qualquer pessoa com a URL pode compartilhá-lo. Isso pode ser aceitável para amostras grátis, mas é fraco para produtos pagos.

Os downloads protegidos adicionam uma verificação no servidor:

  • Quem é o usuário?
  • Esse usuário comprou o produto?
  • O asset de download está ativo?
  • O servidor consegue gerar uma URL temporária?

O usuário ainda recebe um download normal no navegador, mas o caminho de armazenamento permanente não é público.

Login com Supabase

O Supabase dá ao ImgKit uma identidade de conta. Um comprador entra com e-mail, e então o checkout e os downloads podem ser vinculados a essa conta.

Para os primeiros produtos, o login por e-mail é suficiente. Os compradores não precisam de um painel complicado só para baixar um arquivo protegido.

Checkout com Stripe

O Stripe cuida da sessão de pagamento. O comprador inicia o checkout no site, paga e retorna ao ImgKit.

O servidor então precisa conectar a sessão concluída ao acesso do produto. Isso pode acontecer por meio de webhooks e de um endpoint de sincronização de checkout, para que o comprador veja o acesso logo após o pagamento.

Acesso ao produto

O acesso ao produto deve ser separado de rótulos genéricos de assinatura. Um comprador pode possuir um produto, mas não outro.

No caso do ImgKit, o descontinuado Builder Case Study usava seu próprio direito de produto. Esse modelo ainda permite que produtos futuros existam sem transformar cada comprador em um membro de assinatura ampla.

Armazenamento privado no R2

O R2 armazena o pacote ZIP real fora do bundle público do site. O site não linka diretamente ao objeto do R2.

Em vez disso, um endpoint de download verifica o acesso e pede uma URL temporária ao armazenamento.

URLs assinadas

Uma URL assinada concede acesso temporário a um arquivo privado. Se a URL expirar após uma janela curta, fica menos útil compartilhá-la permanentemente.

Isso não é um DRM pesado. É um limite prático de entrega paga para um MVP.

O que o ImgKit aprendeu

A página arquivada de ImgKit Builder Case Study preserva as decisões de implementação ao redor: por que as vendas de software pago foram pausadas, como os downloads protegidos foram moldados e como o pacote de código-fonte foi testado como a primeira oferta paga.

Esse contexto importa porque o fluxo técnico é apenas metade do produto. A outra metade é decidir o que vender primeiro.

Perguntas frequentes

Por que não colocar os arquivos ZIP pagos em uma pasta pública?

Arquivos públicos podem ser compartilhados diretamente. A entrega protegida permite que o servidor verifique o acesso da conta e retorne URLs de download de curta duração.

O Stripe armazena o arquivo?

Não. O Stripe cuida do pagamento. O acesso ao produto e a entrega do download são tratados pelo aplicativo e pelo armazenamento privado.

Por que usar URLs assinadas?

URLs assinadas permitem que um arquivo privado seja baixado por um tempo limitado sem expor o acesso permanente ao armazenamento.

Guias relacionados

Leia a seguir