[GH-ISSUE #1834] SMTP environment variables from .env file are ignored by the application process in Docker environment

kerem commented

2026-02-26 18:47:27 +03:00

Owner

Originally created by @limson8 on GitHub (Jun 11, 2025).
Original GitHub issue: https://github.com/documenso/documenso/issues/1834

Issue Description

When deploying Documenso v1.11.1 using the official Docker Compose method, the application completely ignores all SMTP_* environment variables set in the .env file. Although the configuration is correct and the variables are successfully loaded into the container's environment, the application still attempts to connect to a hardcoded or incorrect default address (127.0.0.1:2500) when trying to send an email (e.g., for a password reset). This results in an EBADNAME error, rendering the email functionality completely broken.

Steps to Reproduce

Set up a standard Linux (x86_64) server.

Use the official docker-compose.yml and .env files for deployment.

In docker-compose.yml, specify the image as documenso/documenso:v1.11.1.

In the .env file, correctly and completely configure all SMTP_* variables (e.g., using Google SMTP settings).

Start the services using sudo docker compose up -d. The services run, and user login works correctly.

Verify the environment variables inside the container by running sudo docker compose exec app printenv | grep SMTP. This command confirms that all SMTP_* variables and their values have been successfully loaded into the container's shell environment.

Trigger an email-sending action from the application's frontend (e.g., "Forgot Password").

Check the application logs using sudo docker compose logs -f app.

Expected Behavior

The application should read the SMTP_HOST (smtp.gmail.com), SMTP_PORT (587), and other related variables from the environment and attempt to connect to the configured mail server.

Current Behavior

The application log shows an attempt to connect to an invalid hostname 127.0.0.1:2500, which immediately fails with the error Error: queryA EBADNAME 127.0.0.1:2500. This proves that the Node.js process is not utilizing the environment variables that are present in its runtime environment.

Log Snippet:

app-1  | Error: queryA EBADNAME 127.0.0.1:2500
app-1  |   at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:45:19)
app-1  |   at QueryReqWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
app-1  |   errno: undefined,
app-1  |   code: 'EDNS',
app-1  |   syscall: 'queryA',
app-1  |   hostname: '127.0.0.1:2500',
app-1  |   command: 'CONN'
app-1  | }

Additional context:
Extensive troubleshooting has been performed to rule out configuration errors:

The docker-compose.yml was simplified to rely only on env_file to eliminate any variable override conflicts.

The .env file was recreated from scratch to rule out any hidden formatting issues (like CRLF vs LF).

Database connectivity and user authentication (with a manually created user) are working correctly.

The issue seems to be isolated to how the application process itself consumes the environment variables specifically for the SMTP feature.

Screenshots (optional)

No response

Operating System [e.g., Windows 10]

Linux (Ubuntu/Debian)

Browser [e.g., Chrome, Firefox]

Chrome

Version [e.g., 2.0.1]

documenso/documenso:v1.11.1

Please check the boxes that apply to this issue report.

I have searched the existing issues to make sure this is not a duplicate.
I have provided steps to reproduce the issue.
I have included relevant environment information.
I have included any relevant screenshots.
I understand that this is a voluntary contribution and that there is no guarantee of resolution.
I want to work on creating a PR for this issue if approved

Originally created by @limson8 on GitHub (Jun 11, 2025). Original GitHub issue: https://github.com/documenso/documenso/issues/1834 ### Issue Description When deploying Documenso v1.11.1 using the official Docker Compose method, the application completely ignores all SMTP_* environment variables set in the .env file. Although the configuration is correct and the variables are successfully loaded into the container's environment, the application still attempts to connect to a hardcoded or incorrect default address (127.0.0.1:2500) when trying to send an email (e.g., for a password reset). This results in an EBADNAME error, rendering the email functionality completely broken. ### Steps to Reproduce Set up a standard Linux (x86_64) server. Use the official docker-compose.yml and .env files for deployment. In docker-compose.yml, specify the image as documenso/documenso:v1.11.1. In the .env file, correctly and completely configure all SMTP_* variables (e.g., using Google SMTP settings). Start the services using sudo docker compose up -d. The services run, and user login works correctly. Verify the environment variables inside the container by running sudo docker compose exec app printenv | grep SMTP. This command confirms that all SMTP_* variables and their values have been successfully loaded into the container's shell environment. Trigger an email-sending action from the application's frontend (e.g., "Forgot Password"). Check the application logs using sudo docker compose logs -f app. ### Expected Behavior The application should read the SMTP_HOST (smtp.gmail.com), SMTP_PORT (587), and other related variables from the environment and attempt to connect to the configured mail server. ### Current Behavior The application log shows an attempt to connect to an invalid hostname 127.0.0.1:2500, which immediately fails with the error Error: queryA EBADNAME 127.0.0.1:2500. This proves that the Node.js process is not utilizing the environment variables that are present in its runtime environment. Log Snippet: ``` app-1 | Error: queryA EBADNAME 127.0.0.1:2500 app-1 | at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:45:19) app-1 | at QueryReqWrap.callbackTrampoline (node:internal/async_hooks:130:17) { app-1 | errno: undefined, app-1 | code: 'EDNS', app-1 | syscall: 'queryA', app-1 | hostname: '127.0.0.1:2500', app-1 | command: 'CONN' app-1 | } ``` **Additional context:** Extensive troubleshooting has been performed to rule out configuration errors: The docker-compose.yml was simplified to rely only on env_file to eliminate any variable override conflicts. The .env file was recreated from scratch to rule out any hidden formatting issues (like CRLF vs LF). Database connectivity and user authentication (with a manually created user) are working correctly. The issue seems to be isolated to how the application process itself consumes the environment variables specifically for the SMTP feature. ### Screenshots (optional) _No response_ ### Operating System [e.g., Windows 10] Linux (Ubuntu/Debian) ### Browser [e.g., Chrome, Firefox] Chrome ### Version [e.g., 2.0.1] documenso/documenso:v1.11.1 ### Please check the boxes that apply to this issue report. - [x] I have searched the existing issues to make sure this is not a duplicate. - [x] I have provided steps to reproduce the issue. - [x] I have included relevant environment information. - [ ] I have included any relevant screenshots. - [x] I understand that this is a voluntary contribution and that there is no guarantee of resolution. - [ ] I want to work on creating a PR for this issue if approved

