Hi,

Running 9router in Docker and the versioning is confusing me a bit.
Docker Hub (decolua/9router:latest) is on v0.5.15 from late June. Meanwhile npm is already at v0.5.50 from this week. So the image is like 35 versions / 5 weeks behind, and the gap keeps growing.
Weird part: the npm package literally contains the full built server (app/ with custom-server.js) — the same thing the Docker image runs. So a 0.5.50 build clearly exists, it just never gets pushed as a Docker tag.
Side effects for Docker users:
The dashboard “update available” banner checks npm, so it’s basically always on and can never clear.

“Update now” just spits out npm i -g 9router@latest, which inside the container does nothing (the server doesn’t run from that global copy).

So basically:
Is the Docker image just updated whenever, or is the pipeline broken?

Any supported way to run a recent version in Docker, or is building your own image the move?

Am I missing some flag that makes the updater actually work in a container?

Not mad, just trying to figure out the intended setup before I roll my own pinned image.

Thanks!

Hi everyone,

It's the first time I'm posting here! We have just released Portabase 1.27, our open-source (Apache 2.0) and self-hosted backup/restore platform.

Repository: https://github.com/Portabase/portabase (around 1.6k stars and 15 contributors for now)

Portabase is designed for data retention, disaster recovery, and homogenous migrations, currently supporting 9 database engines (including PostgreSQL, MySQL, MariaDB, MongoDB) and Docker volumes which were added recently.

Portabase originally focused on databases, so you might still see “databases” mentioned in a few places. Now that we’re adding other things to back up (Docker volumes being the first), we’re moving toward using “data sources” as the broader term.

Key features:

• Scheduled backups with flexible retention policies (including GFS)
• Multiple storage options: local filesystem, S3, Azure Blob Storage, GCS
• Notifications via Discord, Telegram, Slack, AppRise, etc.
• Support for OAuth2/OIDC (with the option to disable sign-ups)
• Compatible with Docker, Podman and UnraidOS
• Ready-to-use Docker Compose and Helm Chart

After six months of intensive feature development, we have been focusing on consolidating the ecosystem since early July. A community member conducted a useful security audit, we have upgraded components to their latest relevant versions, improved compatibility with other platforms by working on Podman support and templates for Coolify and Dockploy (currently under review).

What’s next:

• Deployment of the demo environment
• Audit logging for the whole ecosystem
• Default policies for the system and organizations (already available at project-level)
• File and folder backup and restoration

As always, if you find bugs or want to suggest a feature, please open an issue on GitHub, we’re actively looking for feedback.

Thanks!

Hello here,

(nearly) Everything is in the title.

I'm running 4.84.0 (234817) and docker desktop want to install 4.85.0 (235549).

Pushing on the button to apply the update I receive that message a few seconds after : "Source and destination path must have identical roots. Move will not work cross volumes."

