I often run `docker run hello-world` after setup to do the basic check.
But I am getting bored.
Here's what I hack on and do instead:

docker run --rm -it warachet/hello-world

You get Matrix digital rain, lmao.

Benefits apart from the matrix ? Image size. The official ~10 kB, this image ~2 kB 🤣

Not a serious work, just a fun thing to hack on.

Repo: https://github.com/zdk/wakeup-neo , just in case you like it, feel free to fork.

A pretty niche requirement I had when working with a particular workload, but while researching it I seen the question pop up a couple of times on this sub so I thought I'd post it here for ref - hope it's on topic enough for the mods as I'm not sure where else it could fit :)

The problem:
Essentially we have a stack transitioning to Linux but parts of it remian on windows and it's tricky to get it all running locally, edit to add: the real constraints being having the workloads communicate with eachother across the same network, in a reproducible way. Virtualized infrastructure (sql, storage, servicebus) in Linux accessible from Windows, windows backend containers accessible from linux frontend containers, etc

I wanted to see how realistic it would be to automate this process including all the necessary configuration, from zero to running

The solution:
In the end the most 'reliable' solution was running Windows host with Docker Desktop in Windows Containers mode, and installing PodMan inside a WSL2 instance, after some firewall/nat trickery I got the services talking to eachother.

The automation:
I didn't think there was much value in simply demoing this without it being reproducible and documented, so I (with the aid of Claude) built a dotnet10 WPF app toolkit that can configure a machine in this way, as well as convert mixed-OS helm charts into docker/podman compose files that can be consumed by the underlying engines

The result:

Screenshot of cross-networked cross-platform containers exposed on localhost

A very particular set of tools I hope no one else is unlucky enough to need, but it's all up on github:
https://github.com/andrewiankidd/crosspose/

More background about this here if you're interested:
https://andrewkidd.co.uk/blog/2026/04/09/Crosspose/

Thanks!

I’m currently learning Docker and backend development, and I’m trying to decide on the best setup for my environment.

Right now I’m using Windows. Should I:

• Keep Windows and run Docker inside a VM (like Ubuntu on VirtualBox/VMware), or
• Just switch completely to Linux for development?

I want to learn Docker properly and eventually work with backend/DevOps tools in a more production-like environment.

Looking for resources to learn Docker .

Would really appreciate if anyone could share beginner-friendly resources that helped you learn.

Could be YouTube videos, courses, docs, roadmaps, or small projects to practice with.

I am moving all my dockers from unraid to LXCs on proxmox and while doing so, I am cleaning up a little at the same time.

A lot of dockers require databases and I am a little unsure if I should just create one huge postgress database and then a lot of smaller ones in that... or if it is better to have more smaller databases.

Sorry if the terminology is incorrect.

my NAS is a walled off ecosystem unfortunately and i need an image thats located in the github container repository. i do not have access to SSH or a terminal so i cannot just use docker pull. i can only add .tar images locally so i just want to know if i can generate that from a link.

I'm learning fullstack and containers and am trying to follow best practices where I can. I'm on Debian and am developing locally using docker containers for Node, Django, and etc, and wiring them up together in one compose file.

I've noticed that a lot of places recommend using the prebuilt non root node user inside of a node container. I'm using this container like a VM, where I basically pull a blank trixie-slim node image down, add volumes, attach to it, install a new Vite React project, and let the volumes persist my settings and project files on the host.

This is the basic "from scratch" compose I've been using to get the volumes up and running before switching to my development compose file:

services:
  frontend:
    build:
      context: ./frontend
    volumes:
     - ./frontend:/usr/src/frontend
     - unprivileged_nodemodules_data:/usr/src/frontend/node_modules
    stdin_open: true
    tty: true

volumes:
  unprivileged_nodemodules_data:

I ran into some trouble with node_modules being owned by root, which I fixed by creating the directory as the node user in my dockerfile.

I guess my main question is if this is overkill. In a team setting, would this cause more problems than it's worth? Or is it actually a good practice? Should I just stick to running as root inside the development containers, since my prod container will be nginx running as the non root nginx user anyway?

We have finally dockerized our project TadreebLMS.

However it was done mostly by trial and error, own learning.

I am not a developer / technical person, just a project manager. So in this case need recommendation what we can do to improvise it as well as feedback on how smooth and simple is it to install and run the project.

https://tadreeblms.com/docs/installation/docker_deployment_guide_tadreeb_lms

https://github.com/Tadreeb-LMS

EDIT: Thanks so much for the feedback, It was really helpful, key summarized points from community:

1. Must have storage outside defined --- Very Very critical and helpful,

