Replies: 5 comments 3 replies
-
I am also working with a group attempting to do an install of chatbot-ui and supabase on our Openshift environment based on this chart but we have found a lot of issues that need to be fixed at least for Openshift and we are struggle bussing through it pretty hard right now. I honestly think option #1 is the best option, just have a basic DB set up and BYO the rest of your infrastructure. That is probably where we will end up at the end of the day. But if we can get our version of the helm chart working we will put it in a public repo somewhere so others copy it. |
Beta Was this translation helpful? Give feedback.
-
@jland-redhat We've been pulling the thread on #2, for better or worse. Got to the point where we're building all images from scratch, and working on the helm orchestrations. If y'all have a helm chart together I would love to take a look; otherwise happy to share our progress. |
Beta Was this translation helpful? Give feedback.
-
Okay, update time! We've been wrestling with this self-deployed Supabase setup. Their docs definitely leave something to be desired when you're not using Docker Swarm. Despite that, we got a basic Supabase instance and the chat-ui working. I tossed the Helm chart we used up here: https://github.com/jland-redhat/supabase-helm Keep in mind it is still very much a WIP, but it should get the image up and running |
Beta Was this translation helpful? Give feedback.
-
@nfairbank @stubclan @jland-redhat You guys should join the discord over here -- https://discord.gg/K5hkY333kz |
Beta Was this translation helpful? Give feedback.
-
If Supabase is a problem and you want more flexible deploy, you should consider this other chat bot: Very full featured, free, postgres is the only dependency, docker images and pre-built deploy scripts already built. Check the discussions for guidelines on Kubernetes, which has been figured out. |
Beta Was this translation helpful? Give feedback.
-
I'm starting with this project as a base, but have some unique constraints for my deployed environment that preclude using Supabase out of the box (essentially I need to host totally sandboxed, with Kubernetes orchestration). To that end, I'm planning on a fairly major refactor that will take one of two forms:
Simplifying the backend by replacing Supabase with base Postgres (and minimal other utilities), then refactoring next.js application code to use the simplified backend.
Doing significant backend work by creating and orchestrating individual Supabase images with Kubernetes to replicate the needed functionality, but hopefully leaving the next.js application code itself mostly intact.
I'm leaning towards #2, but would love @mckaywrigley's input on what parts of Supabase the project actually uses (https://supabase.com/docs/guides/getting-started/architecture), to simplify the effort.
I'm also happy to make this effort public if there others are interested in contributing to the process or benefiting from the outcome.
Beta Was this translation helpful? Give feedback.
All reactions