Akvorado turns sampled flows into a network’s working memory

Summary

• Akvorado is an active open-source flow-analysis project initiated by Vincent Bernat, supported in Free’s operational environment and developed through a public contributor community rather than a standalone company.
• Its 2.x architecture separates UDP reception, Kafka transport, enrichment, and ClickHouse storage, allowing each stage to scale independently while leaving pre-ingestion packet loss and source quality unresolved.
• The platform becomes useful when it converts addresses, interface indexes and counters into peering, capacity and incident context, but those conclusions remain conditional on metadata, classifiers and timing.

A maintenance release points back to a larger redesign

On 14 July 2026, Akvorado’s maintainers released version 2.4.1. The release itself was a routine marker of active maintenance. The more consequential fact sat behind it: the project’s current generation no longer asks one tightly coupled collector to receive every flow export, decode it, enrich it and push it directly into analytical storage. Akvorado 2.0 divided that journey into separate operating units, with an inlet receiving datagrams, Apache Kafka carrying a compact representation, outlet workers adding context and ClickHouse storing the result for search and aggregation.

That architecture describes a practical answer to a familiar operator problem. A large network can produce far more traffic evidence than engineers can inspect packet by packet. Routers and switches can summarise what they see into NetFlow, IP Flow Information Export, or IPFIX, and sFlow records. Those exports preserve enough information to answer many questions about volume, direction, interfaces and communicating endpoints without retaining every payload. Akvorado collects that evidence, attaches network meaning to it and makes the resulting history available through a web interface and filter language.

The apparent simplicity of a graph hides a chain of decisions. The exporting device chooses which packets or flows are represented. Sampling can exclude short conversations. UDP can lose datagrams before the collector records them. Templates can change. Interface identifiers can be reused. A routing feed can describe a path that changed after the traffic passed. An autonomous-system or geographic database can classify an address incorrectly. A human-written rule can label traffic as customer, peer or transit even though that label never existed in the packet.

Akvorado matters because it exposes much of that chain in open code rather than presenting the chart as an unexplained appliance result. The project gives operators control over collection, retention, enrichment, queries and access. It also gives them responsibility for the weaknesses of every component they choose. The governing question is therefore practical rather than promotional: how far can a self-hosted flow system turn partial exports into dependable operational memory without allowing a polished dashboard to outrun the evidence?

The answer depends on the job. For capacity planning, a sampled trend can be valuable even when it is not an exact packet count. For peering, broad traffic direction and autonomous-system context can reveal where demand is moving. For an incident, a historical flow may narrow the time, interface and counterpart involved. None of those uses requires packet-level omniscience. Each requires the operator to know what the record represents, what it omits and how later enrichment changed its meaning.

Flow records exist because packet capture is too costly to keep

Full packet capture can preserve headers, ordering and sometimes payload at a level that supports detailed forensic reconstruction. It also creates enormous storage, access-control and privacy burdens on busy links. Flow telemetry accepts a different bargain. The exporter groups or samples traffic and emits records containing selected fields such as source and destination addresses, ports, protocol, counters, timestamps and input or output interfaces. The result is smaller, easier to retain and suited to long-range aggregation, but it is no longer a literal replay of the packets that crossed the network.

NetFlow and IPFIX commonly describe conversations through flow records created when a cache entry expires or a flow ends. IPFIX formalises an architecture built around exporters, collectors, templates and data records. A collector needs the template to interpret the values that follow; a field position has no stable meaning on its own. Vendor-specific elements and different cache policies can make two exporters describe similar traffic in unlike ways. Akvorado’s decoders therefore sit at a boundary between a family of standards and the realities of device implementations.

sFlow usually approaches the problem through packet sampling and counters. A device selects packets at a configured rate, exports sample information and can report interface statistics. At sufficiently high volumes, sampling allows broad traffic patterns to be observed without requiring the hardware or collector to process every packet as a separate event. The trade-off becomes visible at the edges: a short flow may never be selected, a sudden burst can be underrepresented and an estimate needs a sampling rate and denominator before it can be read responsibly.

The distinction matters because “flow” is not one uniform evidence type. A sampled packet header, an aggregated conversation record and an interface counter answer different questions. They can support one another, but they should not be merged into a single claim of exactness. Akvorado can store and present the fields it receives; it cannot make an exporter reveal packets that were never selected or fields that were never emitted.

