This seems pretty vanilla based on what other have suggested but I use regular markdown files in a git repo.

For data flows or diagrams, mermaidJS syntax within the markdown file works wonders and when I need to link one document to another or one section to another, you can use the normal link syntax of markdown.

Easy to use, hardly any setup and easily accessible.

Do you have other clients backing up to your unraid? I’m looking for a complete solution to backing up end user workstations (windows, Mac and Linux) to my unraid server then backing up my unraid server to something like wasabi, Amazon, backblaze, etc. Preferably a single solution.

I had this same problem but Pihole can act as your DHCP server too. I turned off DHCP on my ISP router, turned it on in Pihole and configured my range (with some buffer for static IPs for servers and others) and off it went. When all my clients (laptops, workstations, phones, etc.) requested an IP (which I saw them trickle in almost immediately), they got their IP from Pihole and also automatically directed all DNS queries to Pihole. No need for complicated setups.

Edit: fix typos.

Alright I’ll give it a try and see what happens. Thanks for your help!

The one time that it wasn’t …… DNS hahah

Yea I always try to dedicate networks to each app and if it’s a full stack app then one for front end (nginx and app) and another for backend (app and database).

I didn’t think about spinning up the alpine container to troubleshoot so that’s another great pointer for future soul crushing and head bashing sessions!

Great pointers! Some of them I had done and triple checked and other are great future troubleshooting points. There was no way I was going to put hours of troubleshooting and checking on a post so I tried to provide as much information as possible without putting up a giant wall of text.

Yea not sure why it didn’t just crash and hid behind all kinds of successful messages.

Fair enough! If I create a secondary config as you are suggesting, wouldn’t it create a conflict with the server blocks of default.conf? If I remember correctly, default.conf has a server listen 80 block going to localhost (which in my case wouldn’t be the correct path since the app is in another container) so wouldn’t nginx get confused because it doesn’t know which block to follow???

Or maybe I saw the block in default.conf but it was all commented it out out of the box. Idk I had to step away for a sec. As you can imagine I’ve been bashing my head for hours and it turned out to be some bs I should have probably read the entire log stream. So I’m pretty angry/decompressing at the moment.

1. 192.168.0.3 is the IP of the django app container (checked with docker inspect app | grep IP and docker logs nginx which shows blah blah upstream http://192.168.0.2:8020 blah blah)
2. I created a “frontend” network. This nginx and app container are both connected to this network but only nginx has the forwarding (0.0.0.0:80 and 0.0.0.0:443). The app container is set to EXPOSE 8020 in the Dockerfile and docker compose and the entrypoint.sh has this line after the usual django commands gunicorn app.wsgi:application --user www-data --bind 0.0.0.0:8020 --workers 3.

SOLVED… ALMOST THERE??? There were no signs (docker logs app) of an issue, until I scrolled all the way to the very top (way past all the successful migrations, tasks being run upon boot and successful messages). There was an uncaught exception to boot gunicorn workers because of middleware I had removed from my dependencies a few days ago. Searched through my code, removed any calls and settings for this middleware package. Redeployed the app and now I can hit the public page.

What now? So now that it looks like everything is working. What is the best practice for the nginx.conf? Leave it all in /etc/nginx/nginx.conf (with user as root), reestablish the out box nginx.conf and /etc/nginx/conf.d/default.conf and just override the default.conf or add a secondary config like /etc/nginx/conf.d/app.conf and leave default.conf as configured out of box? What is the best practice around this?