Obserae FAQ · obserae

What exactly is an NDR?

An NDR helps you understand the communications flowing across a network, spot the ones that look abnormal, and provide the material needed to investigate them.

NDR stands for Network Detection and Response. Unlike a tool installed on workstations, an NDR observes network communications: who talks to whom, over which protocol, at what time, in which direction, and with what volumes.

Obserae turns those observations into actionable information: reconstructed sessions, named devices, expected or unexpected flows, suspicious destinations, behavioural anomalies, and alerts. It does not simply display IP addresses and ports: it places communications back into the context of your infrastructure.

What does Obserae do, in one sentence?

Obserae turns the NetFlow and IPFIX records from your infrastructure into an understandable map, then detects communications that are unusual, suspicious, or unplanned.

It brings collection, session reconstruction, cartography, declaration of expected communications, investigation, public-address enrichment, and alerting together in a single self-hosted application.

Which companies is Obserae built for?

Obserae is primarily designed for small businesses, mid-sized companies, startups, and technical teams that want serious network visibility without deploying a complex security platform.

It targets organisations that have a firewall, a router, a switch, a hypervisor, or a probe able to export NetFlow or IPFIX, but do not necessarily have a SOC, a dedicated network team, or a budget sized for high-end NDR platforms.

Obserae is particularly relevant when an organisation wants to:

better understand its actual network;
keep control of its segmentation;
spot unexpected communications;
detect suspicious destinations or behaviours;
keep its security data inside its own environment;
have usable material at hand during an audit or an investigation.

It can equally be used in a homelab, or by a professional who simply wants a clearer view of their own infrastructure.

Why would a small or mid-sized company need an NDR?

Because a small organisation can be attacked just like a large one, while having far fewer resources to monitor its network.

In a mid-sized company, the real network usually ends up drifting from the theoretical architecture: new devices, temporary services that became permanent, direct administrative access, legacy firewall rules, forgotten applications, or cloud communications that are hard to identify.

An NDR makes those gaps visible. In particular, Obserae can help answer simple but important questions:

is a user workstation talking directly to a sensitive server?
is a machine contacting a known malicious destination?
is a device using a service that was never planned for it?
is an unusual volume of data leaving the network?
has a new communication appeared since the last review?
does the segmentation actually observed match the one that was defined?

The goal is not to turn a small company into a SOC, but to give it visibility it would generally not have otherwise.

How is Obserae simpler than an NDR such as Darktrace, Vectra, or ExtraHop?

Obserae favours a self-hosted, compact, understandable architecture over the feature coverage and infrastructure of a high-end NDR.

Obserae does not try to reproduce every function of platforms designed for large enterprises with several security teams, many sensors, and substantial operational capacity.

The product is built as an all-in-one instance that collects, stores, analyses, and presents the data. It requires no cluster, no Kafka, no Elasticsearch, no Redis, and no external SaaS platform. That reduces the hardware needed, the power consumption, the number of components to maintain, and the time spent on upgrades.

This simplicity implies deliberate trade-offs: Obserae performs no full packet inspection and does not aim to cover every scenario a high-end NDR would. In exchange, it is easier for a small team to deploy, understand, back up, and operate.

Product X has a feature Obserae doesn’t. Doesn’t that make it the better tool?

A feature list is not a detection outcome. Obserae’s scope was chosen from what actually catches intrusions in real networks — and the deciding factor is rarely the exotic capability, it is whether the tool is deployed, understood, and running at all.

The 10% of the data that carries 90% of the intelligence

Every feature in Obserae comes from a need seen in the field, not from a competitive checklist. When you look at what genuinely surfaces an incident, the same handful of signals keep doing the work: a machine talking to a destination it has never talked to before, a workstation reaching a server it has no business reaching, a volume that does not fit the hour, a peer count that jumps, a communication nobody ever declared.

Those signals live in flow metadata — the who, when, how much, how often. That is a small fraction of what crosses your network, and it holds the overwhelming majority of the usable intelligence. Obserae is built to extract that fraction extremely well, on hardware you already own, rather than to extract everything adequately on hardware you would have to buy.

The sophisticated attack, and the one that actually happens

Yes, sophisticated evasion techniques exist, and yes, a deep-inspection platform will name some of them that Obserae will not. Two things are worth knowing before that decides your purchase.

In practice, that is not how you get breached. The overwhelming majority of real incidents involve a phished credential, an exposed service, an unpatched appliance, or a legitimate tool used illegitimately — none of which require exotic detection. They require someone to notice that a machine started behaving unlike itself.

And metadata sees the attacker before the attacker sees you. Command-and-control traffic has to reach the network. It can be encrypted, tunnelled over HTTPS, domain-fronted, padded, timed to look like a software update — and it still has to open a connection to a destination that machine has never contacted, at intervals a beacon produces and a human does not. Obserae observes that from a copy of the flow records, off the traffic path, with nothing installed on the compromised host and nothing an attacker can probe, disable, or notice. Evasion tuned against payload inspection does not evade the fact of the conversation.

A tool you can afford to run beats one you cannot

This is also, openly, an economic choice. Obserae is designed to be genuinely capable while staying simple to operate and affordable enough that the decision does not need a board meeting — one instance, no cluster, no per-sensor licensing, running on a small server or even a Raspberry Pi.