kerem added the

Stale

status: triage

labels

2026-02-26 18:47:27 +03:00

kerem commented

2026-02-26 18:47:27 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jun 14, 2025):

Can you share your compose and .env?

@Dvalin21 commented on GitHub (Jun 14, 2025): Can you share your compose and .env?

kerem commented

2026-02-26 18:47:27 +03:00

Author

Owner

@limson8 commented on GitHub (Jun 14, 2025):

Thanks for the response

Compose

services:
db:
image: postgres:16-alpine
restart: always
environment:
POSTGRES_USER: ${POSTGRES_USER}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: ${POSTGRES_DB}
volumes:
- db-data:/var/lib/postgresql/data

app:
image: documenso/documenso:v1.11.1
restart: always
ports:
- "3000:3000"
env_file:
- .env

depends_on:
- db
volumes:
- ./uploads:/app/uploads

volumes:
db-data:

.env

# --- Database Config ---
DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public"
POSTGRES_USER=my_db_user
POSTGRES_PASSWORD=[REDACTED]
POSTGRES_DB=my_db_name
POSTGRES_HOST=db

# --- Application URLs ---
NEXT_PUBLIC_WEBAPP_URL=https://subdomain.your-domain.com/
NEXTAUTH_URL=https://subdomain.your-domain.com/
NEXT_PRIVATE_INTERNAL_WEBAPP_URL=http://app:3000/

# --- SMTP Config ---
SMTP_HOST=[smtp.gmail.com](http://smtp.gmail.com/)
SMTP_PORT=587
SMTP_USER=[user@your-domain.com](mailto:user@your-domain.com)
SMTP_PASSWORD=[REDACTED]
SMTP_FROM=[noreply@your-domain.com](mailto:noreply@your-domain.com)

# --- JWT Secrets ---
JWT_SECRET=[REDACTED]
REFRESH_JWT_SECRET=[REDACTED]

# --- Initial Admin User ---
ROOT_USER_EMAIL=[admin-email@example.com](mailto:admin-email@example.com)
ROOT_USER_PASSWORD=[REDACTED]

# --- Prisma DB URLs ---
NEXT_PRIVATE_DIRECT_DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public"
NEXT_PRIVATE_DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public"

# --- NextAuth Secret ---
NEXTAUTH_SECRET=[REDACTED]

@limson8 commented on GitHub (Jun 14, 2025): Thanks for the response **Compose** ``` services: db: image: postgres:16-alpine restart: always environment: POSTGRES_USER: ${POSTGRES_USER} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} POSTGRES_DB: ${POSTGRES_DB} volumes: - db-data:/var/lib/postgresql/data app: image: documenso/documenso:v1.11.1 restart: always ports: - "3000:3000" env_file: - .env depends_on: - db volumes: - ./uploads:/app/uploads volumes: db-data: ``` **.env** ``` # --- Database Config --- DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public" POSTGRES_USER=my_db_user POSTGRES_PASSWORD=[REDACTED] POSTGRES_DB=my_db_name POSTGRES_HOST=db # --- Application URLs --- NEXT_PUBLIC_WEBAPP_URL=https://subdomain.your-domain.com/ NEXTAUTH_URL=https://subdomain.your-domain.com/ NEXT_PRIVATE_INTERNAL_WEBAPP_URL=http://app:3000/ # --- SMTP Config --- SMTP_HOST=[smtp.gmail.com](http://smtp.gmail.com/) SMTP_PORT=587 SMTP_USER=[user@your-domain.com](mailto:user@your-domain.com) SMTP_PASSWORD=[REDACTED] SMTP_FROM=[noreply@your-domain.com](mailto:noreply@your-domain.com) # --- JWT Secrets --- JWT_SECRET=[REDACTED] REFRESH_JWT_SECRET=[REDACTED] # --- Initial Admin User --- ROOT_USER_EMAIL=[admin-email@example.com](mailto:admin-email@example.com) ROOT_USER_PASSWORD=[REDACTED] # --- Prisma DB URLs --- NEXT_PRIVATE_DIRECT_DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public" NEXT_PRIVATE_DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public" # --- NextAuth Secret --- NEXTAUTH_SECRET=[REDACTED] ```

kerem commented

2026-02-26 18:47:27 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jun 14, 2025):

Add the following

NEXT_PRIVATE_SMTP_SECURE="false"
# OPTIONAL: if this is true and NEXT_PRIVATE_SMTP_SECURE is false then TLS is not used even if the server supports STARTTLS extension
NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS="false"

This should make it work for the 587 port. Let me know if it doesnt

@Dvalin21 commented on GitHub (Jun 14, 2025): Add the following ``` NEXT_PRIVATE_SMTP_SECURE="false" # OPTIONAL: if this is true and NEXT_PRIVATE_SMTP_SECURE is false then TLS is not used even if the server supports STARTTLS extension NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS="false" ``` This should make it work for the 587 port. Let me know if it doesnt

kerem commented

2026-02-26 18:47:27 +03:00

Author

Owner

@limson8 commented on GitHub (Jun 14, 2025):

I have updated my .env file to include the NEXT_PRIVATE_SMTP_SECURE and NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS variables. I then completely rebuilt the environment using docker compose down && docker compose up -d to ensure all changes were applied.

The issue persists with the exact same error log. The application is still trying to connect to 127.0.0.1:2500.

To be sure this wasn't a configuration loading issue, I performed two final checks:

Verified the .env file was loaded correctly into the container's environment. The output of sudo docker compose exec app printenv | grep SMTP confirms all SMTP variables are correctly set inside the container:

SMTP_HOST=smtp.gmail.com
SMTP_FROM=noreply@your-domain.com
SMTP_PORT=587
SMTP_USER=user@your-domain.com
SMTP_PASSWORD=[REDACTED]
NEXT_PRIVATE_SMTP_SECURE="false"
NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS="false"

Triggered the "Forgot Password" function again. The application log still produces the following error, proving it is not using the environment variables available to it:

