Floci – emulador local de AWS gratuito e open source

• Floci é um emulador local de AWS gratuito e open source que pode ser executado imediatamente, sem cadastro de conta nem autenticação, com uma arquitetura leve iniciada por um único comando
• Posiciona-se como uma alternativa sem limitações para o período após o fim do serviço em 2026 da edição Community do LocalStack, e permite uso comercial por meio da licença MIT
• É extremamente leve, com tempo de inicialização de 24 ms, 13 MiB de memória e 90 MB de tamanho de imagem, mostrando velocidade 100 vezes maior e uso de memória 10 vezes menor em comparação com o LocalStack
• Oferece suporte completo a mais de 20 serviços AWS e garante alta compatibilidade com 408 testes de SDK aprovados
• Pode ser integrado imediatamente em ambientes locais de desenvolvimento e teste apenas alterando o endpoint do SDK AWS existente, oferecendo uma solução alternativa pronta para uso

---

Visão geral do Floci

• Floci é um emulador local de AWS gratuito e open source, com uma estrutura que permite execução imediata sem cadastro de conta nem token de autenticação
• É iniciado apenas com o comando docker compose up, sem limitações de CI/CD nem bloqueio de funcionalidades
• O nome vem de cirrocumulus floccus, um tipo de nuvem, e o projeto adota o lema “leve, suave e sempre gratuito”

Posicionamento como alternativa ao LocalStack

• A edição Community do LocalStack está com encerramento do serviço previsto para março de 2026; depois disso, deverá exigir token de autenticação, encerrar o suporte a CI e parar as atualizações de segurança
• O Floci é apresentado como uma alternativa sem limitações a esse cenário
• É distribuído sob a licença MIT, permitindo uso livre, inclusive comercial

Comparação de desempenho e funcionalidades

• Muito leve, com tempo de inicialização de cerca de 24 ms, 13 MiB de memória em idle e 90 MB de tamanho da imagem Docker
• Em comparação com a versão Community do LocalStack, oferece inicialização cerca de 100 vezes mais rápida e uso de memória mais de 10 vezes menor
• Suporte a mais de 20 serviços AWS, com 408/408 testes de SDK aprovados
• Principais serviços suportados:

  • API Gateway v2 / HTTP API**,** Cognito**,** ElastiCache (Redis + autenticação IAM)

  • RDS (PostgreSQL, MySQL, autenticação IAM), S3 Object Lock (COMPLIANCE / GOVERNANCE)

    • DynamoDB Streams, IAM, STS, Kinesis, KMS etc. com suporte completo
    • No LocalStack, esses recursos têm suporte parcial ou não são suportados

Início rápido

• Exemplo básico de configuração docker-compose.yml fornecido
  • Usa a porta 4566 e monta o diretório local ./data
• Comando de execução:

  docker compose up
  

• Todos os serviços podem ser acessados em http://localhost:4566
• As credenciais AWS podem usar valores arbitrários (AWS_ACCESS_KEY_ID=test, AWS_SECRET_ACCESS_KEY=test)
• Comandos de exemplo:
  • aws s3 mb s3://my-bucket
  • aws sqs create-queue --queue-name my-queue
  • aws dynamodb list-tables

Integração com SDK

• Basta alterar o endpoint do SDK AWS existente para usar normalmente
• Exemplos por linguagem:
  • Java (AWS SDK v2): endpointOverride(URI.create("http://localhost:4566";))
  • Python (boto3): endpoint_url="http://localhost:4566";
  • Node.js (AWS SDK v3): endpoint: "http://localhost:4566";
• Em todos os exemplos, region é us-east-1 e as credenciais usam o valor "test"

Tags de imagem

• latest: imagem nativa, recomendada por ter tempo de inicialização inferior a 1 segundo
• latest-jvm: imagem baseada em JVM, com foco em compatibilidade de plataforma
• x.y.z / x.y.z-jvm: releases com versão fixa

Configuração de ambiente

• Todas as configurações podem ser sobrescritas por variáveis de ambiente com o prefixo FLOCI_
• Principais variáveis:
  • QUARKUS_HTTP_PORT: padrão 4566
  • FLOCI_DEFAULT_REGION: padrão us-east-1
  • FLOCI_DEFAULT_ACCOUNT_ID: padrão 000000000000
  • FLOCI_STORAGE_MODE: escolha entre memory, persistent, hybrid, wal (padrão hybrid)
  • FLOCI_STORAGE_PERSISTENT_PATH: caminho do diretório de dados (./data)
• Documentação completa de configuração: configuration docs
• Configuração de armazenamento por serviço: storage docs

Licença

• Fornecido sob a licença MIT, permitindo uso e modificação livres sem restrições

[GN⁺]

Comentários no Hacker News

• Seria bom se provedores de nuvem como AWS, GCP e Azure oferecessem oficialmente emuladores para desenvolvimento local
  Atualmente uso várias stacks serverless da AWS, e testes de integração locais são quase impossíveis
  O Localstack é uma alternativa razoável, mas esse tipo de recurso deveria ser oferecido pela própria AWS para melhorar muito mais a experiência dos desenvolvedores

  • Um emulador local oficial parece bom na teoria, mas na prática a AWS teria que explicar uma por uma as diferenças de comportamento de S3, IAM, Kinesis etc.
    As pessoas confundiriam essas diferenças com bugs da AWS, então do ponto de vista deles isso viraria um pesadelo de suporte
  • Vi o projeto local-web-services, criado por um engenheiro da AWS, e ele oferece funcionalidades bem parecidas
    Também é interessante ver o Localstack enfrentando concorrência graças à tendência de tooling de infraestrutura shift-left baseado em IA
  • Antigamente a Microsoft oferecia um sandbox de nó único chamado Azure Service Dev Kit (ASDK)
    Hoje ele foi reduzido, mas a ideia era imitar toda a nuvem Azure localmente
  • Eu discordo totalmente dessa opinião
    O software deveria ser projetado com foco em abstrações e interfaces, para não ficar preso a APIs específicas de uma nuvem
  • A Cloudflare oferece um emulador local para sua plataforma serverless, e ele funciona bem

• Esse tipo de ferramenta me parece uma tentativa sem sentido
  Para testes unitários, é melhor fazer mocking das chamadas da AWS,
  e para desenvolvimento local é mais seguro provisionar de fato um ambiente de teste com ferramentas de IaC como Terraform
  Se o comportamento do emulador for diferente do serviço real, há risco de bugs escaparem para produção

  • Além disso, também pode acontecer o efeito inverso: código que não funciona bem localmente, mas roda corretamente na AWS real

• Organizei aqui minha experiência e minhas opiniões sobre o conceito de “AWS local”

  • Não acho que esse tipo de produto ajude muito a atrair novos clientes
    Quem evita até cadastrar um cartão de crédito de qualquer forma não vai virar um cliente de alto valor
  • O free tier da AWS é bem generoso. Eu mesmo não gasto nem 10 dólares por ano
  • Para aprender AWS, é preciso vivenciar diretamente a realidade do controle de custos. É melhor ser cobrado em 5 dólares no começo do que perder 5 mil depois
  • A verdadeira vantagem de uma nuvem local é permitir iterações rápidas de desenvolvimento sem carga de segurança
    Mas, na hora do deploy real, essa dívida de segurança precisa ser resolvida, e nesse processo o código que “funcionava na minha máquina” costuma quebrar
  • O Localstack recebe suporte não oficial da AWS, por isso é rico em recursos e lança atualizações rapidamente
    Parece difícil para uma alternativa FOSS alcançar esse nível
  • Para mim, o motivo de precisar desse tipo de ferramenta é justamente a emulação de permissões IAM
    Para seguir o princípio do menor privilégio, é preciso liberar permissões uma por uma, e isso fica lento como um jogo de whack-a-mole de permissões
    Se desse para reproduzir o IAM com precisão localmente, o ciclo de deploy poderia ser bastante encurtado
    O Localstack tem esse recurso na versão paga, e fiquei curioso para saber quão bem o novo projeto implementou isso
  • Em ambientes de CI/CD, o Localstack é praticamente indispensável
    É preciso rodar centenas de testes de integração rapidamente, e chamadas reais à AWS são ineficientes por causa de latência, problemas de consistência, cobrança e rate limit
    Dar uma conta AWS para cada desenvolvedor também é um pesadelo de gestão
    A ideia de que “só se aprende tomando uma bomba de cobrança da AWS” é uma analogia irrealista, como dizer que “para aprender sobre fogo é preciso se queimar”
  • O principal objetivo de emuladores locais é teste unitário e parte dos testes de integração
    Se cada desenvolvedor tiver sua própria conta e apenas forem configurados billing alerts, a questão de segurança não é tão grave

