After trying out Cosmos Cloud (and it not working for the clients), I’m back at square one again. I was going to install Docker Desktop, but I see it warns that it runs on a VM. Will this be a problem when trying to remote connect to certain services, like Mealie or Jellyfin?
Podman is the way.
No its not.
While podman fully OCI image compliant, the network stack of it is different. And podman runsias user, not as root.
Not to mention that podman is a CLI, but OP asked for GUI
Ok, this is interesting 🙂 they also have a learning center thing it says, so maybe I can take the classes/lessons/tutorials they mention.
I just really hope I then figure out the remote connection stuff. That’s the one I’m most paranoid about and wanting to figure out
That’s interesting. I didn’t know Podman had a Windows environment desktop app.
Also works good in macos. Been using it instead of the lima/colima stack for a few weeks now.
Tbf Idk how well it works on windows, but on Linux and Mac I have had no problems with it.
And podman runsias user, not as root.
Both Podman and Docker have rootfull and rootless options
Ive recently replaced my docker setup on Linux with podman and as was said this isn’t entirely true. Running as user is actually a good thing but Podman machine allows root like you’re probably used to and the docker compatibility seems pretty good.
The networking seems a bit less stable with like wifi network changes and stuff but its definitely something to keep an eye on and give a shot as a more open alternative.
I don’t have much experience with podman in production. I use podman to spin up some web tools locally on Linux computer startup (so I have my own searxng only for me). It is a great tool.if you need to spin up something in user space, and because of that, it actually consumes slightly less RAM in general.
About the docker: I never used it as rootless. I’m not sure, but documentation probably said that it is partially or not fully supported or lacks some features or something like that. Anyways, I just run it as root, just because everyone is using it (by everyone, I mean stinky enterprise nerds that do their silly .sh scripts only for docker).
I had some troubles with networking and volume mounts in podman BTW, mostly permissions issues. I guess it makes sense, when a container, tries to create a root file on a rootless podman host and fails.
Though docker is not really fully open source AFAIK. Maybe its source-available, but I remember some bullshit about it.
I don’t see anyone addressing the question from the post: whether it is a problem that Docker Desktop on Linux runs in a separate VM.
The page says:
Docker Desktop on Linux runs a Virtual Machine (VM) which creates and uses a custom docker context, desktop-linux, on startup. This means images and containers deployed on the Linux Docker Engine (before installation) are not available in Docker Desktop for Linux.
To expand on what that means: If you install Docker as usual (the CLI) on Linux, it runs as a process (running as root). The process will isolate the container processes from the rest of the system using Linux kernel features, but you’re really just running processes on your host kernel that have limited access to the file system, network, etc.
When you run in it a separate VM, which is how Docker Desktop is also run on Windows and MacOS, you are running it in a separate Linux instance (VM) that cannot communicate with the outside by default. So, if you’re running Docker on the host computer and inside a VM, those are separate Docker installs and can’t talk to each other. That is what the warning is about.
You can absolutely expose the VM to the outside, the same as if you ran it on Windows. Docker will let you expose those ports and it handles the messy bits of the networking for you. You just have to tell Docker when you run the container (on the command line or in a docker compose file) which ports to expose. By default, nothing is exposed. To do that you can use the
-poption. For example:docker run --rm -it -p 8080:80 httpdWill run an instance of Apache HTTPd and expose it on port 8080. The container itself listens to port 80, but on the outside it’s 8080. If you then hit http://localhost:8080/ you should see “It works!”.
A note on Docker networking: from within the container, localhost is referring to the container itself, not the host. So if you try to do e.g.
curl http://localhost:8080/inside the container, your connection would be refused.Docker Desktop is often frowned upon because you have to pay to use it in a commercial setting (there was some backlash because it used to be free), it’s quite expensive, and they require a minimum license count for enterprise licenses (I know because we bought one at work). So, I suggest exploring free alternatives like Podman Desktop. However, note that they do not always have feature parity with Docker Desktop.
I like Docker Desktop because it gives me a nice dashboard to see all my containers, resource usage, etc. I would not have requested it for work, though, if it weren’t for my IDE (Visual Studio) requiring it at the time (they have added Podman support since).
Final note: I recommend just diving into using Docker from the command line and learn that. Docker complicates networking a little bit because it adds more layers, but understanding Docker is very useful if you’re into self hosting or software development.
I’d bite the bullet and learn how to use Compose from the command line so you can work on it over SSH. If you want a UI, try LazyDocker
A lot of people don’t know that Docker Desktop is actually proprietary.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DHCP Dynamic Host Configuration Protocol, automates assignment of IPs when connecting to a network DNS Domain Name Service/System Git Popular version control system, primarily for code HTTP Hypertext Transfer Protocol, the Web HTTPS HTTP over SSL IMAP Internet Message Access Protocol for email IP Internet Protocol Plex Brand of media server package SMTP Simple Mail Transfer Protocol SSH Secure Shell for remote terminal access SSL Secure Sockets Layer, for transparent encryption TLS Transport Layer Security, supersedes SSL VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting)
[Thread #254 for this comm, first seen 25th Apr 2026, 11:10] [FAQ] [Full list] [Contact] [Source code]
Why run Docker Desktop when it’s installable as a cli service?
What are you actually trying to achieve?
ease of use.
I’m a noob at networking.
there’s only one way to get better at it. by doing it.
Or if it’s not something that’s valuable to you just do it the easy way.
Just throw your services in a docker-compose.yml file, create a docker bridge network, and assign the:
networks: - YourDockerNetworkTo the services in the yaml file, specify the ports it want’s to open with
ports: - 8080:8080And let it start up. If you want to get more complicated suggest reading the man page which really isn’t that long of a read.
Networking really cannot be simplified, you have to view it in a logistical way of how is Point A communicating with Point B which where Docker bridge networks come into play, they make the communication easy, if all your containers are all on the same docker network all you have to do is specify http://ContainerName:Port for them to communicate back and forth internally.
Check out CasaOS. Really easy to set up.
Don’t think Docker Desktop would simplify networking, unless it added a new feature since I last used it ~2 years ago.
Docker Desktop isn’t needed on Linux. If you want a UI, try Portainer
What does networking have to do with docker? You haven’t explained what you’re trying to achieve.
Access containers remotely
As a Mac user who’s migrated over to Linux over the past year or so, I’ve got an idea of where OP is coming from.
Docker on macOS is accessed via a Desktop GUI, so you can easily see what you have installed, how it’s running, etc… So when I shifted over to Linux, I was thrown off by there being no such tool. I wasn’t used to using a terminal to do everything, and grumbled quite a lot about there being no Docker Desktop GUI, given how many self-hostable services run through Docker.
I’ve since gotten used to it, but it really is quite jarring.
There are a lot of Docker GUI tools out there. There just isn’t Docker Desktop. Here are a few:
- Portainer
- Podman Desktop
- Yacht (pretty sure this is unmaintained currently but still should work)
Oh aye, I get it. But when you’re new to the platform and trying to work with tools that are familiar, you don’t know about any of that.
There is Cockpit which allows you to manage the server and has simple management for containers. However, I recommend using something like Dockge with compose because it makes it easier to change the configuration of containers without recreating them manually.
I started with docker desktop on Linux thinking it was the easiest way to get started. It initially ran well, but I started having weird stability issues. Moving to the cli resolved this. Relying on the documentation and web searches will help you quickly gain familiarity.
I just run Docker CLI and Dockge on top of it. Works great. Dockge gives me the general “most-used” controls, and if I need to do anything more advanced I can just drop into the terminal.
You can run a Portainer container to manage your containers
docker desktop is just a GUI for managing docker, is there a specific reason you need it? Anyway you can try Portainer
