If I remember correctly setting APACHE_PORT env variable in the mastercontainer section in your compose file should be enough to expose apache port on the node IP, mastercontainer should handle the process. These are the defaults from their compose example.

services:
  nextcloud-aio-mastercontainer:
    environment:
      APACHE_PORT: 11000  

As you’ve noticed, forwarding things that way seems counterintuitive, because mastercontainer handles the managed containers and accepts limited config options as variables. Check the example compose file for common config options, like the upload limits. This is a major tradeoff of the AIO, by design, it is a standardised deployment, easy to troubleshoot and hadles a lot of things automatically, but it’s inflexible. Once you get it running though it rarely causes problems.

The cleanest way would be to do something described here, in the expanded section “On the same server in a Docker container”. I don’t know your docker setup though. You can however port forward the apache port and expose it on the machine IP, that way you can point the file config to the machine IP. This is the setup you would use if traefik was on a different machine than nextcloud (or any other service), but it will also work in your case. It has a big upside, if you decide to migrate your setup you can just spin up traefik on another machine and copy-paste the dynamic config file with minimal downtime (you would only need to adjust trusted proxy on the nextcloud side, if it’s in use).

I’ve used a AIO + traefik docker setup once, but I might be a little bit rusty, it’s been some time. Docs state that labels do not work with the AIO, due to the fact that mastercontainer manages the containers. With the AIO it is better to not get in the way of the mastercontainer - if any issues occur you have a non-standard deployment and need to consider that while troubleshooting. Not the most elegant solution, but you could run vanilla AIO with traefik external routing via exposed apache port on the node IP using the file provider. If you don’t have one you’ll need to adjust the traefik config file to include:

providers:
  file:
    filename: #dynamic config file path goes here, example: /etc/traefik/fileConfig.yml
    watch: true

Create such file and restart traefik container.

You can use this file to provide all sorts of configs, traefik constantly checks it and makes adjustments. Here’s an example:

http:
  ## EXTERNAL ROUTING ##
  routers:
    nextcloud:
      rule: "Host(`nextcloud.example.com`)"
      entrypoints:
        - "https"
      service: nextcloud
      middlewares:
      tls:
        certresolver: "letsencrypt"
  ## SERVICES ##
  services:
    nextcloud:
      loadBalancer:
        servers:
          - url: "http://IP:PORT of the apache container"

You may route internally if traefik runs on the host network. Check the link to the github documentation above for more info. Consider adjusting for a trusted proxy by limiting access to the apache container as described there.

Pretty much vanilla, only --xformers --medvram arguments and CPU seed. In that case, someone with more A1111 experience should weigh in, mine is limited, I mainly use comfy nowadays and probably am not up-to-date with development.

Regarding different outputs for the same seed: have You changed seed source to CPU in A1111? The noise You get that way is consistent across different hardware vendors and different from the GPU-sourced one.

I have used A1111 just now to check and got very simmilar results to ComfyUI that way.

General advice would be to look boring and hide your IP as much as you are able (get a domain). As long as you’re not looking juicy you won’t attract skilled attention. It’s like locking a bike, most bad actors will just pass by looking around for one without a lock or a real fancy one worth their resources.

You can utilize Cloudflare’s free offerings, starting with simple stuff. Their DNS Proxy is essentialy a single-click but will help substantially. You can build on top of that with simple WAF rules, such as droping connection attempts from IPs originating from countries notorious for “poking around”. You can also reverse that rule and whitlelist only your country.

Keep your firewall tight, don’t expose other ports, put your services behind a reverse proxy and redirect everything to HTTPS. Start simple, constantly improve, learn more advanced methods/concepts.

I usually recommend this one. There’s a section for NPM you’ll find useful.

I know of a project that may match your description: https://github.com/azukaar/Cosmos-Server

I remember seeing it some time ago in a self-hosted community, but don’t remember on which platform.