Long retention is the main operational attraction. An interface counter can show that a link carried more traffic at a particular moment, yet it cannot usually identify the networks or services involved. A packet capture may answer that question in detail, but many operators cannot retain it for weeks or months across every high-capacity link. Flow records occupy the middle ground. They preserve enough dimensions to revisit an event later, provided the sampling and export policies remained known.

That middle ground is why flow analysis belongs in the infrastructure stack rather than at the edge of a dashboard. The collector is part of an evidence-production system. Its output can guide purchases, peering changes, traffic engineering and investigations. Decisions with that consequence need a documented path from device configuration to query result.

The exporter decides what Akvorado can ever know

Akvorado’s first dependency is outside its repository. Routers and switches decide whether flow export is enabled, which interfaces participate, how records are keyed, how often caches expire, what sampling rate is used and which fields appear. Hardware forwarding paths may expose different levels of detail. An operator can deploy a flawless collector and still receive a partial account because the source devices were configured inconsistently or could not export the needed evidence.

Template handling is one fragile point. IPFIX and several NetFlow versions use templates so an exporter can define the structure of later records. If a collector misses a template, receives data before the relevant definition or encounters a changed enterprise field, it can be unable to decode the record correctly. A collector can request or await a fresh template in some circumstances, but telemetry lost during the gap does not reappear automatically. The safe operating practice is to treat template state as a monitored dependency rather than invisible protocol plumbing.

Sequence information can reveal some gaps. Exporters may number packets or records, allowing a collector to notice a reset or discontinuity. That signal is diagnostic, not restorative. A missing sequence can show that the evidence has a hole; it cannot reconstruct the absent traffic. Exporter restarts, path loss, socket overflow and host scheduling can produce similar symptoms, so the loss counter starts an investigation rather than naming the cause.

Sampling adds a different kind of uncertainty. Sampling one packet in several thousand can estimate sustained high-volume traffic well enough for some planning tasks, while offering little confidence about rare conversations. The error is not a fixed percentage that can be applied everywhere. It depends on the distribution of flows, the sampling method, the time window and the question being asked. A graph of aggregate transit traffic and a claim about one short suspicious connection demand different evidence standards.

Calibration gives operators a way to keep the uncertainty visible. Flow-derived byte totals can be compared with interface counters over the same interval. Persistent divergence can point to sampling assumptions, exporter coverage, dropped datagrams or classification errors. The comparison will not make the datasets identical, because counters and flows measure through different mechanisms. It can show whether a flow system is behaving consistently enough for its intended use.

This is the first limit on Akvorado’s authority. The project can decode, enrich and query what arrives. It does not control the instrument at the observation point. An operator that treats exporter configuration as somebody else’s problem will discover that every later stage is analysing an unknown denominator.

Vincent Bernat built Akvorado around the questions operators actually ask

Akvorado emerged around 2019 from practical flow-analysis work associated with Vincent Bernat, a network engineer whose public writing and repository history make him the project’s principal initiator and maintainer. The software also has operational roots in the French internet service provider Free, which provides an important production context and support relationship. The available evidence does not establish Akvorado as a Free-owned commercial product, a separate company or a service operated centrally for every user.

That distinction explains the project’s character. Its public materials concentrate on problems familiar to network operators: receiving several flow formats, translating interface indexes, adding autonomous-system and route context, distinguishing peering from transit, retaining large datasets and letting engineers ask targeted questions. The interface is useful because it sits above an operator-specific data model, not because it offers a generic collection of colourful charts.

The early chronology is less complete than the current architecture. Repository history supports an active project through the early 2020s, with collectors, classifiers and web exploration maturing before the 2.0 redesign. Bernat documented a SQL-like filter language and dynamic Protocol Buffers work in 2023, and releases continued through 2024. The exact first production deployment, project start date and growth of the user base are not established by a public census. Those gaps should remain gaps rather than being filled by a founder legend.

Free’s relevance is strongest as an operational environment. A busy ISP supplies requirements that a laboratory demonstration may not expose: bursts of UDP exports, many interfaces, high-cardinality addresses, changing routes and questions that connect traffic volume with commercial relationships. That context can shape design priorities. It does not prove that every feature was deployed in the same way inside Free, that Free funds every contributor or that the company controls the project’s future.

