Chatbot UI: Node 18, a migration file you edit by line number, and no commits since August 2024

The maintainer promised an update, and the last commit is from 2024-08-03

The updates section of the README is a message rather than a changelog, and it is worth quoting accurately because it is the project's own statement of intent.

It says the author has heard the feedback and is working hard on a big update. The things named are simpler deployment, better backend compatibility, and improved mobile layouts. And then: be back soon.

The repository is not archived, and the last push was 2024-08-03, which is more than two years before the date this article is being written. There are no GitHub releases, so there is no artefact to compare against and nothing to check whether the announced work arrived.

The support policy in the same file is also about boundaries. Issues are restricted to actual issues related to the codebase, because the project says it is getting excessive amounts of issues that amount to feature requests and cloud provider problems, and questions about setup are directed to a help section in Discussions. Anything unrelated will likely be closed immediately.

So a reader should treat this as a codebase in a pause rather than a project with a cadence.

Three commercial surfaces are attached to an MIT repository

The metadata is unusual and worth stating plainly.

The repository's homepage field is a commercial product with an unrelated name, not the project site. The README separately advertises an official hosted version of the app at its own domain, so a user can try it without installing anything. And there is a sponsorship link to the maintainer with a request to support the open-source work.

The licence is MIT, so the code itself carries none of the restrictions people usually worry about when a commercial product sponsors an open source project. The distinction that matters is about what you get: the repository is an application you run, and the two hosted offerings are products someone else operates.

That distinction has a practical consequence for anyone reading the README. The demo link is a social media post, the hosted link is a service, and the code is a third thing, and the README does not draw a line between what the hosted version has that the repository does not. If you are evaluating this as a base for your own deployment, the repository is the only thing you can read, and the two commercial surfaces tell you nothing about its current state.

Browser storage was replaced by Postgres, and the old layer is still in the tree

The local quickstart contains the most informative paragraph in the file, under a heading that asks why Supabase.

It says that previously the project used local browser storage to store data, and that this was not a good solution for a few reasons: security issues, limited storage, and limits on multi-modal use cases. The replacement was Supabase, chosen because it is easy to use, open source, Postgres, and has a free tier for hosted instances. And other providers will be supported in the future to give more options.

That is a documented architectural reversal with its reasons attached, which is more than most projects of this size offer. It also has a cost: an application whose data lives in the browser is a single-user application by construction, and moving to a server database is what turns it into something several people can share.

The tree suggests the reversal was not finished. There is a database directory and a separate Supabase directory, and the Supabase directory is where the generated types and the migrations live. A leftover data layer from the browser-storage era is the kind of thing that makes a codebase harder to reason about, and nothing in the README says whether the older layer is still used.

You are told to edit a SQL migration at line 53 and line 54

The configuration step in both the local and the hosted paths ends the same way, and it is the instruction most likely to break for a new user.

It says that in the first migration file, a file with a dated name in the Supabase migrations directory, you need to replace two values. The first is a project URL, given at line 53, whose default value refers to a Supabase gateway host inside the local stack, and which the README says can remain unchanged if you do not change the project identifier in the configuration file. The second is a service role key, given at line 54, which you get from the command that prints the local stack's status.

The stated reason for doing this at all is to prevent issues with storage files not being deleted properly.

The problem is the mechanism rather than the intent. A migration file is a record of a schema change, it is normally generated or applied once, and keying an instruction to line 53 and line 54 means the instruction breaks the moment the file is reformatted, reordered, or superseded by a later migration. Editing a migration to carry instance-specific credentials is also a bad habit to copy, because the next person will do the same in a file that is supposed to be shared.

The local loop starts a database before it starts the app

The one command that runs the app locally is a chain, and the first element of it is a database. You clone the repository first:

git clone https://github.com/mckaywrigley/chatbot-ui.git

install its dependencies, install Docker, install the Supabase command line tool, and start the database:

npm install

supabase start

Only then does the start script run: it starts Supabase, generates the database types, and then runs the development server. The other scripts follow the same shape, restarting stops Supabase and starts it again, and updating pulls from the default branch, runs the migrations, and regenerates the types.

The environment setup has the same shape. You copy an example file to a local one, you run the command that prints the local stack's status, and you copy values out of its output into the file, with a note that the value you want for one variable is labelled as an API URL in that output. There is also a line explaining that if the environment variable is set, the corresponding input in the user settings is disabled, which is a small courtesy that tells you the settings screen reads from the environment.

Two practical consequences. The development loop needs Docker running, because the database runs in containers, and the README pins the runtime: it says to use a compatible Node version, giving version 18 as the example. Version 18 is past its end of life, and an application whose own documentation names it is telling you something about the age of the setup.

Types are generated from the running database, so a type check needs a live one

The type generation step is a single command that asks the command line tool to generate TypeScript types from the local database and redirect them into a file inside the Supabase directory.

Read the scripts around it and the design becomes clear. The migration script applies the migrations and then regenerates the types. The reset script resets the database and regenerates the types. The start script starts the database and regenerates the types. And the hosted update path, after pulling, runs the migration and the type generation, and for a live instance pushes the database separately.

So the type definitions are not checked in as source. They are an output of a running database, and every workflow that changes the schema has to run the database first.

That is a reasonable design when the database is the contract, and it has a cost that lands on the type check. A type error introduced by a schema change cannot be found without starting Supabase, which means the cheapest check in the toolchain is the one that needs the most infrastructure. For a contributor without Docker, that is the first thing that will not run.

Four model clients, all at early versions, against a claim of any model

The description is two words long: AI chat for any model. The dependency list is where that claim is tested.

There are four model client libraries, and every one of them is at an early version: a client for one major provider's model family, a beta release of another provider's OpenAI-compatible client, a client at an initial minor version for a third, and a client at version zero point zero for a fourth. Next to them sit a schema reference parser, a form resolvers library, and a long list of unstyled interface primitives from a component library, which is the conventional way to build a design-system-free interface.

So the honest description of this project is a chat interface with first-party integrations for four providers plus whatever the OpenAI-compatible path reaches, rather than a model-agnostic abstraction. The abstraction, if there is one, is the code that has to absorb four client libraries which were all young at the time of the last commit.

That is the part of a two-year pause to check first. The interface will have drifted with the frameworks it sits on, and the model clients have had two years of breaking changes to absorb without anyone committing a fix. The tests are configured and the repository has a test directory, so the question is whether anyone is running them.

Editorial conclusion

Use Chatbot UI if you want a self-hosted chat interface with your own database and your own model provider keys, and you are prepared to own the deployment rather than consume a product. Do not adopt it expecting the announced update, because the maintainer's note promises simpler deployment, better backend compatibility and better mobile layouts while the last commit is dated 2024-08-03, and the four model client libraries in the manifest are all at early versions that have had two years to drift. Before you start: read the migration file edit carefully, because it is keyed to line numbers and the file is regenerated, and expect the local development loop to require a running database, since the TypeScript types are generated from it. If you need something maintained, compare the effort of running this against the maintained alternatives rather than assuming this one is where to begin.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository