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!