temBoard

• In the Azure Portal, choose Create a resource and search for temBoard on Ubuntu 24.04 LTS by SecureAnyCloud.
• Select the offer and choose Create.
• Choose your subscription, resource group and region.
• Set the virtual machine size to Standard_B2s or larger.
• Under Administrator account, select SSH public key and supply your key. The admin username is azureuser.
• Under Inbound port rules, allow SSH (22) and Custom (8888).
• Select Review + create, then Create.

# Create a resource group az group create --name temboard-rg --location eastus
# Create the virtual machine from the sac offer az vm image terms accept --urn sac1647283583153:temboard-ubuntu-24-04:default:latest az vm create \
  --resource-group temboard-rg \
  --name temboard-vm \
  --image sac1647283583153:temboard-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
# Open the console port az vm open-port --resource-group temboard-rg --name temboard-vm --port 8888 --priority 1010
# Retrieve the public IP address of the new virtual machine az vm show -d --resource-group temboard-rg --name temboard-vm --query publicIps -o tsv

ssh azureuser@<vm-ip>

Three services make up the appliance. Check that all three report active:

systemctl is-active postgresql@16-main temboard temboard-agent@16-main

The output looks like this:

active active active

Confirm the installed versions:

temboard --version temboard-agent --version

The console is the only service that should answer from outside the machine. Check which ports are listening:

ss -tlnH | grep -E ':(8888|2345|5432) ' | awk '{printf "%-8s %-24s\n", $1, $4}'

The output looks like this. Only 8888 is bound to a wildcard address:

LISTEN 0.0.0.0:8888 LISTEN 127.0.0.1:2345 LISTEN 127.0.0.1:5432

Confirm that the agent is unreachable off-host:

IP=$(hostname -I | awk '{print $1}')
curl -sk -m 6 -o /dev/null -w 'agent from off-host: HTTP %{http_code}\n' "https://$IP:2345/discover" || echo "connection refused — agent is host-local"

The kernel-level fence is independent of the application configuration. Check it:

systemctl show temboard-agent@16-main.service -p IPAddressDeny -p IPAddressAllow

The stock credential is rejected, the agent is unreachable off-host, and the fail-closed secret guard reports no problems.

Every virtual machine generates its own credentials on first boot. Read them with:

sudo cat /stage/scripts/temboard-credentials.log

The file has mode 0600 root:root. It contains the console URL, the admin username and password, and the repository database credentials.

The image ships an end-to-end self-test. It does more than check that the service is up. It generates real database activity, verifies that monitoring data accumulates and keeps growing, and then performs a real administration action:

sudo /usr/local/sbin/temboard-selftest.sh

The test takes about four minutes. It samples the metric row count across a collection interval to show that collection is live and not a single stale batch.

The self-test confirms three things. The stock credential is refused. Monitoring rows grow across a sampling interval. A backend is terminated through the console and is confirmed gone from pg_stat_activity.

The repository database holds the collected metrics. Confirm that the bundled instance is registered:

sudo -u postgres psql -d temboard -c "SELECT substring(hostname,1,28) AS hostname, agent_address, agent_port FROM application.instances"

Confirm that samples are accumulating and are recent:

sudo -u postgres psql -d temboard -c "SELECT count(*) AS samples, max(datetime) AS newest FROM monitoring.metric_sessions_current"

Confirm that the collector is healthy:

sudo -u postgres psql -d temboard -c "SELECT status, last_pull, last_insert FROM monitoring.collector_status"

The bundled repository database holds the registered instance, the accumulated metric samples and a healthy collector.

Open https://<vm-ip>:8888/ in a browser. The console serves a self-signed certificate generated on this virtual machine's first boot, so your browser warns you on your first visit. Accept the warning, or put a trusted certificate in front of the console (Step 15).

Sign in as admin with the password from Step 6.

The temBoard sign-in page. The documented default password does not work on this image.

After you sign in, you land on the instance inventory, which already shows the bundled PostgreSQL:

The bundled PostgreSQL 16 instance, registered automatically at first boot.

Select the instance to open its dashboard. It shows live gauges for CPU, memory, cache hit ratio and sessions, load average and transactions-per-second charts, and a full alerting status grid:

Live figures within minutes of first boot, with no configuration.

The Monitoring tab plots the metrics accumulated in the repository. Use the time-range selector at the top right. On a freshly booted machine, choose Last 1 hour so that the available history fills the chart:

Load average and CPU usage plotted from real collected samples.

This image retains metrics for 90 days. temBoard's own default is 730 days, which grows without bound on a single-disk appliance. Query statistics are retained for 7 days. To change these values, edit /etc/temboard/temboard.conf:

sudo grep -A2 '^\[monitoring\]' /etc/temboard/temboard.conf

