Docker solved environment parity. It did not touch the thing that actually breaks: state parity.
"Works on my machine" rarely means a missing dependency anymore. It means your machine held one user, one clean dataset, and no history.
Production holds the opposite. A ledger with rows written by three generations of the codebase. Webhooks that arrive twice, out of order, or hours late. Catalog pages from a retailer who changed their markup overnight. Rows written before a column existed, sitting there legally NULL in a field the new code assumes is set.
That does not fit in a fixture.
The failures I keep meeting are the ones real state produces: a payment matched to the wrong obligation because two near-identical requisites existed. A job that passes alone and deadlocks the second two workers run it. A parser that handles the happy path for the top ten SKUs and quietly returns an empty list for the long tail.
So I stopped treating local green as evidence. What I want instead: a production-shaped copy to run against, not a seeded one. Test the second delivery of a webhook, not the first. Run the migration twice. Assume every nullable column is null somewhere (in a system older than three years, it is).
The reframing that helped me most: your laptop is not a smaller production. It is a different system that happens to run the same code.
I write up more of these state-level failure modes here: https://polycratia.com/c/435931fd
Your local environment lies to you somewhere: data shape, concurrency, or time. I think you already know which one...