[GH-ISSUE #1343] Background Job stuck at pending

kerem commented

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

Owner

Originally created by @zxtanzxzx on GitHub (Sep 11, 2024).
Original GitHub issue: https://github.com/documenso/documenso/issues/1343

Issue Description

Just want to talk to someone from the team about issue that i am having and see if i did my setup wrong.
I was trying out and evaluting Documenso and setup the docker compose/.env to my fitting.

However, after signing up, i did not receveid the confirmation email. So, i have to manually 'verify' my account by going to DB and manually update the emailverified column.
Signing requested was not received in my inbox
And signed document is stuck at pending state.

Job to perform task seems to be created successfully but not being executed.

Here are the list of pending jobs that were in the BackgroundJobTask table

send.signup.confirmation.email
send.signing.requested.email
internal.seal-document
Using the original docker compose file from
ENV File

POSTGRES_USER="dbtest"
POSTGRES_PASSWORD="dbtest"
POSTGRES_DB="dbtest"
NEXT_PRIVATE_DATABASE_URL="postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@database:5432/${POSTGRES_DB}"

NEXTAUTH_SECRET="some-secret"
NEXT_PRIVATE_ENCRYPTION_KEY="some-key"
NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY="some-secondary-key"
NEXT_PUBLIC_WEBAPP_URL="http://localhost:3000"

NEXT_PUBLIC_DISABLE_SIGNUP=false

NEXT_PRIVATE_SIGNING_PASSPHRASE="test123"

Steps to Reproduce

Install and run Documenso follwing instruction in https://docs.documenso.com/developers/self-hosting

Expected Behavior

Expect all the listed jobs to run

Current Behavior

All the listed jobs not running

Screenshots (optional)

Operating System [e.g., Windows 10]

MAC OS and Ubuntu

Browser [e.g., Chrome, Firefox]

Chrome

Version [e.g., 2.0.1]

1.7.0

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 @zxtanzxzx on GitHub (Sep 11, 2024). Original GitHub issue: https://github.com/documenso/documenso/issues/1343 ### Issue Description Just want to talk to someone from the team about issue that i am having and see if i did my setup wrong. I was trying out and evaluting Documenso and setup the docker compose/.env to my fitting. However, after signing up, i did not receveid the confirmation email. So, i have to manually 'verify' my account by going to DB and manually update the emailverified column. Signing requested was not received in my inbox And signed document is stuck at pending state. Job to perform task seems to be created successfully but not being executed. Here are the list of pending jobs that were in the BackgroundJobTask table - send.signup.confirmation.email - send.signing.requested.email - internal.seal-document Using the original docker compose file from ENV File ``` POSTGRES_USER="dbtest" POSTGRES_PASSWORD="dbtest" POSTGRES_DB="dbtest" NEXT_PRIVATE_DATABASE_URL="postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@database:5432/${POSTGRES_DB}" NEXTAUTH_SECRET="some-secret" NEXT_PRIVATE_ENCRYPTION_KEY="some-key" NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY="some-secondary-key" NEXT_PUBLIC_WEBAPP_URL="http://localhost:3000" NEXT_PUBLIC_DISABLE_SIGNUP=false NEXT_PRIVATE_SIGNING_PASSPHRASE="test123" ``` ### Steps to Reproduce Install and run Documenso follwing instruction in https://docs.documenso.com/developers/self-hosting ### Expected Behavior Expect all the listed jobs to run ### Current Behavior All the listed jobs not running ### Screenshots (optional) <img width="1558" alt="image" src="https://github.com/user-attachments/assets/a8bdabca-8d44-48c6-ae81-5e34e6721318"> ### Operating System [e.g., Windows 10] MAC OS and Ubuntu ### Browser [e.g., Chrome, Firefox] Chrome ### Version [e.g., 2.0.1] 1.7.0 ### 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. - [ ] I want to work on creating a PR for this issue if approved

kerem added the

Stale

status: triage

labels

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

kerem commented

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

Author

Owner

@github-actions[bot] commented on GitHub (Sep 11, 2024):

Thank you for opening your first issue and for being a part of the open signing revolution!

One of our team members will review it and get back to you as soon as it possible 💚

Meanwhile, please feel free to hop into our community in Discord

@github-actions[bot] commented on GitHub (Sep 11, 2024): Thank you for opening your first issue and for being a part of the open signing revolution! <br /> One of our team members will review it and get back to you as soon as it possible 💚 <br /> Meanwhile, please feel free to hop into our community in [Discord](https://documen.so/discord)

kerem commented

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

Author

Owner

@jsbrain commented on GitHub (Sep 20, 2024):

Facing the exact same problem, the http://localhost:3000/api/trpc/profile.sendConfirmationEmail?batch=1 returns:

[
    {
        "result": {
            "data": {
                "json": null,
                "meta": {
                    "values": [
                        "undefined"
                    ]
                }
            }
        }
    }
]

@jsbrain commented on GitHub (Sep 20, 2024): Facing the exact same problem, the `http://localhost:3000/api/trpc/profile.sendConfirmationEmail?batch=1` returns: ```json [ { "result": { "data": { "json": null, "meta": { "values": [ "undefined" ] } } } } ] ```

kerem commented

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

Author

Owner

@matheusliraofficial commented on GitHub (Sep 24, 2024):

After debugging a lot, I fixed the issue, I found out that I had to add this variable to my .env:

NEXT_PRIVATE_INTERNAL_WEBAPP_URL="http://{CONTAINER_INTERNAL_IP}:3000"

Since in my case I was running it inside a container, instead of using localhost, I had to use the container IP address

@matheusliraofficial commented on GitHub (Sep 24, 2024): After debugging a lot, I fixed the issue, I found out that I had to add this variable to my .env: `NEXT_PRIVATE_INTERNAL_WEBAPP_URL="http://{CONTAINER_INTERNAL_IP}:3000"` Since in my case I was running it inside a container, instead of using localhost, I had to use the container IP address

kerem commented

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

Author

Owner

@jsbrain commented on GitHub (Sep 27, 2024):

I simply cannot get it to run. Setting NEXT_PRIVATE_INTERNAL_WEBAPP_URL="http://{CONTAINER_INTERNAL_IP}:3000" helped to trigger the jobs and now they actually run in the db but signing jobs always fail, for what ever reason.

Also when setting NEXT_PRIVATE_JOBS_PROVIDER="trigger" the jobs still run locally it seems, even with having all trigger related envs set to my trigger cloud endpoint.

The job payload looks like this:

and I have absolutely no idea where the 192.168.65.1 ip is coming from. I am not connected to any such network.

@jsbrain commented on GitHub (Sep 27, 2024): I simply cannot get it to run. Setting `NEXT_PRIVATE_INTERNAL_WEBAPP_URL="http://{CONTAINER_INTERNAL_IP}:3000"` helped to trigger the jobs and now they actually run in the db but signing jobs always fail, for what ever reason. Also when setting `NEXT_PRIVATE_JOBS_PROVIDER="trigger"` the jobs still run locally it seems, even with having all trigger related envs set to my trigger cloud endpoint. The job payload looks like this: <img width="652" alt="Screenshot 2024-09-27 at 10 54 00" src="https://github.com/user-attachments/assets/9560f8c0-4b64-4219-a0ba-85fe673768f1"> and I have absolutely no idea where the `192.168.65.1` ip is coming from. I am not connected to any such network.

kerem commented

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

Author

Owner

@jsbrain commented on GitHub (Sep 27, 2024):

Finally got it to work, the solution for me was to not set an export password when creating the .p12 certificate. This makes sense, as according to my research, there is no option to set said export password anywhere, meaning the signing docs are quite misleading. It even states that when setting the export password, you should remember it as you'd need it to use the password but without an option to set said password how should it even work?

@jsbrain commented on GitHub (Sep 27, 2024): Finally got it to work, the solution for me was to not set an export password when creating the .p12 certificate. This makes sense, as according to my research, there is no option to set said export password anywhere, meaning the [signing docs](https://github.com/documenso/documenso/blob/main/SIGNING.md) are quite misleading. It even states that when setting the export password, you should remember it as you'd need it to use the password but without an option to set said password how should it even work?

kerem commented

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

Author

Owner

@jiaweing commented on GitHub (Oct 5, 2024):

Finally got it to work, the solution for me was to not set an export password when creating the .p12 certificate. This makes sense, as according to my research, there is no option to set said export password anywhere, meaning the signing docs are quite misleading. It even states that when setting the export password, you should remember it as you'd need it to use the password but without an option to set said password how should it even work?

How did you generate the p12 without an export pass? I tried leaving it empty and it still doesn't work

@jiaweing commented on GitHub (Oct 5, 2024): > Finally got it to work, the solution for me was to not set an export password when creating the .p12 certificate. This makes sense, as according to my research, there is no option to set said export password anywhere, meaning the [signing docs](https://github.com/documenso/documenso/blob/main/SIGNING.md) are quite misleading. It even states that when setting the export password, you should remember it as you'd need it to use the password but without an option to set said password how should it even work? How did you generate the p12 without an export pass? I tried leaving it empty and it still doesn't work

kerem commented

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

Author

Owner

@shrey565 commented on GitHub (Oct 8, 2024):

@jiaweing i faced the same issue, fixed it by setting export password in this variable NEXT_PRIVATE_SIGNING_PASSPHRASE.
@jsbrain setting empty export password in certificate worked because NEXT_PRIVATE_SIGNING_PASSPHRASE was set empty by default.

@shrey565 commented on GitHub (Oct 8, 2024): @jiaweing i faced the same issue, fixed it by setting export password in this variable NEXT_PRIVATE_SIGNING_PASSPHRASE. @jsbrain setting empty export password in certificate worked because NEXT_PRIVATE_SIGNING_PASSPHRASE was set empty by default.

kerem commented

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

Author

Owner

@jsbrain commented on GitHub (Oct 8, 2024):

@shrey565 that's curious, I would expect the NEXT_PRIVATE_SIGNING_PASSPHRASE to be, as the name suggests, the passphrase of the certificate, not the export password. It doesn't really make sense to me that it would work for the export password but well, if it works it works :)

@jsbrain commented on GitHub (Oct 8, 2024): @shrey565 that's curious, I would expect the NEXT_PRIVATE_SIGNING_PASSPHRASE to be, as the name suggests, the passphrase of the certificate, not the export password. It doesn't really make sense to me that it would work for the export password but well, if it works it works :)

kerem commented

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

Author

Owner

@jiaweing commented on GitHub (Oct 9, 2024):

@shrey565 I tried both with and without a passphrase for the p12 cert and setting the NEXT_PRIVATE_SIGNING_PASSPHRASE variable but I'm still having issues with sealing the document. Weird.

2024-10-09T11:59:49.510840312Z [JOBS]: Triggering job internal.seal-document with payload {
2024-10-09T11:59:49.510882754Z   documentId: 73,
2024-10-09T11:59:49.510886959Z   requestMetadata: {
2024-10-09T11:59:49.510890496Z     ipAddress: 'xxxxxxxxxxx,
2024-10-09T11:59:49.510894028Z     userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36 Edg/129.0.0.0'
2024-10-09T11:59:49.510897817Z   }
2024-10-09T11:59:49.510900992Z }
2024-10-09T11:59:53.616471649Z [JOBS]: Job internal.seal-document failed g [BackgroundTaskFailedError]: Task failed
2024-10-09T11:59:53.616531427Z     at Object.runTask (/app/apps/web/.next/server/chunks/9783.js:1:17386)
2024-10-09T11:59:53.616536281Z     at async Object.handler (/app/apps/web/.next/server/chunks/9783.js:1:26393)
2024-10-09T11:59:53.616540453Z     at async /app/apps/web/.next/server/chunks/9783.js:1:15444
2024-10-09T11:59:53.616544060Z     at async K (/app/node_modules/next/dist/compiled/next-server/pages-api.runtime.prod.js:20:16853)
2024-10-09T11:59:53.616547554Z     at async U.render (/app/node_modules/next/dist/compiled/next-server/pages-api.runtime.prod.js:20:17492)
2024-10-09T11:59:53.616550854Z     at async NextNodeServer.runApi (/app/node_modules/next/dist/server/next-server.js:600:9)
2024-10-09T11:59:53.616554125Z     at async NextNodeServer.handleCatchallRenderRequest (/app/node_modules/next/dist/server/next-server.js:269:37)
2024-10-09T11:59:53.616557409Z     at async NextNodeServer.handleRequestImpl (/app/node_modules/next/dist/server/base-server.js:816:17)
2024-10-09T11:59:53.616560668Z     at async invokeRender (/app/node_modules/next/dist/server/lib/router-server.js:174:21)
2024-10-09T11:59:53.616563983Z     at async handleRequest (/app/node_modules/next/dist/server/lib/router-server.js:353:24)
2024-10-09T11:59:53.620583130Z Submitting job to endpoint: http://documenso:3000/api/jobs/internal.seal-document/cm21thun4000vk52114rw43f0

@jiaweing commented on GitHub (Oct 9, 2024): @shrey565 I tried both with and without a passphrase for the p12 cert and setting the NEXT_PRIVATE_SIGNING_PASSPHRASE variable but I'm still having issues with sealing the document. Weird. ``` 2024-10-09T11:59:49.510840312Z [JOBS]: Triggering job internal.seal-document with payload { 2024-10-09T11:59:49.510882754Z documentId: 73, 2024-10-09T11:59:49.510886959Z requestMetadata: { 2024-10-09T11:59:49.510890496Z ipAddress: 'xxxxxxxxxxx, 2024-10-09T11:59:49.510894028Z userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36 Edg/129.0.0.0' 2024-10-09T11:59:49.510897817Z } 2024-10-09T11:59:49.510900992Z } 2024-10-09T11:59:53.616471649Z [JOBS]: Job internal.seal-document failed g [BackgroundTaskFailedError]: Task failed 2024-10-09T11:59:53.616531427Z at Object.runTask (/app/apps/web/.next/server/chunks/9783.js:1:17386) 2024-10-09T11:59:53.616536281Z at async Object.handler (/app/apps/web/.next/server/chunks/9783.js:1:26393) 2024-10-09T11:59:53.616540453Z at async /app/apps/web/.next/server/chunks/9783.js:1:15444 2024-10-09T11:59:53.616544060Z at async K (/app/node_modules/next/dist/compiled/next-server/pages-api.runtime.prod.js:20:16853) 2024-10-09T11:59:53.616547554Z at async U.render (/app/node_modules/next/dist/compiled/next-server/pages-api.runtime.prod.js:20:17492) 2024-10-09T11:59:53.616550854Z at async NextNodeServer.runApi (/app/node_modules/next/dist/server/next-server.js:600:9) 2024-10-09T11:59:53.616554125Z at async NextNodeServer.handleCatchallRenderRequest (/app/node_modules/next/dist/server/next-server.js:269:37) 2024-10-09T11:59:53.616557409Z at async NextNodeServer.handleRequestImpl (/app/node_modules/next/dist/server/base-server.js:816:17) 2024-10-09T11:59:53.616560668Z at async invokeRender (/app/node_modules/next/dist/server/lib/router-server.js:174:21) 2024-10-09T11:59:53.616563983Z at async handleRequest (/app/node_modules/next/dist/server/lib/router-server.js:353:24) 2024-10-09T11:59:53.620583130Z Submitting job to endpoint: http://documenso:3000/api/jobs/internal.seal-document/cm21thun4000vk52114rw43f0 ```

kerem commented

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

Author

Owner

@jsbrain commented on GitHub (Oct 10, 2024):

@jiaweing try this

@jsbrain commented on GitHub (Oct 10, 2024): @jiaweing try [this](https://github.com/documenso/documenso/issues/1296#issuecomment-2405194397)

kerem commented

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

Author

Owner

@jiaweing commented on GitHub (Oct 11, 2024):

@jiaweing try this

I managed to solve it. I was generating the keys on Windows this whole time, generating on the machine itself solved it.

@jiaweing commented on GitHub (Oct 11, 2024): > @jiaweing try [this](https://github.com/documenso/documenso/issues/1296#issuecomment-2405194397) I managed to solve it. I was generating the keys on Windows this whole time, generating on the machine itself solved it.

kerem commented

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

Author

Owner

@Ange7 commented on GitHub (Dec 30, 2025):

Hello,

Does anyone know how to re-run a background job?

I have one job stuck in PENDING:

SELECT status, name, COUNT()
FROM "BackgroundJobTask"
GROUP BY status, name
ORDER BY COUNT() DESC;

Result:


  status    |             name              | count
------------+-------------------------------+-------
 COMPLETED  | send-signing-email            | 2
 COMPLETED  | update-recipient              | 2
 COMPLETED  | store-audit-log               | 2
 COMPLETED  | send-recipient-signed-email   | 1
 PENDING    | seal-document                 | 1

I would like to re-run the seal-document job in order to complete an old document that is still pending.

Is there a way to re-queue or manually trigger this job?

Thanks.

@Ange7 commented on GitHub (Dec 30, 2025): Hello, Does anyone know how to re-run a background job? I have one job stuck in PENDING: SELECT status, name, COUNT(*) FROM "BackgroundJobTask" GROUP BY status, name ORDER BY COUNT(*) DESC; Result: ``` status | name | count ------------+-------------------------------+------- COMPLETED | send-signing-email | 2 COMPLETED | update-recipient | 2 COMPLETED | store-audit-log | 2 COMPLETED | send-recipient-signed-email | 1 PENDING | seal-document | 1 ``` I would like to re-run the seal-document job in order to complete an old document that is still pending. Is there a way to re-queue or manually trigger this job? Thanks.

kerem commented

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

Author

Owner

@hanprat commented on GitHub (Feb 12, 2026):

@Ange7 My solution for rerunning sealing-job is :

Activate your user as admin, adding ADMIN role.

UPDATE "User" SET roles = ARRAY['ADMIN', 'USER'] WHERE email = 'your-email@example.com';

Access the dashboard admin https://your-documenso-site.com/admin.
Go to the Documents page and search the document you want to seal.
After you find the document and go to the detail page, just find "Reseal Document" button on the Admin Actions section

@hanprat commented on GitHub (Feb 12, 2026): @Ange7 My solution for rerunning sealing-job is : 1. Activate your user as admin, adding `ADMIN` role. ```sql UPDATE "User" SET roles = ARRAY['ADMIN', 'USER'] WHERE email = 'your-email@example.com'; ``` 1. Access the dashboard admin `https://your-documenso-site.com/admin`. 2. Go to the Documents page and search the document you want to seal. 3. After you find the document and go to the detail page, just find "Reseal Document" button on the **Admin Actions** section

kerem commented

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

Author

Owner

@aleksander-pankow commented on GitHub (Feb 13, 2026):

Problem

Documenso requires a signing certificate (.p12) to sign documents. Without a valid certificate, functions like document signing fails and status is PENDING all time. Common issues include:

Missing certificate – The .p12 file doesn’t exist in the container.
Incorrect path – The NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH points to a location where the file isn’t present.
Incorrect permissions – The certificate exists but the Documenso process (running under user 1001) cannot read it.

These problems typically occur when deploying Documenso with Docker using volumes or after container redeployments.

Solution

I introduce a cert-generator container that:

Runs before Documenso starts.
Checks if the certificate exists in a shared volume (documenso-certs).
If missing, generates a self-signed .p12 certificate using OpenSSL.
Ensures correct file ownership (chown 1001:1001) so Documenso can read it.
Keeps the certificate persistent across redeploys.

Benefits

Fully automated certificate generation, no manual steps.
Works reliably across redeployments.
Prevents silent failures of document signing.
Compatible with Docker version: "3.8" and persistent volumes.

Tested in production using DOKPLOY v0.25.5

version: "3.8"

services:
  postgres:
    // your configuration

  cert-generator:
    image: "alpine:3.19"
    restart: "no"
    volumes:
      - "documenso-certs:/certs"
    environment:
      - "SIGNING_PASSPHRASE=${SIGNING_PASSPHRASE}"
    command: >
      sh -c '
      if [ ! -f /certs/cert.p12 ]; then
        echo "Generating signing certificate..." &&
        apk add --no-cache openssl &&
        openssl req -x509 -newkey rsa:4096 -nodes \
          -keyout /certs/key.pem \
          -out /certs/cert.pem \
          -days 3650 \
          -subj "/C=HK/ST=Hong Kong/L=Hong Kong/O=COMPANY NAME/CN=website.com" &&
        openssl pkcs12 -export \
          -out /certs/cert.p12 \
          -inkey /certs/key.pem \
          -in /certs/cert.pem \
          -passout pass:$SIGNING_PASSPHRASE &&
        rm /certs/key.pem /certs/cert.pem;
      else
        echo "Certificate already exists";
      fi &&
      chown 1001:1001 /certs/cert.p12
      '

  documenso:
    image: "documenso/documenso:v2.6.0"
    restart: "unless-stopped"
    depends_on:
      postgres:
        condition: service_healthy
      cert-generator:
        condition: service_completed_successfully
    ports:
      // your configuration
    volumes:
      - "documenso-certs:/opt/documenso"
    environment:
      // your configuration
      - "NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH=/opt/documenso/cert.p12"
      - "NEXT_PRIVATE_SIGNING_PASSPHRASE=${SIGNING_PASSPHRASE}"

volumes:
  documenso-data:
  documenso-certs:

Here:

-subj "/C=HK/ST=Hong Kong/L=Hong Kong/O=COMPANY NAME/CN=website.com" &&

Change data in this line to yours own.
Implement SIGNING_PASSPHRASE=your_pass_phrase to ENV.

Behavior after certificate generation:

Once the signing certificate has been successfully generated:

Existing documents that are already in Pending status will not be updated automatically.
Any newly created documents will be signed immediately and their status will quickly change to Complete.

This is the simplest way to generate a signing certificate so the system works out of the box. For those who need a more advanced or paid certificate, the script would require some modifications. Nevertheless, this approach is ideal for users who need it immediately.

Enjoy.

@aleksander-pankow commented on GitHub (Feb 13, 2026): ### Problem Documenso requires a signing certificate (.p12) to sign documents. Without a valid certificate, functions like document signing fails and status is PENDING all time. Common issues include: - Missing certificate – The .p12 file doesn’t exist in the container. - Incorrect path – The NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH points to a location where the file isn’t present. - Incorrect permissions – The certificate exists but the Documenso process (running under user 1001) cannot read it. These problems typically occur when deploying Documenso with Docker using volumes or after container redeployments. ### Solution I introduce a cert-generator container that: - Runs before Documenso starts. - Checks if the certificate exists in a shared volume (documenso-certs). - If missing, generates a self-signed .p12 certificate using OpenSSL. - Ensures correct file ownership (chown 1001:1001) so Documenso can read it. - Keeps the certificate persistent across redeploys. ### Benefits - Fully automated certificate generation, no manual steps. - Works reliably across redeployments. - Prevents silent failures of document signing. - Compatible with Docker version: "3.8" and persistent volumes. **Tested in production using DOKPLOY v0.25.5** ``` version: "3.8" services: postgres: // your configuration cert-generator: image: "alpine:3.19" restart: "no" volumes: - "documenso-certs:/certs" environment: - "SIGNING_PASSPHRASE=${SIGNING_PASSPHRASE}" command: > sh -c ' if [ ! -f /certs/cert.p12 ]; then echo "Generating signing certificate..." && apk add --no-cache openssl && openssl req -x509 -newkey rsa:4096 -nodes \ -keyout /certs/key.pem \ -out /certs/cert.pem \ -days 3650 \ -subj "/C=HK/ST=Hong Kong/L=Hong Kong/O=COMPANY NAME/CN=website.com" && openssl pkcs12 -export \ -out /certs/cert.p12 \ -inkey /certs/key.pem \ -in /certs/cert.pem \ -passout pass:$SIGNING_PASSPHRASE && rm /certs/key.pem /certs/cert.pem; else echo "Certificate already exists"; fi && chown 1001:1001 /certs/cert.p12 ' documenso: image: "documenso/documenso:v2.6.0" restart: "unless-stopped" depends_on: postgres: condition: service_healthy cert-generator: condition: service_completed_successfully ports: // your configuration volumes: - "documenso-certs:/opt/documenso" environment: // your configuration - "NEXT_PRIVATE_SIGNING_LOCAL_FILE_PATH=/opt/documenso/cert.p12" - "NEXT_PRIVATE_SIGNING_PASSPHRASE=${SIGNING_PASSPHRASE}" volumes: documenso-data: documenso-certs: ``` Here: ``` -subj "/C=HK/ST=Hong Kong/L=Hong Kong/O=COMPANY NAME/CN=website.com" && ``` Change data in this line to yours own. Implement SIGNING_PASSPHRASE=your_pass_phrase to ENV. ### Behavior after certificate generation: Once the signing certificate has been successfully generated: - Existing documents that are already in Pending status will not be updated automatically. - Any newly created documents will be signed immediately and their status will quickly change to Complete. This is the simplest way to generate a signing certificate so the system works **out of the box**. For those who need a more advanced or paid certificate, the script would require some modifications. Nevertheless, this approach is ideal for users who need it **immediately**. Enjoy.

kerem referenced this issue

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

[PR #377] [CLOSED] refactor: Refactor code #924

Rows
Columns

[GH-ISSUE #1343] Background Job stuck at pending #377

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.

Problem

Solution

Benefits

Behavior after certificate generation: