Floci: Emulador AWS All-in-One para Desenvolvimento Local

Existe uma ironia cruel no desenvolvimento cloud-native: para construir software que roda na nuvem, você precisa da nuvem. E isso tem um custo. Não apenas financeiro — embora uma conta de AWS que cresce sem controle seja dor suficiente —, mas de latência, de complexidade, de credenciais que expiram, de ambientes que divergem entre desenvolvedores.

A solução tradicional é ter uma conta de desenvolvimento na AWS. Cada membro do time com suas próprias credenciais, seus próprios buckets S3, suas próprias filas SQS. Funciona, até o dia em que alguém apaga o banco de staging sem querer, ou a conta de teste gera uma fatura de três dígitos porque um loop infinito encheu o CloudWatch de logs.

Há um caminho melhor.

O Que é o Floci

O Floci é um emulador de serviços AWS que roda inteiramente dentro de um único container Docker. Ele implementa as APIs do S3, SQS, RDS, ElastiCache, CloudWatch, X-Ray e DynamoDB — tudo acessível através de uma única porta, chamada edge port, na porta 4566.

A ideia não é nova. O Floci é um fork do LocalStack, adaptado para ser mais leve e focado nos serviços que realmente importam para o dia a dia. A diferença fundamental é que você não precisa de uma conta AWS, de credenciais reais, ou de conexão com a internet para desenvolver. Tudo roda localmente, no seu laptop, com latência zero e custo zero.

Para uma aplicação que usa S3 para armazenar arquivos, SQS para processamento assíncrono, RDS como banco de dados e ElastiCache como cache, o Floci substitui todos esses serviços por uma única linha no docker-compose.

A Arquitetura da Edge Port

O truque mais elegante do Floci é a edge port. Em vez de expor uma porta diferente para cada serviço — 4572 para S3, 4576 para SQS, 4571 para RDS —, o Floci usa uma única porta, 4566, como ponto de entrada universal.

Quando seu código faz uma requisição para http://localhost:4566, o Floci inspeciona o cabeçalho da requisição e roteia internamente para o serviço correto. Se a requisição é uma operação S3, vai para o emulador S3. Se é uma chamada SQS, vai para o emulador SQS. Se é DynamoDB, vai para o emulador DynamoDB.

Isso simplifica drasticamente a configuração. Em vez de gerenciar seis portas diferentes e seis variáveis de ambiente, você aponta tudo para um único endpoint. No código, isso se traduz em uma única variável: AWS_ENDPOINT_URL=http://localhost:4566. O SDK da AWS (boto3, aws-sdk, CLI) já sabe como lidar com endpoints customizados.

Para o desenvolvedor, a experiência é indistinguível de usar a AWS real. O mesmo código que funciona localmente funciona em produção, sem adaptações.

Floci na Prática: Um Projeto Real

No projeto SafeHire AI Platform, usamos o Floci como a espinha dorsal do ambiente de desenvolvimento local. A aplicação depende de PostgreSQL para dados relacionais, S3 para armazenamento de currículos, SQS para processamento assíncrono de análise de candidatos, ElastiCache para cache de sessões e DynamoDB para locking de state de infraestrutura.

Tudo isso, no docker-compose de desenvolvimento, é um único serviço:

floci:
  image: floci/floci:latest
  ports:
    - "4566:4566"
    - "5433:5432"
    - "6380:6379"
  environment:
    SERVICES: sqs,s3,rds,elasticache,cloudwatch,logs,xray,dynamodb

Três portas expostas. A edge port 4566 para todos os serviços AWS, a 5433 para o PostgreSQL emulado e a 6380 para o Valkey (compatível com Redis). O resto — SQS, S3, CloudWatch, X-Ray, DynamoDB — tudo passa pela 4566.

Os serviços da aplicação apontam para o Floci através de variáveis de ambiente. O código Python usa boto3 com endpoint_url, o TypeScript usa aws-sdk com configuração similar. Nenhuma lógica condicional de "se é local, faz X; se é produção, faz Y". O código é o mesmo.

Floci + OpenTofu: Testando Infraestrutura Localmente

