# temBoard, one web interface for a fleet of PostgreSQL instances > dalibo/temboard is an agent plus web application pair for administering PostgreSQL at fleet scale, with dashboards, session management, bloat tracking with scheduled vacuum, slow query analysis and configuration tuning. It is Python on the server side and a packaged UI, released under the PostgreSQL licence rather than an OSI licence. **dalibo/temboard** — PostgreSQL Remote Control - Repository: https://github.com/dalibo/temboard - Website: https://labs.dalibo.com/temboard - Stars: 769 · Forks: 80 - Language: Python - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/dalibo-temboard ## Two pieces: an agent on every server and one web app temBoard's stated purpose is to monitor, optimize and configure multiple PostgreSQL instances from a unique web interface, and the architecture follows from that. The project is composed of two services. A lightweight agent has to be installed on every PostgreSQL server you want to manage. A central web app controls the agents and collects the metrics. That split is the standard shape for infrastructure monitoring, and it has the usual consequences: the agent needs to be deployed and kept up to date on every host, and the central application is a component that needs its own availability and its own database. The feature list from the README covers the administrative surface rather than the monitoring surface, and it is worth reading as a list of jobs that are tedious with psql alone. Managing hundreds of instances in one interface is the headline. There are fleet-wide and per-instance dashboards. PostgreSQL is monitored with advanced metrics. Running sessions can be managed, so you can see what is connected and terminate what should not be. The three features that go beyond observation are the interesting ones. Tracking bloat and scheduling vacuum on tables and indexes is a maintenance task that most teams do manually or not at all, and having the tool identify the bloated relations and schedule the work is real value. Tracking slow queries is the second, since it turns the vague question of which query is hurting into a list. Tweak PostgreSQL configuration is the third, and the word tweak is doing quiet work, since it implies small adjustments with a comparison view rather than wholesale changes. The operational features around those are Prometheus support, a remote management surface, and the PostgreSQL licence, which is the same permissive-with-attribution style as PostgreSQL itself. ## Running the Docker environment for evaluation The README points at a complete testing environment based on Docker and a quickstart guide, and the docker-compose.yml in the repository shows what that environment contains. It is more elaborate than a single database, which tells you something about how the project expects to be tested. The compose file defines a repository service that stores the temBoard data itself, running a postgres:18-alpine image with log_statement and log_connections turned on and a log_line_prefix that includes the timestamp, process id, user, client host, database and application name. That logging configuration is not decoration, since a monitoring tool needs its own database to record query history and session data. It also defines a mock SMTP server, using the mailhog image with ports 1025 and 8025 exposed. That is for the alerting by email feature, and a mock server means the development environment does not send real mail. Then there are the PostgreSQL instances themselves, the first being postgres0, which mounts a home volume, a run volume and a WAL archive volume, and starts through a custom entrypoint script that sets up replication. It also mounts a SQL file that creates the pg_stat_statements extension, which is how slow query tracking gets its data. The exposed port is 15432 rather than 5432 so it does not collide with the repository service, and the note in the compose file explains that the port is important for the dev/bin/switchover.sh script. The dev/postgres-setup-replication.sh script runs at container init through the docker-entrypoint-initdb.d directory, and the PEER_HOST environment variable points at the second instance. So the environment includes a replication pair, which is a sensible way to exercise failover behaviour rather than testing it only in theory. ## The development build and its toolchain The Makefile in the repository gives a good picture of how the project is built, and it is a uv-based Python workspace with a separate front end. The pyproject.toml is explicitly marked as a virtual project to manage a single development environment, with the note that the temboard-workspace project must never be built or released. The real packages are the uv workspace members: agent, ui and toolkit, mapped to the distribution names temboard-agent, temboard and temboard-toolkit, all installed as editable from the workspace. The Python requirement is 3.9 up to but not including 3.14, and ruff is configured with target-version py39, with import sorting enabled and one rule ignored. The end-to-end test group is telling: httpx, pytest, pytest-mock, pytest-tornado, selenium, tenacity and sh. Selenium in the test dependencies means there is a browser-driven end-to-end suite, and the Makefile has a restart-selenium target for the development selenium container. The main development target is a version-parameterised one, and the pattern target generates a Python virtual environment for the requested version: ```bash docker compose up -d repository ``` That command brings up the database that stores the temBoard data, and the Makefile then waits for it with a retry loop before running the create_repository.sh script from the ui/share directory to initialise it. The build sequence in the develop target covers the whole stack: it checks the Docker version against a maximum of 30, installs the Python dependencies for the requested version, builds the Prometheus binary and promtool into ui/build/bin, runs npm install-clean and npm run build in the ui directory for the front end, then builds the agent image and brings the compose stack up. The final message tells the developer they can now execute the temBoard UI. The repository also carries a CHANGELOG.md, a CONTRIBUTING.md with details referenced from the Makefile help, and a mkdocs.yml for the documentation. ## Packaging, releases and the licence question temBoard provides packages for RHEL and its clones as well as Debian, and the documentation site at temboard.readthedocs.io carries the installation instructions. The upstream project is Dalibo, a French company whose Labs division hosts the project, and the homepage in the repository is labs.dalibo.com/temboard. The release history shows a major version transition in late 2025. Version 10.0rc1 was cut on 2025-12-01, 10.0rc2 on 2025-12-03, and 10.0.0 on 2025-12-08. The last push to the repository was on 2026-10-22, so the project is still being worked on after the 10.0 release. The licence deserves a note. The README says temBoard is available under the PostgreSQL License, and the repository's licence field says it is a custom licence GitHub cannot classify. That is not a defect. The PostgreSQL Licence is a well-known permissive licence, a BSD-style licence with a clause that says you cannot claim the software is endorsed by the PostgreSQL Global Development Group. It is OSI approved in spirit and widely used for PostgreSQL-adjacent tooling. It is not one of the SPDX identifiers GitHub recognises, which is why the classifier says custom. For a team with a policy that requires a specific SPDX identifier in a dependency inventory, that is a small friction point worth flagging to whoever owns the policy, not a blocker. The project is also, by its own account, an open project: the README says contributions are welcome and points at the contributing guide, and the CircleCI badge in the header shows continuous integration is part of the workflow. ## How temBoard compares to the built-in tools and to other dashboards PostgreSQL itself gives you pg_stat_statements, pg_stat_activity and the statistics views, and the honest comparison starts there. Everything temBoard does for a single instance, you can do with psql and a query against those views. What temBoard adds is repetition and reach. With a handful of servers, a monitoring agent per host is overhead. With a few hundred, it is the only way to get a fleet-wide view without writing the collection yourself, and the dashboards exist because that view is what an administrator actually looks at. Against the dedicated PostgreSQL monitoring tools, the difference in approach is scope. A tool built only for monitoring gives you metrics and alerts, and stops there. temBoard includes the write operations, meaning you can terminate a session, schedule a vacuum and change a configuration parameter from the same interface where you saw the problem. That is convenient and it is also the part that carries risk, since an automated vacuum schedule that fires on a misread bloat figure causes a production incident. The other comparison is with cloud-managed PostgreSQL, where the provider supplies a dashboard and metrics. temBoard is independent of the hosting, which matters for a fleet that is split across providers or runs on your own machines. The realistic bar for adoption is whether the operations you do today are repetitive enough to be worth automating. If you routinely log into ten servers to check bloat and kill a stray session, the answer is yes. If you have one database that one person knows well, the answer is no, and psql plus a monitoring agent is enough. ## Conclusion Adopt temBoard if you administer a fleet of PostgreSQL instances and want one place to see bloat, slow queries, live sessions and configuration drift, and you can accept an agent installed on every server. Skip it if you run a single instance, since the setup cost of an agent plus a central application is not repaid by one database. Verify first by running the Docker quickstart environment, then check that the agent on a representative server reports the metrics you rely on, especially the bloat and vacuum figures, before you schedule anything from it. ## FAQ ### What is temBoard and what does it manage? temBoard is a tool for monitoring, optimizing and configuring multiple PostgreSQL instances from one web interface. It provides fleet-wide and per-instance dashboards, advanced metrics, session management, bloat tracking with scheduled vacuum, slow query tracking and configuration tuning. ### What are the two components of temBoard? A lightweight agent that you install on every PostgreSQL server you want to manage, and a central web application that controls the agents and collects the metrics. Packages are provided for RHEL and clones as well as Debian. ### What does the temBoard Docker environment include? The compose file defines a repository PostgreSQL instance that stores the temBoard data, a mock SMTP server for testing email alerting, and PostgreSQL instances including a replication pair configured through dev scripts, with pg_stat_statements created so slow query tracking has data. ### Under what licence is temBoard released? The PostgreSQL License, which the README links and which GitHub cannot classify as a standard identifier. The repository's licence field therefore reports a custom licence, and the LICENSE file holds the actual terms. ### How does temBoard compare with using psql and the PostgreSQL statistics views directly? For a single instance the built-in views give you the same raw data. temBoard earns its place at fleet scale, where collecting from many servers by hand is impractical, and it adds write operations such as session termination, scheduled vacuum and configuration changes that psql does not automate. ## Sources - [dalibo/temboard on GitHub](https://github.com/dalibo/temboard) - [Issues](https://github.com/dalibo/temboard/issues) - [Project website](https://labs.dalibo.com/temboard) - [README](https://github.com/dalibo/temboard/blob/master/README.md) - [Releases](https://github.com/dalibo/temboard/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dalibo-temboard