The public repository gives external operators a different kind of confidence. They can inspect code, issues, release notes and configuration guidance. They can run the stack in their own environment, keep sensitive metadata under their own access controls and modify the software under the GNU Affero General Public License version 3. Transparency, however, is not a substitute for support. An organisation still needs people who understand exporters, Kafka, ClickHouse, routing data and the consequences of an upgrade.

Akvorado’s origin therefore sets up the central tension rather than resolving it. Operator-led software can encode the right questions more faithfully than a generic analytics product. It can also carry the concentration risk of a small maintainer community and the operational assumptions of the environments that shaped it.

Version 2.0 split reception from interpretation

The original appeal of a single integrated collector is obvious. One process or tightly coupled stack receives records, decodes them, enriches them and writes them to storage. Deployment is easier to explain and there are fewer moving parts to operate. The weakness appears when input and analysis stop moving at the same speed. A burst of UDP datagrams cannot wait while a database merge stalls or an external metadata lookup slows. If the receiving path blocks, the oldest and most irreplaceable evidence can be lost at the entrance.

Akvorado 2.0 separated those concerns. The inlet concentrates on receiving flow datagrams and publishing a compact encoded representation to Kafka. Outlet workers consume the stream, decode records, add metadata, apply classifiers and batch inserts into ClickHouse. Reception capacity, enrichment capacity and database throughput can then be scaled as related but distinct problems.

The decoupling changes failure behaviour. A temporary ClickHouse slowdown no longer has to stop the UDP listener immediately; Kafka can hold a backlog within the limits of its retention and available storage. More outlet workers can be added when enrichment falls behind. Partitions can distribute work, while the inlet remains small enough to focus on socket handling and exporter state.

The design also creates a clearer operational vocabulary. Engineers can ask whether datagrams reached the inlet, whether the inlet published them, whether consumers kept pace, whether enrichment succeeded and whether ClickHouse accepted the batch. A monolithic service can hide those stages behind one health indicator. Separate components make the hand-offs observable, although only if the deployment collects and retains the relevant metrics.

More components bring more ways to fail. Kafka brokers require capacity, replication choices, retention policy and maintenance. Consumer lag can grow silently. Partitions affect distribution and ordering. Outlet workers can become inconsistent if schema or enrichment configuration differs. ClickHouse may be healthy enough to answer old queries while recent inserts queue elsewhere. The 2.0 architecture improves control by making the pipeline explicit; it does not make the pipeline self-managing.

Migration is another boundary. A redesign that changes message representation, service roles and storage behaviour can create compatibility and operational work for existing users. The public release history shows active maintenance through version 2.4.1, but there is no independent census of how many operators moved from earlier versions, how long those migrations took or which failure modes appeared at the largest scales.

The 2.0 change is best understood as an allocation of responsibility. The inlet protects the moment of arrival. Kafka absorbs timing differences after publication. The outlet turns raw records into the schema Akvorado expects. ClickHouse preserves the analytical history. Each stage can be improved and tested separately, and each stage leaves a specific kind of gap when it fails.

Kafka absorbs processing delays after the data arrives

Kafka is the hinge in Akvorado’s current architecture because it converts a burst-sensitive receive path into a stream that downstream workers can process at a different pace. Messages are placed on topics and partitions, retained for a configured period and consumed by outlet workers. That buffer can keep an expensive enrichment or storage delay from propagating directly back to the exporter-facing socket.

The timing boundary is exact. Kafka can protect data only after the inlet has received and published it. A datagram dropped on the network, discarded by an exporter, lost to a full socket buffer or rejected before publication never enters Kafka’s buffered stream. Calling the pipeline “lossless” because Kafka is present would erase the most vulnerable part of the path.

After publication, durability still depends on choices. Broker replication, acknowledgements, disk capacity, retention and failure recovery determine how much protection the queue provides. A short retention period can turn a prolonged ClickHouse outage into data loss. A partitioning design that concentrates heavy exporters can create uneven lag. A broker failure during an under-replicated period can remove records that the inlet had already accepted.

Ordering requires care as well. Kafka provides order within a partition, not across every partition in a cluster. Flow analysis often cares more about bounded timestamps and aggregate windows than a single total order, but template state, exporter sequence and enrichment updates can still depend on the relationship among records. Operators need to know which ordering assumptions the outlet makes and how restarts or rebalances affect them.

