One of the main things you will want to setup before putting your Budibase platform into production use is a proxy, which can control access to the cluster via a domain (removing the need for a port number and so on) as well as allowing the use of HTTPS for a domain that you own. In this section we will provide some configuration options to get this up and running easily with NGINX or Caddy.

Simple HTTPS Setup with Caddy

Caddy is an open source web server with automatic HTTPS written in Go.

If you want to get HTTPS up and running on your budibase instance as quickly as possible with caddy, go through the following steps.

Install Caddy

Follow the caddy installation instructions here:

Once you have done this, you should be able to check that you have caddy available on your machine.

caddy version # should print your version of caddy

Next, create a Caddyfile with your domain in it.

yourdomain.com

You can then simply run caddy start, and HTTPS should be set up on your domain.

You must now set up Caddy to point at your budibase instance. You can do this by stopping caddy with caddy stop, and restarting it with the following command. (Remember to replace your domain name and the URL with the ones you use.)

caddy reverse-proxy --from yourdomain.com --to localhost:10000

That's it! Full HTTPS and reverse proxy setup with caddy and budibase.

NGINX (Advanced)

Our recommendation for running Budibase is a "many app one server" approach, where many different apps can be deployed to the same self hosted Budibase platform. Below we have detailed a basic method for getting Budibase up and running behind a reverse proxy, which you can then update to add into an existing configuration or add SSL information.

Here is a basic reverse proxy configuration which will simply pass all requests from a domain/sub-domain/path to your Budibase platform.

# Budibase
set $budibase_host      <BUDIBASE_ADDRESS>;
set $budibase_port      10000;

server {
    listen 80;
    server_name yourdomain.com;
    
    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_pass http://$budibase_host:$budibase_port;
    }
    
    client_max_body_size 50m;
}

In this configuration all that needs to be updated for this to work is where the Budibase platform has been hosted, if it is hosted on the same machine then simply replace <BUDIBASE_ADDRESS> with localhost.

There are a few ways this can be extended/altered:

1. This is just a basic version which will proxy on any requests to your domain/sub-domain to the Budibase platform, you can change the server_name to suit your needs.

2. Where location / has been set you can change the slash to a path name if you desire to have your Budibase app server running on a specific path rather than the whole domain or a sub-domain.

3. Lastly if you want to make use of HTTPS/TLS you can either configure this basic configuration to re-direct traffic to HTTPS and then add your certificate, or you can use certbot-auto to automatically generate and look after the certificates for your domain!

In this section we'll cover some useful options for using your self hosted Budibase platform in production. These options aren't required for testing but we do recommend setting these up for any real production use cases. Below is a list of the options we have documented so far:

1. Reverse proxy - how to use your own domain as the URL for Budibase deployments and apps, as well as using existing certificates or certbot-auto to configure TLS/HTTPS.

If there is anything else you would like to see documented here, or an easier method to setup produced then please let us know by opening a Github Discussion with your suggestion!