Install On-Premises and Configure Agentless Connections

Install the Datasentinel platform on a single Linux server, then connect your PostgreSQL instances agentlessly, with no agent to deploy on the database hosts.

This guide takes you through the fastest path to a self-hosted Datasentinel: install the platform on a single Linux server, then register your PostgreSQL instances from the platform itself, with no agent to install on the database hosts.

It is the right pattern for cloud-managed databases (RDS, Aurora, Cloud SQL, Azure, AlloyDB), containerized PostgreSQL (Kubernetes, Docker), and any environment where deploying agents per host is impractical.

Why on-premises + agentless

Benefit

What it means

One machine to install

The platform bundles InfluxDB, Grafana, an embedded PostgreSQL, the Datasentinel backend, and an internal pool of agents.

Reach managed services

The platform PULLs metrics directly from RDS, Aurora, Cloud SQL, Azure, AlloyDB and any container-hosted PostgreSQL where you can't install an agent.

Centralised configuration

Add, tune, or pause connections from the platform UI or the Platform API (no per-host CLI rounds).

One thing to upgrade

Internal agents follow the platform automatically: upgrade once and you are done.

Part 1: Install the on-premises platform

This part is a guided walkthrough of the most common path.

For the full reference (every installer flag, log-file locations, systemd commands, the status API, and component management), see Installation › Platform.

Prerequisites

Requirement

Detail

Operating system

RHEL / Rocky / AlmaLinux 8 or 9, SLES 15, or Debian Bullseye. Contact support for other distributions.

License key

Either a 60-day trial key or a commercial key from support.

Sizing

Scales with the number of monitored instances. Defaults below assume 14-day retention.

Privileges

root is required for the one-time install only. Afterwards everything runs as the application user.

Recommended sizing:

Instances

CPUs

Memory

Storage

1 – 10

8 GB

25 GB

11 – 50

16 GB

50 GB

51 – 100

32 GB

75 GB

101 – 200

64 GB

100 GB

> 200

96 GB

150 GB

Use a virtual machine you can resize later.

Set vm.swappiness=1 (or disable swap) for stable memory behaviour.

Open the network

Two firewall concerns matter in agentless mode:

Inbound to the platform. NGINX terminates everything on port 443 by default (UI + API). Open it to your users and to any local agents you might add later.
Outbound from the platform to PostgreSQL. The platform PULLs metrics directly, so it must reach every monitored instance on its PostgreSQL port (typically 5432, or the cloud-provider equivalent).

SELinux must be set to Permissive or Disabled on the platform host.

Enforcing mode blocks internal traffic and stops components from starting.

Symptom: a 502 error in the UI even when every service is running. See How to configure SELinux.

Install in under five minutes

Download the bundle

A single tarball ships the platform, InfluxDB, Grafana, the embedded PostgreSQL, and the internal agent pool (around 690 MB).

File

RHEL / Rocky / AlmaLinux 8

install-datasentinel-platform-rocky8-latest.tar.gz

RHEL / Rocky / AlmaLinux 9, SLES 15

install-datasentinel-platform-rhel9-latest.tar.gz

Debian Bullseye

install-datasentinel-platform-debian-bullseye-latest.tar.gz

wget https://app.datasentinel.io/ds-api/download/install-datasentinel-platform-rhel9-latest.tar.gz

Install NGINX

NGINX is the entry point. Install it before the Datasentinel installer runs.

dnf install -y nginx     # RHEL / Rocky / AlmaLinux
# apt install nginx      # Debian

Run the installer as `root`

Unpack the bundle and launch init_datasentinel.sh. It runs in under two minutes.

tar xvzf install-datasentinel-platform-rhel9-latest.tar.gz
./init_datasentinel.sh

The script prompts for the application user (default datasentinel) and the listening port (default 443), creates /datasentinel/, deploys all components, registers systemd services, and starts everything.

Use ./init_datasentinel.sh -d for a silent install with default values.

Replace the self-signed certificate (optional)

The installer ships a self-signed certificate at /etc/nginx/certs/. To use your own:

Copy your certificate and key over cert_datasentinel.pem and key_datasentinel.pem.
Reload NGINX:
```
/usr/sbin/nginx -s reload
```

URL: https://<<server_name>>
User: datasentinel
Password: shown at the end of the installer output

Then follow Update the license token to activate your key.

Verify the platform is healthy

From the platform host:

status_datasentinel        # alias available as the datasentinel user

Or hit the API:

curl -k https://localhost/ds-api/

You should see "status": "OK" and every service reported as "running": true.

Part 2: Configure agentless connections

With the platform up, you can register PostgreSQL instances without installing anything on the database hosts.

The platform uses its internal pool of agents to PULL metrics directly.

Each monitored cluster still needs the pg_stat_statements extension and a read-only monitoring user reachable from the platform.

The Onboard Your First PostgreSQL Cluster guide walks through both.

Register a connection

Open the Tools menu and click Agentless settings.
Click Add connection and fill in host, port, monitoring user, password, and tags.
Save. The instance appears on the Home dashboard within a minute.

A short animated walkthrough of the same dialog is available on the Agentless Monitoring reference page.

The same operation as a one-liner, perfect for scripting bulk onboarding from CI/CD.

cat > /tmp/connection.json <<EOF
{
  "host": "pg-sales-1734",
  "port": 5432,
  "user": "datasentinel",
  "password": "myPassword",
  "tags": "application=sales,environment=production,provider=aws,datacenter=eu-west-1"
}
EOF

curl -sk \
  --header "user-token: $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  -X POST https://$DATASENTINEL_HOST/ds-api/pool/pg-instances/sales-production \
  -d @/tmp/connection.json

{ "status": "Connection created and connected!" }

See the full recipe in Automate with the API.

Apply a consistent tagging scheme at creation time: tags drive filtering, consolidation, and role-based access.

See Organize Content using Tags.

A note on system metrics

In agentless mode, the platform doesn't have shell access to the database host, so CPU / memory / I/O metrics aren't collected by default.

Two options:

Install the system_stats extension on the cluster. It exposes OS metrics through SQL.
For managed services where you can't install extensions or reach the OS (RDS, Aurora, Cloud SQL…), rely on the provider's own host metrics and use Datasentinel for PostgreSQL-side observability.

Tune collection limits (since v2025.11)

Table and query monitoring limits apply centrally to every agentless instance:

Edit the config file

/datasentinel/soft/datasentinel_backend/config/datasentinel.yml

Set your limits

agent:
  tables-monitoring-limit: 5000
  query-monitoring-limit: 15000

Restart the dispatcher

sudo systemctl stop datasentinel_dispatcher
sudo systemctl start datasentinel_dispatcher

These limits apply to all agentless instances.

To tune a single connection independently, use an agent-based deployment for that instance instead.

Where to go next

Onboard Your First PostgreSQL Cluster: extension, monitoring user, and a tagging scheme that scales.

Monitor Cloud-Managed Instances: RDS, Azure, Cloud SQL specifics on top of agentless.

Manage Users and Role-Based Access: turn the tags you set above into per-team access rules.

Automate with the API: bulk-register connections and operate the platform as code.

Conclusion

A single Linux server, one installer, and a handful of HTTPS calls is everything that stands between you and a fully self-hosted Datasentinel monitoring fleet of agentless PostgreSQL instances.

Add hosts agentlessly when you don't control the OS, install local agents when you need OS-level depth, and mix both freely as your estate evolves.

PreviousGenerate, Email, and Schedule PDF Reports NextOnboard Your First PostgreSQL Cluster

Last updated 21 days ago