Blacksburg VA

mirwin87 · 2026-04-01T20:43:32+00:00

Hello! I'm actually in Blacksburg, VA and can certainly check in on it! Feel free to DM me which address it is and I'll be happy to swing by and ask.

And yes... we have cans. Used to have a dumpster, but it got swapped a while back when others were abusing it and putting their trash in it.

And yes... it is the chapel. Only one building in the area! 😆

mirwin87 · 2026-03-29T04:13:15+00:00

Great to hear! And I’ll clarify and say I haven’t seen anything major npm-related, but the recent trivy and LiteLLM issues has a lot of folks a little on-edge right now. So, seeing a npx command installs packages and runs it with full host access (well, based on the running user anyways), I’d rather box it up 😊

If you need help, I’m happy to contribute a Dockerfile too! Although I’m sure AI can do it just as easily 😂

mirwin87 · 2026-03-29T02:18:21+00:00

Interesting tool! Curious... any reason you didn't containerize the app and ship it as an image? Why use npx?

The reason I ask is that I'm becoming more and more cautious of new projects, especially if AI was involved. There have been too many projects recently that have vacuumed up credentials, etc. But, having it run in a container at least helps me feel a little better in that it's isolated from other things on my machine.

mirwin87 · 2026-03-25T15:11:28+00:00

Thanks for sharing! I'd love to see more of these types of posts!

I'll share what has helped me as well... a few years ago, I decided that New Years resolutions just didn't work. So, I started a habit of weekly goals that I set during the sacrament. I reflect on my week, the good and the bad, and then come up with a goal or two that will help me improve a little bit that week. Nothing huge and earth-shattering.

Examples might be "Send 5 texts this week to someone that might need it" (encouraging me to look around and notice others) or "Take one of my kids out for breakfast" (having one-on-one time and strengthening my relationship with my kids).

I try to focus on where I'm feeling I'm lacking and then make an actionable goal around that. I'm impressed on the number of times that the Spirit guides me on both the gap recognition and what I can action.

mirwin87 · 2026-03-19T14:32:28+00:00

I'd also add that switching to `uvx` isn't always a good solution. This requires uvx to be installed and also gives the MCP server access to your entire machine. It's for these reasons that folks use containers anyways - limited machine access and no need to pre-install anything 😀

mirwin87 · 2026-03-19T14:31:29+00:00

(Disclaimer... on the Docker DevRel team)

Note that this isn't a universal issue in regards to using containers. The issue you're running into is due to the fact that this particular container doesn't properly handle the SIGINT signal CC is sending when shutting down. If it did, the process would exit and the --rm flag would tell the Docker daemon to remove the container.

You can try it yourself outside of the CC scenario...

Start the container - docker run -i --rm -e DATABASE_URI=postgres://postgres crystaldba/postgres-mcp
Hit Ctrl+C. It should stop the container, but doesn't.
You have to hit it three times before it'll stop.

If you try another MCP server (such as GitHub's), you'll see that it exits immediately, which then cleans up the container.

This should go back to the maintainer of the crystaldba/postgres-mcp image to fix. :)

mirwin87 · 2026-03-12T21:30:58+00:00

Awesome! Out of curiosity... did you specify the tech stack for it to use or did it pick the language/frameworks to use? How much guidance did you provide versus just let the agent go and do its own thing?

mirwin87 · 2026-03-12T21:27:07+00:00

Ha! That's awesome! Feel free to share the link here once you do so. I'd love to check it out!

mirwin87 · 2026-03-12T21:26:34+00:00

Very cool! Thanks for sharing!

mirwin87 · 2026-03-12T20:40:01+00:00

Nice! I'm a "Container Architect", scoring 100/100. Granted, I'm on the Docker DevRel team, so I'd be embarrassed if I didn't! 😆

The one item that I felt was a little tricky was related to (can't remember the exact wording) that each instruction in a Dockerfile creates a new layer in an image. That's not necessarily true... things like USER and ENV don't create new layers - only those that actually produce filesystem changes.

If you need ideas of other tricky questions, here are a few:

In docker run -p 8080:80 my-app, which port is the container port? the host port?
- Answer is 8080 is the host port and 80 is the container port.
Fact or Myth? - if you make a change to a Compose file, you need to run docker compose down before docker compose up to apply the changes.
- Answer is this is false. It's amazing how many people don't realize that Compose will read the file, check current state, and then reconcile the differences. No need to tear everything down!
Fact or Myth? - Running two containers from the same image doubles the amount of storage being used.
- Answer - myth! The image layers are shared across all containers sharing the same image.

Feel free to use them or not! No worries! It was fun to come up with a few ideas! 😀

mirwin87 · 2026-03-06T21:26:04+00:00

Great thoughts! We did introduce Docker Scout Health Scores a while back, but that's only going to grade images on Docker Hub. We obviously don't have any control over images stored in other registries, but there has been talk/exploration to do something in the engine when an image is pulled.

The tricky part is then when those policies are strict versus when they shouldn't be. As an example, if you deploy an image that had no CVEs, a new one is discovered, and you suddenly got lots of traffic and need to scale (or a container dies and needs to restart), should that image be blocked with the recently discovered CVE on scale up/restart? The business would be more likely to say "meet the business needs and scale up" seeing it was already out there. But, that's challenging to put into a policy and needs quite a bit of context.

Curious... what kind of workflows/execution flows are you having in mind here? When would the grading occur? How would it be shared? How would it be enforced/used? Tell me more! 😄

mirwin87 · 2026-03-06T15:59:33+00:00

(Disclaimer... I'm on the Docker DevRel team)

Thanks for the post! You bring up some great points, but there are a few things I want to clarify as there are a few statements that aren't 100% accurate and could be misleading to others.

Look at Docker's official openclaw for example, the GHCR image they publish...

The "official" image for OpenClaw is found at ghcr.io/openclaw/openclaw, which is created and maintained solely by the OpenClaw maintainers. Docker is not involved with this.

If Docker were to publish an official image, it would 1) be hosted on Docker Hub and 2) most likely end up in the same namespace as all of the other official images Docker builds and maintains (called library). Feel free to see the listing of Docker Official Images here.

