Criei um navegador open source de recursos da AWS porque cansei de rodar comandos na CLI

O problema: estávamos voando às cegas

Na Refer, nossa missão é permitir que pessoas talentosas alcancem todo o seu potencial profissional, ajudando-as a conquistar o emprego ideal. Nos bastidores, isso significa um monte de microsserviços — e, recentemente, decidimos consolidar tudo em um monorepo.

Se você já migrou dezenas de microsserviços para um monorepo, conhece o roteiro: os contratos entre serviços precisam ser explícitos, os testes precisam ser rápidos e a experiência de desenvolvimento tem que ser boa o bastante para ninguém precisar de git blame para descobrir quem quebrou o quê (isso fica para outro post).

Como parte desse processo, comecei a usar o MiniStack para emular serviços da AWS localmente. A ideia era simples: em vez de fazer deploy na AWS toda vez que quiséssemos testar uma integração (o que custa tempo e dinheiro), rodaríamos tudo localmente.

Funcionou muito bem. Até deixar de funcionar.

"O que tem, afinal, nessa fila?"

Era assim que uma sessão típica de debug minha ficava:

aws --endpoint-url=http://localhost:4566 sqs list-queues
aws --endpoint-url=http://localhost:4566 sqs receive-message --queue-url http://localhost:4566/000000000000/my-queue
aws --endpoint-url=http://localhost:4566 s3 ls
aws --endpoint-url=http://localhost:4566 dynamodb scan --table-name users

De novo. E de novo. E de novo.

Algumas pessoas do meu time não são do tipo que vive na CLI. Elas queriam ver os recursos. "A mensagem está na fila?" "O que tem nesse bucket do S3?" "A Lambda criou mesmo o item no DynamoDB?"

São perguntas visuais. Merecem respostas visuais.

A primeira tentativa: um PR para o MiniStack

Meu primeiro instinto foi construir uma interface direto no MiniStack. Abri um PR, montei um navegador de recursos básico e comecei uma discussão com os mantenedores.

Depois de algumas idas e vindas, chegamos a uma conclusão: isso deveria ser um projeto próprio. O raciocínio fazia sentido: a ferramenta não deveria ficar presa a um único emulador. Ela deveria funcionar com LocalStack, MiniStack, Moto ou até com a AWS de verdade. Uma ferramenta independente poderia atender uma comunidade maior e evoluir no próprio ritmo, com seu próprio ciclo de releases.

E foi assim que nasceu o StackPort.

O que o StackPort faz

O StackPort é um navegador universal de recursos da AWS. Você aponta para qualquer endpoint compatível com a AWS e ganha um dashboard visual de todos os seus recursos.

Um comando para rodar:

pip install stackport
AWS_ENDPOINT_URL=http://localhost:4566 stackport

Ou com Docker:

docker run -p 8080:8080 -e AWS_ENDPOINT_URL=http://host.docker.internal:4566 davireis/stackport

Só isso. Abra localhost:8080 e você já está navegando pelos seus recursos da AWS de forma visual.

Mais de 35 serviços, e contando

O StackPort descobre automaticamente recursos em mais de 35 serviços da AWS: S3, SQS, DynamoDB, Lambda, EC2, ECS, RDS, Secrets Manager, IAM, CloudWatch Logs, Step Functions, EventBridge, SNS, KMS, e a lista continua crescendo.

Navegadores dedicados por serviço

Para os serviços que você mais usa, construímos interfaces dedicadas (8 até agora, com mais a caminho) que vão muito além de uma tabela simples:

O S3 Browser permite navegar por buckets e pastas, pré-visualizar objetos e fazer upload e download de arquivos. O SQS Browser mostra as mensagens, deixa você enviar novas e esvaziar filas. O DynamoDB Browser oferece scan/query com um editor JSON para criar e editar itens. O Lambda Browser permite invocar funções com payloads personalizados e ver o resultado ali mesmo. IAM, EC2, CloudWatch Logs e Secrets Manager também têm suas próprias telas. E esse número aumenta a cada release.

Funciona com tudo

Dá até para se conectar a vários endpoints ao mesmo tempo e alternar entre eles.

Por que open source?

Eu poderia ter mantido isso como uma ferramenta interna da Refer. Mas abrir o código foi uma escolha deliberada.