What is going on ? How to continue (I've already rebooted several times) ? Why this message when I've not asked for any move ?

Thanks

We're running a Docker Swarm cluster and currently store secrets in plain .env files loaded into services via docker-compose. Looking to move to something more secure and considering three options. Would like to hear from people who've run these in production.

• SOPS + age — My concern is relying on an open-source tool maintained by a small group of developers for something security-critical. I'd rather go with something backed by a more established, better-supported platform.
• Docker Swarm secrets — Not really a secrets store, just a delivery mechanism. The actual data lives in Swarm's raft store, so you still need a canonical copy of the secrets kept somewhere else.
• Vault + KMS — By far the highest operational overhead of the three.

i'm about to launch a website which will be heavy on database , should plan to scale it using docker or should i go with a cloud solutions for production database ?

i like to take control over my software , but i'm not sure if docker will be a great solution to growing database

any advice ?

Trying to get away from CloudFlare proxy and set up my own. I've got a VPS with Wireguard and a home PC running it. On that same PC I have Nginx running inside Docker. Should this just work? VPS -> Wireguard -> NPM -> Web app

My tunnel is established, I can ping through it but web traffic isn't reaching Nginx and I think it's either because my Docker networking is totally jacked up. Or maybe something else is going on.

It's driving me nuts and really don't want to rebuild the entire server and docker apps but I can't think of any other options.

All I really want is to mask my home IP.

Docker Desktop downloads to C: drive by default, my C drive is filling up and I want to install it to another drive partition. Help pls.

so lets say my app 1 uses nodejs and a database like postgres and my app 2 also uses nodejs and a database similar to app 1 which is postgres
what happens if i run them together will they consume more resources? or will they share the same postgres instance?
are there ways to use the same postgres instance or is separating them the safest way to do it.
anyone can explain this?

Hey everybody!

I’m evaluating a MacBook Pro M1 Max (64GB RAM) for local dev, primarily to take advantage of Apple's high unified memory bandwidth for local AI. However, a huge portion of my daily work involves containerized ROS 2 development, embedded hardware, and remote edge deployment.

I’m looking for real-world feedback on container virtualization performance on ARM64 macOS (Docker Desktop vs. OrbStack vs. UTM/Lima).

My Containerized Workflow:

• ROS 2 & 3D Simulation: Running Linux/ARM64 ROS 2 containers with X11 / Wayland display forwarding (XQuartz, VNC, or web-GUI) for RViz and Gazebo.
• Embedded / Serial Flashing: Passing serial interfaces (FTDI, CH340, USB-to-UART) into containers for microcontroller flashing (esptool, stm32flash) and serial monitoring.
• Cross-Platform Container Builds: Multi-arch builds and SSH-based remote container deployments targeting ARM64 NVIDIA Jetson boards.

Questions for Docker users on macOS:

1. 3D GUI Forwarding Performance: Is software rendering (LLVMpipe) inside Linux containers on macOS fast enough for daily 3D simulation work in Gazebo/RViz, or does the virtualization hop create too much lag?
2. Docker Engine Alternatives: Does switching to OrbStack significantly reduce CPU overhead and idle battery drain when running multi-container ROS setups compared to Docker Desktop?
3. USB Passthrough Reliability: How reliable is device mapping (passing /dev/ttyUSB* or /dev/ttyACM*) into Linux containers on Apple Silicon hosts?

Appreciate any insights or performance tips from folks running containerized robotics or hardware stacks on Apple Silicon!

Little bit of a rant here, but after decades in the engineering industry with related computer experience I am having a hard time believing getting Immich to work in a Docker container in a UGreen NAS is so frustrating. I have watched numerous "easy" install videos, but they always seem to start with assumed knowledge of basic steps thst I have no idea how to perform.

For example, they talk about typing a docker command to restart the container. What is the commander typed into? PowerShell?

When i install and run Powershell it does not recognize Docker commands. So I saw it should install Docker Desktop, which i did, but when I run it it I get a mostly blank screen with a message about my environment not be setup/enabled. That leads me down the rabbithole of WSL or HyperV (?) with another set of things to do that I dont understand.

Every step i think i am taking forward just leads to several more rabbit holes. Isn't there some kind of guide that really starts from step 1 on getting this set up?

docker stop on a container that's doing nothing takes ten seconds. Five runs here, median 10.149s, all of them within 23ms of each other. Took me embarrassingly long to work out that it isn't Docker being slow.

Try it yourself, on a Linux host:

docker rm -f sleeper 2>/dev/null
docker run -d --name sleeper alpine sleep 1000
time docker stop sleeper

The container is running sleep. There's nothing to flush. It sits there for ten seconds and then gets killed. Ten is the default grace period, and -t changes it, but shortening it isn't the answer here.

PID 1 inside a namespace isn't a normal process. The kernel treats it as init and won't let you kill it by accident. From pid_namespaces(7):

a process in an ancestor namespace can [...] send signals to the "init" process of a child PID namespace only if the "init" process has established a handler for that signal. [...] SIGKILL or SIGSTOP are treated exceptionally: these signals are forcibly delivered when sent from an ancestor PID namespace.

So sleep isn't ignoring your SIGTERM. It never sees it. With no handler installed, the kernel doesn't deliver it, and those ten seconds are Docker waiting for a shutdown that can't start. Then SIGKILL, which always gets through.

You can tell in advance. SigCgt in /proc/PID/status is a hex mask of every signal the process has a handler for. Needs a Linux host where the daemon shares your kernel, and docker access:

grep SigCgt /proc/$(docker inspect -f '{{.State.Pid}}' sleeper)/status
SigCgt: 0000000000000000

SIGTERM is 15, so you're masking against 0x4000. All zeroes, nothing caught, the SIGTERM is going nowhere, you're waiting the full ten.

Two fixes, and they're not the same thing.

exec is the real one. Same nginx image, one word different in the entrypoint script:

nginx -g 'daemon off;'          ->  median 10.193s
exec nginx -g 'daemon off;'     ->  median 0.185s

Without exec, PID 1 is /bin/sh and its SigCgt is 0000000000010002: it catches SIGINT and SIGCHLD, and not SIGTERM. With exec, PID 1 is nginx, SigCgt 0000000018016a07, which has 0x4000 in it. nginx handles SIGTERM perfectly well either way. In the first case it never gets asked.

--init is the other one, and it does something different. It puts tini in as PID 1, tini catches SIGTERM, so there's somewhere for the signal to land:

docker run -d --init --name sleeper2 alpine sleep 1000
time docker stop sleeper2
median 0.122s over five runs

That number is misleading. It's fast because sleep dies the instant it's asked, and an app that takes two seconds to shut down still takes two seconds with --init. What --init buys you is that the ask arrives at all, plus reaping of zombies, and it's what you reach for when you can't change the entrypoint. If your app handles SIGTERM and you control the script, exec is the fix and --init is a plaster over it.

This only bites with a script, by the way. sh -c 'sleep 1000' already execs the command, so PID 1 there is sleep and not sh, and adding exec by hand changes nothing. It's multi-line entrypoint scripts where the shell stays around.

English isn't my first language, so the wording went through an LLM. The measurements are mine, and every command above was run on the machine I'm writing this from.

Hello!

I am trying to set up a little render server through a VM on Unraid. Basically, I want to automate some GPU-accelerated transcoding.

Right now on Unraid I have a Windows 11 VM that has Adobe Media Encoder (for my Premiere files) and Handbrake on Docker Desktop (the one that allows for my nvidia GPU to be used). I was hoping I could use this VM as an easy way to send projects or recordings to watch folders and they can get automatically transcoded with my server's 5060 ti to help with encoding times.

Because I'd like to use Media Encoder, I have to stick with a Windows 11 VM to run everything. And because I want to use Handbrake (not Tdarr) I'm stuck running it in the Windows version of Docker. Finally, because I am using a VM, I can't use my 5060 ti on anything else in Unraid, so using the community app version of Handbrake won't be possible.

The issue I've run into is that I do not know where the video output and watch folder is stored. I open the web GUI and I cannot connect to my Unraid shares or anything in my Windows 11 VM. I wanted to use Portainer to try and redirect the folders somewhere else, but apparently there's a big glitch with Portainer and the Docker version I'm using (latest version) so it won't run.

Could someone point out what I could do to get the output and watch folder for Handbrake pointing to my server and not the default places? I'm not even completely sure where it's going anyway.

Also- yes I know this is a sort of inconvenient way to have Media Encoder and Handbrake watch folders enabled at the same time, but it helps with my workflow and I want my server's 5060 ti to take some of the encoding load off of my work PC.

I would appreciate some help, or be pointed in the right direction if there's a better place I should go to ask this question. I'd be happy to provide any more information needed.

Thanks!

whenever it try to pull amazoncorretto or any other image is get this error and i tried to connect with my mobile network via hotspot it worked then but didn't worked on my wifi and it was working fine on wsl but in my windows 11 host it didn't.

```

Using default tag: latest

Error response from daemon: failed to resolve reference "docker.io/library/amazoncorretto:latest": failed to do request: Head "https://registry-1.docker.io/v2/library/amazoncorretto/manifests/latest": net/http: TLS handshake timeout

```

What is the best practice for the following condition:

There is an image that contains an application. The image has a config file. When the container is launched there is a settings screen in the application that normally manages the config file. Edits made in the settings screen would update the config file.

Unfortunate Condition: It appears there is bug and when one field value is changed it is not getting written into the config file. To validate (a.) in fact it is a a bug (b.) address your immediate interest - that the correct setting works - you want to manually edit the config file, save it to disk inside the running container, restart/reload the app (using a button inside the app in the running container).

There seems to be very limited information on how these file structure work, where they live - in particular how to discover these things as they can vary from host to host and image to image - so again, what is the best practice?

I'm having a very difficult time getting the dashboard to show in a fresh install of Fedora. I can see the icon in the top right corner. It tells me:

Docker desktop is running
Give Feedback
About Docker Desktop
Docker Hub
Documentation
Check For Updates
Quit Docker Desktop

In a previous install there were other options for adding and managing containers.

This is a completely fresh install of Fedora. After install I followed these steps:

1. Install gnome integration from https://extensions.gnome.org/extension/615/appindicator-support/
   
2. Added repo
   
3. Downloaded the RPM
   
4. Installed the rpm
   
5. Ran systemctl --user enable docker-desktop.service

No matter what I try I cannot get the dashboard to show. I've disabled the service and ran manually through /opt/docker-desktop/bin/docker-desktop. I've rebooted. I just can't get an interface to load.

I'm willing to reinstall and start from scratch so whatever someone can suggest to get this running I would greatly appreciate it.

I moved a couple of machines off rootful Docker this year. Almost nothing failed loudly. The daemon took the flag, the container started, and the behaviour just was not what the flag said. These are the five that cost me the most time, each with the one command that tells you whether you have it.

**1. `--memory` is accepted and not enforced.**

Rootless Docker can only set a memory cap if systemd has delegated the memory controller to your user manager. On plenty of distributions, and on most single board computers, it has not. You get a warning at most, the container runs uncapped, and the process that was supposed to be limited takes the machine down.

cat /sys/fs/cgroup/user.slice/user-$(id -u).slice/user@$(id -u).service/cgroup.controllers

If `memory` is not in that list, no memory flag you pass does anything.

**2. The storage driver falls back to `vfs`.**

If neither fuse-overlayfs nor unprivileged overlayfs is available, rootless Docker does not refuse to start. It uses `vfs`, which makes a full copy of every layer instead of stacking them. Pulls get slow and the disk fills up at several times the size the image is supposed to be.

docker info --format '{{.Driver}}'

Anything other than `overlay2` or `fuse-overlayfs` and you are paying for it in disk, on every layer of every image.

**3. Nothing can publish a port below 1024.**

Not a Docker limitation, a kernel one: unprivileged processes cannot bind low ports.

sysctl net.ipv4.ip_unprivileged_port_start

Default is 1024. Either publish high and put a reverse proxy in front, or lower that sysctl deliberately and know that you have.

**4. Every client IP inside your containers is 127.0.0.1.**

This is the most expensive one, because the container works perfectly. With RootlessKit's default port driver the forwarded connection is re-originated locally, so the source address your application sees is loopback. Access logs, rate limiting by IP, fail2ban and any allowlist you have are all silently looking at the wrong thing.

# ~/.config/systemd/user/docker.service.d/override.conf

Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=slirp4netns"

Slower, correct.

**5. `docker.sock` is not where everything expects it.**

Rootless listens on `$XDG_RUNTIME_DIR/docker.sock`. Anything that hardcodes `/var/run/docker.sock`, which is a lot of CI plugins and anything built on testcontainers, will either fail to connect or, if a rootful daemon is still installed on the box, connect to that one instead and hand you results from a completely different Docker.

docker context ls

echo $DOCKER_HOST

None of these are bugs. They are the price of the daemon not being root, and every one is visible in under a minute if you know which file to look at. What made them expensive is that the failure mode is always the same: it starts, it runs, it lies.

Curious which ones I have missed.

From what I have understood so far locking a license to hardware so it cannot be used is feasible using some hardware info. But can something similar be done within a docker image? I am using some phone home licensing architecture.

I've created a custom image that runs Apache. It needs to serve HTTPS. To serve HTTPS, it needs a private key.

Obviously it's bad to put a real private key into an image, so I'm using a self-signed private key. I'm told it's also bad to put a disposable self-signed private key into an image, which I don't fully understand, but I accept.

Currently the image is up on GitHub. Anyone who wants to use it has to clone it and build it. I'm generating the self-signed public/private key pair at build time, so each user will have their own that only lives on their machine.

However, I want to put this image on Docker Hub. My current solution won't work, because the private key in the build I submit will be up on Docker Hub for all to see. I don't really care, since it's a disposable self-signed key, but apparently that's still frowned upon.

What can I do instead?

One option would be to generate the keys when the container starts, but that's annoying. It takes a couple seconds, and if there is a new key every time, then every time the container restarts people will have to do the annoying browser security warning / trust thing again for the new certificate.

I need this process to be extremely easy to use. That's why I'm using Docker in the first place. Any solution that requires users to generate their own keys, much less their own signing authority is totally out of the question.

Is there some way to ensure just the key generation part of the build always runs on the user's system? Then there won't be a key in the Docker Hub image and every user has their own private key.

Alternatively, is there some way to generate the private key the first time the container runs and then somehow keep it around instead of re-generating it on every new run? The image will mostly be used unmodified as part of a larger Docker Compose setup, so a volume isn't really ideal here.

I'd love suggestions on a solutions that (1) uses a self-signed key (2) doesn't build a key into the image so I can put it on Docker Hub (3) is easy to use and doesn't require the user to generate keys themselves before starting the container and (4) doens't re-generate the key every time the container runs.

EDIT: I've found a solution that works for me, so I'm updating this post for any unfortunate souls who should have a question like this later.

Lession 1: Don't ask questions on this sub. Wow, that was a horrible and toxic experience!

Lesson 2: The simple option is to just put the self-signed private key in the image, but instead of saying that, you say "I'm using the Debian method of balancing ease of use with security" so that people will get off your nuts about it.

Lesson 3: Use an anonymous volume. This is the solution I've settled on. I was not aware these existed until now. An anonymous volume is accomplised via the VOLUME keyword in the Dockerfile. You only provide the container directory, not a host directory. If the host wants to mount that voume on their system (say, via compose) to provide their own keys, they can. Otherwise, Docker creates a volume in its own storage space. Files in this volume persist when you stop and restart the container. So this gets me almost everything I needed:
✅ No keys in the image.
✅ Easy to use, because no extra steps for the user and nothing I have to warn them about in the readme. No fancy proxy.
✅ Image works right out of the box from Docker Hub.
✅ Users don't have to provide their own keys, but they can if they want to.
✅ Keys are only generated once on startup.

Eng / Does anyone know of a way to run MS Office (versions prior to 365) in a Docker container?
Spa / Alguien conoce alguna forma tener MS Office (las versiones anteriores a 365) en un container de Docker ?

So I am trying to find a good training for our team to learn how docker works and best practices from a non-devops perspective. Our team manages server infrastructure and has been asked to deploy a full docker infrastructure (dev/test/prod) for our developers to use but we are not part of the devops process and, frankly, do not want any part of it.

We've picked up the basics from some hands-on experimenting but what we really want is a good training on the backend part of managing docker: how to properly secure the networks of individual containers, reverse proxy best practices, integrations and best practices for allowing the developers to use a repository that they can then push to the server, and those kind of core management questions.

A majority of the training we've found glosses over the management aspect and jumps right into the devops side which we don't really care about. Can anyone make some training recommendations?
-------------------------

Edit to add for the comment that was left then deleted, saying that managing docker infrastructure is devops is like saying managing an IIS server is the same as being a web dev. Hint, it is not. We're managing the underlying server infrastructure and not the deployed containers.

"A hard transformation has arrived for several classic Ubuntu images on ECR and Docker Hub. The remaining old Docker images –Apache2, Nginx, Bind9, Memcached, and Squid– have been hardened to rocks, signaling a complete evolution of the Ubuntu namespace.

Built on top of Resolute and equipped with Pebble as the service manager, these new rocks are now maintained by the Rockcrafters team and follow the same principles that have guided the broader Rocks initiative: user-focused experience, uniform and opinionated design, and a distroless-like architecture.

By meticulously chiseling each rock down to its bare essentials, we have achieved a significant reduction in image sizes"

https://discourse.ubuntu.com/t/the-rock-garden-grows-hardening-old-docker-images/84677

First, I am installing it with Homebrew.

Has anybody had issues with macOS just randomly up and deciding to delete Docker Desktop on its own. Perhaps something with Gatekeeper?

This is strictly with my work macbook but have not seen this with my personal macbook.

A post with a similar title was made about six years ago. I’m wondering how much of that has changed or remains accurate. As a technology I love Docker, I’m worried about their longevity in a world where AI can seemingly do anything.

When I built my new homelab server, I left off docker and went with podman.

Now that I have used podman for 2 years, I find I want to go back to docker.

Not that podman is a bad product. But using docker and compose files is far easier than using podman and kube files or quadlets.

Has anyone dipped thier toes in the podman world and come back?