Consumer lag is the most useful operational signal because it translates architecture into time. A queue of ten million records means little without the arrival rate and processing rate. Lag measured in seconds or minutes shows how far the analytical view trails the network. When a capacity or incident team believes it is looking at current traffic, that delay becomes part of the evidence and should appear in the service’s own health model.

Kafka also changes the skills required to run Akvorado. A small networking team that previously managed one collector and one database now operates a distributed message system. The added burden may be justified by scale and resilience. It is still a cost borne by the operator, not a free property of open-source software.

The right claim is narrow and useful: Kafka reduces coupling between reception and downstream work. It creates room to survive temporary imbalance. It does not restore records lost before the inlet, guarantee every deployment’s durability or remove the need to monitor the queue as production infrastructure.

ClickHouse makes long traffic histories queryable

Flow telemetry is well suited to a columnar database because many questions scan a few fields across a very large number of rows. A peering engineer may group bytes by destination autonomous system and time. A capacity planner may compare interfaces or sites over weeks. An incident responder may filter a narrow set of addresses and ports within a short interval. Columnar storage can read the relevant columns, compress repeated values and aggregate without treating every query as a full reconstruction of each record.

Akvorado batches inserts into ClickHouse and organises data for time-bounded analytical work. Derived or materialised fields can make common dimensions easier to query. The database provides the persistence that turns ephemeral exports into memory: an engineer can return to a traffic shift after the device counters have rolled on and the original routing state has changed.

That memory has a physical cost. High-cardinality addresses, ports, interface metadata and labels consume storage and affect compression. Partitions, sorting keys and merge behaviour influence query latency and insert stability. Retention decisions determine whether the system holds days, months or longer periods. A deployment that keeps every available dimension indefinitely can exhaust disks or spend more on storage than the questions justify.

ClickHouse’s background work matters because fresh data and historical queries compete for the same system. Merges, compaction and replication can consume input/output capacity while outlets are inserting new batches. A database can remain technically online and still be operationally behind. Disk pressure may first appear as slower merges, then delayed inserts and finally missing recent evidence from the user’s point of view.

Query design can create a similar illusion. A graph that returns quickly may rely on precomputed or derived fields whose semantics differ from the raw record. A broad query over a high-cardinality dimension can produce an expensive scan. An operator needs limits, query observability and a clear distinction between full-resolution data and any aggregation or retention policy applied within the deployment.

The project’s SQL-like filter language helps users avoid direct database syntax, but it does not remove the database model. Fields must exist, have stable meanings and be indexed or organised well enough for the workload. Schema evolution can add dimensions while creating migration and compatibility work. Dynamic Protocol Buffers can make transport representation more flexible; ClickHouse still needs a coherent analytical schema on the other side.

ClickHouse is therefore more than a dependency hidden under the web interface. It is part of the product’s operational contract. Storage health, merge performance, query latency and retention policy determine whether Akvorado can answer the question an operator asks at the moment it matters.

Enrichment turns interface indexes into a map of the business

A raw flow record can say that traffic entered interface 287 and left interface 914. Those numbers are meaningful to the exporting device, but they do not tell an engineer whether the path crossed a customer port, a private interconnect, a transit provider, a backbone link or a maintenance interface. Akvorado enriches records so the query can be framed in the vocabulary of the network rather than the vocabulary of the exporter.

Simple Network Management Protocol (SNMP) polling is one source of that context. Akvorado can cache interface names, descriptions, speeds and addresses so numeric indexes become recognisable links. This makes a graph usable during capacity review or incident investigation. It also creates a temporal problem: interface indexes can be reused, descriptions can be edited and polling can fail. A record generated on Monday can be displayed with metadata collected later unless the implementation preserves the relationship carefully.

Address and autonomous-system databases add another layer. They can associate an IP prefix with an organisation, autonomous system or location, giving peering teams a way to group traffic by network and geography. Those databases are useful reference material rather than perfect ownership records. Prefix origins change, organisations merge, anycast complicates location and commercial databases use methodologies that may disagree. A label should carry enough provenance that an analyst can challenge it.

