CouchDB password rotated every deploy

[djjudas21]

Checklist

• I have searched budibase discussions and github issues to check if my issue already exists

Related to, but different from, #13760

Hosting

• Self
  • Method: k8s
  • Budibase Version: 3.13.2

Describe the bug

I'm a new Budibase user, so I'm deploying on k8s with Helm. I noticed that re-running the Helm deploy command restarts the CouchDB instance, and after this Budibase can no longer authenticate with CouchDB. It seems like CouchDB is being reconfigured with a new admin password.

My values.yaml is almost completely stock - I've only set the URL and the storageClass. I haven't set any credentials for CouchDB.

App logs:

{"level":"WARN","timestamp":"2025-06-25T19:41:59.324Z","service":"@budibase/server","err":{"type":"bh","message":"CouchDB error: Name or password is incorrect.","stack":"Error: CouchDB error: Name or password is incorrect.\n    at e.performCall (/app/dist/index.js:7:9949)\n    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\n    at async /app/dist/index.js:7:3549\n    at async t (/app/dist/index.js:389:94917)\n    at async Object._fe (/app/dist/index.js:966:20621)\n    at async /app/dist/index.js:1034:22996\n    at async J8r (/app/dist/index.js:742:4174)\n    at async dMr (/app/dist/index.js:485:263)\n    at async /app/node_modules/koa-compress/lib/index.js:38:5\n    at async /app/dist/index.js:485:416\n    at async uW (/app/dist/index.js:7:17286)\n    at async eit (/app/dist/index.js:485:395)\n    at async pMr (/app/dist/index.js:484:4654)\n    at async /app/node_modules/koa-mount/index.js:52:26\n    at async userAgent (/app/node_modules/koa-useragent/dist/index.js:12:5)\n    at async iit (/app/dist/index.js:485:1065)","status":401,"statusCode":401,"reason":"Name or password is incorrect.","name":"Error","errid":"non_200","description":"Name or password is incorrect.","error":"unauthorized"},"pid":29,"tenantId":"default","correlationId":"6aa2a02c-f55f-42ec-931f-5e8925b284cb","msg":""}

To Reproduce
Steps to reproduce the behavior:

1. Initial install helm upgrade -i --create-namespace -n budibase budibase -f values.yaml budibase/budibase
2. Wait for Budibase to come up
3. Start using Budibase
4. Redeploy helm upgrade -i --create-namespace -n budibase budibase -f values.yaml budibase/budibase
5. Observe Budibase no longer works due to CouchDB errors

Expected behavior

Redeploying with the same settings shouldn't break a working Budibase installation

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[linear]

BUDI-9432 CouchDB password

[djjudas21]

Confirmed, every re-running of helm upgrade regenerates the adminPassword in the budibase-couchdb secret.

The pod budibase-couchdb-0 restarts, but none of the others do, so they must still be using the original password.

So the problem is that the adminPassword changes every deployment, but it should only be generated once.

[djjudas21]

# couchdb password before redeploy
jonathan@ideapad:~$ kubectl get secret budibase-couchdb -o yaml | grep adminPassword
  adminPassword: N0NqY045bUU0NE44bzRHaVFLV2k=

# redeploy
jonathan@ideapad:~$ helm upgrade -i --create-namespace -n budibase budibase -f values.yaml budibase/budibase
Release "budibase" has been upgraded. Happy Helming!
NAME: budibase
LAST DEPLOYED: Wed Jun 25 22:51:59 2025
NAMESPACE: budibase
STATUS: deployed
REVISION: 4
NOTES:
1. Get the application URL by running these commands:
  http://budibase.example.com/

# couchdb password after redeploy
jonathan@ideapad:~$ kubectl get secret budibase-couchdb -o yaml | grep adminPassword
  adminPassword: eUpRRE5aYk5UWEM3a0FHWTFsZmU=

[ConorWebb96]

Hey @djjudas21,

Thanks for writing this up. I’ve spoken with our ops engineers. They are aware of the issue. We’ll be looking into a fix.

In the meantime, if you manually set your password in CouchDB, you shouldn’t run into this issue again, as it will reuse the specified password:

couchdb:
  adminPassword: passwordSetHere

I hope this workaround helps in the meantime.

[djjudas21]

Thanks @ConorWebb96, I can confirm the workaround works for me. Happy for you to close this if your ops engineers are on it, also happy for it to stay open until the fix is ready to be tested 🙂

[calexiou]

Hey @djjudas21, it's an interesting one but if we were to change the behaviour of this we would be modifying the default upstream CouchDB chart behaviour.

You will find out that swapping the password is what helm upgrade does, by default, in the CouchDB chart.

helm repo add couchdb https://apache.github.io/couchdb-helm/

helm install test-couch couchdb/couchdb \
  --namespace couchdb-test --create-namespace \
  --set couchdbConfig.couchdb.uuid=$(uuidgen) \
  --set persistentVolume.enabled=true

Then, grab your adminPassword from the secret.

kubectl get secret test-couch-couchdb -n couchdb-test -o yaml | grep adminPassword

Use it to get your UUID if you haven't printed it earlier, from within one of the pods.

curl -u admin:<decoded-password> http://localhost:5984/_node/_local/_config/couchdb/uuid

Run an upgrade for the UUID to make definite that Helm points to the correct cluster.

helm upgrade test-couch couchdb/couchdb \
  --namespace couchdb-test \
  --set couchdbConfig.couchdb.uuid=<UUID_HERE> \
  --set persistentVolume.enabled=true

Grab the encoded admin password from the secret, once more. You will find out it's a different one this time.

We could change this if we preconfigured our values with createAdminSecret: false and forced Budibase Helm chart's users to set

a) a secret name OR
b) adminPassword

but we don't think it's the right way to go. We added a warning on the Helm chart to document this.

TLDR; A swapped password is the default upstream chart behaviour on helm upgrades and we think that the workaround proposed by @ConorWebb96 is how people should enforce persistent credentials.

[ConorWebb96]

Hey all,

I will convert this to a discussion rather than close it, as it might be helpful for others. If there are any related questions, they can be addressed as well.