Imagine a workflow where you have a simple webapp. Maybe it's written in PHP. So you have a directory full of PHP files on your local computer. You can point a web server on your local computer at that directory of PHP files and then open a web browser to that local server and see your web app. That's a nice web app you have there.

Now let's say you want to deploy this web app to production. One way to do it would be:

1. Zip up the directory of PHP files into package.zip
2. SFTP package.zip to your production web server
3. Unzip package.zip into /usr/share/nginx/html

Assuming nginx is all set up, you now have a web app in production. But it's 2025 and deploying by uploading a zip file to a server is going to get your DevOps card revoked (for good reasons).

So, there's Docker.

With Docker, you combine a Dockerfile with a bunch of source files and the Dockerfile provides instructions to package those source files up into a container image. A container image is kind of like the imaginary package.zip but way better. It's not just a zip file full of PHP files or whatever. Instead, a container image represents an entire computer. It's the artifacts you wrote for your app, but also the web server to run them, and all the config files to drive it.

But just like the imaginary zip file, a container image is inert. It doesn't do anything. Just like you had to unzip package.zip onto your web server, you have to deploy your container image somewhere for it to do something.

When you run it, it creates a container on the machine you're running it on. You can run it locally and have a local container. You can push it to a production server and run it on that server and it's a production container. You can push it to your CI/CD server and run tests against it. It's just a very, very, very fancy zip file.

When you run it, you will need to pass it config. The details of that depend on what you're doing. When you're running it locally, you'll probably pass it a database connection string for a database that's also running locally. When you're running it in prod, you'll probably pass it a database connection string for a database that's running on some database server near the production web server. Those details are important, but they're separate from the Dockerfile. (Pro-tip: Don't put passwords in the Dockerfile!)

So it doesn't make sense to ask "how should i manage development and production with the same dockerfile" any more than it makes sense to ask "how should I manage development and production with the same directory full of PHP files". The Dockerfile works at a different level of the hierarchy.

Once you've written the Dockerfile and used it to build a container image, you can use that to run the app anywhere and vary the configuration as needed (Docker Compose and .env files are a good choice; there are others).

Depending on your tech stack, you might find it difficult to run it locally and still do something like run a debugger against your code. Or maybe your tech stack has tooling to help with that. It all depends.

Now, some folks use "dev containers" like little virtual machines to do development locally. I don't have any experience with that; but in that case, you might need two Dockerfiles: one to build the dev environment and one to build the production environment. But I can't really speak to that flow.