Especialização · Supabase Pro · Founder Access aberto

Pare de tratar Supabase como um Firebase com PostgreSQL.

Aprenda a projetar, proteger, testar e operar backends Supabase que você teria coragem de colocar em produção — com arquitetura multi-tenant, failure drills e evidence que mostra o que realmente está protegido.

  • 91
  • 14
  • 13
  • Professional Delivery Kit

Por que esta especialização é diferente

O dashboard facilita o começo. Engenharia decide se o sistema sobrevive ao crescimento.

Criar tabela, ativar Auth e fazer um select funcionar é a parte fácil. O trabalho de backend aparece quando existem tenants, permissões, sessões revogadas, uploads, eventos, migrations, falhas de rede e operações que precisam ser explicadas depois. É aí que entra o método Build → Break → Prove.

Build → Break → Prove Construir → atacar → observar → corrigir → provar.

  1. 01 Build Modele a capacidade e deixe o happy path funcionar.
  2. 02 Restrict Defina grants, RLS, scopes e trust boundaries.
  3. 03 Break Tente atravessar tenant, sessão, objeto, topic e privilégio.
  4. 04 Observe Leia SQL, logs, responses e estado durável.
  5. 05 Recover Trate reconnect, retry, drift e recuperação.
  6. 06 Prove Feche o Lab com teste, SHA exato e evidence sanitizada.

O backend que você aprende a defender

O Workspace Intelligence Backend cresce módulo a módulo: a mesma arquitetura SaaS recebe novas superfícies sem perder identidade, tenancy e capacidade de auditoria.

  1. CAP Capstone — Workspace Intelligence Backend
  2. M13 n8n, agents e integrações assíncronas
  3. M12 pgvector e IA com boundaries
  4. M11 Observabilidade, backup e recovery
  5. M10 Performance, conexões e custo
  6. M09 Edge Functions e webhooks
  7. M08 Realtime privado
  8. M07 Storage privado
  9. M06 Data API, RPC e fronteiras de confiança
  10. M05 RLS e multi-tenancy
  11. M04 Auth e ciclo de sessão
  12. M03 Schema as Code e migrations
  13. M02 Integridade, transações e performance inicial
  14. M01 PostgreSQL e modelagem relacional
  15. M00 Arquitetura, trust boundaries e threat model

Do PostgreSQL ao backend SaaS operável

Sua evolução

Você começa modelando. Termina raciocinando como quem precisa operar o sistema.

A progressão não é uma lista de features. Cada fase acrescenta uma superfície e obriga você a preservar tenancy, identidade, autorização e capacidade de recuperação.

  1. 01

    1. Construa uma fundação que o banco consegue defender

    Domínio, invariantes, transactions e migrations deixam de ser detalhes de setup e viram contrato técnico do produto.

    • M00 — Como pensar Supabase em produção
    • M01 — PostgreSQL e modelagem relacional
    • M02 — Integridade, transações e performance inicial
    • M03 — Schema como código
  2. 02

    2. Separe identidade de autorização

    JWT identifica. RLS autoriza. Membership atual decide. Você prova isolamento entre tenants em vez de confiar em filtros de aplicação.

    • M04 — Identity lifecycle com Auth
    • M05 — Autorização e multi-tenancy com RLS
  3. 03

    3. Abra superfícies sem abrir brechas

    Data API, Storage e Realtime entram com boundaries explícitas, adversarial tests e reconciliação de estado.

    • M06 — APIs e fronteiras de confiança
    • M07 — Storage seguro
    • M08 — Realtime privado e estado durável
  4. 04

    4. Leve o backend para operação real

    Functions, jobs, pooling, observabilidade, backup, vetores e integrações assíncronas entram com idempotência, budgets e recuperação.

    • M09 — Edge Functions, webhooks e integrações
    • M10 — Performance, conexões e custo
    • M11 — Observabilidade, operação e recovery
    • M12 — pgvector e fundação para aplicações com IA
    • M13 — n8n, agents e integrações assíncronas
  5. 05

    5. Integre tudo no Capstone

    O Workspace Intelligence Backend vira um sistema multi-tenant integrado e submetido a failure drills ponta a ponta.

    • Capstone — Workspace Intelligence Backend