Border Gateway Protocol context can connect traffic to the control plane. Akvorado’s current architecture supports routing information, including data obtained through the BGP Monitoring Protocol, or BMP. Prefix, peer and next-hop information can help explain which route was visible and which relationship may have carried the traffic. The strongest qualification is time: a routing snapshot collected after the flow may not describe the route selected when the packets crossed the network.

The enrichment stage therefore creates both value and new evidence types. Device metadata describes local interfaces. Routing data describes control-plane state. IP and ASN databases describe external mappings. Geographic data estimates location. None should be treated as a native property of the packet. Akvorado combines them so an operator can ask better questions, but the query result inherits each source’s timestamp and error model.

This distinction is especially important when an organisation uses the same data for technical and commercial work. A stale interface description may be an inconvenience during troubleshooting. The same mistake can shift traffic into the wrong customer or transit category and influence settlement, investment or sales discussions. Enrichment is where a collector becomes an operational system, and where an innocent metadata error can become an organisational fact.

Classification is where technical records become commercial evidence

Networks do not emit a “peer”, “customer” or “transit” bit in every packet. Those categories come from contracts, routing relationships, interface design and operator policy. Akvorado’s classifiers can combine interfaces, autonomous systems, prefixes, BGP communities and other metadata to assign the labels that make traffic commercially intelligible.

The value is immediate. A total utilisation graph can show that a link is filling, but it cannot tell whether growth comes from paying customers, settlement-free peers, upstream transit or internal backbone movement. Classification lets an operator separate those flows and ask which relationship is driving the change. Peering teams can look for candidates whose traffic has grown. Capacity planners can decide whether a new port, route or circuit is justified.

The classifier is also a policy document expressed as code. A rule that maps one interface to “customer” records an assumption about the network’s organisation. A prefix list can encode a business boundary. A BGP community can stand in for a contract category. When those inputs change without the rules changing, the dashboard can continue to look precise while its meaning drifts.

Review needs to match the consequence. Classifiers that support internal exploration can be tested informally. Classifiers used in capacity budgets, partner negotiations or billing-related analysis need change control, peer review and calibration against independent data. A small rule edit can reclassify months of history or alter the apparent economics of a route.

Historical consistency is another problem. If a classifier changes today, should old records retain the label that applied when they were collected or be reinterpreted under the new policy? Both approaches can be useful. The first preserves what the organisation believed at the time. The second allows comparable reporting under a current definition. The system and the analyst need to know which one a graph represents.

Akvorado makes such decisions visible enough to manage because the rules and data remain under operator control. It does not choose the correct commercial ontology for the network. The most important dashboard review may therefore happen outside the user interface, where engineering, peering and finance teams agree on what the categories mean.

A SQL-like language lowers the distance between data and operator

A flow database is useful only when engineers can ask questions quickly enough to influence operations. Direct SQL offers power, but it exposes storage details and can create unsafe or expensive queries. Akvorado’s SQL-like filter language gives users familiar predicates, sets and operators while mapping them into the project’s own query model.

The language matters because operational questions are iterative. An engineer may begin with one interface, then narrow by autonomous system, address family, protocol, port or direction. A peering analyst may compare a network before and after a routing change. An incident responder may move from an aggregate spike to a short list of endpoints. A query interface that keeps those steps close to the domain vocabulary reduces the delay between suspicion and evidence.

Abstraction has a boundary. A field can be queried only if it exists in the schema and was populated correctly. A convenient alias can hide whether a value came from the exporter or an enrichment database. Set membership can be fast or expensive depending on implementation. The language protects users from some database complexity; it cannot make an ill-defined field precise.

Schema evolution is one reason Bernat documented the use of dynamic Protocol Buffers in 2023. Flow formats and enrichments change, and a rigid compiled message definition can force every producer and consumer to move together. A dynamic representation can carry new fields more flexibly and keep the inlet’s encoded messages compact. Compatibility rules, field numbers and semantics still need discipline, especially when older consumers or stored records remain in service.

The web interface completes the path by turning filters into tables and graphs. Visualisation is valuable because humans can recognise shifts, periodicity and outliers faster than they can read raw rows. It can also create false confidence. A smooth line may be based on sampled traffic, a delayed queue and an updated classifier. The graph’s design should make the time window, aggregation and relevant evidence limits available rather than hiding them behind presentation.

A good query layer therefore performs two jobs. It makes complex data accessible, and it keeps enough of the model visible for an operator to challenge the answer. Akvorado’s open implementation gives teams the opportunity to inspect that path. Whether they do so is a matter of operating culture, not software licence.

