plugin_daemon kept crash-restart looping

[roykteo]

Versions

1. dify-1.14.0

Describe the bug
The plugin_daemon is stuck in a crash-restart loop (kept trying to start and failing)
The error confirms: it's still looking for db_postgres which doesn't exist
This loop is slowing down everything else, which is why Dify is taking forever to load

To Reproduce
Steps to reproduce the behavior:

1. Just download from this GitHub (for self-hosting): https://github.com/langgenius/dify/releases
2. Followed the instructions for this Self-Hosting Documentation: https://docs.dify.ai/getting-started/install-self-hosted
3. Under Access, I entered this on Google Chrome browser: http://localhost/install
4. Noticed the loading was taking to long, went to Docker to take a look at the container status
5. Went to docker to check, noticed the plugin_daemon keep crash-restart looping.

Expected behavior
The Dify should have load on the browser, and I would be able to set up an account.

Screenshots

I'm not sure if the screenshot works, but here's the error message.

failed to initialize database, got error failed to connect to host=db_postgres user=postgres database=postgres: hostname resolving error (lookup db_postgres on 127.0.0.11:53: no such host)
ERROR failed to init dify plugin db error="failed to connect to host=db_postgres user=postgres database=postgres: hostname resolving error (lookup db_postgres on 127.0.0.11:53: no such host)"
panic: failed to init dify plugin db

Additional context
I'm new here, so I do apologize if this is a newbie mistake.

[dosubot]

Hi @roykteo! I'm Dosu and I’m helping the dify-plugin-daemon team.

This looks like a Docker networking/configuration issue. The plugin_daemon service is trying to connect to a database host called db_postgres, but that hostname isn't resolving in your Docker network.

In the dify-plugin-daemon, the database host is configured via the DB_HOST environment variable [1]. The hostname db_postgres is likely set in the .env file or docker-compose.yaml that ships with the main dify repository.

A few things to check:

1. Ensure the PostgreSQL container is running — look in Docker Desktop for a container whose service name matches db_postgres (or db). If it's not running or failed to start, the plugin_daemon can't resolve that hostname.

2. Check your .env file — in the dify/docker directory, open the .env file and look for DB_HOST. Make sure its value matches the actual service name of your PostgreSQL container as defined in docker-compose.yaml.

3. Make sure all containers are on the same Docker network — if you started services separately or modified the compose file, containers may not share a network. Run docker compose up -d from the docker/ directory to bring everything up together.

4. Try a clean start — sometimes stale state causes issues:

   cd docker
   docker compose down
   docker compose up -d

This is a common setup hiccup and not a bug in the plugin daemon itself — it just needs its database to be reachable at the configured hostname.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[roykteo]

Am I supposed to have 2 containers running? Or should I only have 1 container running? If it is only 1 container, should I rename that container?

[dosubot]

In the standard Dify self-hosted setup (from the main dify repository's docker/ folder), you should have multiple containers running — including a PostgreSQL database container and the plugin_daemon container (among others like api, web, redis, etc.). They are separate services that communicate over Docker's internal network.

You don't need to rename anything. The issue is that the plugin_daemon container is configured to look for a database host called db_postgres, but that hostname needs to match the service name of your PostgreSQL container as defined in the docker-compose.yaml.

If you're using the standard Dify docker-compose setup, the database container's service name should already match what's set in the .env file. The most likely cause is that the PostgreSQL container hasn't started (or failed to start), so the hostname can't be resolved.

Run docker compose ps from your docker/ directory and check whether the database container is up and healthy. If it's not running, that's why plugin_daemon can't connect.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[roykteo]

I run docker compose ps, everything seems to be running except for the plugin_daemon

[roykteo]

What about this error from worker_beat?

Database migration failed: (psycopg2.OperationalError) could not translate host name "db_postgres" to address: Name or service not known

[fatelei]

root@688fbea46a77:/app# getent hosts db_postgres

do dns resolve

[fatelei]

bash -c 'cat < /dev/tcp/db_postgres/5432' 2>&1
echo $?

[Markzhangeth]

Hello, I see you're working on the Dify workflow project. We have a multi-model API transfer service compatible with OpenAI formats, supporting models like GPT, Claude, Gemini, and Kimi, suitable for developers to quickly integrate and reduce the cost of maintaining multiple models. If your project has API call requirements, I can give you some test credits to try it out. One-stop shop for large model APIs: https://xtokens.shop