• Fiquei curioso sobre como esse projeto difere do moto
  Há muita insatisfação com a mudança de licença do Localstack, mas já existem boas alternativas
  A cobertura de serviços do moto é impressionante
  Nossa equipe quase migrou, mas continuamos com o Localstack graças ao contrato de suporte enterprise

• Parece bem útil para testes
  Estou criando automação de empacotamento de Lambda com uma role do Ansible,
  e seria muito mais prático se eu pudesse fazer mocking da parte que verifica se já existe um zip no S3

• A edição comunitária do LocalStack será encerrada em março de 2026, com exigência de token de autenticação e fim das atualizações de segurança previstos
  O Floci é apresentado como uma alternativa sem essas restrições

  • É triste ver isso acabar depois de tantos anos, mas a licença enterprise que usamos na empresa era realmente excelente
    Ela criou um loop de feedback rápido sem precisar esperar deploys do CloudFormation, economizando milhares de horas
    Também permitia testar no trem sem conexão com a internet

• O nome desse projeto é engraçado porque em romeno significa “pequeno tufo de pelos” e, na gíria, pelos pubianos

  • Em latim, significa “tufo de lã”, e também aparece na expressão flocci non facio, com sentido de “algo sem valor”

• Esse é o projeto que eu estava esperando
  Gosto do Localstack, mas sempre achei que uma solução aberta guiada pela comunidade seria muito mais adequada
  Se houvesse uma estrutura em que engenheiros da AWS pudessem contribuir diretamente, seria bom para todos
  Com a adoção de IA acelerando agora, testes de integração locais são essenciais

  • Mas, do ponto de vista da AWS, não há motivo para dar suporte a um clone FOSS
    Em vez disso, seria mais realista oferecer oficialmente uma versão local em contêiner
  • Concordo totalmente. Especialmente agora que workflows com agentes alteram estado real,
    o teste local é a única forma segura de experimentar situações como “a alucinação do modelo que apaga a tabela”

• Já usei o Localstack e achei bem decente
  Alguém sabe se existe algo parecido para GCP?
  O bigquery-emulator foi útil,
  mas ainda não encontrei nada que emule o GCP inteiro

• Os recursos parecem legais, mas o histórico de commits é quase inexistente, e não há PRs nem issues
  Passa a impressão de ser um projeto gerado automaticamente, então é difícil confiar
  Não tenho certeza se é seguro para testar dados reais

  • Também concordo. Em um projeto OSS, deveria haver ao menos algumas issues acumuladas para encontrar pontos de contribuição
    Como ainda está bem no começo, vou continuar observando
  • Talvez seja um projeto vibe-coded
  • Ver que o projeto acabou de completar uma semana e já levantar esse tipo de suspeita é exagero
    Antigamente eu acreditava que, por ser open source, alguém acabaria encontrando problemas de segurança,
    mas hoje também dá para rodar auditorias de segurança com LLM
    Não é perfeito, mas esse tipo de auditoria automática dificulta esconder código malicioso