That matters because of how these projects usually end. The high-end platform gets evaluated, everyone agrees it is impressive, the quote lands, and the project is postponed — for a year, then another. Meanwhile the network keeps drifting from its documentation and nobody is watching it. The most expensive NDR is the one that never got deployed: its detection rate is zero.

The realistic comparison is not Obserae versus product X. It is Obserae, running, with your network mapped and your expected flows declared — versus nothing at all, while you wait for a budget that may not come. For most organisations that is not a close call.

And if you do run a high-end platform, Obserae is not in competition with it: it maps your network by name, models the traffic you consider legitimate, and forwards its alerts to your SIEM or SOAR like any other source.

What is the difference between Obserae and a plain NetFlow analyser?

A NetFlow analyser generally presents flows and statistics; Obserae turns them into security context and investigation material.

Starting from NetFlow and IPFIX records, Obserae adds several extra layers:

reconstruction of flows into network sessions;
identification of client and server;
packet and byte counters in each direction;
cartography of networks, machines, groups, and services;
readable names instead of bare IP addresses;
declaration of expected communications in a flow matrix;
identification of sessions that do not match that matrix;
enrichment of public destinations;
the NFQL investigation language;
detection rules and alerts;
behavioural baselines and anomaly detection.

A single NetFlow line can therefore become a statement such as: “the integration server just contacted the production database directly, while no such communication is declared”.

Does Obserae replace a firewall, an EDR, a SIEM, or an IDS?

No. Those tools serve different purposes and are complementary.

A firewall allows or blocks communications according to a network policy.

An EDR observes what happens inside a workstation or a server: processes, files, users, memory, and system behaviour.

An IDS analyses traffic to look for attack signatures or behaviours, often from the packets themselves.

A SIEM centralises and correlates logs coming from many tools.

A SOAR automates response procedures.

Obserae observes network relationships from NetFlow and IPFIX, compares them to a cartography and a communication policy, then helps detect and investigate the gaps.

It can send its alerts to a SIEM, a SOAR, or other tools, but it does not aim to replace them.

Why use Obserae if my firewall already shows network connections?

Because a firewall mainly shows what it sees and what it decides, whereas Obserae builds a historical, contextualised view of communications.

Firewall logs can answer a specific question, but they are rarely designed to maintain a living cartography, reconstruct sessions observed by several devices, name systems, model expected communications, and look for deviations over time.

Obserae notably lets you:

centralise flows from several exporters;
keep a history suited to investigation;
group observations into sessions;
search by machine, group, or service name;
distinguish planned communications from undocumented ones;
enrich external destinations;
turn a useful query into an alerting rule.

Beyond that, a firewall placed at the edge does not necessarily see all the internal communications between servers, VLANs, or hypervisors. Visibility always depends on where the flows are exported from.

Which threats can Obserae detect?

Obserae can detect suspicious network behaviour, unplanned communications, and deviations from the usual operation of your infrastructure.

Depending on the visibility provided by the exporters and the rules enabled, Obserae can surface things such as:

communications towards Tor nodes or known malicious addresses;
direct access to databases or sensitive services;
administrative connections bypassing a bastion;
cross-zone communications that do not match the intended segmentation;
network scans;
repeated attempts against many services;
unusual data volumes;
transfers towards an unexpected cloud provider;
new peers or new destinations;
an abnormal increase in the number of sessions, peers, or bytes;
communications that match no rule in the flow matrix.

An alert is a signal to investigate, not automatic proof of compromise. Organisational context remains essential to tell an attack, a misconfiguration, and legitimate activity apart.

What can Obserae not detect?

Obserae can only detect what produces a network signal visible in the NetFlow or IPFIX data it receives.

It does not directly see:

files created or modified on a machine;
processes being executed;
the user logged in on a workstation, unless external enrichment provides it;
the content of an application request or response;
commands executed inside an encrypted session;
an attack that stays entirely local to one machine;
traffic that crosses no device or sensor configured to export it;
a communication the originating device is technically unable to observe.

Nor can it always identify with certainty the application, its version, or the exact nature of the content exchanged. A connection on port 443 is visible as a TCP communication to port 443, but Obserae does not claim to know what action took place inside that connection.

This is why Obserae complements a firewall, an EDR, an IDS, or a SIEM rather than replacing them.

Does Obserae inspect packet content?

No. Obserae neither records nor inspects full packet content. It analyses NetFlow and IPFIX metadata.

That metadata includes, among other things, source and destination addresses, ports, protocol, timestamps, packet counts, byte counts, and the information supplied by the exporter.

For the use cases Obserae targets, this information provides most of the signal needed to understand network relationships, detect policy deviations, identify suspicious destinations, and observe behavioural change.

Layer 7 application inspection is richer, but it generally requires far more CPU, memory, and storage. It also increases deployment complexity and can raise more privacy questions.

Choosing NetFlow and IPFIX lets Obserae stay lightweight, retain more history, and run on infrastructure that fits the means of a small or mid-sized company.

Can Obserae detect suspicious behaviour inside encrypted traffic?

Yes, as long as the communication produces visible NetFlow or IPFIX metadata — but Obserae cannot read the encrypted content.

Encryption hides the application payload, but it does not necessarily hide:

which systems are communicating;
the addresses and ports used;
when the communication happened and how long it lasted;
the number of packets;
the volume sent in each direction;
the frequency of connections;
the appearance of a new peer;
the cloud destination, ASN, or country associated with a public address.

Obserae can therefore detect that a workstation suddenly talks to an unusual destination, or that a server sends an abnormally large volume of data, even when the communication uses TLS.