app-1  | Error: queryA EBADNAME 127.0.0.1:2500
app-1  |   at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:45:19)
app-1  |   ...
app-1  |   hostname: '127.0.0.1:2500',
app-1  |   command: 'CONN'
app-1  | }

@limson8 commented on GitHub (Jun 14, 2025): I have updated my .env file to include the NEXT_PRIVATE_SMTP_SECURE and NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS variables. I then completely rebuilt the environment using docker compose down && docker compose up -d to ensure all changes were applied. The issue persists with the exact same error log. The application is still trying to connect to 127.0.0.1:2500. To be sure this wasn't a configuration loading issue, I performed two final checks: Verified the .env file was loaded correctly into the container's environment. The output of sudo docker compose exec app printenv | grep SMTP confirms all SMTP variables are correctly set inside the container: ``` SMTP_HOST=smtp.gmail.com SMTP_FROM=noreply@your-domain.com SMTP_PORT=587 SMTP_USER=user@your-domain.com SMTP_PASSWORD=[REDACTED] NEXT_PRIVATE_SMTP_SECURE="false" NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS="false" ``` Triggered the "Forgot Password" function again. The application log still produces the following error, proving it is not using the environment variables available to it: ``` app-1 | Error: queryA EBADNAME 127.0.0.1:2500 app-1 | at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:45:19) app-1 | ... app-1 | hostname: '127.0.0.1:2500', app-1 | command: 'CONN' app-1 | } ```

kerem commented

2026-02-26 18:47:27 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jun 14, 2025):

I have updated my .env file to include the NEXT_PRIVATE_SMTP_SECURE and NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS variables. I then completely rebuilt the environment using docker compose down && docker compose up -d to ensure all changes were applied.

The issue persists with the exact same error log. The application is still trying to connect to 127.0.0.1:2500.

To be sure this wasn't a configuration loading issue, I performed two final checks:

Verified the .env file was loaded correctly into the container's environment. The output of sudo docker compose exec app printenv | grep SMTP confirms all SMTP variables are correctly set inside the container:
SMTP_HOST=smtp.gmail.com
SMTP_FROM=noreply@your-domain.com
SMTP_PORT=587
SMTP_USER=user@your-domain.com
SMTP_PASSWORD=[REDACTED]
NEXT_PRIVATE_SMTP_SECURE="false"
NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS="false"
Triggered the "Forgot Password" function again. The application log still produces the following error, proving it is not using the environment variables available to it:
app-1  | Error: queryA EBADNAME 127.0.0.1:2500
app-1  |   at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:45:19)
app-1  |   ...
app-1  |   hostname: '127.0.0.1:2500',
app-1  |   command: 'CONN'
app-1  | }

You need to also set

NEXT_PRIVATE_SMTP_TRANSPORT="smtp-auth"
I've never seen anyone having the "[]" or "()". I'm wondering if this is adding to the issue?

@Dvalin21 commented on GitHub (Jun 14, 2025): > I have updated my .env file to include the NEXT_PRIVATE_SMTP_SECURE and NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS variables. I then completely rebuilt the environment using docker compose down && docker compose up -d to ensure all changes were applied. > > The issue persists with the exact same error log. The application is still trying to connect to 127.0.0.1:2500. > > To be sure this wasn't a configuration loading issue, I performed two final checks: > > Verified the .env file was loaded correctly into the container's environment. The output of sudo docker compose exec app printenv | grep SMTP confirms all SMTP variables are correctly set inside the container: > > ``` > SMTP_HOST=smtp.gmail.com > SMTP_FROM=noreply@your-domain.com > SMTP_PORT=587 > SMTP_USER=user@your-domain.com > SMTP_PASSWORD=[REDACTED] > NEXT_PRIVATE_SMTP_SECURE="false" > NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS="false" > ``` > > Triggered the "Forgot Password" function again. The application log still produces the following error, proving it is not using the environment variables available to it: > > ``` > app-1 | Error: queryA EBADNAME 127.0.0.1:2500 > app-1 | at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:45:19) > app-1 | ... > app-1 | hostname: '127.0.0.1:2500', > app-1 | command: 'CONN' > app-1 | } > ``` You need to also set NEXT_PRIVATE_SMTP_TRANSPORT="smtp-auth" I've never seen anyone having the "[]" or "()". I'm wondering if this is adding to the issue?

kerem commented

2026-02-26 18:47:27 +03:00

Author

Owner

@limson8 commented on GitHub (Jun 14, 2025):

still not working....same log
and sry for the confuse, i was using [REDACTED] as a placeholder to hide my passwords

heres my updated .env

DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public"
POSTGRES_USER=my_db_user
POSTGRES_PASSWORD=[REDACTED]
POSTGRES_DB=my_db_name
POSTGRES_HOST=db
NEXT_PUBLIC_WEBAPP_URL=https://subdomain.your-domain.com
NEXTAUTH_URL=https://subdomain.your-domain.com
NEXT_PRIVATE_INTERNAL_WEBAPP_URL=http://app:3000
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USER=user@your-domain.com
SMTP_PASSWORD=[REDACTED]
SMTP_FROM=noreply@your-domain.com
NEXT_PRIVATE_SMTP_TRANSPORT="smtp-auth"
NEXT_PRIVATE_SMTP_SECURE="false"
NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS="false"
JWT_SECRET=[REDACTED]
REFRESH_JWT_SECRET=[REDACTED]
ROOT_USER_EMAIL=admin-email@example.com
ROOT_USER_PASSWORD=[REDACTED]
NEXT_PRIVATE_DIRECT_DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public"
NEXT_PRIVATE_DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public"
NEXTAUTH_SECRET=[REDACTED]

