Github RepoCommunityContact salesSign inGet started

Kubernetes

Set up Budibase in your Kubernetes cluster.

Suggest Edits

There are a few command-line utilities we have to set up before we can get started with Budibase on Kubernetes. Follow the guides below to set up Kubectl and Helm.

📘

Info

We recommend running on K8S nodes with at least 2GB of memory, but we recommend larger instances for higher volume use cases.

Setting up a Kubernetes Cluster

If you don't already have an existing Kubernetes cluster, follow one of the guides below for your provider.

Install Budibase Helm Chart

Now that you have your Kubernetes cluster up and running, you can now install the Budibase helm chart which will provision all the relevant infrastructure for running Budibase in a K8S environment. Run the commands below to download the helm chart from our repository, and install it.

🚧

Required

You must install Budibase in a Kubernetes namespace called budibase. This helps segregate your Budibase resources from the rest of your cluster.

helm repo add budibase https://budibase.github.io/budibase/
helm repo update
helm install --create-namespace --namespace budibase budibase budibase/budibase

Wait a few moments as Budibase creates all the containers and resources. You can then run:

kubectl get pods -n budibase

You should now be able to see your new Budibase installation up and running in your K8S cluster.

Budibase installation K8S

Time to build! To use your new installation, you need to get the IP address of your ingress controller. Budibase makes use of the NGINX ingress controller to direct incoming traffic to the other Budibase services.

You can access your Budibase installation using the IP address of the ingress controller, which you can grab using the following command:

kubectl get ingress -n budibase

Visit the ingress URL in your browser and you will see that your Budibase installation is up and running.

932

Budibase admin interface

Upgrading your Chart

To get the latest and greatest, you can run the following commands to update the repo and install the latest Budibase Helm Chart to your environment!

helm repo update
helm upgrade -n budibase budibase budibase/budibase

Configuration

Cloud Specific Load Balancers

By default, Budibase configures a basic NGINX ingress controller to route traffic to your Budibase services. If you want to run a load balancer for your specific cloud, you can turn off the NGINX ingress controller bundled with Budibase and run your own ingress controller for your specific cloud.

ingress:
  nginx: false
  aws: true

Using a Custom Domain

If you are using a custom domain for your installation, you need to add it in the host section of the ingress controller in values.yaml. Notice here how we have added yourdomain.com. You should then be able to set up an A record in your DNS provider to point to the URL of your ingress controller.

ingress:
  enabled: true
  nginx: true
  className: ""
  annotations: 
    kubernetes.io/ingress.class: nginx
  hosts:
    - host: yourdomain.com
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: proxy-service
            port:
              number: 10000

Scaling Budibase

You can scale up nodes in your installation by updating the replicaCount of a given service in the values.yaml of the Budibase helm chart. For example, if we wanted to scale up the worker and app service due to high load, we can update our values.yaml to have a higher replicaCount. Once updated, upgrade your chart to apply the changes.

services:
  dns: cluster.local

  proxy:
    port: 10000
    replicaCount: 1

  apps:
    port: 4002
    replicaCount: 2
    logLevel: info

  worker:
    port: 4001
    replicaCount: 2

Secrets Management

If you have createSecrets set to true in your values.yaml, budibase will create the following credentials for you:

  • An internal API key, that can be used for API requests.
  • a JWT secret
  • Object store access key (if using MinIO)
  • Object store secret key (if using MinIO)
    If you need to read the value of your secrets, you can do so using kubectl and the following commands to read the values out from your k8s secrets:
# for internal API key
kubectl get secret budibase-budibase -o go-template='{{ .data.internalApiKey }}' -n budibase | base64 --decode

# JWT secret
kubectl get secret budibase-budibase -o go-template='{{ .data.jwtSecret }}' -n budibase | base64 --decode

# MinIO Access Key
kubectl get secret budibase-budibase -o go-template='{{ .data.objectStoreAccess }}' -n budibase | base64 --decode

# MinIO Secret Key
kubectl get secret budibase-budibase -o go-template='{{ .data.objectStoreSecret }}' -n budibase | base64 --decode

Redis

The Budibase helm chart ships with a Redis server that will be included by default. If you want to use your own external Redis cluster, you can configure the values.yaml file in the helm chart to switch off the Budibase one by turning enabled off. Here's what your configuration may look like if you wanted to circumvent the default bundled Redis and use an external Redis cluster hosted on myrediscluster.io.

  redis:
    enabled: false # disable if using external redis
    port: 6379
    replicaCount: 1
    host: "myrediscluster.io"
    password: "your-redis-password"

CouchDB

The Budibase helm chart will automatically bring up a 3 node couchDB cluster within your environment. If you would rather use an existing CouchDB instance, you can turn off the one Budibase supplies and point at your own. Please note - you must set up search in your CouchDB cluster in order to use all the search functionality that Budibase provides. Below is an example configuration of how you would point Budibase to a CouchDB installation hosted on mycouch.io:

  couchdb:
    enabled: false
    replicaCount: 3
    url: "http://mycouch.io:1234"
    user: "couchuser"
    password: "couchpassword"

MinIO/Amazon S3

Budibase ships with a MinIO server included for object storage. Since MinIO is Amazon S3 compliant, you can switch out the bundled MinIO for an S3 bucket in your AWS account. Here's how your values.yaml should look if you want to use S3 instead of MinIO.

  objectStore:
    minio: false
    browser: false
    port: 9000
    replicaCount: 1
    accessKey: "your-access-key" # AWS_ACCESS_KEY
    secretKey: "your-secret-key" # AWS_SECRET_ACCESS_KEY

NGINX Proxy

Budibase ships with an NGINX proxy that sits in front of the budibase services to route traffic. There are some values you can configure at the proxy level to route requests or update the DNS resolver that is used in your kubernetes setup.

proxy:
	port: 10000
	resolver: kube-dns.kube-system.svc.local
   upstreams:
     apps: http://custom-apps-url
     worker: http://custom-worker-url
     minio: http://custom-minio-url
     couchdb: http://custom-couch-url

Troubleshooting

Connection Issues In My Cluster

Make sure that your Budibase installation is running in the Budibase namespace in Kubernetes. The proxy that routes traffic to Budibase services relies on this.

Still Having issues?

If you need a hand or have discovered a bug, please raise a discussion on our GitHub discussions forum. For Kubernetes installations, try to include the following information in your discussion:

  • Which K8S provider you are using (AWS/MiniKube etc)
  • Screenshots/Logs of errors that are occurring
  • Screenshots of your values.yaml if you have changed any configuration
  • Anything else that is relevant to the issue you are having.

Updated 10 months ago

What’s Next