Arkime: full packet capture at scale, with the storage bill you choose

What Arkime solves, and who ends up running it

Most monitoring stacks tell you that something happened. Arkime is built around the assumption that you will want the bytes afterwards. The README states that it augments your current security infrastructure to store and index network traffic in standard PCAP format, with fast indexed access, and that it is not meant to replace an IDS but to work alongside one.

The project's own history explains the target user. Arkime was created at AOL in 2012 to replace commercial full packet systems, and the README's claim is a cost one: with control of hardware, full packet capture could be deployed across all networks for roughly what one network cost under a commercial tool, with larger retention. That framing is honest about the trade. You are not buying detection logic. You are buying the ability to go back to a session from three weeks ago and pull the packets.

The people who end up running it are network security engineers, incident responders and threat hunters who already have an IDS or a flow collector and keep hitting the same wall: the alert fired, the flow record exists, and the payload is gone. Arkime is also used by teams that need to hand a PCAP to someone else, since exports stay in standard PCAP and open in tools like Wireshark.

Three components: capture, viewer, and the search database

The architecture is deliberately split, and the split is where most operational decisions come from. Capture is a threaded C application. It monitors network traffic, writes PCAP formatted files to local disk, parses the captured packets, and sends metadata, described in the README as SPI data, to OpenSearch or Elasticsearch. Viewer is a Node.js application that runs per capture machine, handles the web interface, and transfers packets to the browser. OpenSearch or Elasticsearch is the search database powering the system.

That data flow has a consequence worth stating plainly. The metadata index and the packets live in different places with different scaling rules. PCAP retention is based on available sensor disk space; metadata retention is based on the Elasticsearch cluster scale. The README says both can be increased at any time and are under your complete control. Control here means you own the capacity planning. There is no tiering service inside Arkime that decides what to drop.

Around the core, the repository ships optional applications: cont3xt for structured contextual intelligence, esProxy as an extra security layer between capture and the database, Parliament as a monitor and front door for multiple Arkime clusters, and wiseService for integrating threat intelligence into session metadata. The top-level directories match that list, with capture/, viewer/, cont3xt/, parliament/ and wiseService/ sitting beside common/, db/ and tests/.

Installing Arkime from prebuilt binaries or containers

The README recommends prebuilt binaries or containers over a source build. Binaries are on the downloads page with simple install instructions, and the project provides official containers documented on its Docker page, including the available tags. For a first look, the container path avoids compiling the C capture code and the Node viewer yourself.

If you do build from source, the README calls it advanced and lists the steps. Node must be in your path, and main currently supports Node version 22.x. The easybutton build script takes options and installs, and the README points at .github/workflows/versions to find the option set for your OS. A minimal sequence looks like this:

git clone https://github.com/arkime/arkime
cd arkime
./easybutton-build.sh --help
./easybutton-build.sh --install
make config

The first script call prints the available easybutton options so you can pick the right ones for your distribution before running the install. The final make config performs an initial Arkime configuration; most system settings then live in /opt/arkime/etc/config.ini, and the variables are documented on the project's settings page rather than in the README.

Once it is running, the README gives the entry point: point your browser to http://localhost:8005. The Sessions page lists individual sessions that expand to show metadata and packet details, and the SPI View page shows every unique value for each field Arkime recognizes.

Ports, TLS and the security posture you have to supply

Arkime assumes a segmented network and tells you which holes to open. Machines need to communicate with each other on port 8005, with the OpenSearch or Elasticsearch machines on ports 9200 through 920x, and the web interface itself is served on port 8005. The README also says Arkime machines should be locked down.

Access control is delegated. The README states that access to Arkime is protected by HTTPS with digest passwords or by an authentication-providing web server proxy, and that Arkime can be configured to use OpenSearch or Elasticsearch user auth or API keys. The viewer should be configured to use TLS, and the README notes it is easiest to use a single certificate with multiple names, which is a hint about how many hostnames a real deployment accumulates.

All PCAPs are stored on the sensors and are only accessed through the Arkime interface or API. That is a meaningful boundary: the packets are not in the search cluster, so compromising the cluster does not hand over the payloads, but it also means sensor disk is the thing you must protect and size. The esProxy component exists precisely to add a security layer between capture and the database, which tells you the maintainers consider that link worth isolating.