@limson8 commented on GitHub (Jun 14, 2025): still not working....same log and sry for the confuse, i was using `[REDACTED]` as a placeholder to hide my passwords heres my updated .env ``` DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public" POSTGRES_USER=my_db_user POSTGRES_PASSWORD=[REDACTED] POSTGRES_DB=my_db_name POSTGRES_HOST=db NEXT_PUBLIC_WEBAPP_URL=https://subdomain.your-domain.com NEXTAUTH_URL=https://subdomain.your-domain.com NEXT_PRIVATE_INTERNAL_WEBAPP_URL=http://app:3000 SMTP_HOST=smtp.gmail.com SMTP_PORT=587 SMTP_USER=user@your-domain.com SMTP_PASSWORD=[REDACTED] SMTP_FROM=noreply@your-domain.com NEXT_PRIVATE_SMTP_TRANSPORT="smtp-auth" NEXT_PRIVATE_SMTP_SECURE="false" NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS="false" JWT_SECRET=[REDACTED] REFRESH_JWT_SECRET=[REDACTED] ROOT_USER_EMAIL=admin-email@example.com ROOT_USER_PASSWORD=[REDACTED] NEXT_PRIVATE_DIRECT_DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public" NEXT_PRIVATE_DATABASE_URL="postgresql://my_db_user:[REDACTED]@db:5432/my_db_name?schema=public" NEXTAUTH_SECRET=[REDACTED] ```

kerem commented

2026-02-26 18:47:27 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jun 15, 2025):

How do you jave it setup? Do you have it setup local only? Do you jave it behind reverse proxy?

On Jun 14, 2025 at 5:57 AM, Jiayang @.***> wrote:

limson8 left a comment (documenso/documenso#1834)

I have updated my .env file to include the NEXT_PRIVATE_SMTP_SECURE and NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS variables. I then completely rebuilt the environment using docker compose down && docker compose up -d to ensure all changes were applied.

The issue persists with the exact same error log. The application is still trying to connect to 127.0.0.1:2500.

To be sure this wasn't a configuration loading issue, I performed two final checks:

Verified the .env file was loaded correctly into the container's environment. The output of sudo docker compose exec app printenv | grep SMTP confirms all SMTP variables are correctly set inside the container:

SMTP_HOST=smtp.gmail.com @.*** SMTP_PORT=587 @.*** SMTP_PASSWORD=[REDACTED] NEXT_PRIVATE_SMTP_SECURE="false" NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS="false"

Triggered the "Forgot Password" function again. The application log still produces the following error, proving it is not using the environment variables available to it:

app-1 | Error: queryA EBADNAME 127.0.0.1:2500 app-1 | at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:45:19) app-1 | ... app-1 | hostname: '127.0.0.1:2500', app-1 | command: 'CONN' app-1 | }

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

@Dvalin21 commented on GitHub (Jun 15, 2025): How do you jave it setup? Do you have it setup local only? Do you jave it behind reverse proxy? > > On Jun 14, 2025 at 5:57 AM, Jiayang ***@***.***> wrote: > > > limson8 left a comment (documenso/documenso#1834) > > > I have updated my .env file to include the NEXT_PRIVATE_SMTP_SECURE and NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS variables. I then completely rebuilt the environment using docker compose down && docker compose up -d to ensure all changes were applied. > > > > The issue persists with the exact same error log. The application is still trying to connect to 127.0.0.1:2500. > > > > To be sure this wasn't a configuration loading issue, I performed two final checks: > > > > Verified the .env file was loaded correctly into the container's environment. The output of sudo docker compose exec app printenv | grep SMTP confirms all SMTP variables are correctly set inside the container: > > > SMTP_HOST=smtp.gmail.com ***@***.*** SMTP_PORT=587 ***@***.*** SMTP_PASSWORD=[REDACTED] NEXT_PRIVATE_SMTP_SECURE="false" NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS="false" > > > Triggered the "Forgot Password" function again. The application log still produces the following error, proving it is not using the environment variables available to it: > > > app-1 | Error: queryA EBADNAME 127.0.0.1:2500 app-1 | at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:45:19) app-1 | ... app-1 | hostname: '127.0.0.1:2500', app-1 | command: 'CONN' app-1 | } > > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you commented.Message ID: ***@***.***> > >

kerem commented

2026-02-26 18:47:27 +03:00

Author

Owner

@limson8 commented on GitHub (Jun 15, 2025):

I am running it on a remote Ubuntu 22.04 server using Docker Compose. The stack consists of two containers: documenso/documenso:v1.11.1 for the application and postgres:16-alpine for the database.
This is not a local-only setup. It is deployed on a live server.
And it is running behind an Nginx reverse proxy. The Nginx instance handles SSL termination for my public domain and forwards all traffic to the Documenso app container on port 3000.

Let me know if you need any other information. Thanks!

@limson8 commented on GitHub (Jun 15, 2025): I am running it on a remote Ubuntu 22.04 server using Docker Compose. The stack consists of two containers: documenso/documenso:v1.11.1 for the application and postgres:16-alpine for the database. This is not a local-only setup. It is deployed on a live server. And it is running behind an Nginx reverse proxy. The Nginx instance handles SSL termination for my public domain and forwards all traffic to the Documenso app container on port 3000. Let me know if you need any other information. Thanks!

kerem commented

2026-02-26 18:47:27 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jun 15, 2025):

What does your host and hostname files have in them?

On Jun 15, 2025 at 2:32 AM, Jiayang @.***> wrote:

limson8 left a comment (documenso/documenso#1834)

I am running it on a remote Ubuntu 22.04 server using Docker Compose. The stack consists of two containers: documenso/documenso:v1.11.1 for the application and postgres:16-alpine for the database.
This is not a local-only setup. It is deployed on a live server.
And it is running behind an Nginx reverse proxy. The Nginx instance handles SSL termination for my public domain and forwards all traffic to the Documenso app container on port 3000.

Let me know if you need any other information. Thanks!

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

@Dvalin21 commented on GitHub (Jun 15, 2025): What does your host and hostname files have in them? > > On Jun 15, 2025 at 2:32 AM, Jiayang ***@***.***> wrote: > > > limson8 left a comment (documenso/documenso#1834) > > > I am running it on a remote Ubuntu 22.04 server using Docker Compose. The stack consists of two containers: documenso/documenso:v1.11.1 for the application and postgres:16-alpine for the database. > This is not a local-only setup. It is deployed on a live server. > And it is running behind an Nginx reverse proxy. The Nginx instance handles SSL termination for my public domain and forwards all traffic to the Documenso app container on port 3000. > > > > Let me know if you need any other information. Thanks! > > > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you commented.Message ID: ***@***.***> > >

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@limson8 commented on GitHub (Jun 16, 2025):

/etc/hostname

mycompany-server

/etc/hosts

# Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
#     /etc/cloud/cloud.cfg or cloud-config from user-data
#
127.0.1.1 mycompany-server mycompany-server
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

@limson8 commented on GitHub (Jun 16, 2025): /etc/hostname `mycompany-server` /etc/hosts ``` # Your system has configured 'manage_etc_hosts' as True. # As a result, if you wish for changes to this file to persist # then you will need to either # a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl # b.) change or remove the value of 'manage_etc_hosts' in # /etc/cloud/cloud.cfg or cloud-config from user-data # 127.0.1.1 mycompany-server mycompany-server 127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters ```

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jun 16, 2025):

/etc/hostname

mycompany-server

/etc/hosts

# Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
#     /etc/cloud/cloud.cfg or cloud-config from user-data
#
127.0.1.1 mycompany-server mycompany-server
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

I don't know what your company server requirements are, but I noticed your still using 127.0.1.1. I have mine set up as
Example:
127.0.0.1 localhost mycompany-server

WARNING!!!
I am not a server export or admin.
Pretty sure you will know more than me. But it was just a thought.

@Dvalin21 commented on GitHub (Jun 16, 2025): > /etc/hostname > > `mycompany-server` > > /etc/hosts > > ``` > # Your system has configured 'manage_etc_hosts' as True. > # As a result, if you wish for changes to this file to persist > # then you will need to either > # a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl > # b.) change or remove the value of 'manage_etc_hosts' in > # /etc/cloud/cloud.cfg or cloud-config from user-data > # > 127.0.1.1 mycompany-server mycompany-server > 127.0.0.1 localhost > > # The following lines are desirable for IPv6 capable hosts > ::1 localhost ip6-localhost ip6-loopback > ff02::1 ip6-allnodes > ff02::2 ip6-allrouters > ``` I don't know what your company server requirements are, but I noticed your still using 127.0.1.1. I have mine set up as Example: 127.0.0.1 localhost mycompany-server WARNING!!! I am not a server export or admin. Pretty sure you will know more than me. But it was just a thought.

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@limson8 commented on GitHub (Jun 19, 2025):

Hi, thank you for the suggestion.

Although my original /etc/hosts file has a standard Ubuntu cloud-init configuration, I have followed your advice to rule out any possibilities.

I have now modified my /etc/cloud/templates/hosts.debian.tmpl file and rebooted the server. My /etc/hosts file now looks like this:

127.0.0.1 localhost mycompany-server
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

After rebuilding the containers with docker compose down && docker compose up -d, I triggered the "Forgot Password" function again. Unfortunately, the result is still the same. The application log still shows the Error: queryA EBADNAME 127.0.0.1:2500 error.

This confirms the issue is not related to the server's local hostname resolution. The application is still not consuming the SMTP environment variables.

@limson8 commented on GitHub (Jun 19, 2025): Hi, thank you for the suggestion. Although my original /etc/hosts file has a standard Ubuntu cloud-init configuration, I have followed your advice to rule out any possibilities. I have now modified my /etc/cloud/templates/hosts.debian.tmpl file and rebooted the server. My /etc/hosts file now looks like this: ``` 127.0.0.1 localhost mycompany-server # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters ``` After rebuilding the containers with docker compose down && docker compose up -d, I triggered the "Forgot Password" function again. Unfortunately, the result is still the same. The application log still shows the Error: queryA EBADNAME 127.0.0.1:2500 error. This confirms the issue is not related to the server's local hostname resolution. The application is still not consuming the SMTP environment variables.

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jun 21, 2025):

Hi, thank you for the suggestion.

Although my original /etc/hosts file has a standard Ubuntu cloud-init configuration, I have followed your advice to rule out any possibilities.

I have now modified my /etc/cloud/templates/hosts.debian.tmpl file and rebooted the server. My /etc/hosts file now looks like this:
127.0.0.1 localhost mycompany-server
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
After rebuilding the containers with docker compose down && docker compose up -d, I triggered the "Forgot Password" function again. Unfortunately, the result is still the same. The application log still shows the Error: queryA EBADNAME 127.0.0.1:2500 error.

This confirms the issue is not related to the server's local hostname resolution. The application is still not consuming the SMTP environment variables.

Sorry for the late response. I have you figured out the issue on this? Also, can you check what is listening on port 2500?

@Dvalin21 commented on GitHub (Jun 21, 2025): > Hi, thank you for the suggestion. > > Although my original /etc/hosts file has a standard Ubuntu cloud-init configuration, I have followed your advice to rule out any possibilities. > > I have now modified my /etc/cloud/templates/hosts.debian.tmpl file and rebooted the server. My /etc/hosts file now looks like this: > > ``` > 127.0.0.1 localhost mycompany-server > # The following lines are desirable for IPv6 capable hosts > ::1 localhost ip6-localhost ip6-loopback > ff02::1 ip6-allnodes > ff02::2 ip6-allrouters > ``` > > After rebuilding the containers with docker compose down && docker compose up -d, I triggered the "Forgot Password" function again. Unfortunately, the result is still the same. The application log still shows the Error: queryA EBADNAME 127.0.0.1:2500 error. > > This confirms the issue is not related to the server's local hostname resolution. The application is still not consuming the SMTP environment variables. Sorry for the late response. I have you figured out the issue on this? Also, can you check what is listening on port 2500?

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@limson8 commented on GitHub (Jun 24, 2025):

Hi, thanks for getting back to me.

No, the issue is still unresolved. The application log continues to show the Error: queryA EBADNAME 127.0.0.1:2500 when I trigger an email action.

As you requested, I checked to see if any service is listening on port 2500, returned nothing, which confirms that nothing is listening on that port.

Here is the command and its empty output:

$ sudo ss -tulpn | grep :2500
$

This seems to reinforce the conclusion that the application is attempting to connect to a hardcoded, non-existent endpoint, rather than being influenced by a local service or a misconfiguration. The problem appears to be internal to the application's handling of SMTP configuration.