Classification gives traffic volume its commercial meaning

Flow analysis earns its place in a network when it changes a decision. Capacity planning is one of the clearest examples. Interface counters can show utilisation, but flow history can divide demand by destination network, region, protocol, customer class or other dimensions. That detail can help an operator decide whether to upgrade an existing link, add a peering session, shift traffic or investigate a sudden change.

The decision remains conditional on the evidence chain. A sampled dataset may represent a sustained large flow well and miss many short ones. An incomplete set of exporters can make one part of the network look quieter. A classifier can assign the wrong relationship. A later route change can confuse interpretation if the relevant control-plane state was not retained. The planning value comes from consistent measurement over time, not from treating one number as an invoice-grade truth.

Peering analysis illustrates the difference between technical reach and commercial meaning. An autonomous system that appears frequently in destination data may be a candidate for direct interconnection, but traffic volume alone does not establish mutual benefit, location, port availability, policy or contract terms. Akvorado can identify a pattern worth examining. The peering decision still belongs to operators who understand route paths, cost, resilience and counterpart willingness.

Capacity forecasts have a similar boundary. Historical growth can guide investment, yet application launches, customer churn, caching changes and routing events can alter the pattern. A long retention window helps teams see seasonality and structural shifts. It does not make the future a continuation of the past. The most responsible use of the data is to define scenarios and thresholds rather than one deterministic forecast.

Flow history can also test whether an intervention worked. After a route-policy change, engineers can compare traffic distribution before and after the event. If a transit link falls and a peer rises, the result is consistent with the intended shift. BGP records and interface counters can strengthen the interpretation. None of the signals alone proves that every packet followed the desired path or that user experience improved.

This is where Akvorado’s value is easy to overstate and easy to dismiss. It does not automate the commercial decision. It gives a network a durable, queryable account of the observations on which that decision can be argued. In organisations where peering and capacity knowledge otherwise lives in spreadsheets, one-off scripts and individual memory, that shared account can be infrastructure in its own right.

Flow history narrows an incident without proving its cause

During an incident, the first operational advantage of retained flow data is time. Engineers can ask when a traffic pattern changed, which interfaces were involved, which endpoints or autonomous systems dominated and whether the event was still occurring. Those questions can narrow a broad outage or congestion report into a smaller set of systems and relationships.

The evidence is strongest when it is combined. Interface counters can confirm the magnitude of a link change. BGP or BMP records can show a control-plane event. Device logs can reveal a restart or policy update. Packet capture can provide detail for a short period. Endpoint telemetry can show whether an application failed. Akvorado’s flow history connects those sources through time and network identity, but it does not replace them.

A large traffic spike is not automatically an attack. It can be a popular release, backup, cache miss, routing change or measurement error. Flow metadata can show sources, destinations, ports and volume; it usually lacks application payload and endpoint state. Security teams can use it to identify candidates for blocking or deeper investigation. Attribution and intent require additional evidence.

A quiet graph can mislead as well. If an exporter stopped, the disappearance of records may look like recovery. If Kafka lag grew, the interface may show an old state. If a classifier changed, traffic can move between categories without moving on the wire. Incident runbooks need explicit checks for data freshness, exporter health, sequence gaps and pipeline lag before analysts interpret the traffic.

Retention creates an advantage after the immediate pressure has passed. Teams can reconstruct the minutes before an alert, compare the event with earlier baselines and test competing explanations. That is especially useful when the original device state has been overwritten. The post-incident review can also expose weaknesses in the evidence system itself: missing interfaces, stale SNMP descriptions, inadequate sampling or a retention window that ended too soon.

The correct language for Akvorado in an incident is “supports investigation”. It can make a failure legible and reduce the search space. A graph remains an observation filtered through exporters and metadata, not a causal verdict.

An IPv6-first case shows portability—and the limits of one example

On 9 April 2026, the APNIC Blog published an operational article about setting up Akvorado for an IPv6-first network. The case is useful because it comes from outside the project’s core narrative and places the software in a specific deployment context. It shows that the stack can be adapted to an environment where IPv6 is central rather than an afterthought.

