swell Downloads

The current swell build for each platform. It is one self-contained binary on Linux and Windows and a signed installer package on macOS, so there is nothing to install alongside it and nothing to compile.

Read the next section before you save one of these links anywhere. swell download URLs carry the release date, which means a saved link keeps working and keeps giving you the build from that date rather than the current one.

Then follow the install page for your platform: Linux, macOS, or Windows. For a network or security appliance, Install on a Linux Appliance covers running it on a schedule instead.

Why does the download URL keep changing?

Because it is pinned to a release date. Every swell download sits under a path built from the date its build was released:

https://downloads.stairwell.com/swell/<YYYYMMDD>/swell-<os>-<arch>

So the links above are correct for the current release and will not be correct for the next one. Three consequences worth planning for rather than discovering:

• A bookmark does not go stale in the way you expect. It keeps working. It keeps handing you the same old build, quietly, with no warning that a newer one exists. This is more awkward than a broken link, because nothing tells you.
• Any script that fetches swell has a date in it. Treat that date as a pinned version to review on a schedule, the same way you would treat a pinned package version, rather than as a constant nobody looks at again.
• The macOS filename is not derivable from the date. The package carries its own version in its name, so you cannot construct the macOS URL by substituting a new date into the pattern. Take the link from this page.

How do I get the current link?

This page is the source. It is updated when a new swell build ships, so come back here rather than reusing a URL from an old runbook or a support thread.

To find out what you are running now:

$ swell version

That prints the build you have installed, which is the first thing to check when behavior does not match a page in these docs. If the version you have is older than you expected, someone's script is pinned to an old date.

Two habits that keep this from biting a team. Fetch swell in your automation from one place that you update deliberately, rather than pasting the URL into every job that needs it. And if you distribute swell to analysts, put it somewhere internal and update that copy, so nobody is choosing between a link they remember and a link they searched for.

Which platforms and architectures are there?

The macOS package holds both architectures, so you do not choose between Intel and Apple silicon and you do not need two entries in an MDM. On Linux and Windows the download is the program: put it on the path and run it.

The Linux binary carries its own dependencies, which is the property that makes it usable on the hosts that matter most here. A stripped-down appliance, a container with almost nothing in it, and an old distribution outside the tested set will usually all run it. Install on Linux lists the distributions Stairwell tests against.

Do I need an auth token before I download?

No. Downloading needs nothing. Authenticating comes after, and swell auth login walks you through it: it prints a URL, you sign in, Stairwell shows you a token, and you paste it back at the prompt.

The one thing worth having ready is the ID of the environment you intend to work in, because most commands need it. swell Configuration covers storing it so you stop passing it on every command.

What should I read next?

• swell, for what the tool is for and a good first command.
• Pre-Deployment Check, for the two checks to run with it before any forwarder rollout.
• swell Command Reference, the lookup page for every command and flag.