Logstag
Outbound only
The agent connects out to Logstag over HTTPS on port 443. It opens no listening port, so nothing connects in.
Security
How Logstag handles your data.
What the agent does on your hosts, what leaves your network, and how the Logstag app handles it. Each statement here is checked against the product as it ships today.
Last reviewed: 4 October 2026
logstag.com/security · Logstag security overview
At a glance
Read-only access
It reads system views and statistics with a monitoring user you create. That user needs no write access to your data.
No table rows
Table rows, MongoDB documents and Redis or Valkey key values stay in your network. Query text has engine-specific caveats, listed below.
No remote SQL or shell
Logstag can send the agent only a fixed set of commands. None of them runs SQL or shell commands, or points the agent at a new host.
The agent
One agent can monitor several databases, on the same host or elsewhere in your network. It runs on Linux and Windows, or in Docker.
| Build | A Rust binary with the C runtime linked in. TLS comes from rustls. The agent does not load OpenSSL or an Oracle client library. |
|---|---|
| Runs as | Linux: a dedicated logstag system user with no login shell, under systemd with PrivateTmp, ProtectHome, ProtectSystem=full and a 1 GB memory limit. Windows: a service running as LocalSystem. |
| Network | Outbound HTTPS to the Logstag API on port 443. Server certificates are verified against the public root list built into the agent, so proxies that inspect TLS with a private certificate authority are not supported. To find its own IP address at startup, the agent asks the operating system for a route to 8.8.8.8, which sends no packet; if there is no route, it tries a TCP connection to 8.8.8.8 on port 53, which your firewall may log. |
| Packages and updates | Packages and update checks come from Logstag; we share the addresses to allow during setup. The agent checks for a new version once a day and installs it. Set update_check_enabled = false or auto_install_updates = false in the [agent] section of its configuration to turn this off. |
| Commands from Logstag | The agent polls Logstag for commands from a fixed list built into it, such as opening a health-check window or re-testing a configured connection. None runs SQL or shell commands sent by Logstag. Each command times out after 30 seconds. |
| Database access | Read statements against system views and statistics. The only session settings it changes are a lock timeout on SQL Server and a rollback when an Oracle connection returns to the pool. Read-only access comes from the permissions of the monitoring user, so grant only what the setup guide lists. |
| Load on your databases | At most 3 connections per database (10 on Oracle). Schema lists are capped at 1,500 objects, and SQL Server statistics queries cap their memory grant at 10%. |
| Local logs | /var/log/logstag-agent/agent.log on Linux, rotated at 50 MB and deleted after 3 days. The API key is redacted from request logs. |
What leaves your network
Operational metadata and statistics: sessions and waits, query performance statistics, schema and object metadata, users, roles and permissions, and configuration and capacity signals. Activity is collected every 10 seconds, query statistics every minute and configuration every 10 minutes.
Never collected
- Table rows, MongoDB documents, and Redis or Valkey key values.
Query text and object definitions are where the engines differ. This is what you should know before you connect each one:
| PostgreSQL | Normalized on your host before it leaves: literal values become $1, $2. Statements the agent cannot parse are sent as they are. Function and view definitions are sent in full. |
|---|---|
| SQL Server | Sent as Query Store, the plan cache and active sessions expose it. It can include literal values. View, procedure and function definitions are sent in full. |
| Oracle | The first 4,000 characters of each statement, as Oracle exposes it. It can include literal values. |
| MongoDB | Command bodies from active operations are not kept. Startup warnings and recent server log lines are sent, and they can include command details and client addresses unless log redaction is enabled on the server. |
| Redis | Slowlog entries include command arguments, and client lists include client addresses and names. If the monitoring user may run CONFIG GET, the full server configuration is sent, including password settings such as requirepass. |
| Valkey | Slowlog entries include command arguments, and client lists include client addresses and names. If the monitoring user may run CONFIG GET, the full server configuration is sent, including password settings such as requirepass. |
Details per engine are in Data collection and privacy.
The Logstag app
Sign-in and sessions
Email and password. Passwords are hashed with PBKDF2. A failed sign-in does not reveal whether the account exists. The refresh token is kept in an HttpOnly, Secure cookie and replaced each time it is used.
Resets and invitations
Password reset links work once and expire after 30 minutes. Invitations expire after 7 days, and Logstag keeps only a hash of the invitation token.
Roles
Admin manages members, API keys, databases, alerts and integrations. DBA manages databases and alerts. Developer is read-only. Billing manages billing.
Audit log
Admins see the actions signed-in users take in the app: who, what, when and from which IP address. Entries are kept for 30 days.
Support access
Logstag support can open a session as a user in your organization to help with an issue. Successful actions in that session appear in your audit log, marked as a support session. A session lasts at most one day.
Emailed reports
Reports go only to active members of your organization. The download link carries a random token that Logstag stores only as a hash. The file is deleted after 30 days.
AI features. Two features send data to a third-party AI model. Data Inventory, for PostgreSQL and SQL Server, sends schema, table and column names with their data types to classify sensitive columns; it sends no row data. Recommendations in health-check results send the health-check data, which can include query text and login names. A switch to turn these off for one organization is not available yet.
Retention and deletion
| Query statistics, raw | 7 days |
|---|---|
| Session, lock and schema snapshots | 31 days |
| Hourly rollups | 35 days |
| Daily rollups | 1 year |
| Audit log | 30 days |
| Report files | 30 days |
| Resolved and dismissed insights | 30 days |
| Alerts and health-check results | As long as the instance exists in Logstag |
Removing an instance deletes its alerts, health checks and inventory at once. Statistics already collected are not deleted with it; they expire on their own schedule.
For your security review
Security reviews often ask about these. They are not part of Logstag today.
- Two-factor authentication.
- Single sign-on (SAML or OpenID Connect).
- IP allowlisting for the app.
- Customer approval before a support session starts.
- Signed agent updates. Turn automatic installation off if you install updates through your own process.
- Verified TLS between the agent and your databases. PostgreSQL connections use TLS when the server offers it, without checking the certificate; the other engines connect without TLS. Run the agent close to the databases it monitors.
- Signed RPM packages and a code-signed Windows installer.
- Audit log export.
On request
We answer these directly, under NDA where needed:
Hosting and subprocessors
Where the platform runs, and which providers process your data.
ISO 27001
The certificate and its scope.
Data processing agreement
Our DPA for your legal review.
Questionnaires
Your security questionnaire, answered by the team that builds the product.
Found a vulnerability? Write to hello@logstag.com with "Security" in the subject.