Where Arkime is the wrong tool

The README is explicit that Arkime is not meant to replace an IDS. If your requirement is signature detection, alerting on known-bad patterns, or inline prevention, Arkime does not do that job and adding it will not close that gap. It stores and indexes traffic so other tools and people can investigate.

The second limitation is structural. Full packet capture at scale is a disk business. Retention is bounded by sensor disk, and once the disk fills, the oldest packets are what you lose; the metadata index will still show the session. That asymmetry surprises teams. You can find a session in the interface and discover the PCAP is gone. Nothing in the README describes a tiered archive that moves old PCAPs to object storage automatically, even though the dependency list includes an S3 client and an OpenSearch/Elasticsearch client, so anyone expecting cold storage to be handled for them should verify that against the settings documentation.

The third is the deployment shape. Capture is threaded C that needs to see traffic, which usually means a span port or a tap and a machine sized for the throughput. The README claims the system can scale to handle tens of gigabits per second across many systems, but that is a property of the cluster you build, not of a single install. A laptop install is fine for learning the interface and useless for a 10G link.

Arkime compared with Zeek, Suricata and Malcolm

Zeek and Suricata answer different questions. Zeek produces structured protocol logs and is extensible through scripts; Suricata is an IDS and IPS engine with rule-based detection. Neither is a packet retention system with an indexed web interface for browsing sessions and exporting the original PCAP. Teams commonly run one of them for detection and Arkime for the archive, which is exactly the arrangement the README describes when it says Arkime works alongside an IDS.

Malcolm is the closer comparison, because it is also an integrated network traffic analysis stack rather than a single engine. The practical difference is composition. Arkime is a system you assemble: capture, viewer and OpenSearch or Elasticsearch, plus optional pieces like cont3xt, Parliament, esProxy and wiseService. An integrated distribution makes different choices about which components ship together and how they are wired. If you want to choose your database, your retention policy and your sensor placement, Arkime's split is the point. If you want a stack that arrives pre-integrated, that is a different trade.

The older name in the search data, Moloch, is not a separate alternative. Arkime is the renamed project, so anyone comparing the two is comparing a version of the same codebase against its own history.

Licence, maintenance and the cost of staying current

Arkime is Apache-2.0, and the repository carries both a LICENSE and a NOTICE file at the top level. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also carries attribution and notice obligations, and the NOTICE file exists for that reason. If you redistribute Arkime or ship it inside a product, read LICENSE and NOTICE together rather than treating the licence badge as the whole story. Nothing here is legal advice; the files in the tree are the authority.

The repository is not archived and the last push was on 2026-09-18, four days before this writing, so activity is current rather than historical. The release list is worth reading carefully, though, because it is not a tidy version ladder: v6.7.0 is dated 2026-08-19, while entries named last-commit6 and last-commit7 are dated 2024-10-24 and 2026-05-07. Anyone pinning to a tag should check which of these the deployment documentation actually refers to rather than assuming the newest date is the release to run.

Upgrade cost concentrates in two places. The Node side moves with the ecosystem: main supports Node 22.x, and the dependency list spans Express, Passport, OpenID, Vuetify and the OpenSearch and Elasticsearch clients, so viewer upgrades can drag in a runtime change. The storage side moves with your own cluster, since metadata retention depends on the Elasticsearch cluster scale. Neither upgrade is automated by the project; both are yours to schedule.

Editorial conclusion

Adopt Arkime when you need the packets themselves and can supply sensor disk plus an OpenSearch or Elasticsearch cluster, and when your team can run a C capture daemon and a Node viewer. Do not adopt it as a replacement for an IDS, and do not adopt it if nobody will own the retention math, because PCAP retention is bounded by sensor disk and metadata retention by the cluster. Before committing, verify the Node version your build path expects, confirm the ports capture, viewer and the database need, and check the licence and notice files in the source tree against how you plan to redistribute it.

Frequently asked questions

Official sources

1. arkime/arkime on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases