Couchbase console UI - web app configuration


Where can I find the default web app configuration for couchbase console UI.


@Noorkumar Can you please take a look here ?

@raju Thank you for the reply.
https://couchbase-ui-{dns name}/clusterId --> this is our url to access the couchbase UI.
for example
It is not working after we added the cluster Id in the path, before adding the cluster id in the path the url was like and it was working fine.
After path based changes we are not able to access the console UI, it shows blank scree and will not ask for credentials to login.
Is there anything which restrict the path variable to access the console UI

Hi @Noorkumar:
Standard port for the Couchbase HTTPS UI is 18091 - so given that things work when you access, this must mean that you access Couchbase Server through a web proxy that maps the root path (/) to whatever host the server is actually running on, say database-host:18091. If you try to access /abc123 that will map to database-host:18091/abc123 - which will not work as this is not a valid path.

You’ll need to work with whomever has configured the web proxy to map /abc123 -> database-host:18091. Once you have the web proxy in front of Couchbase Server configured this way, it should work.


Hi @davef Thank you for the support.
Below is the my ingress resource which maps console UI. I try changing the port to 18091 also it didn’t work, I also tried to access the http instead of https but still won’t work. if I remove the path from ingress resource and access works fine.


All the API’s will work fine, like I can post the data with, I can access the buckets, /pools etc all API’s works fine. I am not able access the console UI only.

HI @Noorkumar - are you running Couchbase Server in Kubernetes deployed with the Couchbase Operator, by chance?

Hi @davef
Yes, We have deployed the Couchbase server in Kubernetes with the Couchbase operator .

Hi @Noorkumar

For most deployments it is highly recommended that one of the supported methods for connecting to Couchbase are used as documented here:

There is a possibility that the Ingress controller will work with the Couchbase Operator, but getting it to work with a rewrite rule may take some additional research into the service itself. If you’re looking for a starting point with ingress, the following should work.

kind: Ingress
  name: my-ingress
  annotations: cookie persistent
  - http:
      - path: /
        pathType: Prefix
          serviceName: example-couchbase-cluster
          servicePort: 8091

Hi @davef @tommie
We are trying to access the UI from and cluster id changes for everytime when we create the instance. when I try to access the above url, the page loads but it will prompt for the login and when I look network tab it is excluding the cluster id i.e, abc123 from some API’s like rather it should have been
My problem is same as the below.
Config setting for UI base path?

Thanks for your help.

The content shouldn’t need a base path due to relative addressing of HTTP content. However there are number of bugs I can see. First up the HTTP redirect doesn’t work because it doesn’t know about the prefix (mod_rewrite has stripped it). Even then when I manually set the path to /kung-fu-panda/ui/index.html (random prefix… it’s Monday morning), it still doesn’t work, but does look a lot better in the Firefox console.

Unless Dave knows better, and he usually does, my suggestion is to use the hostname to perform multiplexing e.g. and, then the proxy should inject X-Forwarded-Host, X-Forwarded-Proto etc. and things will work as you expect. Host based routing (SNI too) is always a better option than doing path based routing, in my opinion. It’s an option to consider if path based routing doesn’t work for you.

Hi @simon.murray Thanks for your reply.
We need to have fixed domain server certificates and cluster are created dynamically that is the reason we are going for path based routing.

Any suggestion to solve the issue will be helpful.

There’s nothing I can personally think of that would allow path routing to work. Someone else may have a suggestion.

I don’t know if this is possible, but you can still use host based routing – with static certificates more importantly – if you get a wildcard issued e.g. *, that would work for all the examples in my previous message. They can be wonderfully cheap too.

Hi @tommie

I used the link that you provided, Access the Couchbase Server User Interface | Couchbase Docs, but since I use K8s v1.19, the pathType: Prefix is no longer supported. So, I used pathType: ImplementationSpecific and got the following error message: no healthy upstream.

If anyone can share any information, docs, or links that I can look into, that will be great, highly appreciated.

I’m not sure I follow, the official docs even show a prefix example: Ingress | Kubernetes

Why do you think it’s not supported?

This is a generic routing error, are you using a service mesh like Istio?

Have you configured it to match your specific cluster details? The example values need replacing with your actual cluster details.

You are right about the documentation. I misread, version earlier thatn 1.21.3-gke.1600, the only supported value for pathType is ImplementationSpecific, for 1.21.3-gke.1600 or later, Prefix and Exact are supported.

I was wondering how I can resolve this.

This is my ingress

kind: Ingress
  name: cb-ingress
  annotations: cookie persistent
  - http:
      - path: /
        pathType: Prefix
            name: cb-example
              number: 8091

When I described the ingress, this is what I got:

▶ kubectl describe ing cb-ingress

  Type     Reason     Age                    From                     Message
  ----     ------     ----                   ----                     -------
  Normal   Sync       2m9s (x125 over 3d4h)  loadbalancer-controller  Scheduled for sync
  Warning  Translate  47s (x37 over 3d3h)    loadbalancer-controller  Translation failed: invalid ingress spec: only "ImplementationSpecific" path type is supported