I have modified the examples to include mime-types from Nginx to the web container, and removed the "workaround" from the nginx.conf file to keep it as consistent as possible with the official Nextcloud docs.

IMHO it's bad to duplicate all default mime.types just to modify a single line. Just adding

types {
    text/javascript mjs;
}

should be enough.

Over the years we have several instances running using MariaDB and experience shows that 10.8.2 works better than 10.6 with recent versions of Nextcloud.

We use whatever Nextcloud recommends in their documenation. We also don't pin minor releases because then somebody would need to take care of updates.

All docker-compose.yml files are renamed to compose.yaml files as per docker requirements.

Fine for me but I'm not sure how used people are to docker-compose.yml and if we should stick with it for a while or if this would be more confusing for those still using docker-compose.

Redis

Initially it wasn't added everywhere because it's optional and to keep the examples simple. But technically a database server is also optional.

Logging

Logging is out of scope for the examples. We shouldn't make any assumptions about their logging system.

I have modified the examples to include mime-types from Nginx to the web container, and removed the "workaround" from the nginx.conf file to keep it as consistent as possible with the official Nextcloud docs.

IMHO it's bad to duplicate all default mime.types just to modify a single line. Just adding

types {
    text/javascript mjs;
}

should be enough.

You are quite correct here, this is the most "clean" way of doing it. Instead of adding js and mjs, only mjs is added. Thanks !

Over the years we have several instances running using MariaDB and experience shows that 10.8.2 works better than 10.6 with recent versions of Nextcloud.

We use whatever Nextcloud recommends in their documenation. We also don't pin minor releases because then somebody would need to take care of updates.

I thought so, reverted back to 10.6 as per docs.

All docker-compose.yml files are renamed to compose.yaml files as per docker requirements.

Fine for me but I'm not sure how used people are to docker-compose.yml and if we should stick with it for a while or if this would be more confusing for those still using docker-compose.

Docker put the notice of deprecation of V1 syntax quite a long time ago. As per docker docs and requirements, it must be named compose.yaml or compose.yml and this should have been done long ago. docker-compose.yml is the old V1 syntax and it can create more confusion if people update their docker / docker compose plugin.

More info here and here

Redis

Initially it wasn't added everywhere because it's optional and to keep the examples simple. But technically a database server is also optional.

Logging

Logging is out of scope for the examples. We shouldn't make any assumptions about their logging system.

Removed the logging sections too. While I agree with the fact we should not make assumptions, and people using these should take care of that, I think we might mention this problems with the logs somewhere. On a busy instances with more than few users these logs can get quite large and actually cause problems. Nginx and LE compaion tend to output a lot of stuff, most of the time harmless, but they can pile up if all goes well for longer time periods.

Also fixed the random typos here and there, didn't noticed them the last 3 times I've read the changes.

EDIT: I removed the conf volume. It's also based on some assumptions that shouldn't be assumed. It is usually helpful if someone is injecting additional stuff in the proxy, but in a general-use-case where the proxy is used only for NC, that volume is not needed.

I thought so, reverted back to 10.6 as per docs.

Removed the logging sections too.

Needs to be reverted in the README too

I still have the mjs problem and spent 4 hours yesterday (just to say I'm not just lazily expecting help) to see how modifying nginx.conf might help with the well known error message about the mjs mime type. No success. I only mount the nginx.conf specifically in the container from outside, not the mime.types.

I'm working off of this one with the fpm alpine docker compose:

.examples/docker-compose/with-nginx-proxy/mariadb/fpm/web/nginx.conf

Some of the posts I read through suggest it has something to do with DNS / domain entries, but a curl to an mjs file from inside the container yields results, so it doesn't seem it's a URL issue.

I still have the mjs problem and spent 4 hours yesterday (just to say I'm not just lazily expecting help) to see how modifying nginx.conf might help with the well known error message about the mjs mime type. No success. I only mount the nginx.conf specifically in the container from outside, not the mime.types.

I'm working off of this one with the fpm alpine docker compose:

.examples/docker-compose/with-nginx-proxy/mariadb/fpm/web/nginx.conf

Some of the posts I read through suggest it has something to do with DNS / domain entries, but a curl to an mjs file from inside the container yields results, so it doesn't seem it's a URL issue.
Hi,

Use the nginx.conf from this commit, it works fine without the need of mounting the mime-types file. ->> 05353cf

I thought so, reverted back to 10.6 as per docs.

Removed the logging sections too.

Needs to be reverted in the README too

Reverted the README me, my bad. Also removed the GH-specific markdown. Fixed the little ":" too.