One case carries bounded weight. It does not establish the number of active Akvorado installations, market share, universal IPv6 behaviour or suitability for every operator. The hardware, exporters, traffic profile, staff experience and retention goals of that deployment may differ from those of a large carrier, enterprise or content network. A case study is evidence of use, not a census.

Its larger significance lies in portability. Akvorado is distributed as open software rather than a centrally operated service. An external team can install it, connect its own exporters, define its own classifiers and keep its own data. That ability separates the project from an internal Free tool and gives the repository a life beyond the environment that helped shape it.

Portability also tests documentation. A project is easier to adopt when an operator can understand the inlet, Kafka, outlet and ClickHouse roles without private guidance. Public installation material and a demonstration environment lower the first barrier. They cannot anticipate every vendor template, scale problem or security policy. External case studies reveal where the documented model survives contact with a different network.

More independent deployment accounts would materially strengthen the evidence. Useful reports would state exporter types, sampling rates, record volumes, retention, infrastructure costs, loss measurements, migration experience and the relationship between flow estimates and interface counters. They would also describe failures, because successful screenshots reveal little about how the system behaves under pressure.

Akvorado’s public adoption record is therefore credible but incomplete. Repository activity, releases and an APNIC-published case show a living project with use beyond one maintainer. They do not support a precise installation count or a claim that the stack has become the default choice for flow analytics.

Self-hosting keeps sensitive metadata close

Flow records usually omit application payload, yet they can reveal a great deal about relationships. Addresses, ports, timing, volumes and interfaces can show which systems communicated, how often and through which part of the network. Long retention turns those observations into a behavioural history. For a carrier, enterprise or public institution, that dataset can be operationally valuable and sensitive at the same time.

Akvorado’s self-hosted model lets an organisation keep collection, Kafka, ClickHouse and the web interface inside infrastructure it controls. The operator can decide where data resides, how long it is retained, who can query it and which enrichment services are used. That is a meaningful advantage for teams that cannot send detailed network telemetry to an external service.

Local control is only as strong as local practice. The web interface, APIs, database credentials, Kafka access and underlying hosts all become part of the security boundary. A broad analyst role can expose relationships well beyond what the user needs. Backups and replicas can preserve data after the nominal retention window. Exporting query results can move sensitive information into less controlled systems.

Retention needs a purpose. Capacity planning may work with aggregated history, while incident response may require more detailed records for a shorter period. A single indefinite policy maximises investigative possibility and breach impact at the same time. Access tiers, aggregation, deletion and audit logging should follow the questions the organisation has decided it is entitled and prepared to answer.

Enrichment can add privacy risk as well as operational value. Mapping an address to an organisation or location makes a record easier to interpret and easier to misuse. An inaccurate mapping can also direct suspicion towards the wrong party. Analysts should be able to see which fields came from the exporter, which came from internal metadata and which came from external databases.

The AGPLv3 licence gives users access to the code under its terms, but the licence does not design an organisation’s data governance. Self-hosting removes one vendor from the chain of custody. It does not remove the need for least privilege, secure maintenance, retention limits and a clear account of who can turn traffic metadata into decisions.

An open licence leaves operators with the cost of the stack

Akvorado does not require a conventional software licence fee for use under the terms of its AGPLv3 licence. That fact can make the platform attractive to operators that want control over cost, data and customisation. It should not be confused with free operation. A production deployment consumes servers or virtual machines, storage, network capacity, staff time and on-call attention.

Kafka and ClickHouse are substantial systems in their own right. Their capacity must be planned, upgrades tested and failures repaired. Exporter coverage needs continuous maintenance as network devices and firmware change. SNMP credentials and metadata need protection. Classifiers require review. Security patches must be applied. The largest cost may be the engineering time needed to keep the evidence trustworthy.

Commercial platforms such as Kentik offer another allocation of those costs. A managed service can combine hosting, support, integrations and a broader product surface under a contract. ElastiFlow and other open or commercial stacks offer different storage, licensing and support choices. pmacct, ntopng, FastNetMon, general observability tools and packet systems solve adjacent parts of the problem. The comparison should be made by operating model and evidence requirements rather than by counting dashboard features.

A self-hosted operator keeps more control over raw records, schema, retention and query logic. It also carries the risk that a specialist leaves, a dependency changes or an upgrade fails. A managed customer transfers some infrastructure and support responsibility to a vendor, while accepting contract, data-location, pricing and product-roadmap dependencies. Neither model eliminates lock-in; each locates it differently.