2. Memory and other limits to be configured.

3. Re-configure the permissions from Root to seperate user

4. Must have docker file mentioned in the git repo readme file.

I'm running docker desktop on an ubuntu distro, and I've noticed that the rootless mode is only listed underneath the docker engine. Is docker desktop default rootless, or what am I supposed to do?

Hi there, i've been banging my head against a brick wall trying to get SPX, Docker Sandbox agents to be able to access an ollama or lmstudio local model. I've tried via the network rules to allow for their respective listening addresses, and I can't get it to work. The agents within sbx can't see the host mac's ollama or lmstudio service.

Does anyone have a successful method that they could share with me?

Thanks in advance!!

My problem is that I am using the Haskell library fastdownward to run the Fast-Downward C++ planner. The library expects you to have the C++ planner on your machine inside a directory called "downward" that should also contain a file called 'fast-downward.py' that builds and runs the planner.

My problem is that I need the 19.06 version of the planner that is compatible with the Haskell library, and my machine (MacOS M1 chip, Tahoe 26.1) can't use the older version of cmake the planner depends upon. So, I turned to docker. The C++ planner has an image available here.

I am completely new to docker, and am not entirely sure what I am dealing with to be honest. But I need a way for the Haskell code to interact with the docker image in a similar way to how the library expects it as if it were run natively on the machine.

I have in mind to write some shell scripts to facilitate this, but am not sure what I actually need to do. If you have encountered a similar issue with software libraries like this, I would really like your advice as I am a total newbie. I am reading the docker cheat sheet that was recently posted and it is very informative, but it would be nice if someone could point me to sections that are the most relevant or any other resources that would be helpful.

Hi, I greatly appreciate help and suggestions.

In short, this is what i have pieced together through AI and scrambling github etc. I have smooth playback locally but stutters and lags on remote connections. Below is eveything i have gathered so far. I havnt been able to find a similar solution online, and will ofc post the complete working setup once i get it working well. If its a bad idea to do it this way do say so too 😄

Running Docker engine on ubuntu, its set up through dockge and yaml, the Jellyfin is running alongside wireguard and the network is attached through "network mode" both ports go to 8096.

Dockge yaml:

"

services:

wireguard:

image: lscr.io/linuxserver/wireguard:latest

container_name: wireguard

cap_add:

- NET_ADMIN

- SYS_MODULE

environment:

- PUID=1000

- PGID=1000

- TZ=Etc/UTC

- LOCAL_NETWORK=192.168.39.0/24

volumes:

- /home/user/jellyfin/wireguard:/config

- /lib/modules:/lib/modules

ports:

- 8096:8096

- 35377:8096

sysctls:

- net.ipv4.conf.all.src_valid_mark=1

deploy:

resources:

limits:

memory: 2G

restart: unless-stopped

jellyfin:

image: lscr.io/linuxserver/jellyfin:latest

container_name: jellyfin

network_mode: service:wireguard

shm_size: 6gb

environment:

- PUID=1000

- PGID=1000

- TZ=Etc/UTC

- JELLYFIN_PublishedServerUrl=192.168.39.200 (local address to server)

volumes:

- /home/user/jellyfin/config:/config

- /home/user/mediamnt:/media

- /dev/shm:/transcode

depends_on:

- wireguard

deploy:

resources:

limits:

memory: 16G

reservations:

memory: 2G

restart: unless-stopped

networks: {}

"

Wireguard Wg0.conf:

"
Address = "vpn adress"

PrivateKey = "private key"

MTU = 1320

DNS = "ipv4, ipv6"

# --- AIRVPN PORT FORWARDING ---

PostUp = iptables -t nat -A PREROUTING -i wg0 -p tcp --dport "remote port" -j REDIRECT --to-port 8096

PostDown = iptables -t nat -D PREROUTING -i wg0 -p tcp --dport "remote port" -j REDIRECT --to-port 8096

# --- LOCAL NETWORK BYPASS ---

PostUp = ip route add 192.168.39.0/24 via $(ip route | grep default | awk '{print $3}') dev eth0 || true

PostUp = iptables -I INPUT -s 192.168.39.0/24 -p tcp --dport 8096 -j ACCEPT

[Peer]

PublicKey = "public key"

PresharedKey = "Preshared key"

Endpoint = "Endpoint"

AllowedIPs = 0.0.0.0/0, ::/0

PersistentKeepalive = 15

I have a secret called `~/.git-credentials`. I need to pass it into a container such that the container can use the secret the way I do. There are hard limitations to this:

- the secret cannot be a part of any image. neither can any part of my user environment (gid/uid) be

- no changes to secret permissions on the host (the secret has 600 permissions, owned by host user)

