Zammad 6.5 Puma server ignores puma.rb bind address, forcing 127.0.0.1

Technical assistance
1

Hello everyone,

I’m facing a strange issue with a Zammad 6.5 installation where the application’s Puma server seems to be ignoring all standard configuration files, causing API requests via a reverse proxy to fail. I’ve exhausted all standard troubleshooting and I’m hoping someone might have seen this behavior before.

System Environment:

  • Zammad Version: 6.5.0
  • Installation Source: Official package from packager.io (https://dl.packager.io/srv/deb/zammad/zammad/stable/ubuntu 24.04/main amd64 Packages)
  • Operating System: Ubuntu 24.04 (Noble)
  • Database: PostgreSQL

The Problem: My goal is to get metrics from the Zammad API using an external monitoring tool (Prometheus json_exporter).

  • A direct API call from within the server using curl http://localhost:3000/api/v1/... works perfectly and returns a 200 OK.
  • Any API request that comes through the Nginx reverse proxy fails with a 503 Service Unavailable error.
  • Running sudo ss -tlpn | grep ':3000' confirms that the Zammad/Puma process is only listening on 127.0.0.1:3000.

The root cause seems to be that the Puma process will not bind to 0.0.0.0, which is causing issues with how proxied requests are handled.

Troubleshooting Steps Performed:

  1. Edited /opt/zammad/config/puma.rb to explicitly include the line bind 'tcp://0.0.0.0:3000'. After a full restart of all Zammad services (sudo systemctl restart zammad*), the ss command still showed the process listening on 127.0.0.1. The configuration change was completely ignored.
  2. Tried setting environment variables by creating /etc/default/zammad and adding WEB_BIND_IP='0.0.0.0'. This was also ignored after a restart.
  3. Inspected the systemd service file. /etc/systemd/system/zammad-web-1.service is very simple and just calls ExecStart=/usr/bin/zammad run web, so the startup logic is inside that script.
  4. Checked trusted_proxies. The file /opt/zammad/config/environments/production.rb already trusts 127.0.0.1 by default, so this is not the issue.
  5. Performed a package reinstall. sudo apt-get install --reinstall zammad completed successfully but did not change the behavior.

It seems the Zammad startup script is forcing the bind address to 127.0.0.1 and overriding any standard configuration method.

My Question: Why would a standard Zammad 6.5 installation ignore its puma.rb configuration and persistently bind to 127.0.0.1? Is there a non-standard configuration file, an environment variable, or an override mechanism I am not aware of that controls the Puma bind address for package-based installations?

Thank you in advance for any help or insight you can provide.