O que você constrói

Artefatos que fazem sentido fora do curso

Migrations, policies, Labs, validators e failure drills existem para virar repertório de engenharia — não apenas atividade concluída.

  1. 01

    Workspace Intelligence Backend multi-tenant

  2. 02

    modelo relacional com constraints e índices

  3. 03

    migrations e schema reproduzível

  4. 04

    Auth lifecycle com revogação e failure drills

  5. 05

    RLS com isolamento entre tenants

  6. 06

    Data API e RPC com trust boundaries

  7. 07

    Storage privado com ownership e MIME/size boundaries

  8. 08

    Realtime privado com authorization e reconciliação após gaps

  9. 09

    webhooks/functions idempotentes

  10. 10

    estratégia de jobs e processamento assíncrono

  11. 11

    observabilidade, backup e recovery

  12. 12

    pgvector/IA sem perder filtro e autoridade

  13. 13

    Capstone integrado com evidence

Prova técnica

Aqui “evidence” não é um selo de marketing.

Os Labs importantes fecham com contratos verificáveis e execuções isoladas no Genesis Runner. Quando um módulo recebe E2, isso significa que aquela capability foi reproduzida no runtime delimitado — não que qualquer ambiente hosted esteja automaticamente validado.

  • PostgreSQL reproduzível
  • Auth lifecycle exercitado
  • RLS cross-tenant negada
  • stale membership revogada
  • Data API boundary tests
  • Storage adversarial
  • Realtime privado + reconnect
  • zero host ports nos Labs isolados

Você não termina um Lab quando a feature aparece na tela.

Você termina quando consegue explicar a boundary, reproduzir o comportamento, provocar a falha relevante e validar a evidence. Esse hábito é transferível para os seus próprios sistemas.

  1. schema e invariantes
  2. migration drift
  3. Auth lifecycle
  4. RLS adversarial
  5. Data API trust boundaries
  6. Storage ownership
  7. Realtime private channels
  8. idempotência e webhooks
  9. performance e recovery
  10. IA/pgvector com filtro de tenant

Projeto final

Workspace Intelligence Backend — O projeto que amarra a especialização.

Você evolui um SaaS multi-tenant com organizations, workspaces, memberships, projects e documents. O Capstone conecta Auth, RLS, API, Storage, Realtime, processamento server-side, observabilidade e IA — e só recebe claim integrado quando essas boundaries forem realmente executadas.

Para quem é

Para quem quer deixar de depender de receitas prontas

  • Desenvolvedores que já conseguem construir aplicações e querem elevar maturidade de backend.
  • Quem está criando SaaS, produtos multi-tenant, sistemas internos ou aplicações com recursos de IA.
  • Quem usa Supabase, mas ainda sente insegurança em Auth, RLS, service role, Storage, Realtime ou migrations.
  • Quem quer entregar projetos para clientes com uma arquitetura que consiga explicar, testar, manter e defender em revisão técnica.

Para quem não é

Não é um curso de atalhos ou dashboard tourism

  • Quem está procurando um curso de programação do zero.
  • Quem quer apenas copiar SQL/policies sem entender o modelo de autorização.
  • Quem espera transformar uma service role em solução universal para segurança.
  • Quem procura promessa de renda, carreira acelerada ou “atalho secreto” em vez de engenharia.

Instrutor

Asllan Maciel

Programador há mais de 25 anos. Empreendedor digital. Ensina o que usa de verdade — com um objetivo claro: ajudar pessoas a ganharem mais e terem mais liberdade. Tecnologia e produto são a base; oferta, vendas e clientes fecham o ciclo até a renda.

Limites profissionais

Profissionalismo também é saber exatamente o que a prova não diz.

