itsaquestion/chatbot-docker-x

Chatbot UI Containerized

All in one deployment with Supabase

This project focuses on reducing Chatbot UI to as few files as possible for a rapid Docker deployment.

Tested on:

• Debian 12.5, Docker 25.0.3
• Fedora 39, Podman 4.9.3

Getting Started

Prerequisites

• Docker (obviously)
  • Docker compose (plugin recommended)
• A domain and DNS under your control (even if that's .local and a hosts file)
• Another reverse proxy configured to terminate TLS (optional)

Startup

• Copy .env.example to .env so docker-compose can read it.
• Change all values under the Secrets header, and at least the DOMAIN variable under the Webserver header.
  • Supabase can generate some keys based on your JWT Secret if you go here.
  • Make sure you have TLS configured if you plan on using HTTPS.
• Ensure DNS resolves to the domain/subdomains you've specified.
  • If you're trying to run this locally, you'll need a minimum two changes in your hosts file - one each for the chat and supabase subdomains. A third is required for access to the studio/dashboard.
• Run docker-compose up.
• You should be up and running on your specified $SCHEME://$CHATBOTUI_SUBDOMAIN.$DOMAIN/ (!)

Optional changes

• The Supabase containers can have a prefix and postfix specified instead of Chatbot UI's default "supabase_" and "_chatbotui", governed by $CONTAINER_PREFIX and $CONTAINER_POSTFIX in the .env file.
  • If you change these, you must also change the url attributes in kong.yml, see Things to Know, below.
• You can also move $KONG_PORT and $STUDIO_PORT if you want, although they don't get published.
• Both Supabase and Chatbot UI have additional envs that have been stripped to reduce the compose to only what is absolutely needed to run.
  • For Supabase configuration, see their .env.example. You can add these right to the .env file.
  • For Chatbot UI, see .env.local.example. These need to be added directly to the docker-compose.yml file under the "chatbot: build: args:" attribute. I recommend using a docker-compose.override.yml instead of modifying the main file. Of course, although the envs must be added to the compose for them to be passed at build time, you can still manage them in the .env and pass them over like any other value in the .env file.
• I don't recommend changing anything else already in the .env file. Several envs are marked 'Do not change' and the app WILL break if you change them.

Things to Know

• Fundamentally, the project is still somewhat separated from its two constituant components. Because Chatbot UI uses the Supabase cli, it generates URIs when used to a separate Supabase backend. Thus, we put our CBUI container in a docker network with the Supabase containers, and have it all run under a basic nginx configuration that binds to 0.0.0.0.

  • The internal nginx container could probably utilize some URI rewriting to reduce this to one domain.

• The docker-compose.yml file is the core file, which was adapted by taking Supabase's example self-hosting docker-compse.yml and contrasting it with a functioning self-hosted Chatbot UI using docker inspect.

• The .env.example file contains the values that must be configured for the software to run.

  • Chatbot UI's env.local has 3 envs that are required at runtime; they're now constructed from .env and handed off during the compose build phase.

• Supabase's Postgres DB runs some initial SQL on setup and then restarts.

  • In the Supabase docker-compose, this is split up into multiple pieces, but doing it this way fails for some reason. Instead, we combine the SQL files into two files, one for the set that runs during init-scripts, and another for the set that runs during migrations.
  • In Chatbot UI's supabase start workflow, additional SQL is run after this restart. To emulate this behavior, a dbmate service is added to take advantage of Supabase's built-in support. It runs once and quits - that's normal. dbmate-entrypoint.sh pulls the latest migrations from the Chatbot UI repo and applies the service key from your .env file to the setup SQL (as specified here) before importing the migrations into the db.

• kong.yml and custom_nginx.template are sourced from the Docker entrypoint for Kong generated by the supabase start CLI command using Chatbot UI's provided config.toml. The The Kong API Gateway doesn't have any templating method, so any changes of container names or request URIs elsewhere must also be reflected in kong.yml.

• The Dockerfile that generates a container for Chatbot UI has a VERSION build-arg which is currently set to main as CBUI does not have any official releases or branches other than main at this time.

Known issues

• The Chatbot UI Dockerfile uses npm build, which bakes the secrets into static files in the container image, so maybe don't share the container or store it remotely, and just have it build every time.
• Realtime/websockets don't work. I think the supabase start cli command does some additional work that I couldn't recreate (yet). It may be in the realtime internal Postgres db.
• The realtime, chatbot-ui, and studio containers don't report healthy on Podman. This is a mystery to me, since their healthcheck commands return true if you run them inside their containers.
• DBMate should probably clean itself up, but I don't know how to do that in a way docker-compose will like.
• The Chatbot UI image won't build using podman-compose. It doesn't understand the ulimits attribute, and the NPM build will fail. Comment out pull_policy:build in docker-compose.yml#L293 and build it manually using buildah bud --ulimit nofile=10000:10000 ...
• There are no tests.
• Probably other things 🤷🏻‍♂️