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

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

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.

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.

Update, October 2026

Five months later, StackPort is at v0.4.5, with 27 releases, 158 stars, 26 forks, 10 contributors and 35k+ Docker pulls. A few things changed since this post first went out:

• The UI moved to Cloudscape in v0.4.0, AWS's own design system — so StackPort now looks and feels like the console it stands in for.
• More dedicated views and write operations: log tailing, CloudWatch dashboards and SNS (v0.4.1), a KMS browser (v0.4.5), and create/delete for CloudWatch log groups.
• Beyond browsing: a CLI (stackport status, list, describe, export), live updates over WebSockets, and guided lessons that run against your own emulator and check your real resources as you go.

Two of the "good first issues" I listed back then — CloudWatch Logs write operations and the KMS browser — have since shipped. These are open now:

• Full-stack: Route 53 browser for DNS record management.
• DevOps: Helm chart for Kubernetes deployment.
• Docs/Backend: OpenAPI spec and SDK generation.
• Backend/Frontend: KMS browser follow-ups and a DynamoDB editor type-fidelity fix.

The CONTRIBUTING.md has the full dev setup guide.

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

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!

Originally published on DEV in May 2026.