Founder Access · E2 por capability · E3 continua separado

  • 01

    E2 comprova o comportamento reproduzido no harness delimitado; não significa paridade automática com qualquer projeto hosted, região, plano ou configuração.

  • 02

    M00–M13 e o Capstone compõem a entrega disponível no Founder Access. Claims E2/E3 permanecem separados por capability e execução.

  • 03

    Nenhuma secret key, token real, connection string de produção ou credencial do aluno faz parte da evidence pública.

  • 04

    A plataforma evolui. Versões, comportamento e recomendações relevantes são tratados como parte do conteúdo técnico, não escondidos atrás de screenshots antigos.

Evolução incluída

12 meses de evolução desta especialização incluídos

Sua matrícula Founder inclui 12 meses de atualizações do Supabase Pro. Se Auth, Realtime, API keys, runtimes ou práticas relevantes mudarem de forma material, a edição acompanha o que altera arquitetura, segurança ou operação. Renovação futura, se oferecida, será opcional e explícita.

Investimento

Founder Access · Supabase Pro

R$ 1.497,00 R$ 797,00

Economize R$ 700,00

  • Acesso imediato
  • Atualizações por 12 meses
  • Suporte da plataforma

Dúvidas antes de entrar

O que você precisa saber antes da matrícula

Isso já está à venda?

Sim. A matrícula Founder está aberta por R$ 797 no checkout padrão do AMCursos. M00–M13 e o Capstone estão disponíveis agora nesta edição Founder.

O valor Founder é pagamento único?

Sim. O valor Founder de R$ 797 é cobrado uma única vez e inclui acesso ao conteúdo e 12 meses de atualizações desta especialização. Depois desse período, o acesso expira. Não há renovação automática anunciada nesta oferta.

O que consigo levar para um projeto real?

Você sai com migrations, policies, testes adversariais, runbooks, failure drills e templates de evidence que podem ser adaptados ao contexto do seu projeto. O curso ensina o raciocínio e os contratos; ambiente, plano, região e configuração hosted continuam exigindo validação própria.

O que recebo imediatamente no Founder Access?

M00–M13 e o Capstone estão disponíveis no Founder Access, incluindo o Lab assíncrono e o pacote operacional do projeto final.

Preciso já dominar Supabase?

Não precisa dominar Supabase, mas esta não é uma formação de programação do zero. Conforto com desenvolvimento web/backend, SQL básico, APIs e autenticação ajuda bastante.

É um curso baseado no dashboard?

Não. O dashboard aparece quando ajuda, mas o eixo é PostgreSQL, migrations, identidade, autorização, APIs, runtime, debugging e operação. A interface não é tratada como arquitetura.

O curso realmente cobre preocupações de produção?

Sim, dentro dos boundaries ensinados: multi-tenancy, revogação, RLS, objetos privados, Realtime privado, migrations, idempotência, performance, observabilidade, backup e recovery. O material também deixa claro onde a evidence ainda não equivale a um ambiente hosted específico.

O que significa E2?

E2 significa que aquela capability foi reproduzida em runtime controlado com critérios verificáveis e evidence sanitizada. É mais forte que “tem código” ou “passou num mock”, mas não significa E3/produção hosted automaticamente.

E3/hosted está garantido?

Não. E3 é uma classe separada. Região, plano, quotas, rede, secrets, configuração hosted e integrações do seu ambiente precisam da própria validação.

Por quanto tempo tenho acesso e recebo atualizações?

A matrícula Founder inclui acesso ao conteúdo e atualizações desta especialização por 12 meses. Qualquer renovação futura, se existir, será opcional e explícita.

Ainda existem módulos desta edição aguardando liberação?

Não. M00–M13 e o Capstone estão liberados. Atualizações futuras entram como evolução do conteúdo dentro da janela incluída, sem reclassificar automaticamente claims de runtime.

Pare de tratar Supabase como um Firebase com PostgreSQL.

Não apenas construa um backend. Construa um backend que você consegue defender, operar e provar.

Como o portal é feito

Stack do AMCursos