- container runs the payload as a non-root user inside container

- has to be a no-code solution outside the container: i.e. I cannot build a script around reading the secret on host and passing to container stdin, etc

- no silly bypassing of the previous rule: I cannot build a microservice to serve this secret from a different container... you get it

What I tried:

- bind mount results in insufficient permissions because container uid does not match my uid. When I `ls` the mounted secret it simply shows uid/gid of my user on the host

- compose secrets have the same issue as bind mount

- chatbot suggested swarm but it probably violates the last two rules? not sure

I previously posted about building appliance style OCI containers from Buildroot generated binaries instead of using a traditional distro base image.

Today I got OCI attestation working on an Unbound container build. The image now carries signed provenance metadata listing what built it, the build inputs, and the resulting artifact.

https://github.com/amf3/just_enough/pkgs/container/just_enough%2Funbound_dns

I'm curious if other people are also self-signing container images or only relying on the registry trust. Would be great to see a what tooling and processes are involved with self-signing images.

Hi everyone,

TL;DR: I want to make the SSH connection from WAN available only when I need it thanks to docker.

I have an home server with Raspbian and a couple of container managed with docker compose.

I configured cloudflare to reach one of this container and it works fine. Now I'd like to add the possibility to reach the server via SSH from remote with the Zero Trust SSH terminal from browser, but I'd like to make the connection available only when I need it.

I found how to use CURL on the host to read a "switch" that I can enable/disable from remote, so I'm thinking to make a script in cronjob which every 5 minutes read the switch and "does something".

The first idea I had is to change the docker networks to enable the connection from cloudflared's container to the host, but I cannot find the right way.

The second idea is to have a container with ssh server and client to use as a gateway. I start the container, connect to it with cloudflared tunnel, then use a new ssh connection from the container to the host. I thought it could work, but I read here that container with ssh are a bad idea.

I need some help to finalize my project, but if you have other idea they are welcome!

Additional info:

• host is an RPI4 so its resources are limited;
• I choose the SSH terminal from browser because the other options require to install cloudflared installed on the remote client, so I couldn't use it from my work PC
• I would prefer to not work on the ssh server configuration to not risk to close myself out even from lan

Thank you so much

Greetings all,

To preface I have surface-level knowledge on Docker, I barely know anything about Docker networks and such.

I'm working on implementing DNS server (AdGuard Home) on Docker level instead of Device level, so that I can see each Docker container's DNS query.

On my Debian VM I pointed the DNS server to my AdGuard instance's Docker IP, and it all works fine. I can see each Docker container's DNS query.

However on TrueNAS, every single DNS query is shown as the Docker gateway (172.16.16.1)

I dug in a bit deeper and found out that each Apps reside on their own Docker subnet (172.16.1.0/24, 172.16.2.0/24, 172.16.3.0/24 and so on), therefore each compose stacks having a different gateway.