Primeiro, velocidade. Contribuidores trazem funcionalidades que eu não priorizaria. Alguém adicionou edição de itens no DynamoDB. Outra pessoa melhorou as operações do S3. Tudo isso aconteceu em paralelo ao meu próprio trabalho.

Segundo, qualidade. Mais olhos, mais casos de borda encontrados. O ecossistema de emuladores é diverso. Quem testa com LocalStack encontra problemas que eu nunca veria usando só o MiniStack.

Terceiro, comunidade. Desenvolvimento local com AWS é uma dor compartilhada. Todo time que roda LocalStack ou MiniStack tem o mesmo momento de "o que tem na minha fila?". Uma ferramenta compartilhada beneficia todo mundo.

Em apenas um mês, lançamos 10 releases, fizemos merge de PRs de contribuidores externos e chegamos a um ponto em que a ferramenta cobre quase tudo o que um time precisa no desenvolvimento local do dia a dia.

A stack

Mantive tudo simples de propósito. Eu queria que contribuidores conseguissem entrar no projeto sem uma curva de aprendizado íngreme.

O backend é Python com FastAPI e boto3. Route handlers síncronos (o FastAPI joga em threadpool automaticamente). Padrão de registry para descoberta de serviços. O frontend é React, TypeScript, Vite, Tailwind CSS e shadcn/ui. Só tema escuro, porque não somos monstros. O deploy é uma única imagem Docker em que o backend serve o frontend como arquivos estáticos. Sem nginx, sem reverse proxy, sem drama.

stackport/
├── backend/          # FastAPI + boto3
│   ├── routes/       # Um arquivo por serviço
│   └── schemas/      # Modelos Pydantic
├── ui/src/           # React + TypeScript
│   ├── components/   # Navegadores dos serviços
│   └── lib/          # Cliente da API, tipos
└── Dockerfile        # Build em dois estágios

Adicionar um novo serviço ao navegador genérico é, literalmente, adicionar entradas a um dicionário Python. Criar uma interface dedicada segue um padrão claro e documentado.

Comece em 30 segundos

# Instale
pip install stackport
 
# Suba seu emulador (escolha um)
pip install ministack && ministack
# ou: docker run -p 4566:4566 localstack/localstack
 
# Rode o StackPort
AWS_ENDPOINT_URL=http://localhost:4566 stackport

Abra localhost:8080 e comece a navegar.

Atualização, outubro de 2026

Cinco meses depois, o StackPort está na v0.4.5, com 27 releases, 158 estrelas, 26 forks, 10 contribuidores e mais de 35 mil pulls no Docker. Algumas coisas mudaram desde que este post saiu:

• A interface migrou para o Cloudscape na v0.4.0, o design system da própria AWS — então o StackPort agora tem a cara e o jeito do console que ele substitui.
• Mais telas dedicadas e operações de escrita: acompanhamento de logs em tempo real, dashboards do CloudWatch e SNS (v0.4.1), um navegador de KMS (v0.4.5) e criação/remoção de log groups do CloudWatch.
• Além de navegar: uma CLI (stackport status, list, describe, export), atualizações ao vivo via WebSockets e lições guiadas que rodam no seu próprio emulador e conferem seus recursos de verdade enquanto você avança.

Duas das "good first issues" que listei na época — operações de escrita no CloudWatch Logs e o navegador de KMS — já foram entregues. Estas estão abertas agora:

• Full-stack: navegador de Route 53 para gerenciar registros de DNS.
• DevOps: Helm chart para deploy em Kubernetes.
• Docs/Backend: especificação OpenAPI e geração de SDK.
• Backend/Frontend: melhorias no navegador de KMS e uma correção de fidelidade de tipos no editor do DynamoDB.

O CONTRIBUTING.md tem o guia completo para montar o ambiente de desenvolvimento.

GitHub: github.com/DaviReisVieira/stackport · Site: stackport.cloud

Se isso resolve um problema seu, deixa uma estrela. Se quiser deixar a ferramenta melhor, dá uma olhada nas issues. E se só quiser dar um oi, abre uma issue. Eu leio todas.

Bom código!

Publicado originalmente em inglês no DEV em maio de 2026.