Akvorado’s absence of a canonical commercial support company is therefore material. Consultancies may help individual deployments, but the reviewed evidence does not establish one vendor that guarantees migration, security response or service levels for the project as a whole. An organisation adopting the stack should decide whether it can operate independently, contract for expertise or contribute enough upstream to reduce its own support risk.

Total cost also depends on the value of retained history. A smaller network with modest flow volume may find the stack economical on ordinary infrastructure. A large operator retaining detailed, high-cardinality records can face significant storage and database costs. The useful denominator is not cost per server. It is the cost of producing evidence reliable enough to change an operational decision.

This economic boundary is easy to overlook because open-source projects do not publish revenue or valuation. Akvorado’s sustainability rests on maintainer labour, Free’s operational support, external contribution and each user’s willingness to run the dependencies. The project can create large downstream value without possessing a balance sheet that measures it.

A maintainer-led project can be transparent and still be concentrated

Vincent Bernat is the principal public initiator and maintainer associated with Akvorado. The repository records contributions from others, and releases, issues and pull requests make development visible. No separate foundation, elected board, formal membership body or complete funding arrangement was identified in the reviewed material.

Repository-centred governance has real strengths. Decisions leave a public trace. Users can propose changes, inspect discussions and fork the code if they reject the direction. The licence and source availability make technical exit possible in a way that a closed service does not. The project can also respond quickly when maintainers share a clear operating model.

The same structure concentrates practical authority. Maintainers decide which changes enter official releases, how compatibility is handled and which bugs receive attention. Expertise around the inlet, dynamic schema, classifiers and migration paths may sit with a small number of people. A fork is legally possible but operationally expensive when the departing community lacks that knowledge.

Free’s support reduces some continuity risk by anchoring the project in a production environment. It also creates dependence on priorities that are not fully documented publicly. If the company’s requirements change, if maintainers move roles or if sponsorship declines, external users need to know whether the broader contributor community can sustain releases, security fixes and dependency upgrades.

Upstream projects add another layer of distributed control. Kafka and ClickHouse set their own roadmaps. Device vendors change exporter behaviour. Standards bodies evolve IPFIX and BMP-related work. External databases alter schemas and licensing. Akvorado can adapt, pin versions or replace components, but it cannot veto those decisions.

A mature governance story would not require Akvorado to become a large foundation. It would make continuity legible. A documented release policy, broader maintainer group, security process, compatibility commitments and succession plan would tell operators what happens when the current informal relationships are stressed. None was established as a complete public framework at the research cutoff.

The project’s openness should therefore be described precisely. The code and much of the decision trail are public. Funding, time allocation and succession are less visible. Transparency reduces dependence on trust, but it does not abolish dependence on people.

The best dashboard is the one that reveals its denominator

Akvorado’s contribution is not a claim to see the whole network. It is a way to preserve and interrogate selected observations long after the devices that produced them have moved on. The project connects router exports, queueing, enrichment, storage and query in a form that operators can inspect and run themselves.

Its strongest uses accept uncertainty rather than hiding it. Capacity teams can follow durable trends while checking flow totals against counters. Peering teams can discover traffic relationships while reviewing classifier rules. Incident responders can narrow time and scope while seeking routing, log, packet and endpoint evidence. Privacy teams can keep data local while limiting who can read it and how long it survives.

The main failure mode is epistemic before it is technical: a clean graph can make an unknown denominator feel exact. Missing exporters, packet sampling, UDP loss, delayed consumers, stale interface data and retrospective labels can all produce a plausible line. The system becomes safer when those conditions are measured alongside the traffic rather than treated as implementation detail.

That is also the most useful test of Akvorado’s next phase. Release cadence after version 2.4.1 will show whether the 2.x architecture remains maintainable. Independent deployments can show migration cost, data loss, query performance and total operating burden. Better temporal handling of routing and metadata can strengthen historical analysis. A broader security and governance process can reduce continuity risk.

Success does not require Akvorado to replace every managed platform or become a universal standard. It requires the project to remain good at the narrower job it chose: turning incomplete flow exports into an honest, durable working memory. The decisive evidence will be whether operators can explain the path from a line on the screen back to the devices, sampling, queues, metadata and rules that created it.