What it cannot do is determine the exact content transmitted inside the encrypted session.

Does Obserae only alert, or can it also block a connection?

Obserae is designed to detect, contextualise, and alert. It does not block communications directly by default.

That choice is deliberate. A network detection may be a false positive, or may correspond to legitimate activity that is simply not documented yet. Poorly controlled automatic blocking can interrupt a business application, a backup, or a production process.

Obserae can send an alert by webhook to a SOAR, an automation tool, or a service able to change a firewall policy. Building an automated response around the product is therefore technically possible.

The recommended policy, however, is to keep a human in the loop, at least until the rule is well understood. Gradual automation can then be introduced for very specific, low-risk scenarios.

Do I need a complete network map before I can start?

No. You can start with a small part of the network and fill in the cartography progressively.

The discovery feature surfaces the observed networks and devices that are not documented yet. You can then adopt them into the cartography and give them a name, a role, a zone, or services.

An effective approach is to start with:

the main networks;
critical servers and devices;
user groups;
sensitive services;
a few important expected communications.

Knowledge held by the system administrators, existing documentation, DHCP, DNS, or an inventory greatly speeds up this step. Discovery helps you observe what exists, but it cannot guess a server’s business function on its own, nor decide whether a communication is legitimate.

The cartography and the flow matrix therefore become progressively more accurate as the team qualifies its infrastructure.

What do I need in order to install Obserae?

A Linux machine, disk space matched to the retention you want, and at least one device or probe able to send NetFlow or IPFIX.

Obserae can be installed with Docker or from prebuilt binaries on AMD64 or ARM64. It runs on Linux servers, virtual machines, mini-PCs, and recent Raspberry Pi boards.

Obserae deliberately adopts an all-in-one, single-instance architecture. The collector, the storage, the query engine, the detection, and the interface all live in the same application. No cluster and no set of external databases is required.

That architecture means the instance is a single point of failure. This is an accepted trade-off in favour of simplicity, cost, and maintainability.

In a normal deployment, Obserae receives a copy of the network metadata and does not sit in the path of the communications. An outage therefore leaves the organisation temporarily blind to that telemetry, but it does not block applications or business traffic. Backup and restore let you rebuild the instance; the actual duration depends on the data volume and the hardware used.

Which routers, firewalls, switches, or hypervisors are compatible?

Any device able to export a compatible NetFlow or IPFIX format can potentially send its data to Obserae.

The documentation provides guidance for devices and platforms such as:

Cisco;
Juniper;
MikroTik;
Fortinet FortiGate;
Palo Alto;
pfSense;
OPNsense;
Check Point;
Sophos;
SonicWall;
WatchGuard;
Ubiquiti;
HPE Aruba;
Huawei;
Arista;
Open vSwitch;
VMware vSphere Distributed Switch.

When a device cannot export NetFlow or IPFIX directly, a software probe such as softflowd, pmacct, nProbe, YAF, or ipt-NETFLOW can sometimes be used on a server or on a mirror interface.

Actual compatibility depends on the model, the operating-system version, and the export features enabled. It is therefore recommended to check the vendor documentation and the Obserae exporter configuration page.

Does Obserae accept sFlow, AWS VPC Flow Logs, or other cloud logs?

Obserae ingests NetFlow v5, NetFlow v9, and IPFIX directly. It does not natively ingest sFlow or the proprietary cloud flow-log formats.

sFlow is a different protocol, generally based on packet sampling. When a device only offers sFlow, an intermediate tool such as pmacct, sflowtool, or sFlow-RT can be used to convert or relay the data in a compatible format.

AWS VPC Flow Logs, Azure NSG Flow Logs, and Google Cloud VPC Flow Logs, for their part, are produced as structured data deposited into cloud services. They are not sent as NetFlow or IPFIX records over UDP. A dedicated conversion chain is therefore required before they can be used with Obserae.

This choice keeps the collector’s scope clear and its ingestion chain predictable.

How long does it take to install Obserae and get the first useful results?

The technical installation takes a few minutes; the quality of the results then grows with the cartography and your knowledge of the environment.

Once the instance is running and one exporter is configured, the first flows can be visible quickly. You can then look at sessions, top destinations, volumes, and observed devices. The website indeed suggests starting with a single exporter and a small part of the network.

Getting a first operational payoff does not require launching a full cartography project. A few networks, critical servers, and expected communications are enough to start spotting deviations.

The behavioural features need more time, because they must observe several periods before building a reliable baseline. Obserae includes a warm-up phase during which the models learn without raising alerts immediately.

In practice, the first observations can be obtained on deployment day, while a more mature model of the network builds up progressively.

What CPU, memory, and disk resources should I plan for?

Sizing depends mainly on the number of flows received, the retention period, and the length of your conversations. The Sizing page gives the measured figures and the arithmetic; this is the short version.

Comfortable starting points:

4 GB of memory and 4 vCores for a small business at low volume;
8 GB of memory and 8 vCores at around 1,000 flows/s;
storage sized from your traffic and retention — count roughly 15 MB per million flows and 110 MB per million sessions, plus about 1.5 GB of fixed footprint for enrichment data and the database.

As a reference point, a site with around thirty machines and exporters at ~700 flows/s needs about 20 GB for three days of history.

All heavy processing happens in RAM, and obserae parallelises across the cores it is given, up to around 50. Storage is plain files on disk — no Elasticsearch, Kafka, or Redis. Because much of the work is writing those files, disk performance matters: prefer NVMe or a decent SSD at meaningful traffic volumes.

