App de flashcards auto-hospedado e de código aberto para repetição espaçada

Sim, o Nibomo pode ser auto-hospedado. Todo o código da aplicação e da infraestrutura é de código aberto sob a licença MIT. Você pode rodar os serviços localmente para desenvolvimento ou implantar na AWS a stack de produção documentada do repositório. Se você não quer operar infraestrutura, o app hospedado continua disponível.

Telas do Nibomo no celular para revisão, progresso, chat de IA e cartões

O que dá para auto-hospedar

O repositório contém os serviços e a infraestrutura usados no sistema principal do Nibomo:

  • o app web e o app admin
  • a API de backend e o serviço de autenticação sem senha
  • o schema do PostgreSQL, as migrações, a sincronização e o agendamento de revisões baseado em FSRS
  • o servidor MCP e a Agent API voltada para máquinas
  • a stack de AWS CDK para rede, banco de dados, autenticação, APIs, hospedagem web estática, segredos, backups, monitoramento e CI/CD

Ele também inclui os clientes nativos de iOS e Android. Esses apps são builds separados; implantar a stack da AWS não publica as suas próprias versões na App Store ou no Google Play.

Existem dois jeitos suportados de rodar a stack do lado servidor:

  1. Desenvolvimento local: o Docker Compose sobe o PostgreSQL e o job de migração. Os scripts do repositório rodam os servidores de desenvolvimento de auth, backend, web e admin na própria máquina.
  2. Produção na AWS: a stack de CDK incluída implanta a arquitetura AWS documentada e conecta seus domínios públicos pelo Cloudflare.

O Docker Compose não é uma implantação de produção em um comando. O caminho de produção é específico para AWS, e o projeto não promete uma infraestrutura neutra em relação a fornecedor.

O que o repositório inclui hoje

Isso é bem mais que um editor de cartões avulso. O repositório atual inclui:

  • um cliente web em React e um cliente admin
  • clientes nativos em SwiftUI no iOS e em Jetpack Compose no Android
  • armazenamento local offline-first e sincronização para os clientes de pessoas
  • cartões com frente e verso, tags, mídias relacionadas e revisão com FSRS
  • OTP por e-mail sem senha pelo Amazon Cognito e pelo serviço de autenticação
  • chat de IA apoiado por um worker assíncrono implantado e credenciais de modelo fornecidas por quem opera
  • um endpoint MCP para clientes de IA compatíveis
  • uma Agent API para ferramentas de terminal e outros fluxos automatizados

A documentação de arquitetura é a melhor fonte sobre os limites atuais entre os serviços. O guia da API público explica o ponto de entrada da Agent API hospedada.

Hospedado x auto-hospedado

Área App hospedado Implantação auto-hospedada
Configuração inicial Abra o app e entre Configure contas, segredos e domínios, e implante a stack da AWS
Infraestrutura Operada pelo projeto Nibomo Operada nas suas contas da AWS e do Cloudflare
Banco de dados e backups Gerenciados para você RDS, política de backup, migrações e recuperação são responsabilidade sua
Autenticação e e-mail Gerenciados para você Cognito mais suas credenciais de envio de e-mail e o DNS
IA Usa a configuração do serviço hospedado Usa o worker implantado e suas credenciais de modelo; o acesso de convidado tem uma cota separada
Monitoramento Gerenciado para você CloudWatch/SNS e sua configuração do Sentry
Atualizações Entregues pelo serviço hospedado Você baixa, valida, implanta e monitora as atualizações
Custo Valem os termos do plano hospedado Você paga direto os custos da AWS e de outros provedores

Auto-hospedar dá a você o controle da implantação e do banco de dados. Também coloca nas suas mãos as atualizações de segurança, os segredos, a disponibilidade, os backups, a entrega de e-mail, o monitoramento e os custos de nuvem.

Requisitos e início rápido local

O desenvolvimento local hoje precisa de Git, Bash, GNU Make, Docker com Docker Compose, Node.js 24 e npm. O arquivo do Compose incluído roda o PostgreSQL 18.4 e aplica as migrações do banco.

A partir da raiz do repositório:

git clone https://github.com/kirill-markin/flashcards-open-source-app.git
cd flashcards-open-source-app
cp .env.example .env
make db-up
npm install --prefix api
npm install --prefix apps/auth
npm install --prefix apps/backend
npm install --prefix apps/web
npm install --prefix apps/admin

Para o começo mais curto, só local, rode o backend com o papel criado pela migração e habilite de forma explícita a autenticação local insegura:

AUTH_MODE=none \
ALLOW_INSECURE_LOCAL_AUTH=true \
DATABASE_URL=postgresql://backend_app:backend_app@localhost:5432/flashcards \
REPORTING_DATABASE_URL=postgresql://reporting_readonly:reporting_readonly@localhost:5432/flashcards \
make backend-dev

Depois rode os clientes em terminais separados:

make web-dev
make admin-dev

