Reviewable implementation
The PulsusDB source is public. Security teams can inspect the ingest handlers, query compilers, data models and dependency choices used by the version they deploy.
Open the repository ↗Trust and security
Security across the observability data path
PulsusDB is an open source observability data platform designed to run inside infrastructure you control. Its security model spans the stateless PulsusDB tier, the stateful ClickHouse database tier and the deployment boundary around both.
DEPLOYMENT BOUNDARYoperated by your team
INGRESS AND ACCESS
↓ TLS 1.2 or newerBasic auth or gateway identity
STATELESS PulsusDB ingest APIs · query APIs · compilers
↓ STATEFUL ClickHouse database telemetry · indexes · rollups · retention
Private networkEncryptionBackups
CODEOpen source and reviewable
SERVICE TIERStateless by design
DATA TIERDeployed in your environment
ASSURANCEdigitalis.io ISO 27001 ISMS
SECURITY MODEL
Controls follow the architecture
PulsusDB does not operate a separate hosted telemetry service. You choose where the platform runs, how clients reach it and how the ClickHouse database is protected. The design keeps durable state in one database tier and makes the PulsusDB processes replaceable.
Controlled data topology
PulsusDB does not maintain a second durable application database. Telemetry, indexes, metric rollups and retention state live in the ClickHouse database deployment inside your network boundary.
TLS on both service paths
The PulsusDB listener supports TLS 1.2 or newer and refuses to start when only a certificate or key is supplied. Connections to the ClickHouse database can use HTTPS with public roots or a configured CA file.
Built-in authentication boundaries
HTTP Basic authentication can protect every ingest and query route, with separate credentials for administrative paths. An identity-aware gateway can add the organisation’s SSO, policy and network controls.
Tenant-scoped requests
Logs, metrics and traces can be written and read within an X-Scope-OrgID tenant. The deployment boundary must authenticate callers and set or validate that tenant identity.
Bounded query execution
Hard query timeouts, scan budgets, memory ceilings, concurrency limits and ingest backpressure constrain the work accepted by a PulsusDB process. Per-request IDs correlate query activity with ClickHouse logs.
SHARED RESPONSIBILITY
Product security and deployment security are different jobs
digitalis.io maintains the PulsusDB code and coordinates fixes for confirmed vulnerabilities. The operator controls the production environment, access boundary and stateful database underneath it.
PulsusDB and digitalis.io
- Maintain the public PulsusDB source and release history
- Receive and assess private vulnerability reports
- Address confirmed issues in PulsusDB code and published artefacts
- Document APIs, configuration and architecture needed for secure deployment decisions
- Communicate relevant remediation through the project channels
Platform operator
- Protect ingest and query endpoints with TLS, authentication and authorisation
- Replace the default administrative credentials before exposing the service
- Restrict network access to PulsusDB and the ClickHouse database
- Control tenant headers, service credentials, ClickHouse users and object storage secrets
- Configure retention, backups, replication and recovery
- Apply updates and monitor the complete deployment for security events
GOVERNANCE AND ASSURANCE
Built by a team operating an ISO 27001 certified ISMS
PulsusDB is developed by digitalis.io Limited. The company operates an information security management system certified to ISO 27001 and independently audited on an annual basis.
The certification applies to the company information security management system. It is not presented as a separate product certification for PulsusDB or as certification of an operator’s deployment.
Review digitalis.io assurance information ↗01Company governanceDocumented information security management
02Independent auditAnnual ISO 27001 assurance for digitalis.io
03Open source reviewInspect the implementation you plan to run
04Deployment ownershipKeep telemetry inside infrastructure you control
VULNERABILITY REPORTING
Send sensitive reports privately
Do not open a public issue for a vulnerability that has not been fixed. Email the details to digitalis.io with the subject “PulsusDB security report” so the report can be assessed without exposing users before remediation is available.
Email [email protected] →The affected version or commit, deployment context, reproduction steps, expected impact and the minimum proof needed to demonstrate the issue.
Accessing data that does not belong to you, service disruption, denial of service, social engineering and publication before a fix can be coordinated.
Use GitHub issues for non-sensitive defects, documentation corrections and feature requests.
Open GitHub issues ↗REVIEW MATERIAL
Start security diligence with the implementation
The repository, architecture documentation and legal information provide the current public evidence for a technical or procurement review.