Your team has AWS, Datadog, Prometheus, Grafana, a Jira board with 400 open tickets, and runbooks.

What you don't have is a way to ask "which services depend on this database?" and get a straight answer.

You could check Terraform, but it may have been refactored twice already, Jira, where half the tickets reference renamed services or Slack but the thread that explains it is from a guy who left in September.

Anyshift builds a live graph of your entire stack : cloud, Kubernetes, code, monitoring, and continuously maps every dependency, relationship, and version.

A Perplexity for your production environment. Ask a question, get an answer grounded in what's deployed, not what's documented.

New engineer onboards? She queries the graph instead of pinging Slack for two weeks.
3am incident? Your on-call gets the full dependency chain and recent changes without a twenty-minute archaeology session.

Reliability review? You pull the actual topology, not a whiteboard photo from last quarter.

Most engineers have a default when a container breaks in production. They either restart it every time or rebuild every time. Both work often enough that you never question the habit.

Until it doesn't work and you've wasted an hour at 2am doing the wrong thing.

This week's article is adapted from Michael D. Smith's Mastering Docker on Windows. It's a simple restart-vs-rebuild decision framework that sounds obvious once you see it, but most teams never actually write down.

Cheers,

Shreyans Singh

Editor-in-Chief

Early Bird Offer LIVE Now: 40% Off With Code EARLY40

Offer Ends in 72 Hours

A simple framework for making the right call under pressure

Your container is acting up. Do you restart it or rebuild the whole image?

I've seen engineers waste hours on this because they defaulted to one or the other without thinking it through. So here's how I think about it.

It comes down to one question: is the problem in how the container is running, or in what was built?

If it's a runtime issue: the app got stuck, a config change hasn't taken effect, something just needs a kick, restart. That's the fastest path back to normal and there's nothing wrong with it.

If the image itself might be the problem, restart won't help. You'll just redeploy the same broken thing. You need to rebuild.

Sounds simple, but the tricky part is knowing which situation you're in. Here's how I usually work through it.

Config, env vars, or secrets changed? Restart the service. New values get picked up at runtime. No need for a new image.

Base image tag or digest changed? Rebuild. Even if your code is the same, the stuff underneath it isn't. Your dependencies have moved.

You built with latest or your Dockerfile pulls in dynamic dependencies? Rebuild. You don't really know what's inside that image anymore. Something upstream could have shifted without anyone noticing.

Application code changed? Obviously rebuild. New code needs a new artifact.

Container is misbehaving but the image checks out- tag is right, digest matches, nothing has moved upstream? Restart. The image is fine, the container just needs a fresh start.

Not sure what version is even running? Don't do anything yet. Inspect first. Check your image labels, check the digest. Then decide. Guessing under pressure is how you make things worse.

One small thing that helps a lot: bake a build timestamp into every image. A label, an env var, whatever. It takes seconds to add during the build and it means you can always verify what's actually running where. Saves a ton of time when you're half-awake and troubleshooting.

Here's the whole thing as a quick reference:

This article was adapted from Mastering Docker on Windows by Michael D. Smith.

Early Bird Offer LIVE Now: 40% Off With Code EARLY40

Offer Ends in 72 Hours

📢 If your company is interested in reaching an audience of developers and, technical professionals, and decision makers, you may want toadvertise with us.

If you have any comments or feedback, just reply back to this email.

Thanks for reading and have a great day!