The Activity tab turns temBoard from a dashboard into an administration console. It lists running, waiting and blocking backends. Select any of them and choose Terminate.

To see it work, open a long-running query in another SSH session:

sudo -u postgres psql -d postgres -c "SELECT pg_sleep(90)"

Reload the Activity tab. The backend appears in the Running list:

Live backends with CPU, memory and I/O per session. Select one and choose Terminate to end it.

The Configuration tab reads and writes the managed instance's postgresql.conf. Settings are grouped by category and searchable. temBoard reloads the instance, or flags that a restart is required:

Editable PostgreSQL settings, applied to the managed instance from the console.

The bundled instance demonstrates the product. To manage your own databases, install an agent beside each one. The agent must run on the same host as the PostgreSQL instance it manages. Remote agents are not supported.

On the machine running your PostgreSQL server

Add the Dalibo Labs repository and install the agent:

echo "deb http://apt.dalibo.org/labs $(lsb_release -cs)-dalibo main" | sudo tee /etc/apt/sources.list.d/dalibo-labs.list
sudo curl -fsSL -o /etc/apt/trusted.gpg.d/dalibo-labs.gpg https://apt.dalibo.org/labs/debian-dalibo.gpg
sudo apt update && sudo apt install -y temboard-agent

Configure the agent against your temBoard console. <vm-ip> is the address of your temBoard virtual machine:

sudo /usr/share/temboard-agent/auto_configure.sh https://<vm-ip>:8888

The script prints the agent's TCP port and configuration path. Fetch the console's signing key, then start the agent:

sudo -u postgres temboard-agent -c /etc/temboard-agent/16/main/temboard-agent.conf fetch-key
sudo systemctl enable --now temboard-agent@16-main

Register it with the console

On the temBoard virtual machine, run the following. <private-ip> is the address of the machine that runs the agent:

sudo -u temboard temboard register-instance <private-ip> 2345 --environment default --if-not-exists

Alternatively, use Settings -> Instances -> Add new instance in the web console.

Restrict the agent's exposure. An agent that manages a remote server must be reachable by the console, so it cannot be loopback-only like the bundled one. Restrict its port to the console's address with a network security group rule or a host firewall. Never leave it open to the internet.

The console generates a self-signed certificate on first boot. To use a trusted certificate, point ssl_cert_file and ssl_key_file in /etc/temboard/temboard.conf at your own certificate and restart the service. Alternatively, terminate TLS at an Azure Application Gateway.

# Status systemctl status temboard --no-pager
# Restart the console
sudo systemctl restart temboard
# Restart the agent for the bundled instance
sudo systemctl restart temboard-agent@16-main
# Console logs
sudo tail -n 50 /var/log/temboard/temboard.log
# Agent logs
sudo tail -n 50 /var/log/temboard-agent/temboard-agent.log

/etc/logrotate.d/temboard rotates both log files daily. Each file is capped at 50 MB and 14 generations are kept, so logs cannot fill the disk.

The console will not start. A fail-closed guard runs before the service. It refuses to open the listener if any published default secret is still in effect. Run the guard directly to see what it objected to:

sudo /usr/local/sbin/temboard-secret-guard.sh

First boot did not complete. The console and agent are gated behind a marker that first boot writes, so neither starts until credentials exist:

journalctl -u temboard-firstboot.service -n 20 --no-pager sudo tail -n 40 /var/log/sac/sac-firstboot.log 2>/dev/null || echo "no first-boot log yet"

The instance shows no data. The agent probes every 30 seconds and the console pulls every 60 seconds, so wait two or three minutes after boot. Then check the collector:

sudo -u postgres psql -d temboard -c "SELECT status, last_pull, last_insert FROM monitoring.collector_status"

• Restrict access. Limit inbound 8888 and 22 to your own address ranges in the network security group.
• Use a trusted certificate. Replace the self-signed certificate before you expose the console broadly.
• Use individual accounts. Change the admin password after your first login, and create individual accounts under Settings -> Users instead of sharing the admin login. temBoard records who performed each administrative action.
• Keep the bundled services on loopback. Leave the bundled agent and PostgreSQL bound to loopback. Normal operation never requires exposing them.
• Keep the machine patched. Run sudo apt update && sudo apt upgrade.

temBoard is distributed under the PostgreSQL Licence, a permissive BSD-style licence. PostgreSQL is also distributed under the PostgreSQL Licence. There are no subscription or licence fees for the software in this image.

SecureAnyCloud provides 24/7 support for the image itself, its first-boot provisioning and its configuration.

Deploy on Azure

Find temBoard on Ubuntu 24.04 LTS in the Azure Marketplace.

Need Help?

Contact SecureAnyCloud support at sales@secureanycloud.com.

Deploy on Azure

Launch temBoard on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com