Basically Everyone Should Be Avoiding Docker
80 comments
·July 6, 2025dontTREATonme
kaptainscarlet
The title should be the opposite imo. Why everyone should use docker
flkiwi
After reading this, I assumed this was some level of parody:
“If a program can be easily installed on Debian and (nowadays) installed on Arch Linux, that covers basically all Linux users.”
aspbee555
it really does allow easy setup with compose, multiple containers, different versions, etc. I have been setting up linux servers and desktops for decades but docker made it way easier for a lot of things
I still have email server setups I would never dare try to touch with docker, but I know it is possible
like a lot of things it has its uses and it's really good at what it does
coderatlarge
i love the convenience and ease-of-use but worry about the security compared to full-blown vm
unsnap_biceps
Kata containers is a nice compromise. Each container is run as a microvm
gryn
in addition, docker compose also support reading env variables / .env files from outside that you can use for configuration inside the docker compose file.
SeanAnderson
That... was not a very convincing article! It came across as a frustrated op-ed where the author intentionally focused on the negatives rather than steel manning their own argument. Any potential positives were handwaved as out-of-scope.
VSCode devcontainers are awesome. They are my default way of working on any new project.
Being able to blow away a container and start with a fresh, reproducible setup - at any time - saves so many headaches.
neuronexmachina
It kind of seemed like this might have been the first time the author tried doing anything with Docker containers. And yeah... if you're trying to work with and modify a Docker container the same way you'd work with a VM, you're going to have a bad time.
slashdave
Should this be titled "Basically everyone who doesn't know how to use Docker should be avoiding Docker"?
MadnessASAP
Only people who dont know how to use Linux use Docker because Docker makes Linux easy. This is bad because I don't know how to use Docker.
The Author
udev4096
I mean most people still see it as a blackbox. The magic is in namespaces, cgroups, etc. I would recommend reading this series: https://iximiuz.com/en/posts/container-learning-path/
Freedom2
Agreed. I really tire of flat, authoritative statements with no room for context or clarification. Perhaps that's what's needed to succeed in a VC world, but it's the easiest way to get me to dismiss the author's opinion because they leave no room for discussion.
leakycap
Docker has so much overhead (complexity and technical) - I hear people recommend it for simplicity all the time and assume they have out-of-date, insecure setups ... Docker containers require more setup to secure and backup in my experience.
chii
> require more setup to secure
docker is not secure. It has no "real" security boundry, and any malicious actor could have you run a docker image that is just as malware as an executable. Like locks on doors, it just keeps out the honest people. So i say effort spent trying to secure it is wasted.
> backup
if you have data in the docker instance, you have to use volume mounts, and then backup that volume mount. I say it's easier to backup than an installed app, as you cannot be sure that it didnt write somewhere else their data!
kmoser
> Well, if you’re expecting Docker to have a file-system easily accessible, you’re wrong—in fact, that’s “the point.” I can’t use typical commands like updatedb/locate/find to find what I need. I have to run a command with a massive prefix specific to that container. I don’t have tab completion when running Docker container commands, so when I inevitably mistype while searching for the file or attempting to delete it, I have to re-edit a multi-line command.
Am I missing something? Isn't this as easy as:
docker exec -it --user <username> <container> /bin/bash
I used this just yesterday to get shell access to a Docker container. From there I have full access to the filesystem.
blackjack_
Yes if they want to edit the running container config, that is exactly what to do. Also, if you are just running a mounted volume for the configs, you don't even have to go that far. You can just edit the mounted volume on the host machine and it will show up immediately in the container.
However, I would think you would want to edit the Dockerfile instead so that you fix it every time you restart the container.
But I think the whole point of this post is that the author has no idea how docker works and is mad about having to learn docker things, so nobody should use them. Never mind the entirety of cloud infrastructure running in containers and doing amazing things. Never mind being able to duplicate state across tons of different servers at the same time. It shows that the author isn't into making infrastructure at scale, and has no idea how incredible docker has been to software development, CI/CD pipelines, and deployment / release infrastructure as a whole.
LelouBil
No you're not missing anything, aside from the small part of containers that are "FROM scratch" and don't have a shell binary, you can do the command you wrote.
The author didn't seem to research how to use Docker before writing this.
kousthub
Why would you edit or delete files inside a running container? It’s ephemeral and supposed to be used stateless. You can attach volumes from host system if you need persistence.
hakfoo
At least one use case I've seen for Docker is to replicate the massively microservice oriented system. If your app is deployed across 200 different containers in prod, you're going to be testing it by spinning up the same basic containers with Docker in dev. That means a lot of incremental changes-- trivial stuff like adding transient logging or bypassing default flows-- inside the container as part of the development process.
Then you get into politics: you might need change XYZ for your feature, but you don't own that common image and have to rely on someone else to deploy it, so until then it's manual patches.
dima55
Because there are different use cases. About 100% of the people I talk to that use docker, are using it to make a separate set of dependencies available in a possibly-different distribution. For THOSE people, the ephemeral, stateless nature of docker is a huge detriment in usability, and a chroot would be far more appropriate. I see docker users waste countless hours working around its statelessness. All the time. YMMV
moritzwarhier
> ephemeral, stateless nature of docker is a huge detriment in usability, and a chroot would be far more appropriate
But ephemeral changes (e.g. inside the running container) are the opposite of statelessness in the comment you are responding to?
And if you have required intricate custom changes in mounted host volumes (config, ...) that are not living alongside the compose file in the same repository, you can have "statefulness" that survives killing the containers.
rawkode
The irony here is that the author doesn't know how to use containers, there's nothing specifically Docker there, yet seems to portay a level of Unix knowledge ...
That's 5 minutes of my life in not getting back.
rpcope1
Among the other wrong/dumb things in the post, equivocating all containers with "Docker" reveals a lot of ignorance. You can have your nice existing stuff, and still use containers (and reap the benefits) if you just use LXC. You get the advantages of not needing to pollute a host with everything (including potentially incompatible dependencies), incorporating cgroups and namespaces and ease of migration (really easy to bring LXC containers to a new host), while not having to buy wholesale into all of the parts of Docker you don't want.
This is (basically) burger king, you can have it your way, you just have to actually learn some new shit once in a while and not just refuse to ever pick up or learn anything new.
khaki54
Hmmm this reads like the author neither understands Docker or Linux, many of the issues they seem to have is just stuff they don't know the right approach to tackling.
Imagine pairing with a mid/Sr and watching them scroll up 40 commands in the terminal and they are complaining that bash won't let them up-arrow 10 lines at a time. In this case, someone writes 5000 words about how they can't get certbot working with their docker setup. They would benefit a lot from working with someone who knows what they are doing.
hadlock
This should have been titled "basically everyone should be avoiding containers". I thought this was an article about the company Docker
hn_throw2025
Great points in this thread, but I would say another advantage of Docker is that of documentation.
The Dockerfile is a description of a reproducible build, and a docker-compose.yml file documents how running services interact, which ports are exposed, any volumes that are shared, etc.
It’s all too easy for config knowledge to be siloed in people. I got the impression that the Author prefers tinkering with pet servers.
rascul
> The Dockerfile is a description of a reproducible build
It's not inherently reproducible but it can potentially be made so.
zerof1l
I get the impression that the person who wrote this article doesn't know much about docker. Running 2 apps and a certbot can be done without containers easily. Try running 20 apps, some of which depend on having the same dependency but on a different version.
Regarding security, it depends on how you set up your containers. If you just run them all with default settings - the root user; and give them all the permissions, then yeah, quite insecure. But if you spend an extra minute and create a new non-root user for each container and restrict the permissions then it's quite secure. There are plenty of docker hardening tutorials.
Regarding ease of setup, it took me a while to learn docker. Setting up first containers took very long time. But now, it's quick and easy. I have templates for the docker compose file and I know how to solve all the common issues.
Regarding ease of management, it's very easy. Most of my containers is setup once and forget. Upgrading an app just requires changing the version in the docker-compose file.
I like docker because it makes it super easy to try out apps that I don’t necessarily know that I want and I can just delete it.
I’m also confused about the claim that there is no config file… everyone I know uses docker compose, that’s really the only right way to use docker, using a single docker command is for testing or something, if you’re actually using the app long term, use docker compose. Also most apps I use do have a specific place you can set for configuration in the docker compose file.