DEV Community: Amanpreet Singh

Building a Lightweight Desktop App for Container Management with Go and Wails

Amanpreet Singh — Mon, 19 Oct 2026 12:06:02 +0000

Building a Lightweight Desktop App for Container Management with Go and Wails

I've been working on a project called Dockit, and one of the things I wanted to explore was a simple question:

Can we make container management more approachable without building another resource-heavy desktop application?

Docker is an incredibly useful part of modern development. But depending on your workflow, you may find yourself switching between terminal commands, container images, running containers, engine configuration, and installation instructions.

I wanted to explore what that experience could look like in a dedicated desktop application.

That's how Dockit started.

🔗 Source code: github.com/Amanbig/dockit

📦 Latest release: Download Dockit

Why build another container management tool?

There are already excellent tools in the container ecosystem, so I didn't want to build a desktop interface just for the sake of having one.

I was interested in the overall developer experience.

For example:

How can container management feel more approachable?
How can installation workflows be simplified for Linux users?
Can a desktop application remain lightweight while gaining useful features?
How should an application handle the differences between development environments and Linux distributions?

These questions gave me a practical engineering problem to work on.

Choosing Go and Wails

Dockit uses Go and Wails to build a desktop application.

Go gives me a language well suited to system-facing functionality and integration with container tooling. Wails provides a way to build a desktop interface using web technologies while keeping the application logic in Go.

This combination has been interesting because it lets me work on two different sides of the application:

The desktop experience users interact with.
The underlying logic responsible for interacting with the container environment and handling application workflows.

It also gives me an opportunity to think about packaging, dependencies, and how the application behaves outside my own development environment.

Keeping resource usage low

One thing I've been paying attention to is memory and CPU usage.

Desktop utilities often remain open in the background for long periods. I don't want Dockit to become another application that consumes significant resources when the user isn't actively interacting with it.

During my testing, I've observed approximately:

Metric	Observed usage
Initial memory usage	Around 20–30 MB
Memory during some sessions	Above 40 MB

These are observations from my own setup, not results from a controlled benchmark. Actual usage can vary depending on the operating system, workload, application state, and measurement tools.

Still, it's encouraging to see relatively low initial memory usage, and I want to keep resource efficiency in mind as the application grows.

The goal isn't to chase a particular number at all costs. It's to add functionality without losing sight of performance.

Linux installation is part of the experience

Another area I've been working on is Linux installation.

Linux distributions differ in their package managers, available dependencies, and installation workflows. Supporting these differences means thinking beyond the application itself.

I've been expanding Dockit's installation workflows to account for different Linux environments.

This is an area where testing matters a lot. An installation flow that works on my machine isn't necessarily sufficient for someone using a different distribution or package configuration.

I'd rather keep testing these scenarios and improve the experience incrementally than assume every environment behaves identically.

Building in public means iterating

Dockit is open source, and I'm continuing to develop and test it.

There are still improvements I'd like to make, both in the user experience and in the underlying implementation. I'm particularly interested in feedback about real-world container workflows and how the application behaves on different systems.

For me, projects like this are a way to learn through actual engineering work: making decisions, dealing with platform differences, measuring performance, and improving the software after releasing it.

The first release is only a starting point.

Try Dockit

If you're interested in exploring it, the source code and releases are available here:

GitHub repository: https://github.com/Amanbig/dockit
Latest release: https://github.com/Amanbig/dockit/releases/latest

I'd especially appreciate feedback from developers who regularly work with Docker.

What's one part of your container workflow that you'd like to see made simpler?

I'm interested in hearing about the actual problems you encounter, whether they're related to installation, managing containers, or everyday development.

Thanks for reading!

🚀 DevOrch: The Multi-Provider AI Coding CLI

Amanpreet Singh — Sun, 08 Mar 2026 11:47:02 +0000

As a developer, I love working in the terminal. Fast, keyboard-driven, and distraction-free. But when it comes to AI coding assistants, most tools force you to switch UIs — web apps, IDE plugins, or proprietary apps.

So I built DevOrch, a Python CLI tool that unifies multiple AI providers in one place. Think of it as your personal terminal AI workstation.

🔹 What is DevOrch?

DevOrch is a command-line AI assistant that supports 15+ AI providers, including:

OpenAI (GPT‑4, GPT‑4o)
Anthropic (Claude)
Google Gemini
Mistral, Groq, Together AI, Copilot, Ollama, LM Studio, and more

All from a single CLI. No switching between websites or IDE plugins.

🔹 Key Features

Multi-provider support: Switch between AI providers seamlessly.
Interactive modes:
- ask – get instant answers or code suggestions
- plan – generate project plans or steps
- auto – let DevOrch take actions across files or commands
Session persistence: Keep conversations alive between CLI sessions.
Secure API key storage: No more pasting keys every time.
Terminal-first experience: Fast, distraction-free, works entirely from the command line.

🔹 Why DevOrch?

For terminal lovers: If you live in Vim, Tmux, or your shell, this tool fits naturally.
Extensible: Adding new providers is easy. DevOrch was built to grow.
Portable: Install it with one command:

pip install devorch

🔹 Quick Demo

# Start DevOrch
devorch

