Portainer on Margrop Blog

I Put Docker in a Control Room: Portainer CE 2.39.4 Deployment, Daily Use, and Real Traps

Fri, 10 Jul 2026 15:30:00 +0800

Bottom line first

Portainer does not replace Docker. It is a control room for a Docker host. Docker Engine remains the machinery; Portainer organizes containers, images, networks, volumes, and Compose stacks into a web dashboard.

I ran an isolated deployment of portainer/portainer-ce:2.39.4, initialized it, connected the local Docker environment, inspected the dashboard, filtered a disposable container, and created a demonstration stack. The installation is one docker run command. The important lessons are broader: persist /data, understand that /var/run/docker.sock is highly privileged, and never expose the management interface to an untrusted network without protection.

This article contains no complete IP address, real host name, private domain, administrator password, token, cookie, private registry address, or production container name. The screenshots use disposable names, and the container address is redacted.

Stop Letting Agents Burn Tokens: Wiring Headroom into NewAPI, OpenClaw, and HermesAgent

Sat, 20 Jun 2026 12:30:00 +0800

TL;DR

I did not replace NewAPI, and I did not point OpenClaw or HermesAgent at an unproven gateway. The actual design is simpler: place Headroom in front of NewAPI, then move only the already validated OpenAI-compatible providers to http://<headroom-host>:8787/v1. The original NewAPI endpoint stays available. Long agent context now goes through Headroom first, gets compressed, then continues to NewAPI for the same routing and model management as before.

The rule that kept the rollout boring was: test first, edit second; migrate only OpenAI-compatible providers that pass; leave non-OpenAI fallbacks alone. This post is both a write-up and a runbook you can hand to an Agent or follow manually.

I dockerized AnythingLLM and the container turned into a wound-up squirrel — restarting forever until I handed it that magic 1000:1000

Wed, 17 Jun 2026 20:30:00 +0800

TL;DR

AnythingLLM, Mintplex Labs’ “stuff-anything-in-a-LLM” desktop, ships an official Docker image. In the happy path one docker run is all you need. But the in-container user anythingllm is picky: the host directory you bind-mount has to be owned by 1000:1000, otherwise it can’t write its own SQLite file, the Prisma migration step on startup crashes, and the container enters a restart-crash-restart loop. The fix takes under a minute: chown -R 1000:1000 /your/data/dir, then docker compose up -d again, and it dutifully listens on 3001.

I’ll also explain why Prisma’s file:../storage/anythingllm.db relative path is a footgun, give you a Portainer-ready stack file, and finish with a Q&A on the most common gotchas.

The Portainer 500 Error That Wasn't the YAML — A Two-librespeed_default-Network Story

Sat, 13 Jun 2026 08:00:00 +0800

The short version

You update a stack in Portainer. The browser slaps you with a red 500 Internal Server Error. You assume the YAML is wrong, fix the indentation, swap the quotes, drop the image tag. You hit Update again. Same 500. And again. And again.

The real culprit is buried at the deepest level of the HTTP response body: network librespeed_default is ambiguous (2 matches found on name). Two networks with the same name exist in the same Docker engine—two IDs, two Created timestamps, two com.docker.compose.config-hash labels, but a single shared name. Compose asks the engine to look up that name; the engine refuses to pick between them; compose up fails; Portainer wraps the error as a 500 and returns it to your browser.

The fix is embarrassingly simple: delete one of the two orphan networks (docker network rm <id> or click Remove in Portainer’s Networks page), then re-run Update the stack with the exact same content. It just works.

This post is a real debugging session: a stack update that was supposed to be a 30-second mount-path change turned into a 1-hour investigation. All private details (internal addresses, registry URLs, volume paths, container names, credentials) have been replaced with <PLACEHOLDER>. Only public source code, official docs, and the error text itself are preserved.

When Docker Networks Collide with the Home LAN: Moving Auto-Allocated Subnets Back to 172

Mon, 13 Apr 2026 08:00:00 +0800

This post records a very practical Docker networking failure: the number of containers kept growing, Docker’s auto-assigned user-defined bridge networks eventually started landing in 192.168.x.x, and those networks began colliding with the real home LAN. The symptoms were not dramatic at first. Nothing looked “broken” in the usual sense. Containers were still running, the host was still alive, and the dashboard still looked normal. But parts of the home network became unreliable, and once I dug into it on my NAS, the root cause turned out to be the Docker network allocation strategy rather than any single bad container.

The fix was straightforward in principle, but important in practice: I moved Docker’s automatic network pool to 172.16.0.0/12, migrated the existing 192.168.* networks onto the 172 private range, and made sure future networks created through Portainer, Dockhand, or plain docker compose would follow the same rule.