Stuck on "Deploy Candidate" - Press v0.7.0 / Frappe v15 - No logs or errors

Hello Frappe Community,

I am seeking assistance with a persistent issue in Press where the “Deploy Candidate” process remains stuck in the “Deploy in progress” state indefinitely. There are no error logs generated in the Press UI, and the background workers appear to be running but are not picking up the tasks.

Environment Details

  • Main Press Server: Ubuntu 22.04 LTS (Contabo VPS)

  • Infrastructure: Multi-server setup (DB, Proxy, and App servers configured on Hetzner).

  • Frappe Framework: v15.91.3 (version-15)

  • Press App: v0.7.0 (develop)

What I Have Tried

I have attempted this setup across multiple environments to rule out OS-specific bugs, but I get stuck at the exact same point every time:

  1. Ubuntu 24.04 LTS with Press master branch.

  2. Ubuntu 20.04 LTS.

  3. Frappe v16-beta. In all scenarios, server connections (n1, m1, f1) are successful and green, but the deployment of the Frappe app never starts or finishes.

Troubleshooting Done So Far

  1. Worker Configuration: I realized the sync and default workers were missing from my supervisor setup. I have since updated my common_site_config.json to include them.

  2. Supervisor Status: All workers, including the sync-worker, are now reported as RUNNING by supervisorctl.

  3. Manual Execution: I have tried running bench restart and bench setup supervisor multiple times to ensure the processes are active.

  4. Connectivity: Verified passwordless SSH between the Press server and the Hetzner nodes.

Current common_site_config.json

JSON

{
 "background_workers": 1,
 "file_watcher_port": 6787,
 "frappe_user": "frappe",
 "gunicorn_workers": 9,
 "live_reload": true,
 "rebase_on_pull": false,
 "redis_cache": "redis://127.0.0.1:13000",
 "redis_queue": "redis://127.0.0.1:11000",
 "redis_socketio": "redis://127.0.0.1:13000",
 "restart_supervisor_on_update": true,
 "restart_systemd_on_update": false,
 "serve_default_site": true,
 "shallow_clone": true,
 "socketio_port": 9000,
 "use_redis_auth": false,
 "webserver_port": 8000,
 "workers": {
  "default": { "timeout": 360 },
  "short": { "timeout": 300 },
  "long": { "timeout": 1500 },
  "sync": { "timeout": 300 }
 }
}

The Issue

Despite the sync-worker being active, the “Deploy Candidate” job remains “Scheduled” or “In Progress” in the UI with zero logs in the “View Logs” section. I have checked logs/worker.sync.log but it doesn’t show any incoming jobs being processed.

Is there a specific environment variable or a press.yaml configuration that might be causing the Press agent to ignore the deployment tasks? Since there are no errors, I am finding it very difficult to pinpoint the bottleneck.

Any guidance from the team or anyone who has faced this on a multi-server Press setup would be greatly appreciated.

solved the issue?

@dake there should also be build worker configure

I have

Ubuntu 22.04 on Hetzner

Frappe Framework: v15.105.0 (HEAD)

Press: v0.7.0 (HEAD)

PYTHON_VERSION=“3.10”
NODE_VERSION=“22.14.0”

I was able to setup, proxy servrer, db server.

When the app server was setup the Ansible playbook ran successfully

but the Agent job Update Nginx Access becomes undelivered. This job is getting created as soon as a new f1 server is saved. immediately the job becomes undelivered which is rational with the below reason

HTTPSConnectionPool(host='f1.cloud.lmnaslens.com', port=443): Max retries exceeded with url: /agent//server/update-nginx-access (Caused by NewConnectionError("HTTPSConnection(host='f1.cloud.lmnaslens.com', port=443): Failed to establish a new connection: [Errno 111] Connection refused"))

and the dashboard of the server is still in status installing

One thing to note is currently press is upgrading at a greater pace. however there should be some correct versions of frappe, press, python, node and ubuntu if used can really make press workable.,

I have tired with few other version. but some or the other problem keep coming. Only someone who has done it in the past can help. otherwise it is a tedious task.

I experienced about the same issue before. You may want to check your traffic inboud rules. Protocol TCP port range 3306 (Type: MYSQL/Aurora) must be open (if I remember correctly, it is on the f1 node). After it is solved, the next challenge might be docker image upload.