# Ask a coding question
ask "How do I implement a binary search in Python?"

# Plan a project
plan "Create a CLI tool to automate file backups"

# Auto mode for actions
auto "Update requirements and push changes to GitHub"

DevOrch will respond directly in your terminal, with clear outputs and suggestions.

🔹 Installation

pip install devorch

💡 Optional: Use pipx for isolated CLI installation:

pipx install devorch

🔹 Community & Feedback

DevOrch is open-source: GitHub Repository
If you try it out, please star the repo ⭐, give feedback, or suggest new providers.

🔹 Stats & Early Adoption

Even in its first week, DevOrch has been downloaded 200+ times on PyPI — and the numbers are growing daily.

🔹 Next Steps

Add more AI providers
Improve async handling for faster responses
Integrate tooling like git, Docker, and linters
Add a plugin system so the community can extend DevOrch easily

✅ Try it Today

If you love CLI workflows + AI coding assistance, DevOrch is your tool. Install it, and turn your terminal into a full-fledged AI coding assistant.

pip install devorch
devorch

Released — Schema Support, Cleaner Internals & What’s Next

Amanpreet Singh — Fri, 30 Jan 2026 18:07:10 +0000

RunAPI just got a solid upgrade.

The latest version introduces schema support, improves internal architecture, and sets the foundation for better testing and database extensibility — while keeping RunAPI lightweight and developer-friendly.

If you’re building APIs with Python and like file-based routing + FastAPI under the hood, this release is for you.

✨ What’s New in This Release

✅ Schema Support (Big One)

RunAPI now supports schemas, making it easier to:

Define request and response models
Validate inputs consistently
Keep APIs structured as they grow

This brings RunAPI closer to real-world production needs while still keeping things simple.

🧹 Code Quality Improvements

A number of internal improvements were merged to clean things up:

Python 3.12 compatibility fixes (datetime.utcnow() → datetime.now(timezone.utc))
Safer handling of non-Pydantic models
Removed deprecated Pydantic v1 patterns
Better module loading safety checks
Cleaner route name generation

These changes don’t affect public APIs but make RunAPI more robust and future-proof.

🗄️ Storage: In-Memory + SQLAlchemy (Optional)

RunAPI currently supports two storage backends:

InMemory storage (default, zero dependencies)
SQLAlchemy storage (used only if SQLAlchemy is installed)

If SQLAlchemy isn’t present, RunAPI gracefully falls back to in-memory storage — no crashes, no surprises.

This keeps RunAPI:

lightweight by default
flexible for more serious use cases

🧠 What We’re Improving Next

With schema support in place, the next focus areas are:

🔍 Better Test Coverage

More tests around schemas
Edge-case tests for routing and auth
Stronger confidence as features grow

🧩 Clear Storage Abstraction

Although InMemory and SQLAlchemy backends already exist, we want:

a clear shared interface
cleaner backend selection
easier future extensions (Redis, etc.)

📚 Better Documentation & Examples

Schema usage guides
Storage behavior explained clearly
Real-world CRUD examples

🤝 Want to Contribute?

RunAPI is still evolving and contributions are very welcome.

Good areas to start:

Tests 🧪
Docs 📖
Storage abstraction 🗄️
Examples & templates 🧱

👉 GitHub repo: https://github.com/Amanbig/runapi
👉 Issues: https://github.com/Amanbig/runapi/issues

🏁 Final Thoughts

This release is less about flashy features and more about laying a solid foundation.

Schemas unlock safer APIs.
Cleaner internals unlock faster development.
And the roadmap keeps RunAPI flexible without bloating it.

If you try it out, feedback is more than welcome 🙌

Happy building! 🚀

CLI for creating full stack websites (create-nextpy-app)

Amanpreet Singh — Sun, 12 Oct 2025 08:52:42 +0000

🚀 create-nextpy-app v1.1.1 is live!

Thrilled to announce the latest version of create-nextpy-app, the CLI for scaffolding fullstack apps with Next.js frontend and Python backend.

What’s new in v1.1.1?

Choose your backend framework:

FastAPI ✅

RunAPI ✅ — my own Next.js-inspired file-based routing framework for Python.

Same Next.js frontend for building modern, reactive UIs.

Now, developers can quickly bootstrap a fullstack Python + Next.js project and pick the backend that suits their workflow best.

npm: https://lnkd.in/gi4QegKW

github: https://lnkd.in/gywQ6jm5

Get started:

npx create-nextpy-app@latest

Excited to see what the community builds with this new flexibility! 💡

Python #NextJS #FullstackDevelopment #NextPy #RunAPI #FastAPI #OpenSource #CLI

Runapi (File Based routing for python)

Amanpreet Singh — Thu, 25 Sep 2025 08:41:20 +0000

I just published RunAPI — a Python framework inspired by Next.js, but built on FastAPI.

Why RunAPI?

FastAPI is awesome, but large projects can get messy. RunAPI adds file-based routing to keep things clean & scalable.

It also ships with JWT authentication, middleware, error handling, and a CLI for bootstrapping projects quickly.

📦 Install:

pip install runapi

🔗 Links:

PyPI: https://pypi.org/project/runapi/

GitHub: https://github.com/amanbig/runapi

Try it out & let me know what you think!