Self-hosted Budibase on Kubernetes — “Error loading apps and templates” after login (/api/templates returns 504)

[Abd-Atif]

Hi Budibase team,
I’m running a self-hosted Budibase deployment on Kubernetes and facing an issue after login.
The login process works successfully, but after signing in, the dashboard keeps loading for some time and then shows the following errors:

Error loading apps and templates
Error getting init info

I checked the browser DevTools → Network tab and found that the following request is failing:

GET /api/templates

Response:

504 Gateway Timeout

The request takes a long time and eventually times out.

Environment

• Self-hosted Budibase
• Kubernetes deployment
• Running behind ingress/reverse proxy
• HTTPS enabled

Current Behavior

• _Login works successfully
• UI starts loading
• After some delay, the dashboard shows errors
• Apps/templates never load
• /api/templates consistently returns 504 Gateway Timeout_

Additional Info
From the browser network logs, the issue appears specifically related to the /api/templates endpoint.
At the moment, I’m not sure whether this is related to:

• Kubernetes networking
• ingress timeout
• outbound internet access
• DNS resolution
• template service availability
• or some Budibase configuration issue

Has anyone faced this before in Kubernetes/self-hosted environments?

Any help or guidance would be appreciated.

[mg1986jp]

The 504 on /api/templates after login usually means the worker or CouchDB container isn't reachable from the proxy. In the Kubernetes setup, the Budibase proxy needs to be able to reach the worker service and CouchDB service within the cluster.

Check a few things:

• Are all the pods running? kubectl get pods — make sure the worker, apps, couchdb, and minio pods are all healthy
• Check the worker pod logs: kubectl logs <worker-pod> — if it's crashing or OOM-ing, the templates endpoint will time out
• Make sure the internal service names in your env vars match what K8s DNS resolves. The worker needs COUCH_DB_URL pointing to the right CouchDB service (usually something like http://budibase-couchdb:5984)
• The 504 happening after "some time" suggests it might be a resource issue. CouchDB can be slow to start on K8s if the PVC is on slow storage

If the pods all look healthy, try hitting the worker directly from another pod to rule out K8s networking: kubectl exec -it <any-pod> -- curl http://budibase-worker:4003/health