@limson8 commented on GitHub (Jun 24, 2025): Hi, thanks for getting back to me. No, the issue is still unresolved. The application log continues to show the Error: queryA EBADNAME 127.0.0.1:2500 when I trigger an email action. As you requested, I checked to see if any service is listening on port 2500, returned nothing, which confirms that nothing is listening on that port. Here is the command and its empty output: ``` $ sudo ss -tulpn | grep :2500 $ ``` This seems to reinforce the conclusion that the application is attempting to connect to a hardcoded, non-existent endpoint, rather than being influenced by a local service or a misconfiguration. The problem appears to be internal to the application's handling of SMTP configuration.

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jun 25, 2025):

Hi, thanks for getting back to me.

No, the issue is still unresolved. The application log continues to show the Error: queryA EBADNAME 127.0.0.1:2500 when I trigger an email action.

As you requested, I checked to see if any service is listening on port 2500, returned nothing, which confirms that nothing is listening on that port.

Here is the command and its empty output:
$ sudo ss -tulpn | grep :2500
$
This seems to reinforce the conclusion that the application is attempting to connect to a hardcoded, non-existent endpoint, rather than being influenced by a local service or a misconfiguration. The problem appears to be internal to the application's handling of SMTP configuration.

Yeah, I'm not sure whats going on here. I've never had that issue before. Last resort, remove containers AND images and re-pull? Otherwise I'm out of ideas.

@Dvalin21 commented on GitHub (Jun 25, 2025): > Hi, thanks for getting back to me. > > No, the issue is still unresolved. The application log continues to show the Error: queryA EBADNAME 127.0.0.1:2500 when I trigger an email action. > > As you requested, I checked to see if any service is listening on port 2500, returned nothing, which confirms that nothing is listening on that port. > > Here is the command and its empty output: > > ``` > $ sudo ss -tulpn | grep :2500 > $ > ``` > > This seems to reinforce the conclusion that the application is attempting to connect to a hardcoded, non-existent endpoint, rather than being influenced by a local service or a misconfiguration. The problem appears to be internal to the application's handling of SMTP configuration. Yeah, I'm not sure whats going on here. I've never had that issue before. Last resort, remove containers AND images and re-pull? Otherwise I'm out of ideas.

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@ephraimduncan commented on GitHub (Jun 25, 2025):

Hi @limson8 sorry for the delay, looks like you have the wrong SMTP environmental variables.

Can you use these instead?

NEXT_PRIVATE_SMTP_TRANSPORT=smtp-auth
NEXT_PRIVATE_SMTP_HOST=smtp.gmail.com
NEXT_PRIVATE_SMTP_PORT=587
NEXT_PRIVATE_SMTP_USERNAME=user@your-domain.com
NEXT_PRIVATE_SMTP_PASSWORD=your-app-password
NEXT_PRIVATE_SMTP_FROM_ADDRESS=noreply@your-domain.com
NEXT_PRIVATE_SMTP_FROM_NAME=Your App Name
NEXT_PRIVATE_SMTP_SECURE=true
NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS=false

Since NEXT_PRIVATE_SMTP_HOST is undefined (because you set SMTP_HOST instead), the code falls back to the default hardcoded value 127.0.0.1:2500 here

github.com/documenso/documenso@bb9ba80edb/packages/email/mailer.ts (L93)

@ephraimduncan commented on GitHub (Jun 25, 2025): Hi @limson8 sorry for the delay, looks like you have the wrong SMTP environmental variables. Can you use these instead? ```ts NEXT_PRIVATE_SMTP_TRANSPORT=smtp-auth NEXT_PRIVATE_SMTP_HOST=smtp.gmail.com NEXT_PRIVATE_SMTP_PORT=587 NEXT_PRIVATE_SMTP_USERNAME=user@your-domain.com NEXT_PRIVATE_SMTP_PASSWORD=your-app-password NEXT_PRIVATE_SMTP_FROM_ADDRESS=noreply@your-domain.com NEXT_PRIVATE_SMTP_FROM_NAME=Your App Name NEXT_PRIVATE_SMTP_SECURE=true NEXT_PRIVATE_SMTP_UNSAFE_IGNORE_TLS=false ``` Since `NEXT_PRIVATE_SMTP_HOST` is undefined (because you set SMTP_HOST instead), the code falls back to the default hardcoded value `127.0.0.1:2500` here https://github.com/documenso/documenso/blob/bb9ba80edb2c1faad01e8509063c5887b8605460/packages/email/mailer.ts#L93

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@limson8 commented on GitHub (Jun 26, 2025):

@ephraimduncan

Hi, thank you for the detailed information and your continued support.

I have an important update. I have now completely replaced my old SMTP variables with the new NEXT_PRIVATE_SMTP_* variables you provided, including NEXT_PRIVATE_SMTP_TRANSPORT. After rebuilding the containers, the original Error: queryA EBADNAME 127.0.0.1:2500 is now gone! This confirms the variable names were the primary issue.

However, I am now facing a new problem. When I trigger the "Forgot Password" function, the page hangs, and the application log shows a new error: Error: Connection timeout.

Here is the new log snippet:

app-1  | Error: Connection timeout
app-1  |     at SMTPConnection._formatError (/app/node_modules/nodemailer/lib/smtp-connection/index.js:809:19)
app-1  |     at SMTPConnection._onError (/app/node_modules/nodemailer/lib/smtp-connection/index.js:795:20)
app-1  |     at Timeout.<anonymous> (/app/node_modules/nodemailer/lib/smtp-connection/index.js:237:22)
app-1  |     at listOnTimeout (node:internal/timers:588:17)
app-1  |     at process.processTimers (node:internal/timers:523:7) {
app-1  |   code: 'ETIMEDOUT',
app-1  |   command: 'CONN'
app-1  | }

It seems the application is now correctly trying to connect to smtp.gmail.com but is unable to get a response. Given this new ETIMEDOUT error, are there any other application-level settings or known issues that could be causing this?

Thanks again for your help.

