Oppinions on my personal Docker panel?

[priogeth2 (Priogeth)]

Hey folks,

I’ve been working on this for quite some time now: trying to confine Docker into a single panel.

It’s still far from done, especially considering what the Docker Engine actually has to offer. Docker Desktop as an interface never really matched my workflow — at least not for the use cases I personally have.

Since you’re asking for feedback, maybe this can be inspiring. Maybe a bit controversial. But at the end of the day, I guess I’m just looking for some attention and some feedback for my self

Overview

Would be curious to hear what you think.

[priogeth2 (Priogeth)]

I´m really only exposing a example Project/Container.
But since this is a showcase - mid production, a little dev privacy would be nice
it would also be nice if this doesnt get flagged as advertisment.

[meyay (Metin Y.)]

@priogeth2

But I never really felt Docker Desktop,

You do know that Docker Desktop is designed to be a tool for developer convenience, right? It is not designed to run services 24/7.

I am not the right person to give feedback, as I lack the patience for clickOps Nothing beats compose files and the cli (which is also my favourite way of working with Docker Desktop).

[priogeth2 (Priogeth)]

Fair point — I should have been more precise.

I don’t mean Docker Engine or Compose. My setup is actually built around Compose files and long-running services on a Linux host.

What never really matched my workflow was Docker Desktop as an interface. The panel I’m building is not meant to replace Compose or the CLI, but to make service state, logs, lifecycle actions, and local/remote hosts easier to observe and operate from one place.

[meyay (Metin Y.)]

@priogeth2

I don’t mean Docker Engine or Compose

I was talking about Docker Desktop as well There are plenty of people to want use Docker Desktop as 24/7 container runtime, which it is not designed for. They get frustrated about something Docker Desktop never was designed to do. On Linux, I would always prefer the standalone engine, unless I develop an app/image and want to leverage the MCP Toolkit or the Docker Model Runner. Not every cli plugin that exists in Docker Desktop is available with the standalone engine+cli.

Now I am curious and have some questions:

• Is swarm supported (if I am not mistaken Portainer is the only one supporting it at the moment)?
• Do you have any built-in vulnerability scanner for images in the local image cache?
• Do you validate the compose files against a schema, like IDEs do? And maybe even support autocompletion for the property keys(=language server)?
• Do you plan to support the docker pass feature once it’s GA for the standalone Engine as well?

I am pretty sure others might like your Docker panel and find it helpful. I hope you will attract a big community for it!

[rimelek (Ákos Takács)]

I can’t really give a good feedback after just looking at pictures unfortunately so I think the best way I can contribute to your project is pointing out what I think users would like to know before they can give you a feedback.

• You shared two screenshots, which looks good, but a summary of what is on the screenshots and what is not shared but exists on other tabs is necessary to understand whether it is good enough.
• How can it be used? Is it a web service or or a desktop app or a plugin for an existing IDE? The interface looks like vscode or something similar.
• You mentioned Docker Desktop doesn’t fit your workflow. What are you trying to solve? What do you think your interface does better?
• What feedback do you expect? About the layout of the interface or the included features?

[priogeth2 (Priogeth)]

The panel is not aimed at developers who already prefer living entirely in Compose files and the CLI. It is more about making shipped Compose-based services easier to install, observe, start, stop, inspect, and update for users who may never have touched PowerShell or the Docker CLI.

Swarm is not supported right now. I’m currently focusing on standalone local and remote Docker hosts first.

Image scanning is not built in either, though I know Docker Scout exists and integrations like Scout, Trivy, or Grype could be interesting later.

Compose validation is a very good point. I probably should validate Compose files before running them?

As for docker pass: I haven’t built around it yet. For the moment the project is still closer to env/Compose-based workflows

[priogeth2 (Priogeth)]

Thanks, that helps me frame the project more clearly.

Portal is a standalone desktop app, not a web service and not a plugin for an existing IDE. The interface looks IDE-like because Portal is meant to become a broader project/control environment, and the Docker panel is only one part of it.

In this case, the system panel gives access to locally created virtual machines and remotely controlled machines. It separates responsibilities visually, so the user can understand the basic relationship between machines, hosts, and connections at a glance, before going into the technical details.

The screenshots from before show the current Docker panel. It is meant to turn Compose-based services into something easier to install, observe and operate from one place, keeping in mind that part of the intended user base comes from a non-dev background.

For that group, the value is a more approachable Docker workflow: readable service state, visible logs, predictable lifecycle actions, and fewer moments where users have to guess the right PowerShell or Docker command.

The feedback I’m looking for is mainly about user experience and approachability. Does the interface make the system readable enough before someone has to dive into Compose files, env values, ports, networks, and logs directly?

For example, in the next pass I’m planning to move port details out of the unit cards, because the editor panel on the right will give direct access to env and Compose details anyway. The card should communicate state and action first, while the deeper technical context sits one layer beside it.

Networking will probably become its own larger area as well. I want stable infrastructure for Unreal-based multiplayer/game sessions, and I’m interested in Kubernetes/networking approaches for that, so there’ll probably be a tab for that soon.

Right now I’m still shaping the structure and making the project open-source-ready. The rough goal is to get there by the end of the year, and then move my personal setup over to Linux.

[rimelek (Ákos Takács)]

Thank you for the new details. It looks like a big project and hopefully beginners will look at your topic and share opinions, because we look at these things differently. You also seem to understand what you are doing, so you would indeed need someone who looks at it with the eyes of a beginner and can decide how much it helps them.

For me, after your new post and screenshot, I can say it is an interesting project, but I can understand even a stone better if I can touch it and see in a real environment.

If you have something new to share about the project occasionally, I think it’s okay if you keep the topic alive, so you have a better chance to find a beginner. The topic closes automatically after a month if there is no new reply, but if that happens, you can send a PM or open a new topic and we can merge with this one.

[meyay (Metin Y.)]

I think I understand now who the user base is: tech enthusiasts without deep knowledge.

Have you considered promoting your app in one of the nas related forums (Snyology, QNAP, Ugreen, …) that support docker? At least that’s the target audience I am aware of that would be happy to have a management tool like yours.