O uso mais poderoso do Floci vai além do desenvolvimento de aplicação. Ele permite testar infraestrutura como código inteira sem gastar um centavo com AWS.

O OpenTofu (fork open-source do Terraform) armazena o estado da infraestrutura em um bucket S3 e usa uma tabela DynamoDB para prevenir corrupção quando múltiplas execuções rodam simultaneamente. Normalmente, isso exigiria criar esses recursos na AWS real antes mesmo de começar.

Com o Floci, criamos o bucket e a tabela localmente, apontamos o backend do OpenTofu para o emulador, e rodamos tofu plan e tofu apply contra uma infraestrutura AWS completa — VPC, subnets, security groups, ECS Fargate, RDS, ElastiCache, SQS, S3, CloudWatch — tudo emulado, tudo local, tudo gratuito.

O plano de execução mostra exatamente o que seria criado na AWS. Se o plano está correto, a confiança para rodar em produção é muito maior. Se há um erro de configuração, você descobre antes de provisionar recursos reais.

No próximo artigo desta série, mostro como usamos OpenTofu para versionar toda a infraestrutura AWS com a mesma disciplina de Clean Code que aplicamos ao código.

O Que Fica de Fora

O Floci é um emulador, não uma réplica perfeita. Isso importa, e é honesto reconhecer as limitações.

Performance: O emulador não tem a performance da AWS real. Uma operação S3 que leva 50ms na AWS pode levar 200ms no Floci. Para desenvolvimento, isso é irrelevante. Para benchmark, não.

Serviços não emulados: O Floci cobre os serviços mais comuns, mas não tudo. Lambda, API Gateway, Step Functions, Cognito — serviços mais complexos ou com lógica de negócio embutida não são emulados, ou são emulados de forma limitada.

IAM real: O Floci emula a API do IAM, mas não aplica políticas de permissão da mesma forma que a AWS real. Se sua aplicação depende de políticas granulares de IAM para funcionar, você precisa testar na AWS eventualmente.

Limites de serviço: A AWS tem limites de throughput, tamanho de mensagem, número de conexões. O Floci não replica esses limites. Um código que funciona no Floci pode falhar na AWS se estiver próximo dos limites do serviço.

A regra prática é simples: Floci para desenvolvimento e teste de integração. AWS real para staging e produção. O Floci não substitui a AWS; ele complementa, criando um ciclo de feedback rápido que a nuvem real simplesmente não consegue oferecer.

Quando Usar, Quando Não Usar

Use Floci quando:
- Desenvolvimento local de aplicações que usam serviços AWS
- Testes de integração que precisam de S3, SQS ou DynamoDB
- CI/CD pipelines que precisam de um ambiente AWS isolado e efêmero
- Prototipagem rápida sem configurar credenciais ou contas
- Testar infraestrutura como código antes de aplicar em produção

Não use Floci quando:
- Benchmark de performance
- Testar políticas de IAM granulares
- Serviços não suportados (Lambda, API Gateway, Cognito)
- Validação de limites e quotas da AWS
- Staging ou produção

Conclusão

O Floci resolve um problema que todo desenvolvedor cloud-native enfrenta: como iterar rápido sem depender de infraestrutura remota. A resposta é trazer a infraestrutura para perto — para dentro de um container Docker, rodando no seu laptop, com latência zero e custo zero.

Não é uma substituição da AWS. É um complemento. O Floci é o ambiente onde você experimenta, quebra, conserta e valida. A AWS é o ambiente onde você deploya com confiança, sabendo que o código já foi testado contra as mesmas APIs que vai encontrar em produção.

Essa separação — dev local com emulador, produção com infraestrutura real — é o que permite ciclos de desenvolvimento rápidos sem sacrificar a confiabilidade do deploy. E quando combinado com infraestrutura como código, como veremos no próximo artigo, o ciclo se fecha completamente: do código ao deploy, tudo versionado, tudo testável, tudo reproduzível.

Este artigo faz parte de uma série sobre desenvolvimento cloud-native. O artigo anterior, Além do Clean Code: Projetando Sistemas para a Mente Sintética, discute como adaptar práticas de código limpo para a era dos agentes de IA.