[Support] libredb - LibreDB Studio

I maintain the LibreDB Studio template in Community Applications, where it is listed as LibreDB Studio. It has been there since early August and I never opened a thread for it, which is my fault, and it meant anyone who ran into trouble had nowhere obvious to ask. So here is the thread, and I will be watching it.

LibreDB Studio is a self hosted database client that runs in a browser tab, MIT licensed. The drivers most likely to matter on a server here are PostgreSQL, MySQL and MariaDB, SQL Server, Oracle, SQLite, MongoDB, Redis, ClickHouse, Elasticsearch and Cassandra, and there are more than that; the current list lives in the repo README rather than in this post so it does not go stale. What you do with it is point it at a database you already run, browse the schema, write and run queries, and edit rows in the results grid. There is more in there than that, charting and a schema diagram and snapshots and a monitoring dashboard, but the editor and the schema browser are the part people actually live in. It does not back your database up or manage the database server itself, and if you already have a desktop client you are happy with, this is not trying to take its place.

Project: https://github.com/libredb/libredb-studio

Container image: ghcr.io/libredb/libredb-studio:0.14.1, built for amd64 and arm64

Unraid template: https://github.com/libredb/unraid-templates/blob/main/templates/libredb-studio.xml

Bugs in the application itself: https://github.com/libredb/libredb-studio/issues

Updating from an older install

The template shipped 0.9.66 from early August until I updated it on 7 September, so if you installed before then you have been running an image that is several releases behind. It now points at 0.14.1. No variable names changed and existing appdata is picked up as it is, but this is a jump across a lot of releases, so copy /mnt/user/appdata/libredb-studio somewhere before you press update. I have not tested going back down to 0.9.66 afterwards, so treat that copy as your only way back. What I did test before pushing the template was the upgrade itself: started 0.9.66 with the template's own values, saved a connection, then brought 0.14.1 up on the same appdata, and the saved connection was still there. If yours goes wrong anyway, post the log here with the version you came from and I will work through it with you.

Before you hit Apply

ADMIN_EMAIL and ADMIN_PASSWORD are your login and JWT_SECRET signs the session token. One thing worth knowing early is that the two admin variables are read from the environment at every login rather than copied into an account on first start, so if you forget the password you edit ADMIN_PASSWORD, restart the container, and the new value is the password from then on. JWT_SECRET has to be at least 32 characters, and if it is shorter the container prints the length it got and stops rather than starting into a state where every login fails. If you would rather not think about it, run openssl rand -hex 32 in the Unraid terminal and paste the result in. The template asks for 8 characters or more on the admin password, which is advice rather than something the app enforces, but it is the right side to err on for something that reaches your databases.

The web UI listens on container port 3000 and the template puts the host side on 3006, since 3000 collides with a lot of what people already run. Move it if 3006 is taken as well. Appdata is /mnt/user/appdata/libredb-studio mapped to /app/data, and everything the app keeps for itself lives in there. There are 3 more variables under the advanced view, STORAGE_PROVIDER, STORAGE_SQLITE_PATH and AUTH_COOKIE_SECURE, and the next section is really about those.

Things that will look like bugs and are not

STORAGE_PROVIDER has to stay as sqlite. It is the setting that decides whether your connections and saved queries live on the server or only in the browser you happened to be using at the time, and if you blank that field the app falls back to browser storage without a word in the log, which later looks like your work vanished when you open it from another machine. The template fills it in correctly, so this only bites people who have been through the advanced view and cleared it. If you want to be sure, open http://YOUR-SERVER:3006/api/storage/config and you should see provider sqlite and serverMode true.

The appdata folder will not be empty after you install, but the file you are probably looking for will not be there yet. The container seeds a small sample database, sample-employees.db, and a sample.libredb file at startup, while libredb-storage.db, which is where your own connections and saved queries go, is only created on the first write. Log in, save something, and it turns up.

Once it does turn up, libredb-storage.db sits at 4096 bytes while the content is in libredb-storage.db-wal beside it, with a -shm file as well, because SQLite is running in WAL mode. The size of the .db file tells you nothing about whether your data is there, and it will not move until SQLite checkpoints. If you want to check for real, save a connection, restart the container, and see whether it is still there.

AUTH_COOKIE_SECURE is false on purpose. Unraid serves this over plain HTTP on the LAN, and with it set true the login request itself succeeds, the log even records a successful login, but the cookie comes back marked Secure and your browser throws it away, so you land back on the login screen with nothing anywhere that reads like an error. Set it true once the app is behind HTTPS through a reverse proxy, and do it at the same time as the proxy rather than in advance.

Support

Post here for anything to do with the container or the template and I will answer. Faults in the application rather than the packaging are better on the issue tracker linked above, though I would rather you posted in the wrong one of the two than not at all. When something is broken, the container log from the Docker tab plus your Unraid version, whether the box is amd64 or arm, and which variables you changed is usually enough for me to work out what happened.

Edited Monday at 10:25 PM1 day by libredb