Compatibility

ASF is a C# application that is running on .NET platform. This means that ASF is not compiled directly into machine code that is running on your CPU, but into CIL that requires a CIL-compatible runtime for executing it.

This approach has gigantic amount of advantages, as CIL is platform-independent, which is why ASF can run natively on many available OSes, especially Windows, Linux and macOS. There is not only no emulation needed, but also support for all platform-related and hardware-related optimizations, such as CPU SSE instructions. Thanks to that, ASF can achieve superior performance and optimization, while still offering a perfect compatibility and reliability.

This also means that ASF has no specific OS requirement, because it requires working runtime on that OS and not OS itself. As long as that runtime is executing ASF code properly, it does not matter whether underlying OS is Windows, Linux, macOS, BSD, Sony Playstation 4, Nintendo Wii or your toaster - as long as there is .NET for it, there is ASF for it (in generic variant).

However, regardless of where you run ASF, you must ensure that your target platform has .NET prerequisites installed. Those are low-level libraries required for proper runtime functionality and absolutely core for ASF to work in the first place. Very likely you can have some of them (or even all) already installed.

ASF packaging

ASF comes in 2 main flavours - generic package and OS-specific. Functionality-wise both packages are exactly the same, they're both also capable of automatically updating themselves. The only difference between them is whether or not ASF generic package also comes with OS-specific runtime to power it.

Generic

Generic package is platform-agnostic build that doesn't include any machine-specific code. This setup requires from you to have .NET runtime already installed on your OS in appropriate version. We all know how troublesome it is to keep dependencies up-to-date, therefore this package is here mainly for people that already use .NET and don't want to duplicate their runtime solely for ASF if they can make use of what they have installed already. Generic package also allows you to run ASF anywhere, as long as you can obtain working implementation of .NET runtime, regardless if there exists OS-specific ASF build for it, or not.

It's not recommended to use generic flavour if you're casual or even advanced user that just wants to make ASF work and not dig into .NET technical details. In other words - if you know what this is, you can use it, otherwise it's much better to use OS-specific package explained below.

OS-specific

OS-specific package, apart from managed code included in generic package, also includes native code for given platform. In other words, OS-specific package already includes proper .NET runtime inside, which allows you to entirely skip the whole installation mess and just launch ASF directly. OS-specific package, as you can guess from the name, is OS-specific and every OS requires its own version - for example Windows requires PE32+ ArchiSteamFarm.exe binary while Linux works with Unix ELF ArchiSteamFarm binary. As you may know, those two types are not compatible with each other.

ASF is currently available in following OS-specific variants:

linux-arm works on 32-bit ARM-based (ARMv7+) GNU/Linux OSes with glibc 2.35/musl 1.2.2 and newer. This variant covers platforms such as Raspberry Pi 2 (and newer), it will not work with older ARM architectures, such as ARMv6 found in Raspberry Pi 0 & 1, it will also not work with OSes that do not implement required GNU/Linux environment (such as Android).
linux-arm64 works on 64-bit ARM-based (ARMv8+) GNU/Linux OSes with glibc 2.23/musl 1.2.2 and newer. This variant covers platforms such as Raspberry Pi 3 (and newer), it will not work with 32-bit OSes that do not have required 64-bit libraries available (such as 32-bit Raspberry Pi OS), it will also not work with OSes that do not implement required GNU/Linux environment (such as Android).
linux-x64 works on 64-bit GNU/Linux OSes with glibc 2.23/musl 1.2.2 and newer.
osx-arm64 works on 64-bit ARM-based (Apple silicon) macOS OSes in version 12.0 and newer.
osx-x64 works on 64-bit macOS OSes in version 12.0 and newer.
win-arm64 works on 64-bit ARM-based (ARMv8+) Windows OSes in version 10, 11 and newer.
win-x64 works on 64-bit Windows OSes in version 10, 11, Server 2012+ and newer.

Of course, even if you don't have OS-specific package available for your OS-architecture combination, you can always install appropriate .NET runtime yourself and run generic ASF flavour, which is also the main reason why it exists in the first place. Generic ASF build is platform-agnostic and will run on any platform that has a working .NET runtime. This is important to note - ASF requires .NET runtime, not some specific OS or architecture. For example, if you're running 32-bit Windows then despite of no dedicated win-x86 ASF version, you can still install .NET SDK in win-x86 version and run generic ASF just fine. We simply can't target every OS-architecture combination that exists and is used by somebody, so we have to draw a line somewhere. x86 is a good example of that line, as it's obsolete architecture since at least 2004.

For a complete list of all supported platforms and OSes by .NET 9.0, visit release notes.

Runtime requirements

If you're using OS-specific package then you don't need to worry about runtime requirements, because ASF always ships with required and up-to-date runtime that will work properly as long as you have .NET prerequisites installed and up-to-date. In other words, you don't need to install .NET runtime or SDK, as OS-specific builds require only native OS dependencies (prerequisites) and nothing else.

However, if you're trying to run generic ASF package then you must ensure that your .NET runtime supports platform required by ASF.

ASF as a program is targeting .NET 9.0 (net9.0) right now, but it may target newer platform in the future. net9.0 is supported since 9.0.100 SDK (9.0.0 runtime), although ASF might prefer latest runtime at the moment of compilation, so you should ensure that you have latest SDK (or at least runtime) available for your machine. Generic ASF variant may refuse to launch if your runtime is older than the specified minimum supported one during compilation.

If in doubt, check what our continuous integration uses for compiling and deploying ASF releases on GitHub. You can find dotnet --info output in every build as part of .NET verification step.