Isso não sobe o serviço de autenticação do Cognito, de propósito. O Guia de auto-hospedagem traz as URLs de banco separadas e os passos de carregamento de variáveis de ambiente para um fluxo completo com Cognito e make auth-dev. O app web roda em http://localhost:3000, o app admin em http://localhost:3001, o backend em http://localhost:8080/v1 e a autenticação do Cognito, quando configurada, em http://localhost:8081.

Esse início rápido cobre o desenvolvimento do backend principal, do web e do admin. Ele não deixa o Chat V2 disponível: essas rotas não aceitam o transporte AUTH_MODE=none, e os comandos locais não sobem o worker assíncrono de chat.

Para produção, use o fluxo de primeira implantação do repositório em vez do Docker Compose:

npm ci --prefix apps/auth
bash scripts/deploy/first-deploy.sh \
  --region eu-central-1 \
  --domain example.com \
  --alert-email alerts@example.com

A instalação explícita do auth é necessária hoje em um checkout limpo porque o helper de implantação empacota esse pacote, mas não o instala. Depois disso o helper cria e altera recursos reais na nuvem. Leia o guia de implantação do backend e do web e o guia de implantação com AWS CDK antes de rodá-lo.

A portabilidade dos dados é útil, mas limitada de propósito

A importação e a exportação de pacotes do Nibomo cobrem os cartões, suas tags e as mídias relacionadas. Elas não transferem o histórico de revisões, o estado do agendador FSRS, as configurações do espaço de trabalho, a estrutura completa dos baralhos nem os dados da conta.

Essa diferença importa se você vai sair do serviço hospedado para a sua própria implantação. O pacote portátil é um caminho de transferência de conteúdo, não uma migração completa de banco de dados ou de conta. Para um backup operacional completo, quem auto-hospeda também precisa cuidar do banco PostgreSQL e do armazenamento de mídia criados pela stack da AWS.

IA e credenciais de serviços externos

O código-fonte não inclui contas de nuvem, créditos de modelo nem credenciais de produção. Quem auto-hospeda fornece a configuração correspondente:

  • credenciais e uma conta da AWS para a stack de CDK
  • um domínio e credenciais do Cloudflare para a configuração de DNS documentada
  • credenciais do Resend para o envio de e-mail
  • configuração do Sentry para o monitoramento obrigatório do backend
  • credenciais opcionais da OpenAI e do Langfuse para IA e tracing
  • configuração do GitHub para o fluxo de implantação incluído

A IA é opcional na implantação na AWS. A stack de CDK implanta o worker assíncrono de chat, e as credenciais de modelo habilitam as requisições de IA autenticadas suportadas. O GUEST_AI_WEIGHTED_MONTHLY_TOKEN_CAP controla à parte o uso de IA por convidados; ele não é um interruptor global para a IA de quem está autenticado por sessão ou por bearer. Se você conectar o MCP ou outro cliente de IA externo, os dados de cartões incluídos em uma requisição podem ser processados por esse provedor externo sob os termos dele; auto-hospedar o banco de dados não mantém essas requisições dentro da sua infraestrutura.

Limites reais de beta e de operação

O Nibomo ainda é um produto em fase inicial. O repositório está ativo, as migrações e a configuração de implantação podem mudar, e a auto-hospedagem pressupõe que você se sente à vontade operando uma aplicação na AWS.

A stack de CDK traz backups, alarmes, segredos e automação de implantação, mas esses componentes ainda precisam de alguém operando. Conte com este trabalho:

  • revisar as mudanças de infraestrutura antes de implantar
  • monitorar as versões e as checagens de endpoints públicos
  • confirmar as inscrições de alerta e o DNS do domínio de e-mail
  • proteger e rotacionar as credenciais
  • testar restaurações e planejar os custos da AWS
  • compilar e distribuir os apps móveis nativos à parte, se você quiser publicar suas próprias versões

Se esse trabalho operacional não te serve, o app hospedado é o caminho mais simples.

Uma breve comparação com Anki e Quizlet

O Anki é uma opção madura de código aberto, com um ecossistema grande e fluxos de trabalho fortes no desktop. O Quizlet é um serviço gerenciado para consumidor, com uma experiência de estudo que quase não exige configuração. Os dois podem ser a escolha certa, dependendo de você valorizar uma ferramenta local consolidada ou uma plataforma totalmente gerenciada.

O Nibomo segue outro caminho: um repositório aberto de web, mobile, API e infraestrutura, construído em torno de FSRS, sincronização, fluxos com IA, MCP e uma opção de auto-hospedagem na AWS. Ele é mais novo que o Anki e, quando auto-hospedado, exige bem mais trabalho de operação que o Quizlet. O motivo para escolhê-lo é essa combinação servir para o que você precisa, não a ideia de que toda pessoa que estuda deveria operar uma stack na nuvem.

Teste o app hospedado ou rode sua própria stack

Use a versão hospedada quando quiser estudar sem manter infraestrutura. Use o caminho auto-hospedado quando o controle da implantação compensar o trabalho de AWS, DNS, e-mail, monitoramento e atualizações.

Leia a seguir