Retention is off by default, so the practical approach is to start with a roomy volume, watch the real daily growth on the Storage page, then set a policy with actual numbers in hand.

The single-instance architecture avoids the hardware and operational cost of a cluster. For the organisations Obserae targets, simple backup and restore is generally more useful than complex high availability.

Does the data really stay with me, and does Obserae work without Internet access?

Yes. Flows, sessions, cartography, rules, and alerts stay on your instance. Core operation requires no Internet connection.

Obserae performs no online licence check and sends no usage telemetry to Spartan Conseil. The vendor has no access to the instance’s data.

The only outbound connections are the ones the administrator chooses to enable, for example:

downloading public IP enrichment lists;
sending an alert to a webhook;
sending to Slack, Mattermost, Telegram, Gotify, or an SMTP server;
sending to a SIEM, a search engine, or an on-call platform.

Enrichments can be disabled and outputs are only used when configured. Obserae can therefore be installed in an isolated or air-gapped environment.

Do I have to write every detection rule myself?

No. Obserae ships ready-to-use rule packs, which you can then adapt to your environment.

The community pack currently contains several dozen rules covering, among other things, risky communications, segmentation deviations, certain sensitive services, malicious destinations, and various behaviours worth investigating.

Most of those rules use the cartography and the flow matrix. They look first at the communications you have not already declared as legitimate. When an alert matches normal activity, the right action is often to document that communication in the matrix rather than to disable the detection.

Custom rules can also be created from NFQL queries. A useful investigation can thus become recurring monitoring.

The commercial editions add packs oriented towards behavioural detection, compliance, and SOC integrations.

How does Obserae avoid generating too many false positives?

Obserae combines the context of your infrastructure, the communications you have declared as normal, and explicit tuning mechanisms.

There is no network detection without false positives. Obserae’s strategy is therefore to make alerts understandable and adjustable rather than to hide how they work behind an opaque score.

Several mechanisms help reduce the noise:

the cartography gives systems a role and a context;
the flow matrix describes legitimate communications;
many rules only apply to sessions not covered by that matrix;
rules have severity levels and thresholds;
alerts can be routed by rule, tag, or severity;
behavioural detections use a learning period;
baseline sensitivity can be adjusted;
different baseline methods can be chosen depending on whether the activity is stable, irregular, or seasonal.

An alert remains an invitation to check a situation. That is also why Obserae does not block traffic automatically by default.

How can alerts be sent to our existing tools?

Alerts can be sent to messaging, on-call, search, SIEM, or automation tools.

Depending on the edition in use, Obserae supports:

HTTP webhooks;
Gotify;
Slack;
Mattermost;
Telegram;
email over SMTP;
Syslog in JSON, CEF, or LEEF;
Splunk HEC;
Elasticsearch and OpenSearch;
PagerDuty;
Opsgenie.

Each destination can receive only certain alerts, based on their severity, the rule name, or its tags. Deliveries are queued and retried on temporary failure. Webhooks can also be signed with HMAC so that the recipient can verify their authenticity.

A webhook can be used to forward an alert to a SOAR or an automation platform. Any blocking actions, however, must be designed and validated by the organisation.

Why is Obserae proprietary rather than open source?

Obserae is distributed as proprietary binaries and Docker images in order to keep the product coherent, integrated, and financially sustainable.

The product is designed as a complete application, not as an assembly of components each user would have to integrate and maintain. Controlling the code and the roadmap keeps the architecture homogeneous and limits variants that are hard to support.

That choice means trust has to be earned in other ways. Obserae therefore provides:

signed releases;
checksums;
an SBOM;
build provenance attestation;
a responsible vulnerability disclosure policy;
no telemetry and no online licence check;
the option, for a qualified assessor, to request source-code access under NDA for a security review.

An existing installation keeps working without a licence server or any remote kill switch. The data remains the property of the user.

Which edition should I choose, what is free, and what does the solution really cost?

The edition depends mainly on the size of the organisation and on the enterprise features you need, such as SSO, behavioural detection, and SOC integrations.

Community

The Community edition is free for:

personal, non-commercial use;
an organisation with at most 20 people and at most €2 million in annual revenue.

Both criteria apply together.

It includes the cartography, the flow matrix, sessions, NFQL, alerts, the community rule pack, public enrichments, and the main notification outputs.

Business

Business targets organisations of up to 100 people.

Its list price is €2,900 excl. VAT per year, equivalent to €242 per month, billed annually.

Business+

Business+ targets organisations of up to 500 people.

Its list price is €7,900 excl. VAT per year, equivalent to €658 per month, billed annually.

Enterprise

Enterprise addresses larger organisations, or those with specific contractual and operational requirements.

Its list price is €19,000 excl. VAT per year, equivalent to €1,583 per month, billed annually.

The commercial editions give access to Active Directory or LDAP, OIDC SSO, anomaly detection, advanced rule packs, and SOC outputs such as Splunk, Elasticsearch, Syslog CEF or LEEF, PagerDuty, and Opsgenie.

Exporters, flows, IP addresses, users, and retention are subject to no announced commercial limit. Actual capacity naturally remains dependent on the hardware and the volume processed.

During the beta, all features are open while the product stabilises. The pricing page presents the commercial segmentation planned or applicable under the licence terms.

What is the difference between Obserae and ntopng?

