Announcing full support for ARM CPUs in Seq 2021.4

Seq 2021.4 has shipped! 🎉 Find downloads and container information at

We're committed to making Seq a joy to use wherever you develop. Since Apple's switch to Apple Silicon in M1 MacBook Pros, for many of us this means working on the ARM architecture, alongside the more typical AMD and Intel x64 chips.

Seq now officially supports 64-bit ARM CPUs, including those found in Apple laptops, AWS Graviton, and yes — Seq will happily run on the Raspberry Pi 4.

Here's the obligatory screenshot of Seq running locally on a brand new M1 developer Mac 😎:

Screenshot showing macOS with Docker Desktop open in one window, and a Safari browser window open showing the Seq Dashboards page on localhost.
Developers working on M1 MacBook Pros can now run Seq locally.

For production workloads, it's now possible to provision ARM machines in EC2:

A screenshot showing a web browser open at the AWS Graviton product page, and a separate browser window showing Seq 2021.4.
Graviton promises better price/performance than x64 in AWS.

To run Seq on these platforms, you'll need Docker. The datalust/seq Docker image is multi-architecture, so when you pull it from Docker Hub, you'll get an ARM or x64 build depending the architecture of your local machine.

Important note: preview ARM support was included in several of the 2021.3 release tags. The official release uses a different format for metadata storage, so if you've been using one of these on your ARM system, you'll need to upgrade to 2021.4 so that the existing data can be converted, before upgrading to any future Seq versions.

Seq on the ARM architecture

The "application" side of Seq is implemented in C# on .NET, so Seq on ARM uses the ARM builds of .NET 6. Now that we've been through a platform port ourselves, we have renewed appreciation for the job that the .NET team and community have done to make ARM feel like a first-class platform for running .NET code.

The "data" side of Seq is predominantly Rust. ARM has been supported by the Rust compiler for some time, but only became a Tier 1 target in December 2020. The experience of porting the Rust side of our codebase to ARM has also been smooth and trouble-free. This is especially pleasing because it demonstrated to us that Rust's disciplined approach to concurrency has kept us — as far as we know — clear of the issues that we'd otherwise expect to see when moving highly-concurrent native code between platforms with different memory models. Yes, we're still very happy with our decision to build Seq's native event store in Rust.

Aside from flicking the switches on our .NET SDK and Rust compiler, we made changes in a few other parts of our stack.

Native metadata store

Seq can use a variety of storage back-ends for configuration data like users, signals, dashboards, alerts, and so-on. By default, it uses a local embedded database that stores data in Documents/ under the Seq storage directory.

On ARM platforms, Seq now uses a new embedded database implementation that's integrated into the same Rust codebase that powers the Seq event store. We chose this path because we want to make Seq more predictable and forgiving on weaker filesystems than the existing LMDB-backed solution will allow (see the notes below about Azure Container Instances, for example).

Other long-term goals for this are to reduce Seq's dependencies on third-party storage code, and to make multi-node Seq deployments possible without an external database. We expect that we'll roll this out to Windows and x64 Linux platforms in a near future release.

Porting squirrel-json to Neon

Seq uses a sparse, vectorized JSON deserializer that enables some interesting scenarios in our internal storage architecture. We built squirrel-json using the AVX2 instruction set, which is specific to x64 CPUs.

To run Seq efficiently on ARM, we ported squirrel-json to the Arm Neon instruction set. We were pleased to find that performance is on par with the original version.

Multi-targeting Seq Apps

Finally, because a number of the core Seq Apps we ship are written in native code, we've ported and compiled native ARM binaries for Seq.Input.Gelf, Seq.Input.Syslog, and Seq.App.JsonArchive. Hopefully, with these three ported, you won't encounter too many native apps without ARM binaries.

Apps that target our .NET Seq.Apps SDK can run on ARM unmodified.

What else is new in 2021.4?

We've deliberately (and necessarily) kept 2021.4 focused tightly on ARM support, but we've still made room for a couple of important improvements and fixes.

  • Target URLs within the Seq web interface are now preserved through the login process for all authentication types
  • Signal bar highlighting is disabled on touch devices, improving user experience on iPad and other tablets
  • Seq Apps can now annotate settings with Syntax to indicate preference for a fixed-width font; as more apps are updated to use this, we plan to extend the Seq UI to provide highlighting and editing assistance appropriately
  • We've made some progress on simplifying deployment to Azure Container Instances by making the new native metastore available on all platforms through the SEQ_FEATURES_ENABLED=nativemetastore environment variable (please check in with us before enabling this feature flag for mission-critical/high-load environments 🙂)

As always, there's a milestone in the Seq issue tracker with all of the nitty-gritty details.


Seq 2021.4 is a highly-compatible in-place update. Upgrading existing 202x Seq releases is as simple as clicking through the installer on Windows, or pulling the latest datalust/seq image under Docker. Check out the upgrade guide if you're coming from Seq 5.x or earlier versions.

Download the Windows installer from the Seq downloads page. The Docker image is published to the datalust/seq repository on Docker Hub.

If you need more information, or some help to roll out Seq 2021.4 in your organization, is ready to help, so please just drop us a line!

Update 22nd Dec 2021 — The version of Microsoft.Data.SqlClient used when SQL Server is configured as the Seq metastore will now use encrypted connections by default. This may result in connection failures if the SQL Server instance has an invalid or self-signed certificate. See the Microsoft.Data.SqlClient 4.0.0 release notes for further information.

Nicholas Blumhardt

Read more posts by this author.