WebDataStudio

[fgilde]

Name of the Script

WebDataStudio (webdatastudio.sh)

Script Type

CT (LXC Container)

Does this script support arm64?

arm64 not tested — the release publishes webdatastudio-linux-arm64.tar.gz beside the x64 one and
both scripts pick by dpkg --print-architecture, but I only have an amd64 host to test on.

📋 Script Details

What it is: a database client that runs on the server instead of on one laptop — PostgreSQL,
MySQL/MariaDB, SQL Server, SQLite, Oracle, DuckDB, ClickHouse, MongoDB and Redis from a browser tab,
with a schema explorer, a SQL editor with completion and history, a visual query builder, result
charts, ER diagrams drawn from the foreign keys, schema editing, a column-by-column comparison of two
connections, saved and scheduled queries with file export, and an MCP endpoint for AI agents.
MIT, and I am its developer.

• Source: https://github.com/fgilde/WebDataStudio · docs https://fgilde.github.io/WebDataStudio/
• Releases: https://github.com/fgilde/WebDataStudio/releases

The scripts are written and tested. Pull requests from forks are not open on this repository, so
they are on a branch instead — ready to be pulled in as-is or picked apart:

https://github.com/fgilde/ProxmoxVED/tree/webdatastudio → ct/webdatastudio.sh,
install/webdatastudio-install.sh, json/webdatastudio.json
(diff: main...fgilde:ProxmoxVED:webdatastudio)

How it installs: bare metal, no Docker. The project publishes a self-contained .NET build per
architecture, so it is fetch_and_deploy_gh_release "webdatastudio" "fgilde/WebDataStudio" "prebuild",
one systemd unit and one generated password. Port 8095, Debian 13, unprivileged, updateable: true
through check_for_gh_release, with create_backup / restore_backup around the update. Config, the
database and the encryption key for stored connection secrets live in /opt/webdatastudio_data, so an
update keeps them.

Why the installer generates a password: with neither WDS_USER nor WDS_PASSWORD set the studio
serves without a login screen at all, and it holds the credentials of every database it connects to.
The installer writes both and drops them in ~/webdatastudio.creds, the way aliasvault does.

Tested on real hardware (Proxmox VE 8.2.2, kernel 6.8.4-2-pve):

• Full run of ct/webdatastudio.sh: container created, release 1.3.0 fetched, service created,
  Completed Successfully.
• http://<ip>:8095/ → 200 · /api/connections without a session → 401 · login with the generated
  credentials → 200 · systemctl is-active/is-enabled → active/enabled.
• update inside the container → No update available: webdatastudio (1.3.0).
• Worth knowing for older hosts: that host refuses to create a Debian 13 container
  (unsupported debian version — its LXC stack predates the template), so the verified run used
  var_version=12. The script keeps 13 as the default, per the guidelines.
• The test container was destroyed afterwards and the host left as it was found.

Written with AI assistance and reviewed against AGENTS.md: Claude Opus 5 (Claude Code), high
reasoning effort. What the review changed: a hand-written curl became fetch_and_deploy_gh_release,
a hand-written version check became check_for_gh_release, and the unit's working directory was
corrected after the app answered 404 to every request from the wrong content root.

One thing stated plainly: the app is actively maintained and publishes official release tarballs,
but it is not 6 months old and has nowhere near 600 stars — first release August 2026. If that
alone closes this, no hard feelings; the branch is there if you would rather keep it for later.

[MickLesk]

We have currently an PR Stop in DEV Repo - and your script doesnt meet the min. requirements, come back if they meet the requirements