ntopng is primarily oriented towards traffic visibility and analysis; Obserae uses network flows to build a security reference model and detect the communications that should not exist.

ntopng is a mature traffic collection and analysis tool. It lets you examine devices, protocols, volumes, and the main communications observed on a network. It can collect from several data sources, including NetFlow.

Obserae starts from a different question: do the observed communications match the intended architecture and usage?

To answer it, Obserae adds:

a named cartography of networks, machines, groups, and services;
reconstruction of flows into bidirectional sessions;
a matrix describing the expected communications;
detection of sessions that do not match that matrix;
security rules and statistical baselines;
an investigation language that uses the cartography’s names;
alert management and forwarding to other tools.

Both products can therefore analyse NetFlow data, but Obserae is built around an NDR process: map, formalise intent, detect deviations, and investigate.

Isn’t Obserae just a pretty interface on top of NetFlow?

No. The interface is the visible part of an engine that reconstructs, contextualises, compares, and analyses network communications.

Displaying a list of flows mostly amounts to presenting IP addresses, ports, protocols, and counters. Obserae performs several additional steps before presenting that data:

grouping observations into sessions;
determining client and server roles;
mapping addresses to named devices;
attaching them to the cartography’s networks, groups, and services;
comparing them against the expected communications;
enriching public destinations;
aggregating statistics over time;
applying detection rules;
creating alerts that carry the material needed for investigation.

The goal is not to make a NetFlow table prettier, but to turn a technical record such as:

10.10.42.18 → 10.20.4.11:5432/TCP

into actionable information:

ci-runner-prod → finance-postgres, with no matching communication in the flow matrix.

Why not use Suricata or Zeek instead?

Suricata, Zeek, and Obserae observe the network in different ways. They can be complementary rather than interchangeable.

Suricata is an IDS, IPS, and network detection engine able to inspect packets and apply detailed signatures. Zeek also analyses packets in order to produce structured logs about protocols, transactions, and some observed files.

That richness generally implies:

capturing or mirroring packets;
correctly positioned probes;
more compute power;
a larger log volume;
rules, scripts, and pipelines to maintain;
integrating other components for storage, visualisation, and alerting.

Obserae uses only NetFlow and IPFIX. It does not try to identify the exact content of an HTTP request or of a transferred file. It aims to understand who communicates with whom, in what proportions, how often, and whether that communication was expected.

Suricata and Zeek go deeper at the application level. Obserae is lighter and directly focused on cartography, the flow matrix, and investigating network relationships.

Does Obserae replace my SIEM?

No. Obserae produces network data and alerts that a SIEM can then centralise and correlate with other sources.

A SIEM generally collects logs from many systems:

Active Directory;
firewalls;
servers;
applications;
cloud services;
EDR;
security tools;
network devices.

Obserae focuses on one source and one specific problem: understanding network communications from NetFlow and IPFIX, then detecting the ones that look suspicious or inconsistent with the expected architecture.

A small organisation can use Obserae on its own to get an investigation interface and an alert queue. An organisation that already runs a SIEM can forward the alerts there to correlate them with authentication events, system logs, or EDR alerts.

The commercial editions provide outputs to Splunk HEC, Elasticsearch, OpenSearch, and Syslog in CEF or LEEF format.

Does Obserae replace my EDR?

No. An EDR observes the inside of machines; Obserae observes their network communications.

An EDR can detect:

execution of a suspicious process;
creation or modification of a file;
a privilege escalation;
a PowerShell command;
injection into a process;
a user’s activity on a machine.

Obserae has none of that information. It can, however, see that a machine:

contacts an unusual destination;
starts communicating with many internal systems;
accesses a sensitive server directly;
uses a service that does not match its role;
suddenly sends a large volume of data;
establishes a communication absent from the flow matrix.

The two perspectives are complementary. An EDR can explain what happened on the machine, while Obserae can show which other systems it talked to before, during, and after the event.

I already have a FortiGate, pfSense, or OPNsense. What does Obserae bring me?

The firewall enforces your policy; Obserae helps you understand the communications actually observed and check that they match your architecture.

A firewall knows how to allow, deny, and log the communications that cross it. Its logs, however, are not always designed to:

maintain a living cartography of the infrastructure;
name devices and services;
keep an easily queryable history;
reconstruct observations into sessions;
compare traffic against a matrix of business communications;
identify undocumented devices;
build behavioural baselines;
turn an investigation into an alerting rule.

Beyond that, an edge firewall does not necessarily see exchanges between machines on the same VLAN, between virtual machines, or between networks routed by another device.

The firewall itself can serve as the NetFlow or IPFIX exporter towards Obserae. Coverage then depends on which points of the network the metadata is exported from.

Without packet inspection, how can you call Obserae an NDR?

An NDR is not defined solely by packet-content inspection, but by its ability to use network telemetry to detect and investigate suspicious behaviour.

NetFlow and IPFIX provide the fundamental elements of a communication:

source address;
destination address;
source port;
destination port;
protocol;
timestamp;
duration;
packet count;
byte count.

That information already identifies a large share of the behaviours a security team cares about: new destinations, scans, lateral communications, access to sensitive services, unusual volumes, segmentation deviations, and unplanned communications.

Layer 7 analysis brings more detail, but at a significantly higher cost in collection, compute, storage, and operations. Obserae deliberately chooses to focus on flow metadata in order to offer a lighter, more accessible NDR.

It does not claim to provide the same depth as a packet-inspecting platform. It does, however, bring far more than a plain NetFlow collector, thanks to the cartography, the sessions, the flow matrix, the rules, and the investigations.

Does Obserae really detect attacks, or only unusual ports?

Obserae does not stop at comparing port numbers. It analyses the relationships, volumes, frequencies, timing, and context of every communication.

An unusual port can be a signal, but it is rarely enough on its own. Rules can also examine:

the number of machines contacted;
the number of ports used;
the number of sessions in a given period;
the bytes and packets exchanged;
the direction of the communication;
the role of the machines;
the groups and zones involved;
the presence or absence of a rule in the flow matrix;
the reputation or nature of the public destination;
the deviation from historical behaviour.

Obserae can therefore surface scenarios such as a scan, a bastion bypass, a direct communication to a database, or an unusual outbound volume.

An alert does not automatically mean a confirmed attack. Obserae provides a contextualised signal that the operator must qualify.

Does Obserae use artificial intelligence?

No. Obserae does not use artificial intelligence to perform its detections.

Detections rest on two main mechanisms:

explicit rules, written from understandable criteria;
statistical methods intended to measure deviations from usual behaviour.

The statistical mechanisms can examine changes in volumes, sessions, peers, or other observable metrics. They use explainable methods such as moving averages, medians, deviations, or dispersion measures.

The operator must be able to understand:

which metric was analysed;
which reference period was used;
which value was expected;
which value was observed;
which threshold was crossed;
why the alert fired.

Obserae does not try to replace that explanation with a score produced by an opaque model. The word “behavioural” here means statistical analysis of network behaviour, not an AI engine.

Does Obserae automatically block attackers?

No. Obserae does not modify network traffic directly and does not automatically block a communication.

That choice prevents a false positive from interrupting:

a business application;
a backup;
a synchronisation;
an administrative operation;
an industrial or production process;
a service that is not in the cartography yet.

Obserae runs off the communication path: it receives a copy of the NetFlow or IPFIX metadata. An outage or shutdown of the product interrupts visibility and alerting, but does not block the company’s traffic.

An automated response remains possible by sending alerts to a webhook, a SIEM, or a SOAR able to drive a firewall or another device.

That automation must be governed by the organisation. The recommendation is to start with human validation, then automate only scenarios that are precise, tested, and reversible enough.

Can Obserae run on a Raspberry Pi?

Yes, and for many small companies it is genuinely enough. Obserae ships an ARM64 build, and a Raspberry Pi 5 with 4–8 GB of RAM and an NVMe drive is a perfectly serious deployment.

Obserae is frugal software. A Pi is a good fit for a homelab, a demonstration, a branch office, a small infrastructure, or a first evaluation — but also for a small business running it for real.

The board matters less than the storage. A standard microSD card is the wrong medium for a workload that writes files continuously: it will bottleneck ingestion and wear out. An NVMe hat, or at minimum a decent USB SSD, is the part not to skimp on — a Pi on NVMe will outperform a bigger machine writing to a tired SD card.

For larger volumes, a VM or a small x86 server gives more headroom, and obserae will use the extra cores automatically. See Sizing for the figures.

Where is Obserae from, and where does my data stay?

Obserae is built in Europe, by Spartan Conseil Cybersécurité, a French company. It is used worldwide, and because it is self-hosted, your data stays wherever you choose to install it.

Those two facts are independent, and the second is the one that usually matters. Obserae is not a service you send your network telemetry to; it is software you run on your own infrastructure. There is no vendor cloud in the path, no account to create, and no copy of your flows anywhere but on the machine you installed it on. Data residency is therefore not something we promise you — it is something you decide, in whichever jurisdiction you operate.

That property is useful under any regime you have to answer to, whether that is GDPR or NIS2 in Europe, a sector or state privacy rule in the United States, or a domestic data-residency requirement elsewhere. Obserae does not certify your compliance — no tool can — but it removes the question of where the data went, because it never left.

The design principles behind it:

local installation, on infrastructure you control;
data kept inside your own environment;
no vendor telemetry;
no online licence check;
operation possible without Internet access, including air-gapped;
the option to request a source-code review under NDA.

The licence, in French and in English

The EULA ships in both languages with every release: EULA.txt in French and EULA.en.txt in English. Francophone organisations get a licence they can read and have their own counsel review in their language; the English translation is there so everyone else can do exactly the same. As with most vendors, the text of record is the one in the publisher’s home jurisdiction — here the French version, under French law.

Obserae is distributed as Linux binaries and Docker images, and the documentation, releases, and issue tracking are publicly accessible, even though the product’s source code remains proprietary. If your organisation needs the commercial relationship framed differently — a specific contractual framework, language, or jurisdiction — that is a conversation to have with Spartan Conseil rather than an obstacle.

Why isn’t Obserae open source, given that releases are published on GitHub?

GitHub is used as a distribution and tracking platform, but a public repository does not mean the software is open source.

The public repository is used to publish:

the binaries;
the release notes;
the documentation;
the licences;
the checksums;
the files needed to verify releases;
feature requests and bug reports.

The product’s source code is not published, and the licence does not permit modifying or redistributing it. Obserae is therefore proprietary software with a free edition, not open-source software.

This choice lets Spartan Conseil keep a coherent technical direction and fund the product’s development.

Transparency mechanisms are nevertheless offered: signed releases, an SBOM, provenance attestations, and source access under NDA for qualified assessors performing a security review.