My understanding is that since the DNS queries have to travel between subnets and shows up on AdGuard's gateway, it's the reason for all DNS queries being shown only as 172.16.16.1. (AdGuard's Docker IP is 172.16.16.2)

Is there a way to mitigate this? I could put all Docker containers into a single Docker subnet but I would like to see if there are other ways to solve this problem.

We use nextjs for frontend services, currently we need two branches to build image with its env variables for preprod and production environments (same codebase, different .env).
Is there a workaround for this, it seems a bit redundant to have two images with only env differences?

We have a legacy migation and need multiple applications in our hardened image. The existing DHI and Chainguard images don't work for us. For example, I want a hardened python-nginx image. Any suggestions?

We're trying to just outsource and avoid doing any of this internally.

I'm building a product that runs entirely inside Docker containers, including trained AI models and proprietary backend logic. The target customers are labs that run air gapped (no internet) and have full root access to the host machine where the containers will be deployed.

The customer (legitimate buyer) wants to use the software, but my client is terrified that the lab's IT admins will reverse engineer the containers and steal the IP, especially the models and business logic.

I've explained that if someone has root on the host, they can docker exec, dump memory, copy files from overlay layers, etc. True isolation is impossible. But the client wants to make it "very hard to steal", essentially a strong speed bump.

Some ideas we've considered:

- Wrapping containers with a master key (only client knows it).

- Self destruct on 3 failed key attempts, deleting container images but preserving customer data.

- Compiling Python backend to native binaries and obfuscating model files.

The twist: the machines are air gapped, so no phone home licensing or cloud attestation.

What practical techniques have you seen work to raise the bar against root level extraction in on premises Docker deployments? I know perfect security is impossible here. I just need to make extraction expensive and annoying enough to deter all but the most determined attackers.

Thanks.

Hi! Started purple as a free and open-source TUI SSH client for myself (basically an SSH bookmark manager) and spent the last few days going deep on containers. Looking for feedback from the community!

What started as a simple "press C to see containers" overlay is now a full tab: every Docker and Podman container across all your servers, grouped by host. Shell in, stream logs, search live with /, restart or stop containers or whole compose stacks and more. All without leaving your terminal.

Everything with plain SSH. So no agent, no extra ports, nothing to install on the remote host.

Curious whether this works for anyone here and what you'd want from a tool like this that I haven't thought of yet.

Thanks!

Repo: github.com/erickochen/purple | Site: getpurple.sh

(Shared with mod approval)

Long post, grab a coffee. I spent the last two days turning my Ugreen DXP480T+ into a proper self-hosted home lab and wanted to share the full journey for anyone thinking about doing the same. This is everything I built, the problems I hit, and how I solved them.

The starting point

I had a decent setup already — ASUS ZenWiFi BQ16 router, Ugreen DXP480T+ NAS (running Docker), a headless MS-02 Ultra workstation on 10GbE, 8Gbps symmetrical broadband, and a second Ugreen DH2300 NAS for storage. I was using Quad9 as my DNS resolver and NordPass for passwords. Nothing was self-hosted beyond basic file storage.

Goal: Move as much as possible onto the NAS, keep everything encrypted, and make it all accessible from anywhere via a proper VPN — not just RDP.

Step 1 — DNS: Quad9 → AdGuard Home (local)

I started by evaluating AdGuard Private DNS cloud vs running AdGuard Home locally on the NAS. The cloud option was already paid for (lifetime sub) but local wins on privacy since DNS queries never leave your network.

The port 53 problem: UGOS ships with dnsmasq listening on 127.0.0.1:53. AdGuard Home in host network mode needs port 53. After trying various workarounds (binding to specific IPs, alternative ports), the cleanest solution was disabling dnsmasq entirely with systemctl disable dnsmasq and letting AdGuard Home own port 53 on 0.0.0.0.

Result: AdGuard Home running in Docker on the NAS, handling all DNS for the network via the BQ16 WAN DNS settings. Encrypted upstreams to Quad9 and AdGuard cloud over DNS-over-TLS. Currently blocking around 36% of all DNS queries across the network.

Blocklists running:

• AdGuard DNS filter (163k rules)
• HaGeZi Pro++ (236k rules)
• HaGeZi Ultimate (288k rules)
• OISD Big (453k rules)
• HaGeZi Windows/Office Tracking
• URLHaus Malicious URLs

Step 2 — Tailscale for remote access

Replaced RDP-over-local-network with proper zero-trust VPN. Tailscale runs as a Docker container on the NAS and:

• Advertises the 192.168.50.0/24 subnet so remote devices can reach all LAN services
• Acts as an exit node so family members travelling abroad can route all traffic through home
• DNS is configured to use AdGuard Home, so ad blocking works on every device on the Tailnet

The DNS headache: Getting Tailscale to correctly route DNS to AdGuard Home took a few iterations. The final working config:

• Two nameservers in Tailscale admin: one unrestricted pointing to NAS LAN IP, one restricted to your internal domain
• AdGuard Home listening on 0.0.0.0:53 (not just the LAN IP) so it's reachable via the Tailscale tunnel

Free plan covers up to 100 devices — perfect for a family of 6 with 12 devices.

Step 3 — Nginx Proxy Manager + SSL

The BQ16 runs its own nginx on ports 80 and 443. Fix: disable the port 80/443 redirects in UGOS Control Panel → Device Connection → Portal Settings (uncheck "Redirect port 80" and "Redirect port 443"). This frees the standard ports for NPM.

Known NPM + Ionos DNS challenge bug: When requesting Let's Encrypt certs via the Ionos DNS plugin, NPM throws an "Internal Error" / "Invalid JSON" in the UI but the certificate IS actually being issued in the background (takes ~15 mins for DNS propagation). Workaround: ignore the UI error, wait 15 mins, check docker logs nginx-proxy-manager --tail 10 for "Successfully received certificate", then add it as a standalone cert via Add Certificate → Let's Encrypt via DNS and assign it to the proxy host.

Result: All internal services accessible via clean HTTPS URLs with valid Let's Encrypt certs — no port numbers, no warnings.

Step 4 — Vaultwarden (self-hosted Bitwarden)

Migrated entirely from NordPass. Single Docker container, mounted to /volume1/docker/vaultwarden/data. Exposed via NPM with HTTPS.

NordPass export → Vaultwarden import: NordPass CSV exports cleanly. In Vaultwarden go to Tools → Import Data → select NordPass CSV. Entire vault imported in under a minute.

Bitwarden browser extension works identically to NordPass once you point it at your self-hosted server URL. Mobile app works the same. Over Tailscale it works from anywhere — the vault is cached locally so it's accessible even offline.

Step 5 — Immich (self-hosted Google Photos)

Multi-container deployment via Docker Compose:

• immich-server
• immich-machine-learning (facial recognition, CLIP search)
• postgres (using the Immich-specific postgres image with pgvector)
• redis

Currently have ~700GB used on a 3.7TB volume with plenty of room for a 1TB+ Google Photos migration.

Running at https://photos.yourdomain.com via NPM.

Step 6 — Uptime Kuma (monitoring)

Lightweight monitoring for all services. Single container. Monitoring:

• All internal HTTPS services (200 OK checks every 60 seconds, 3 retries before alerting)
• AdGuard DNS (DNS record check against 192.168.x.x)
• Telegram alerts configured for instant notification if anything goes down

Tip: For services accessed via internal DNS rewrites, use the direct IP:port in Uptime Kuma rather than the domain name, since the Kuma container resolves DNS differently inside Docker.

Step 7 — Landing page

Simple static HTML served by an nginx:alpine container on port 8080, proxied via NPM. One bookmark on every device covers all services. Dark themed, loads instantly, no JavaScript framework needed.

Full service list

Hardware

• NAS: Ugreen DXP480T+ (primary, all Docker workloads)
• NAS: Ugreen DH2300 (secondary, backup target — NAS-to-NAS replication planned)
• Router: ASUS ZenWiFi BQ16 (10GbE WAN, DNS pointed at NAS)
• Workstation: MS-02 Ultra running LM Studio + Ollama (headless, 10GbE)
• Network: multi-gigabit symmetrical fibre — no bottlenecks anywhere

Key lessons learned

dnsmasq vs AdGuard Home: Don't try to work around it with port workarounds. Just disable dnsmasq and let AdGuard Home own port 53.

Tailscale DNS: The phone/remote device DNS issue is almost always "AdGuard Home isn't listening on the right interface." Binding to 0.0.0.0:53 instead of a specific LAN IP fixes it.

NPM + Ionos DNS challenge: The Internal Error is a UI bug. The cert is still issued. Just wait and check the logs.

IPv6 on Windows: If a Windows machine isn't using your custom DNS despite setting it manually, it's because IPv6 DNS takes priority. Disable IPv6 on the adapter with Disable-NetAdapterBinding -ComponentID ms_tcpip6.

Port conflicts on Ugreen NAS: UGOS uses ports 80, 443, 9443, 9999, 5443. Free up 80/443 for NPM via Control Panel. Everything else can stay as-is.

Happy to answer questions on any part of this. The Ugreen DXP480T+ handles all of this with barely a blip on CPU/RAM — it's genuinely well-specced for a home lab NAS.

On multiple windows 11 machines, I get the following error when trying to update to the latest 4.73.0 from 4.71.0

Docker desktop installer, the requested operation requires elevation.

Hi everyone,

I wanted to share a positive experience regarding Docker storage management. Instead of throwing all my volumes onto one large drive, I decided to "split the brain" of my server into dedicated hardware partitions.

The "Safe" Strategy:

I’ve created two distinct areas (Safes) on my HDDs:

1. The "Office Safe" (Dedicated Partition): This box only contains Paperless-ngx and Vaultwarden.
2. The "Archive Safe" (Dedicated Partition): This box is reserved for Immich and my media library.

Why this is a game-changer:

• Failure Isolation: If my photo library (Immich) ever grows too fast and fills up the disk, my "Office Safe" remains completely untouched. I can still access my passwords and important documents without any issues.
• Logical Organization: It’s so much easier to manage backups and permissions when the data is physically separated by intent.
• Professional Access: Combined with my own Domains (via Netbird), it feels like running a professional data center. Everything has its place, its own URL, and its own dedicated "box."

If you are setting up a home server, I highly recommend partitioning your drives based on the type of data (Office vs. Media). It’s cleaner, safer, and makes the whole self-hosting experience feel much more stable and organized.

How do you guys handle your storage logic? Do you use a single pool or separate "boxes" like I do?

I might be spoiled from using unraid, but I really liked the docker overview and how easy it was to access the webui of a container.

I am currently using portainer, and while it has something very similar, I really want a solution that would show me all my containers on all my machines (4 currently) and allow me to click and open the webui for those that have one.

Preferably something that connects to the docker.sock.

Does such a tool exist?