@limson8 commented on GitHub (Jun 26, 2025): @ephraimduncan Hi, thank you for the detailed information and your continued support. I have an important update. I have now completely replaced my old SMTP variables with the new NEXT_PRIVATE_SMTP_* variables you provided, including NEXT_PRIVATE_SMTP_TRANSPORT. After rebuilding the containers, the original Error: queryA EBADNAME 127.0.0.1:2500 is now gone! This confirms the variable names were the primary issue. However, I am now facing a new problem. When I trigger the "Forgot Password" function, the page hangs, and the application log shows a new error: Error: Connection timeout. Here is the new log snippet: ``` app-1 | Error: Connection timeout app-1 | at SMTPConnection._formatError (/app/node_modules/nodemailer/lib/smtp-connection/index.js:809:19) app-1 | at SMTPConnection._onError (/app/node_modules/nodemailer/lib/smtp-connection/index.js:795:20) app-1 | at Timeout.<anonymous> (/app/node_modules/nodemailer/lib/smtp-connection/index.js:237:22) app-1 | at listOnTimeout (node:internal/timers:588:17) app-1 | at process.processTimers (node:internal/timers:523:7) { app-1 | code: 'ETIMEDOUT', app-1 | command: 'CONN' app-1 | } ``` It seems the application is now correctly trying to connect to smtp.gmail.com but is unable to get a response. Given this new ETIMEDOUT error, are there any other application-level settings or known issues that could be causing this? Thanks again for your help.

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@limson8 commented on GitHub (Jun 26, 2025):

@Dvalin21
I've done that multiple times and the result is exactly the same.
Thank you very much for your assistance. Although the issue hasn't been fully resolved yet, I truly appreciate the time and effort you've put into helping me！

@limson8 commented on GitHub (Jun 26, 2025): @Dvalin21 I've done that multiple times and the result is exactly the same. Thank you very much for your assistance. Although the issue hasn't been fully resolved yet, I truly appreciate the time and effort you've put into helping me！

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jun 26, 2025):

@Dvalin21 I've done that multiple times and the result is exactly the same. Thank you very much for your assistance. Although the issue hasn't been fully resolved yet, I truly appreciate the time and effort you've put into helping me！

Thanks, I appreciate that, but @ephraimduncan right now is the real hero. He got us to a different error at least. Ill ook more at it in the morning

@Dvalin21 commented on GitHub (Jun 26, 2025): > [@Dvalin21](https://github.com/Dvalin21) I've done that multiple times and the result is exactly the same. Thank you very much for your assistance. Although the issue hasn't been fully resolved yet, I truly appreciate the time and effort you've put into helping me！ Thanks, I appreciate that, but @ephraimduncan right now is the real hero. He got us to a different error at least. Ill ook more at it in the morning

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@limson8 commented on GitHub (Jun 26, 2025):

update

After working with my cloud provider (DigitalOcean) to ensure port 2525 was unblocked, I have now performed a definitive independent test.

The issue is 100% confirmed to be a bug within the Documenso Docker container.

Here is the proof:

1. Successful Test from the Host Server:

I installed a command-line mailer (swaks) on the host server itself and ran a test using the exact same SendGrid credentials and port from my .env file. The email was sent and received successfully. This proves that the server's network, the firewall rules, and the SendGrid credentials are all working perfectly.

Here is the successful command:

$ swaks --to my-email@example.com \
--from "noreply@my-domain.com" \
--server smtp.sendgrid.net:2525 \
--auth-user "apikey" \
--auth-password "SG.xxx...xxx" 

-> 250 OK

2. Failure from the Documenso Container:

Immediately after the successful test above, I triggered the "Forgot Password" function in the Documenso application again. The application log still shows the same Error: Connection timeout.

app-1  | Error: Connection timeout
app-1  |   code: 'ETIMEDOUT',
app-1  |   command: 'CONN'
app-1  | }

Conclusion:

This demonstrates definitively that the host machine can establish a connection, but the application process inside the Docker container cannot. The problem lies somewhere within the container's networking stack or the application's mailer implementation.

I have exhausted

@limson8 commented on GitHub (Jun 26, 2025): update After working with my cloud provider (DigitalOcean) to ensure port 2525 was unblocked, I have now performed a definitive independent test. **The issue is 100% confirmed to be a bug within the Documenso Docker container.** Here is the proof: **1. Successful Test from the Host Server:** I installed a command-line mailer (`swaks`) on the host server itself and ran a test using the exact same SendGrid credentials and port from my `.env` file. **The email was sent and received successfully.** This proves that the server's network, the firewall rules, and the SendGrid credentials are all working perfectly. Here is the successful command: ``` $ swaks --to my-email@example.com \ --from "noreply@my-domain.com" \ --server smtp.sendgrid.net:2525 \ --auth-user "apikey" \ --auth-password "SG.xxx...xxx" -> 250 OK ``` **2. Failure from the Documenso Container:** Immediately after the successful test above, I triggered the "Forgot Password" function in the Documenso application again. The application log still shows the same Error: Connection timeout. ``` app-1 | Error: Connection timeout app-1 | code: 'ETIMEDOUT', app-1 | command: 'CONN' app-1 | } ``` Conclusion: This demonstrates definitively that the host machine can establish a connection, but the application process inside the Docker container cannot. The problem lies somewhere within the container's networking stack or the application's mailer implementation. I have exhausted

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jun 26, 2025):

So glad you were able to come to a conclusion. I hope now the devs will
research and get this fix!

On Thu, Jun 26, 2025 at 8:16 AM Jiayang @.***> wrote:

limson8 left a comment (documenso/documenso#1834)
https://github.com/documenso/documenso/issues/1834#issuecomment-3008463753

update

After working with my cloud provider (DigitalOcean) to ensure port 2525
was unblocked, I have now performed a definitive independent test.

The issue is 100% confirmed to be a bug within the Documenso Docker
container.

Here is the proof:

1. Successful Test from the Host Server:

I installed a command-line mailer (swaks) on the host server itself and
ran a test using the exact same SendGrid credentials and port from my .env
file. The email was sent and received successfully. This proves that
the server's network, the firewall rules, and the SendGrid credentials are
all working perfectly.

Here is the successful command:

$ swaks --to @.***
--from @.***"
--server smtp.sendgrid.net:2525
--auth-user "apikey"
--auth-password "SG.xxx...xxx"

-> 250 OK

2. Failure from the Documenso Container:

Immediately after the successful test above, I triggered the "Forgot
Password" function in the Documenso application again. The application log
still shows the same Error: Connection timeout.

app-1 | Error: Connection timeout
app-1 | code: 'ETIMEDOUT',
app-1 | command: 'CONN'
app-1 | }

