Same platform, same detections, same AI. Installed on your own OpenShift, Kubernetes or Red Hat servers, and fully air-gapped if your policy requires it.
Some data may not leave the building. On-premises LogPulse brings the platform to the data, not the other way around.
Logs, detections, cases and AI conversations are stored and processed on your own hardware. Nothing is sent to us unless you choose to.
Installation, updates, threat intelligence and AI all work in a fully isolated network. Updates arrive as signed bundles that you bring in yourself.
On-premises is not a stripped-down edition. You get the same search, SIEM, service intelligence and pipelines, from the same code base.
Your own team operates the stack with our support, or we manage it remotely through an outbound-only connection that you control.
LogPulse is delivered as containers with a single installation package, so it lands on the platform you already operate.
Runs under the default restricted security profile, without privileged containers or fixed user IDs. Uses the operators and storage that OpenShift already provides.
Any conformant Kubernetes distribution, such as Rancher, Tanzu or upstream Kubernetes. Installed with a single package and a values file.
No Kubernetes yet? We deliver a scripted installation of a hardened, lightweight Kubernetes on Red Hat Enterprise Linux, with SELinux enforcing. From a single VM for a pilot to a cluster for production.
Every event takes the same path, and every layer scales and fails over on its own.
Your network
Lightweight agents on your servers, plus OpenTelemetry, syslog and HTTP. Agents are installed and updated from your own stack.
Authenticates every source, applies quotas and accepts data even when the rest of the stack is busy.
A replicated stream absorbs peaks and outages. Raw events can be replayed when a parser or pipeline changes.
Parsing, enrichment, stream pipelines, detections and alerting run as horizontally scaling workers.
A replicated columnar log store for fast search over months of data, next to a relational store for configuration, cases and users.
The AI investigator and agents run on open-source models inside your network, on your own GPUs.
Threat intelligence, detection rules and vulnerability data arrive as signed offline bundles, or are pulled automatically where a connection is allowed.
Older data moves automatically from fast NVMe to S3-compatible object storage and stays searchable. Backups land there too. From your platform, or delivered with the stack.
All components run in your own cluster. Access goes through your own identity provider, and every action ends up in a tamper-evident audit log.
You decide how much contact the stack has with the outside world. The functionality stays the same.
The stack receives updates, intelligence and optional cloud AI directly from LogPulse. The least work to operate.
No inbound ports. The stack only fetches updates and intelligence through your proxy, and all AI runs locally.
No network connection at all. Releases and intelligence arrive as signed bundles, the licence is an offline file and AI runs locally.
The AI investigator and agents work on-premises with open-weight models on your own GPUs. No prompt, log line or answer leaves your network.
The investigator works through your logs, tests hypotheses and shows the evidence behind every conclusion.
Ask a question in your own words and get the query and the answer, ready to save or refine.
Agents draft and test detection rules against your data. A person always reviews and publishes.
Alerts and cases arrive summarised, with the likely cause and the next steps.
Compact
Small team or pilot
Team
Security and operations teams
SOC
Around the clock, multiple sites
Open-weight models improve quickly, but on long, multi-step investigations they are not yet as strong as the best cloud models. We test every supported model against our own evaluation set and only recommend models that pass. Where your policy allows it, a connected stack can use our EU cloud models instead.
Three starting profiles. We size your stack together on the basis of volume, retention and search load.
| Profile | PilotProof of concept and test | StandardProduction with high availability | LargeTerabytes per day, multiple sites |
|---|---|---|---|
| Log volume | Up to 50 GB per day | Up to 500 GB per day | From 500 GB to several TB per day |
| Nodes | 1 VM or node | 6 nodes | 9 nodes or more |
| Application nodes | Shared with data: 16 vCPU, 64 GB RAM | 3 × 8 vCPU, 32 GB RAM | 3 or more × 16 vCPU, 64 GB RAM |
| Data nodes | Same node | 3 × 16 vCPU, 64 GB RAM | 4 or more × 32 vCPU, 128 GB RAM |
| Storage per data node | 2 TB local NVMe | Local NVMe sized to retention, for example 4 TB for 90 days at 250 GB per day | Local NVMe for recent data, object storage for older data |
| Availability | Single node, no failover | Survives the loss of a node without data loss | Multiple replicas, optionally spread over two data centres |
Indicative figures, excluding local AI. Event size, retention and search load determine the final sizing, which we work out with you.
Platform
Red Hat OpenShift 4.14 or later, Kubernetes 1.29 or later, or Red Hat Enterprise Linux 9 virtual machines for our scripted installation.
Fast block storage
Local NVMe for the data nodes. Network storage is fine for the other components.
S3-compatible object storage
For backups and long retention. From your platform, or delivered with the stack.
Network and certificates
An ingress or load balancer, a DNS name and a TLS certificate from your own certificate authority.
Identity and mail
Single sign-on through your OIDC or SAML identity provider, and an SMTP relay for notifications.
Container registry
For air-gapped installations: an internal registry, such as Harbor or Quay, into which you load the release bundle.
GPU for local AI (optional)
One or more data centre GPUs for the AI investigator and agents. The model and the amount of GPU memory depend on the number of users.
This is an example, not a blueprint. It shows how the stack spreads over two data centres and a third location so that losing a full site does not stop ingest or search.
Agents and sources at all locations
Load balancer or global DNS
Sends traffic to both data centres and moves it automatically on failure
Data centre A
2 × Application
16 vCPU, 64 GB RAM
2 × Stream buffer
8 vCPU, 32 GB RAM, 2 TB NVMe
2 × Data
32 vCPU, 128 GB RAM, 15 TB NVMe
1 × GPU node
2 × NVIDIA L40S or 1 × H100, for local AI
1 × Coordination
4 vCPU, 16 GB RAM
S3 object storage
Long-term storage for older data and backups, replicated to the other data centre
Every event is stored in both data centres
Data centre B
2 × Application
16 vCPU, 64 GB RAM
2 × Stream buffer
8 vCPU, 32 GB RAM, 2 TB NVMe
2 × Data
32 vCPU, 128 GB RAM, 15 TB NVMe
1 × GPU node
2 × NVIDIA L40S or 1 × H100, for local AI
1 × Coordination
4 vCPU, 16 GB RAM
S3 object storage
Long-term storage for older data and backups, replicated to the other data centre
Location C: witness
1 coordination node of 4 vCPU and 16 GB RAM keeps the majority when a data centre goes down
A data centre can go down
Ingest and search continue in the other data centre. When it comes back, it catches up by itself.
Between the sites
At most 5 ms round-trip time and at least 10 Gbit/s between the data centres. The witness needs only a modest connection.
Grows in steps
More volume means more data nodes, more users mean more application and GPU capacity. Every layer scales on its own.
Predictable releases that you can verify yourself before they go into production.
A tested release every month, with security fixes in between when needed. You decide when it is installed.
Every image is signed and ships with a software bill of materials, so your security team can verify what runs.
A signed licence file sets volume and features. Usage reports leave the stack only when you send them.
Tell us about your platform, volume and network policy. We come back with an architecture and a hardware specification.
Talk to us