Is my network data sent to Spartan Conseil?

No. Spartan Conseil has no access to the flows, sessions, cartographies, rules, or alerts stored in your instance.

Obserae is self-hosted. The data is collected, processed, and retained on the machine you administer.

The product requires:

no account on any Obserae platform;
no online activation;
no remotely verified key;
no transfer of data to a SaaS service;
no vendor access to the instance.

The data remains under the control of the organisation operating the product. The licence also states that the vendor claims no rights over the customer’s flows, sessions, cartography, rules, or reports.

The only possible outbound communications are the ones the administrator decides to configure, for example downloading a public enrichment list or sending an alert to their own webhook.

Does “no telemetry” mean Obserae makes no outbound connection at all?

It means Obserae sends no usage, diagnostic, or licence data to Spartan Conseil. Some connections chosen by the administrator remain possible.

By default, the core operation of the collector, the query engine, and the interface depends on no external service.

Optional outbound connections may cover:

downloading public cloud IP address lists;
downloading threat intelligence lists;
sending an alert to a webhook;
sending to a messaging platform, an SMTP server, a SIEM, or an on-call tool.

Those communications are not vendor telemetry. They correspond to features enabled and configured by the administrator. Enrichment downloads do not transmit the IPs observed on the network: the instance downloads public lists.

Enrichments and outputs can be disabled in order to run Obserae in a fully isolated environment.

Why pay when there is a free edition?

The free edition covers the essential needs of an individual or a small organisation; the paid editions fund the product and add the features larger organisations need.

The Community edition already lets you:

collect NetFlow and IPFIX;
build a cartography;
define a flow matrix;
browse and search sessions;
create rules;
receive alerts;
use the public enrichments;
send alerts to common outputs.

It is free for personal use and for organisations that stay within the thresholds set by the licence.

The commercial editions add:

Active Directory and LDAP;
OIDC SSO;
statistical anomaly detection;
advanced rule packs;
mappings to security frameworks;
integrations with SIEMs and SOC tools;
commercial support.

Commercial funding makes it possible to maintain the product without selling user data or forcing a SaaS platform on anyone.

What justifies €2,900 excl. VAT per year for a mid-sized company?

That price buys an integrated, self-hosted, maintained security application — not just a flow collector.

The Business edition is listed at €2,900 excl. VAT per year for an organisation of up to 100 people. That is equivalent to €242 per month, billed annually.

The price includes access to professional features such as:

Active Directory or LDAP;
OIDC SSO;
statistical anomaly detection;
advanced rule packs;
outputs to SOC tools;
vendor support.

Obserae is designed as an all-in-one product. The organisation does not have to assemble and then separately maintain a collector, a database, a search engine, a cartography, dashboards, a rule system, and an alerting engine.

The relevant comparison is therefore not only against the price of an open-source licence, but against the total cost of the hardware, the integration, the upgrades, and the human time needed to build and then maintain an equivalent service.

Why bill by headcount rather than by IP addresses or flow volume?

Pricing based on the size of the organisation is more predictable and does not push the customer to reduce visibility in order to control the bill.

Per-IP pricing quickly runs into difficulties:

addresses change;
temporary devices multiply;
containers and virtual machines are dynamic;
one machine may use several addresses;
network devices, printers, and connected objects all have to be counted;
the customer may hesitate to monitor a new zone for fear of going over the limit.

Pricing by flow volume, for its part, makes the cost dependent on network activity and can become hard to forecast.

Obserae places no commercial limit on exporters, flows, IPs, users, or retention in the listed editions. Organisation size serves as a simple criterion to distinguish a small structure, a mid-sized company, and a larger enterprise.

Technical capacity naturally remains dependent on the hardware the instance runs on.

Is Obserae stable enough for production use?

Yes — Obserae is in beta and already runs in production at early-adopter sites, day after day, on real traffic.

Beta means the feature set is in place and the product is being operated for real, while the surface is still being refined ahead of 1.0. Security fixes land on the most recent version rather than on several branches maintained in parallel, so staying current is part of running it well.

Everything needed for durable operation is there:

installation under Docker or systemd;
persistent storage;
backup and restore;
identified, signed releases;
an SBOM and provenance attestation;
exportable configuration;
automatic data migration between versions, so an upgrade keeps your history.

Obserae also sits off the traffic path: it receives a copy of the network telemetry. Should the instance stop, visibility and alerting pause, while the network and the applications carry on unaffected — which is precisely why early adopters were comfortable putting it in production before 1.0.

As with any monitoring platform, test your upgrades, keep your backups, and size the deployment to the criticality of the environment.

Is Obserae still in beta, or already commercially available?

Both: the product is in beta and in production at early-adopter sites, while its commercial model and editions are already defined.

The beta status describes technical maturity — the feature set is in place, it is being operated on real traffic, and the surface is still being refined ahead of the first stable release.

The pricing, for its part, describes the terms for professional organisations and the features that belong to the commercial editions.

During the beta, all features are available free of charge so they can be exercised and stabilised. The licence already specifies free usage, usage requiring a commercial licence, and the features intended to become paid — nothing will be sprung on you later.

Organisations can therefore evaluate the product right now, on their own data. For a deployment carrying contractual, support, or SLA requirements, contact Spartan Conseil to define the appropriate framework.

What happens to my installation if Spartan Conseil or the project disappears?

