I Built an Open-Source AWS Resource Browser Because I Was Tired of Running CLI Commands

Davi Reis Vieira — Tue, 05 May 2026 16:22:10 +0000

The Problem: We Were Flying Blind

At Refer, we're on a mission to enable talented individuals to fulfill their professional potential by helping them pursue their ideal job. Behind the scenes, that means a lot of microservices, and recently we decided to consolidate everything into a mono-repository.

If you've ever migrated dozens of microservices into a monorepo, you know the drill: contracts between services need to be explicit, testing needs to be fast, and the dev experience has to be smooth enough that nobody reaches for git blame to figure out who broke what (that's a story for another post).

As part of this process, I started using MiniStack to emulate AWS services locally. The idea was simple: instead of deploying to AWS every time we wanted to test an integration (which costs time and money), we'd run everything locally.

It worked great. Until it didn't.

"What's Actually in That Queue?"

Here's what my typical debugging session looked like:

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

Over. And over. And over.

Some developers on my team aren't CLI people. They wanted to see the resources. "Is the message in the queue?" "What's in that S3 bucket?" "Did the Lambda actually create the DynamoDB item?"

These are visual questions. They deserve visual answers.

The First Attempt: A PR to MiniStack

My initial instinct was to build a UI directly into MiniStack. I opened a PR, built a basic resource browser, and started a discussion with the maintainers.

After some back-and-forth, we reached a conclusion: this should be its own project. The reasoning made sense: it shouldn't be tied to a single emulator. It should work with LocalStack, MiniStack, Moto, or even real AWS. A standalone tool could serve a broader community and evolve independently with its own release cadence.

And so, StackPort was born.

What StackPort Does

StackPort is a universal AWS resource browser. You point it at any AWS-compatible endpoint and it gives you a visual dashboard for all your resources.

One command to run:

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

Or with Docker:

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

That's it. Open localhost:8080 and you're browsing your AWS resources visually.

35+ Services and Growing

StackPort auto-discovers resources across more than 35 AWS services: S3, SQS, DynamoDB, Lambda, EC2, ECS, RDS, Secrets Manager, IAM, CloudWatch Logs, Step Functions, EventBridge, SNS, KMS, and the list keeps growing.

Custom Service Browsers

For the services you interact with most, we built dedicated UIs (8 so far, more coming) that go way beyond a simple table:

S3 Browser lets you navigate buckets and folders, preview objects, upload and download files. SQS Browser shows messages, lets you send new ones, purge queues. DynamoDB Browser gives you scan/query with a JSON editor for creating and editing items. Lambda Browser lets you invoke functions with custom payloads and see the results right there. IAM, EC2, CloudWatch Logs, and Secrets Manager all have their own dedicated views too. And this number keeps increasing with every release.

Works With Everything

Emulator	Works?
MiniStack	Yes
LocalStack	Yes
Moto	Yes
Real AWS	Yes
Any S3-compatible storage	Yes

You can even connect to multiple endpoints simultaneously and switch between them.

Why Open Source?

I could've kept this as an internal tool at Refer. But making it open source was a deliberate choice.

First, speed. Contributors bring features I wouldn't prioritize myself. Someone added DynamoDB item editing. Another person improved S3 operations. These happened in parallel with my own work.

Second, quality. More eyes, more edge cases caught. The emulator ecosystem is diverse. People testing with LocalStack find issues I'd never hit with MiniStack alone.

Third, community. Local AWS development is a shared pain. Every team running LocalStack or MiniStack has the same "what's in my queue?" moment. A shared tool benefits everyone.

In just one month, we've shipped 10 releases, merged PRs from external contributors, and reached a point where the tool covers most of what a team needs for daily local development.

The Tech Stack

I kept it simple on purpose. I wanted contributors to jump in without a steep learning curve.

The backend is Python with FastAPI and boto3. Sync route handlers (FastAPI auto-threadpools them). Registry pattern for service discovery. The frontend is React, TypeScript, Vite, Tailwind CSS and shadcn/ui. Dark theme only because we're not monsters. Deployment is a single Docker image where the backend serves the frontend as static files. No nginx, no reverse proxy, no drama.

stackport/
├── backend/          # FastAPI + boto3
│   ├── routes/       # One file per service
│   └── schemas/      # Pydantic models
├── ui/src/           # React + TypeScript
│   ├── components/   # Service browsers
│   └── lib/          # API client, types
└── Dockerfile        # Two-stage build

Adding a new service to the generic browser is literally adding entries to a Python dictionary. Adding a custom UI follows a clear, documented pattern.

Want to Contribute?

We've tagged several issues as good first issue that cover different skill sets:

Python/Backend: CloudWatch Logs write operations for adding create/delete to log groups.

Full-Stack: KMS Browser to build a read-only key browser, and Route 53 Browser for DNS record management.

DevOps: Helm Chart for Kubernetes deployment.

Docs/Backend: OpenAPI spec to auto-generate API documentation.

Each issue has a detailed implementation plan, acceptance criteria, and testing requirements. The CONTRIBUTING.md has the full dev setup guide.

Get Started in 30 Seconds

# Install
pip install stackport

# Start your emulator (pick one)
pip install ministack && ministack
# or: docker run -p 4566:4566 localstack/localstack

# Run StackPort
AWS_ENDPOINT_URL=http://localhost:4566 stackport

Open localhost:8080 and start browsing.

GitHub: github.com/DaviReisVieira/stackport

If this solves a problem you have, give it a star. If you want to make it better, check out the issues. And if you just want to say hi, open an issue. I read every single one.

Happy building!

Forem: Davi Reis Vieira