starred/documenso

Fork 0

mirror of https://github.com/documenso/documenso.git synced 2026-04-26 06:15:58 +03:00

[GH-ISSUE #1289] No Signing emails send because docker container doesn't reach NEXT_PUBLIC_WEBAPP_URL #362

New issue

Closed

opened 2026-02-26 18:46:41 +03:00 by kerem · 4 comments

kerem commented

2026-02-26 18:46:41 +03:00

Owner

Originally created by @david-loe on GitHub (Aug 15, 2024).
Original GitHub issue: https://github.com/documenso/documenso/issues/1289

Issue Description

Since signing emails are send via backgroud jobs, no signing emails are send any more.
Using resend works, because this is no background job.

Figured out that my container doesn't reach NEXT_PUBLIC_WEBAPP_URL. But no Error is thrown...

Steps to Reproduce

Setup production documenso by docker compose
Add document
-> no email send and no error thrown

Expected Behavior

Email send or at least an error

Current Behavior

no email, no error

Screenshots (optional)

No response

Operating System [e.g., Windows 10]

Docker

Browser [e.g., Chrome, Firefox]

No response

Version [e.g., 2.0.1]

1.6.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 @david-loe on GitHub (Aug 15, 2024). Original GitHub issue: https://github.com/documenso/documenso/issues/1289 ### Issue Description Since signing emails are send via backgroud jobs, no signing emails are send any more. _Using resend works, because this is no background job._ Figured out that my container doesn't reach NEXT_PUBLIC_WEBAPP_URL. But no Error is thrown... ### Steps to Reproduce 1. Setup production documenso by docker compose 2. Add document -> no email send and no error thrown ### Expected Behavior Email send or at least an error ### Current Behavior no email, no error ### Screenshots (optional) _No response_ ### Operating System [e.g., Windows 10] Docker ### Browser [e.g., Chrome, Firefox] _No response_ ### Version [e.g., 2.0.1] 1.6.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. - [X] I have included any relevant screenshots. - [X] I understand that this is a voluntary contribution and that there is no guarantee of resolution. - [X] I want to work on creating a PR for this issue if approved

kerem

2026-02-26 18:46:41 +03:00

closed this issue
added the
status: triage
label

kerem commented

2026-02-26 18:46:41 +03:00

Author

Owner

@david-loe commented on GitHub (Aug 15, 2024):

#1258 maybe related 🤷‍♂️

@david-loe commented on GitHub (Aug 15, 2024): #1258 maybe related 🤷‍♂️

kerem commented

2026-02-26 18:46:41 +03:00

Author

Owner

@david-loe commented on GitHub (Aug 15, 2024):

My Container sits behind a apache reverse proxy, and querying the NEXT_PUBLIC_WEBAPP_URL results in a loopback-problem (Hairpin NAT).
Possible Solution would be to introduce a new ENV variable like NEXT_PRIVATE_INTERNAL_WEBAPP_URL which is the same as NEXT_PUBLIC_WEBAPP_URL by default. This url will than be used every time the container wonts to make request to itself.

@david-loe commented on GitHub (Aug 15, 2024): My Container sits behind a apache reverse proxy, and querying the `NEXT_PUBLIC_WEBAPP_URL` results in a loopback-problem (Hairpin NAT). Possible Solution would be to introduce a new ENV variable like `NEXT_PRIVATE_INTERNAL_WEBAPP_URL` which is the same as `NEXT_PUBLIC_WEBAPP_URL` by default. This url will than be used every time the container wonts to make request to itself.

kerem commented

2026-02-26 18:46:41 +03:00

Author

Owner

@apsinghdev commented on GitHub (Aug 16, 2024):

@david-loe I faced the same issue. To fix that I had to run npm run dx:up along with other commands of manual setup.

@apsinghdev commented on GitHub (Aug 16, 2024): @david-loe I faced the same issue. To fix that I had to run `npm run dx:up` along with other commands of manual setup.

kerem commented

2026-02-26 18:46:41 +03:00

Author

Owner

@RobertPosluszny commented on GitHub (Aug 21, 2024):

Confirming we are having the issue as well with Nginx proxy manager. With NEXT_PUBLIC_WEBAPP_URL set to our public URL, we are unable to send signup emails. With NEXT_PUBLIC_WEBAPP_URL set to the internal "http://localhost:3000" address it will send properly but then users are unable to confirm their email because the verify email URL is set to localhost and not the public URL.

@RobertPosluszny commented on GitHub (Aug 21, 2024): Confirming we are having the issue as well with Nginx proxy manager. With NEXT_PUBLIC_WEBAPP_URL set to our public URL, we are unable to send signup emails. With NEXT_PUBLIC_WEBAPP_URL set to the internal "http://localhost:3000" address it will send properly but then users are unable to confirm their email because the verify email URL is set to localhost and not the public URL.

kerem referenced this issue

2026-02-26 19:31:00 +03:00

[PR #362] [MERGED] fix: hide popover when user selects a recipient #911

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/documenso#362

No description provided.

Rows
Columns