Conclusion:

This demonstrates definitively that the host machine can establish a
connection, but the application process inside the Docker container cannot.
The problem lies somewhere within the container's networking stack or the
application's mailer implementation.

I have exhausted

—
Reply to this email directly, view it on GitHub
https://github.com/documenso/documenso/issues/1834#issuecomment-3008463753,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABY7PVIQXFT3APXZX5RET333FPXDLAVCNFSM6AAAAAB7CN5Q2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMBYGQ3DGNZVGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

@Dvalin21 commented on GitHub (Jun 26, 2025): So glad you were able to come to a conclusion. I hope now the devs will research and get this fix! On Thu, Jun 26, 2025 at 8:16 AM Jiayang ***@***.***> wrote: > *limson8* left a comment (documenso/documenso#1834) > <https://github.com/documenso/documenso/issues/1834#issuecomment-3008463753> > > update > > After working with my cloud provider (DigitalOcean) to ensure port 2525 > was unblocked, I have now performed a definitive independent test. > > *The issue is 100% confirmed to be a bug within the Documenso Docker > container.* > > Here is the proof: > > *1. Successful Test from the Host Server:* > > I installed a command-line mailer (swaks) on the host server itself and > ran a test using the exact same SendGrid credentials and port from my .env > file. *The email was sent and received successfully.* This proves that > the server's network, the firewall rules, and the SendGrid credentials are > all working perfectly. > > Here is the successful command: > > $ swaks --to ***@***.*** \ > --from ***@***.***" \ > --server smtp.sendgrid.net:2525 \ > --auth-user "apikey" \ > --auth-password "SG.xxx...xxx" > > -> 250 OK > > *2. Failure from the Documenso Container:* > > Immediately after the successful test above, I triggered the "Forgot > Password" function in the Documenso application again. The application log > still shows the same Error: Connection timeout. > > app-1 | Error: Connection timeout > app-1 | code: 'ETIMEDOUT', > app-1 | command: 'CONN' > app-1 | } > > > Conclusion: > > This demonstrates definitively that the host machine can establish a > connection, but the application process inside the Docker container cannot. > The problem lies somewhere within the container's networking stack or the > application's mailer implementation. > > I have exhausted > > — > Reply to this email directly, view it on GitHub > <https://github.com/documenso/documenso/issues/1834#issuecomment-3008463753>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABY7PVIQXFT3APXZX5RET333FPXDLAVCNFSM6AAAAAB7CN5Q2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMBYGQ3DGNZVGM> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@mngsgoncalves commented on GitHub (Jul 1, 2025):

I'm being affected by this as well.

@mngsgoncalves commented on GitHub (Jul 1, 2025): I'm being affected by this as well.

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jul 1, 2025):

Thats crazy, I didn't have that issue!! But I host my own email server, so maybe thats the only difference

@Dvalin21 commented on GitHub (Jul 1, 2025): Thats crazy, I didn't have that issue!! But I host my own email server, so maybe thats the only difference

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@cch1985 commented on GitHub (Jul 17, 2025):

ive been ripping my hair out trying to figure this out. same issue exactly, and was able to test the API, and the SMTP from my host server and everything works, except getting a relaying denied 550 5.7.1 mailgun error when trying to push it through Documenso.

@cch1985 commented on GitHub (Jul 17, 2025): ive been ripping my hair out trying to figure this out. same issue exactly, and was able to test the API, and the SMTP from my host server and everything works, except getting a relaying denied 550 5.7.1 mailgun error when trying to push it through Documenso.

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@Dvalin21 commented on GitHub (Jul 17, 2025):

ive been ripping my hair out trying to figure this out. same issue exactly, and was able to test the API, and the SMTP from my host server and everything works, except getting a relaying denied 550 5.7.1 mailgun error when trying to push it through Documenso.

Apparently there are something that are buggy. This has been an issue for a year and more

@Dvalin21 commented on GitHub (Jul 17, 2025): > ive been ripping my hair out trying to figure this out. same issue exactly, and was able to test the API, and the SMTP from my host server and everything works, except getting a relaying denied 550 5.7.1 mailgun error when trying to push it through Documenso. Apparently there are something that are buggy. This has been an issue for a year and more

kerem commented

2026-02-26 18:47:28 +03:00

Author

Owner

@meetjeremy commented on GitHub (Jul 25, 2025):

I'm running via docker compose and mailgun is working for me.
these are my .env settings..
I think you need to give NEXT_PRIVATE_ prefix
NEXT_PRIVATE_SMTP_TRANSPORT="smtp-auth"
NEXT_PRIVATE_SMTP_HOST="smtp.mailgun.org"
NEXT_PRIVATE_SMTP_PORT=587
NEXT_PRIVATE_SMTP_USERNAME="mailgun verified email" # mailgun domain email.. mg.domain.xyz
NEXT_PRIVATE_SMTP_PASSWORD="password"

@meetjeremy commented on GitHub (Jul 25, 2025): I'm running via docker compose and mailgun is working for me. these are my .env settings.. I think you need to give NEXT_PRIVATE_ prefix NEXT_PRIVATE_SMTP_TRANSPORT="smtp-auth" NEXT_PRIVATE_SMTP_HOST="smtp.mailgun.org" NEXT_PRIVATE_SMTP_PORT=587 NEXT_PRIVATE_SMTP_USERNAME="mailgun verified email" # mailgun domain email.. mg.domain.xyz NEXT_PRIVATE_SMTP_PASSWORD="password"

Rows
Columns

[GH-ISSUE #1834] SMTP environment variables from .env file are ignored by the application process in Docker environment #531

Issue Description

Steps to Reproduce

Expected Behavior

Current Behavior

Screenshots (optional)

Operating System [e.g., Windows 10]

Browser [e.g., Chrome, Firefox]

Version [e.g., 2.0.1]

Please check the boxes that apply to this issue report.