[JohnMakin]

> I don't want to be negative, but if one of my engineers came to me saying they wanted to deploy images built from their machine, with all the dev niceties enabled, to go to prod, rather than proper CI/CD of prod optimized images, I'd have a hard time being sold on that.

ditto, "worked on local" is a meme for a reason.

[timbotron]

but "works on my machine" is exactly the problem docker solves -- if you still have those issues then you're not building your images right

[JohnMakin]

That's why there is the meme. Docker doesn't always solve this, or even often on its own. You can't just "build image to docker" and expect things to go okay and pretend you can be agnostic about its prod environment (you kind of can, but usually requires an ops team supporting whatever assumptions your image made).

It's been addressed in other comments but you have:

- differences in architectures, CPU, memory

- if the docker image has a volume attached, unless local perfectly represents prod, you're going to have issues

- networking and firewall rules can be drastically different than a production environment and the assumptions made there

- differences in RBAC/IAM/etc. between local and prod could go on and on.

In reality, this is a nice idea, in practicality, it almost never works 1:1. The common refrain is "well just make the local/dev/sandbox exactly match prod" and my point is this is often unrealistic to the point it cannot/won't happen. If you can do it, good for you, I just personally have never seen this work as simply the author describes it in a system of any kind of complexity.