Considering hardening the exposed containers

Author: drakarahCreated Feb 5, 2026Updated Aug 18, 2026

I'm running mailu-front with

    read_only: true
    tty: false
    stdin_open: false
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
        - NET_BIND_SERVICE # required for listening on ports
        - DAC_OVERRIDE
        - SETUID
        - SETGID
        - SYS_CHROOT
        - CHOWN # required for owning /var/lib stuff
        - KILL # required for dns-client and stuff

    volumes:
       # extra volumes required to work around the read only file system
      - "/data/mailu/nginx/config:/etc/nginx"
      - "/data/mailu/nginx/logs:/var/log/nginx"
      - "/data/mailu/dovecot/config:/etc/dovecot"
       
    tmpfs:
        - /run:exec,uid=1000,gid=1000
        - /var/lib/dovecot:noexec,uid=1000,gid=1000
        - /var/lib/nginx/tmp:noexec,uid=1000,gid=1000

    deploy:
        resources:
            limits:
                cpus: '0.50'
                memory: 250M
                pids: 64

This significantly reduces an attackers capabilities when the container is compromised by preventing writing files and executing them in most places, preventing spawning a shell, preventing resource starvation by enforcing limits and neuter most actions with dropping as many capabilities as possible.

Other containers might also be able to be hardened but it's always a pain to work around the zones that need to be writable with either a volume mount or a tmpfs, sometimes outright impossible, for example the webmail (roundcube) changes /etc/snuffleupagus.rules which would require making /etc a volume mount and that's impossible to do.

Source: Mailu/Mailu

View original on GitHub View discussion on GitHub