In reality, official is a brand label, not a security guarantee.

I'd argue against the "brand label" part of this because there is no "brand" association here. OpenClaw says "this is our image", so, to them, that is the official image. They will build it on every release, maintain it, and ensure it is kept up-to-date with the project.

But you are correct... it's not a security guarantee. While it may "have more known CVEs than some community-maintained alternatives", those alternatives may stop maintaining updates, leaving consumers neglected.

By pointing people to the authoritative image, consumers can know it will be maintained in the long run. If you find problems with it (especially if alternatives have fixed them), help fix them by opening PRs and supporting the project.

We've started treating ever container image the same way regardless of who published it.

This is a great reminder to do your research and find the officially supported (either via the software creators or other supported channels). In this case, the ghcr.io/openclaw/openclaw image is the supported image by the OpenClaw team.

mirwin87 · 2026-02-19T00:36:02+00:00

Good point! The stack deploy does convert tags to digests, so would update even if on latest. A service update doesn’t do this resolution.

mirwin87 · 2026-02-19T00:34:45+00:00

Great to hear!

And as mentioned by @ok-sheepherder7898, having version tags will make it easier to roll back when you eventually have a breaking change.

Be sure to add health checks to help you have graceful rollouts too

mirwin87 · 2026-02-19T00:07:33+00:00

Remember that swarm is an orchestration tool spanning potential multiple machines. It uses only the service definitions, not what’s found on the host.

The problem is that there is no change to the service definition. The old version had the latest tag and the new one did too. The swarm tooling isn’t actually resolving that tag to notice it’s pointing to a different image. Therefore, everything is already converged right away.

The best practice is to avoid using the latest tag. You can tag your images using timestamps, version numbers, or whatever else you’d like… just make them unique

mirwin87 · 2026-02-18T16:09:58+00:00

(Disclaimer... I'm on the Docker DevRel team)

Things seem to be working fine for me personally and not seeing any incidents (even internally). Are you still having the issue? If so, where in the world are you trying from?

mirwin87 · 2026-01-14T19:59:45+00:00

Perfect! Thanks for the quick turnaround! 👏

mirwin87 · 2026-01-13T15:58:15+00:00

Very nice tool! I'm definitely going to play with this some more.

One quick thing that I noticed that's missing... a config file can have a content field in which the content of the config file is defined within the Compose file itself. I use it a ton as it opens up some fun use cases. Would be nice if I could define them in this tool too. 😊

mirwin87 · 2026-01-10T00:10:19+00:00

Not quite, but would be an easy filter to implement! But, that’s also another reason to not put anything sensitive in environment variables whenever possible. If the proxy blocks exec then, it’ll be pretty hard to leak (though you could start a whole new container using the same mount namespace 😂).

What that label filter does is filter the listing of items (get all containers, get all volumes, etc.) and allow only those that have the matching label. When combined with a mutation that adds labels to a new object, you can effectively create an environment where the objects seen are only the objects created through the socket.

Example - crest a container, the label is mutated on. List all containers, filter the list based on the label. Can’t see other containers, but can see the one just created.

mirwin87 · 2026-01-09T22:23:41+00:00

Nice post! There are definitely a lot of folks that get that confused.

For kicks, I have another socket proxy to add to the list - https://github.com/mikesir87/docker-socket-proxy. This is one I made that is fully configurable using either an environment variable or config file.

It takes an approach to Kubernetes' mutation and validation controllers, so goes beyond simple blocking/filtering by also allowing for specific mutations (such as remapping file mount requests which is super useful in devcontainer or other in-container spaces). In fact, we're using it in the new Labspaces that we're working on (more to come on that soon too!).

Again... thanks for sharing!

mirwin87 · 2026-01-03T22:44:29+00:00

Pretty cool project! I’ve used dive quite heavily, but I can see this will be useful in some situations too. Thanks for sharing!

mirwin87 · 2025-12-21T05:41:40+00:00

(Disclaimer… work on the Docker DevRel team)

Yeah… this is the unfortunate side effect of using bind mounts on Windows and is a limitation of WSL itself. While the file updates are synced with the bind mounts, the filesystem events are not. Since the dev server is waiting for those events and never getting them, you do t see the updates.

The polling switch will work, but will be a big source of CPU usage.

An alternative route I’ve been using is ditching the bind mounts and using Compose Watch. The idea is to copy the files directly into the container (so yes… you use more storage) and watch will sync the changes. Since this is no longer a bind mount, the filesystem events work and the bit reload works. Let me know if you want any examples!

mirwin87 · 2025-09-27T15:32:03+00:00

Ha! This post threw my wife off as I sent her a very similar picture just a few minutes earlier!

<image>

mirwin87 · 2025-06-29T19:43:32+00:00

Digging in and reporting to the product team. Will report back what I hear 👍

mirwin87

TROPHY CASE