Your installation keeps running, the builds stay downloadable, and if the product or the company ever stops, the source code of the complete Enterprise edition is released under an open source licence so you can carry on. This is a written commitment in the EULA, not a promise on a website.

Nothing phones home

Obserae contains:

no online activation;
no online licence verification — nothing is ever checked against our servers;
no remote kill switch;
no SaaS dependency required for ingestion or investigations.

This is not an oversight, it is a design position. We are, ourselves, the first to resent software that phones home or holds a customer’s data hostage. We refuse to ship that. An Obserae instance runs on an air-gapped network with the vendor entirely out of the picture, and nothing in the binary reaches out to ask us for permission to start.

About licence terms, plainly

The Community edition needs nothing: no key, no licence file, no sign-up. Eligibility is self-assessed against the criteria in the EULA, and that is the whole of it.

The commercial editions are a subscription, licensed per year. They come with a licence file installed on your instance, and it is renewed each year along with the subscription. We would rather state that here than let the section above read as a perpetual licence — it is a real file with a real validity period.

What it is not is a leash. The file is validated locally, on your own instance, without contacting anything of ours: no account, no online activation, no telemetry riding along. An air-gapped deployment renews by dropping in a new file, and no network outage on our side or yours can interfere with a running instance. And whatever happens with a subscription, your data stays yours and stays readable: flows and sessions live in your own Parquet files, next to a configuration you can export at any time.

The builds stay available

The binaries, the Docker images, the licence, and the documentation ship with every release and are published openly. Nothing about downloading or reinstalling a version requires an account, a key, or our permission — and that is already the case today, not a future promise. Keeping a local copy of the release you run, along with your configuration export and your backups, is good practice and entirely sufficient to rebuild an instance on your own.

If we stop, the code opens

Article 8.3 of the EULA states it plainly: should Spartan Conseil permanently cease its activity, or should Obserae be permanently discontinued, the source code is released under an open source licence allowing users to keep using, maintaining, and evolving the product.

That release covers the complete Enterprise edition — every feature, including the ones behind a commercial licence today. Not a stripped-down core, not a community subset: the whole product, so that a Community user and an Enterprise customer both end up with something they can actually keep running.

The intent is simple. The proprietary licence exists to fund the development of a coherent product, not to trap the people who chose it. If we are no longer around to develop Obserae, there is no reason left for the code to stay closed — and every reason for the organisations that built their network visibility on it to keep going without us.

Has Obserae already detected real compromises?

Obserae produces actionable signals during an incident — but we do not publish what happens on customer networks, for the same confidentiality reasons described below. What we can talk about freely is our own lab.

The product surfaces behaviours frequently associated with an incident:

the appearance of a new external destination;
communication towards a known malicious address;
an internal scan;
lateral movement;
direct access to a sensitive service;
a bastion bypass;
an unusual data transfer;
a communication absent from the flow matrix.

Fun fact: the microwave that had opinions about DNS

On one of our own homelabs, Obserae flagged a communication that matched no rule in the flow matrix: a networked microwave was talking to 8.8.8.8 on port 53. Directly. Ignoring the local DNS server it had been handed by DHCP, and the resolution policy that went with it.

Nothing was compromised. Nobody was exfiltrating anything. The device had simply decided, somewhere in its firmware, that it knew better than the network it was plugged into — a habit rather more common among connected objects than their datasheets suggest.

It is a small thing, and it is exactly the point. Nobody had declared that communication, nobody had noticed it, and it would have kept happening quietly forever. That is the category of finding an NDR is for: not only the dramatic intrusion, but the device that silently stopped following the rules of the house.

Do you have customer references or case studies?

Obserae is deployed and used in production. Those deployments cover sensitive activities, so we deliberately publish no customer names, logos, or case studies.

This is a considered position, not an absence of customers. Disclosing that a given organisation monitors its network with Obserae also discloses something about its security posture: which tooling it runs, and therefore what an attacker would have to work around. For the environments we operate in, that information is itself sensitive, and our customers expect us not to trade their visibility for our marketing.

Concretely, this means we do not publish:

customer names or logos;
the sectors or geographies of individual deployments;
architecture diagrams, volumes, or topologies taken from a real instance;
incidents observed on a customer’s network, even anonymised.

What we can share instead:

reproducible technical scenarios, run on data we own;
the documentation, the rule packs, and the full feature set, open for inspection;
a technical discussion with the team about your own architecture and constraints;
a source-code review under NDA for a qualified assessor.

If a customer ever chooses to speak publicly about its deployment, we will publish that account with their explicit permission and on their terms. Until then, the most honest demonstration is a local evaluation: install Obserae on your own traffic and check directly whether it surfaces communications you did not know about or had never documented. That evidence is worth more than any logo wall.

Can we try Obserae on our own traffic without any commercial commitment?

Yes. Obserae can be installed locally and fed by a single exporter in order to run a first evaluation on the organisation’s real traffic.

A simple evaluation can follow four steps:

install Obserae on a VM, a server, or an ARM machine;
configure a firewall, a router, or a probe to send NetFlow or IPFIX;
name a few important networks and devices;
review the communications that do not match what was expected.

There is no need to start with the whole infrastructure. A single site, a server VLAN, or one firewall can be enough for a first indication of the product’s value. The website specifically suggests starting with one exporter and a few minutes of traffic.

The installation requires no account creation, no licence key, and no data sent to an external platform. During the beta, all features are open so they can be evaluated.

The test data stays on the instance and can be deleted at the end of the evaluation.