Self-Hosted docker connectivity issues

[SapnaL]

Hi team,

I have a self-hosted installation of Langfuse v3 running via Docker. I’ve configured it to use AWS S3 for blob storage instead of MinIO; clickhouse and redis are part of the architecture. The trace, observations are visible in Languse web UI. However we see postgres errors - "cannot connect to postgres db host" and we see user 'unauthorized' error because it cannot read from postgres and ultimately logs the user out from the Langfuse UI.

There are no apparent port conflicts; the necessary ports are open and mapped correctly in Docker.

Has anyone encountered similar issues, or are there any recommended troubleshooting steps for this scenario? Are there any additional network or Docker settings I should check to ensure postgres connectivity?
postgres is forwarded to port 5435 from default 5432

the error is
"Can't reach database server at dhost:5435
Please make sure your database server is running at dhost:5435.
2025-08-21T16:52:23.643Z info   middleware intercepted error with code UNAUTHORIZED UNAUTHORIZED
TRPCError: UNAUTHORIZED
...
2025-08-21T16:52:23.644Z info   tRPC route failed on users.metrics: UNAUTHORIZED UNAUTHORIZED
TRPCError: UNAUTHORIZED"

Thanks in advance for your help!

[inkeep-ai-assistant[bot]]

For remote users to access your self-hosted Langfuse v3 instance running via Docker, you should check the following:

• Ensure the Docker host's firewall/security group allows inbound connections on the mapped port (typically 3000 for the web UI) from remote IPs, not just local or internal addresses(1).
• Confirm that the Docker container is started with the correct port mapping (e.g., -p 3000:3000) and that your host's public IP or DNS is used by remote users to connect(1).
• If you are behind NAT or a cloud provider (AWS EC2, etc.), verify that the public IP is associated with the host, and the security group/network ACL rules allow external access on the required ports(1).
• Only the langfuse-web container and, if used, MinIO need to be accessible externally; other containers can remain internal(1).
• Adding a firewall rule or security group that restricts incoming traffic to the required ports is recommended, but ensure those ports are open to the remote users’ IP ranges(1).

You can follow more detailed instructions at Docker Compose (self-hosted) - Langfuse.

📚 Sources:

1. Docker Compose (self-hosted) - Langfuse

---

Have another question? Just tag @inkeep.

[Steffen911]

@SapnaL Can you confirm that you're running Postgres via Docker Compose? Or are you using a managed instance? If it's the latter, how did you configure it?

[SapnaL]

We have a self-hosted postgres docker container that is used as a bypass to postgres db hosted on dbhost on port 5435, the default port 5432 is forwarded to 5435. We are unable to connect to the database server at dbhost:5435. This is causing the Prisma client to fail when trying to execute prisma.user.findUnique(), which in turn is resulting in a NextAuth JWT session error. Running a - nc -zv dbhost 5435 connects to the host. This happens sporadically,

Actual error

"[next-auth][error][JWT_SESSION_ERROR]
https://next-auth.js.org/errors#jwt_session_error
Invalid prisma.user.findUnique() invocation:

Can't reach database server at dbhost:5435

Please make sure your database server is running at dbhost:5435. {
message: '\n' +
'Invalid prisma.user.findUnique() invocation:\n' +
'\n' +
'\n' +
"Can't reach database server at dbhost:5435\n" +
'\n' +
'Please make sure your database server is running at dbhost:5435.',
stack: 'PrismaClientKnownRequestError: \n' +
'Invalid prisma.user.findUnique() invocation:\n' +
'\n' +
'\n' +
"Can't reach database server at dbhost:5435\n" +
'\n' +
'Please make sure your database server is running at dbhost:5435.\n' +
' at Zn.handleRequestError (/app/node_modules/.pnpm/@prisma+client@6.10.1_prisma@6.10.1_typescript@5.4.5__typescript@5.4.5/node_modules/@prisma/client/runtime/library.js:121:7459)\n' +
' at Zn.handleAndLogRequestError (/app/node_modules/.pnpm/@prisma+client@6.10.1_prisma@6.10.1_typescript@5.4.5__typescript@5.4.5/node_modules/@prisma/client/runtime/library.js:121:6784)\n' +
' at Zn.request (/app/node_modules/.pnpm/@prisma+client@6.10.1_prisma@6.10.1_typescript@5.4.5__typescript@5.4.5/node_modules/@prisma/client/runtime/library.js:121:6491)\n' +
' at async l (/app/node_modules/.pnpm/@prisma+client@6.10.1_prisma@6.10.1_typescript@5.4.5__typescript@5.4.5/node_modules/@prisma/client/runtime/library.js:130:9778)\n' +
' at async /app/web/.next/server/chunks/1463.js:1:15071\n' +
' at async /app/web/.next/server/chunks/899.js:1:98720\n' +
' at async Object.session (/app/node_modules/.pnpm/next-auth@4.24.11_patch_hash=cctoclu_next@14.2.30_@babel+core@7.24.3_@open_f7pfok74kjcrp7lsswmltvtxxu/node_modules/next-auth/core/routes/session.js:52:30)\n' +
' at async AuthHandler (/app/node_modules/.pnpm/next-auth@4.24.11_patch_hash=cctoclu_next@14.2.30_@babel+core@7.24.3_@open_f7pfok74kjcrp7lsswmltvtxxu/node_modules/next-auth/core/index.js:136:27)\n' +
' at async NextAuthApiHandler (/app/node_modules/.pnpm/next-auth@4.24.11_patch_hash=cctoclu_next@14.2.30_@babel+core@7.24.3_@open_f7pfok74kjcrp7lsswmltvtxxu/node_modules/next-auth/next/index.js:18:19)\n' +
' at async p (/app/web/.next/server/pages/api/auth/[...nextauth].js:1:5724)',
name: 'PrismaClientKnownRequestError'
}"

[Steffen911]

@SapnaL Where are you running the nc experiments? On the host or within the Langfuse container?

It could be that they are not on the same docker network which will make it impossible for the Langfuse container to connect using the internal DNS names.

[SapnaL]

the nc was run on host that has the docker containers. so is the recommendation that we have the postgres db within the docker itself and not to a postgres db hosted on a separate host?

[Steffen911]

@SapnaL No, but it is important that the Langfuse container can reach the database. Can you exec into the container and confirm whether this is the case?

[SapnaL]

Sorry for the delay in the response but yes always been able to get to Postgres db when I exec

docker exec -it langfusecontainer1 psql -U user123 -d p_analytics results in

psql (17.5 (Debian 17.5-1.pgdg120+1))
Type "help" for help.

P_analytics=#

[Steffen911]

@SapnaL Can you check the database whether the tables got created by Langfuse? And are there any special characters in the username or password?

[SapnaL]

Yes the tables did get created here with the migration sql, and we are storing data for prompts , member information in there …there is an @ symbol in the password,but it seems the connection timeout is sporadic

[Steffen911]

@SapnaL Can you try to change the password to only contain letters and numbers and check if that makes a difference?

[SapnaL]

Unfortunately this is enterprise db and I can easily change the password

[Steffen911]

It may work if you URL encode the password instead.

[SapnaL]

Ok let me try that

[SapnaL]

So made the change and monitored and it’s same issue we can connect but the connection times out intermittently, it’s the sporadic nature of the connection that we are having trouble with.

[Steffen911]

@SapnaL In that case it is most likely something within your infrastructure setup where we cannot really support due to the limited insights and control. I would recommend to use a managed postgres service instead as those are usually more reliable.