Everest: a mod loader and base API for the game Celeste

What Everest is, and the MonoMod foundation under it

Everest is a mod loader and base API for the game Celeste, and the readme is brief about it.

The implementation detail that matters is in the second line of the description: using MonoMod, an open-source C# modding utility. That single choice explains almost everything about the project's shape.

Celeste is a game written in C# and compiled to managed code, so its internals are reachable and patchable in ways that a native game is not. MonoMod is the library that makes patching managed assemblies tractable: it can rewrite method bodies, intercept calls, add types and generally reshape a compiled assembly without needing the original source. A mod loader built on it is therefore a patcher with a managed layer above it, not a set of loose binary patches that break when the game changes.

That distinction is the practical difference between a loader that survives game updates and one that does not. A loader that replaces a file with a patched copy has to be rebuilt whenever that file changes. A loader that patches at runtime, applying its modifications to the loaded assemblies, can often survive an update as long as the specific methods it touches have not changed.

The other half of the project is the base API. Everest is described as both a mod loader and a base API, and that pairing matters for the ecosystem: mods written against a shared API do not each need their own version of the hooking logic, and a mod that uses the API is more likely to keep working when the loader changes.

The project is MIT licensed, the primary language is C#, and the default branch is dev. The recent releases are stable-1.6642.0 from 2026-10-17, stable-1.6623.0 from 2026-10-03 and stable-1.6580.0 from 2026-09-19, and the last push to the repository was on 2026-10-17.

The repository layout, and what each piece is doing

The tree shows a project with a launcher, an installer, a modding surface and a set of build plumbing, and the directory names are self-describing once you know what they do.

There is MiniInstaller/, which is the component that installs the loader onto a Celeste installation, and the readme refers to running MiniInstaller-win64.exe on 64-bit or MiniInstaller-win.exe on 32-bit, and to the./MiniInstaller-linux and./MiniInstaller-osx binaries on the other two platforms. There is Celeste.Mod.mm/, which is the MonoMod-backed part, the layer that does the actual patching of the game's assemblies. There is EverestSplash/, which is the startup screen. There is DiscordGameSDK/, which is the Discord integration. There is NETCoreifier/, which is a separate component in the tree, and its presence is a hint about the shape of the problem.

Then there is external/, which holds the vendored dependencies, lib-ext and lib-stripped, which look like prepared library trees, and global.json, which pins the.NET SDK version for the build so that every contributor and every build server uses the same one.

The build configuration is Azure Pipelines, with a.azure-pipelines/ directory and a build status badge pointing at the definition, and there is also a.github/ directory, a.editorconfig, a.gitattributes and a.gitmodules file. The submodules matter here, because MonoMod and its ecosystem are dependencies that the build pulls in from their own repositories.

The solution file is Everest.sln, and the readme tells a builder to open it in Visual Studio on Windows, or to work from the command line on the other platforms, and to restore the NuGet packages either way.

Building it: the publish rule and the toolchain

The compiling section is short, and one warning dominates it.

The rule is stated twice, once for each platform, in the same words: it is very important that you publish the project instead of simply building it, as otherwise required dependency DLLs won't be copied. The instruction on Windows is to publish all projects and then copy everything in MiniInstaller\bin\Release\net8.0\publish and Celeste.Mod.mm\bin\Release\net8.0\publish to your Celeste directory, replacing existing files. On macOS and Linux the same two publish output directories are copied to the Celeste directory, with the macOS path given as Celeste.app/Contents/Resources.

That warning is the kind of thing a project only writes after a lot of people have got it wrong, and it is not hard to see why. A build produces the assemblies the project compiles, and a publish produces the assemblies the project compiles plus the dependencies it needs at run time. The output path is the same net8.0/publish folder either way in the instructions, and the difference is whether the dependency assemblies are in it.

The toolchain requirement is specific and slightly unusual. Everest requires version 9.0.0 or higher of the .NET SDK, as well as the .NET 8.0 runtime, for the build process. So the SDK and the runtime are on different major versions, which is the normal arrangement for building a project that targets an older runtime, and it means a machine with only the .NET 8 SDK will not build it.

The two publish output directories that get copied are the same on every platform:

MiniInstaller\bin\Release\net8.0\publish
Celeste.Mod.mm\bin\Release\net8.0\publish

On macOS and Linux there is one extra prerequisite, the mono runtime, installed from the mono project site, which suggests the game or part of the toolchain still runs on mono on those platforms.

The two platforms differ in one more small way. On Windows the executable names differ by architecture, MiniInstaller-win64.exe for 64-bit and MiniInstaller-win.exe for 32-bit, while on macOS and Linux there is a single binary per platform.

And there is a preparatory step for anyone who has used Everest before. If you have previously installed Everest and updated Celeste, or switched betas or branches, you are told to delete the orig directory where Celeste is installed, with the macOS location given as the Contents then MacOS folder inside the application bundle. Leaving that directory behind is the kind of stale state that produces a failure nobody can explain afterwards.

Using it, and where the documentation lives

The readme is pointed at a website rather than repeating itself, and the instruction is emphatic: if you just want to install Everest, go to the Everest website.

That is a sensible division, because the two audiences need very different documents. A player wants installation and usage instructions, and a mod developer wants an API reference and a guide to how to write against the loader. The website at everestapi.github.io carries the first, and the Everest Wiki carries the second, with the readme pointing at it for mod development information and at the modding_help channel on Discord for questions.

The community arrangement is also stated clearly. Everest is in the game modding category on the Mt. Celeste Climbing Association Discord server, and the contributing guidance says contributions of any kind are welcome, with a guide on how to contribute effectively in the repository, and asks you to join the discussion on the Discord.

One line in that section is worth reading closely. This project is created, improved and maintained entirely by volunteers, and if you would like to show your support for this project, consider donating to one or more of its contributors.

That is the whole governance model in two sentences. There is no company behind it, no paid team and no support contract, which means the loader is maintained by people who use it and care about the game, and it also means that a change in the game that breaks the loader is fixed when a volunteer has time and the right patch.

For a game like Celeste, where the community has a strong modding culture and the game itself is built in a language with a managed code base, that arrangement is what the original Everest project was created to serve, and the naming and the structure follow from it.

Where Everest is the wrong tool

The first limit is that it is for one game. Everything in the repository, from the MiniInstaller to the Celeste.Mod.mm patching layer, exists to modify Celeste's assemblies, and none of it is general. The techniques transfer, the tooling does not, and a developer who wants a general managed-code patching framework should use MonoMod directly rather than through this project.

The second is the release cadence and what it implies. The release tags are named for the Celeste build they support, and the recent history shows stable-1.6642.0, stable-1.6623.0 and stable-1.6580.0 on 2026-10-17, 2026-10-03 and 2026-09-19, so a stable build every couple of weeks. That is the right cadence for a game that ships updates, and it is also a cadence that means a user is always moving to a new loader, and a mod that has not been updated can stop working with a new loader even when the game itself has not changed underneath it.

The third is that the build process is not a one-command affair. It needs the right SDK and runtime, a publish rather than a build, a manual copy of two publish output directories into the game's installation, and then running the right installer binary for the platform and architecture. Each of those steps is documented, and each of them is a place where a mistake produces a failure at the next step rather than at the mistake.

The fourth is the dependency on vendored and submodule sources. The external/ directory and the.gitmodules file mean the build is not reproducible from a package feed alone, and the NETCoreifier tool in the tree indicates that the toolchain reaches into the game's own packaging in ways that can break when the game's distribution changes.

And the fifth is the volunteer governance. It is a strength for a project whose users are a community, and it is a risk for anyone who needs a specific behaviour on a specific date, because there is no commitment that a particular patch will exist by a particular release.

Editorial conclusion

Everest is worth following if you play Celeste and want a modding setup that is stable across game updates, because the loader is a proper patching framework rather than a set of file replacements, and because the base API gives mod developers a shared surface instead of every mod hooking the game in its own way. Before you build it yourself, check three things: that you publish rather than build, because the documentation is emphatic that it is very important to publish the project instead of simply building it, as otherwise the required dependency DLLs will not be copied, and that mistake produces an installation that fails in a way that does not name the cause; that your toolchain matches, since Everest requires version 9.0.0 or higher of the.NET SDK as well as the.NET 8.0 runtime for the build process, and that means the SDK and the runtime are on different major versions; and that you know what the release tags mean, because they are named for the Celeste build they support, with stable-1.6642.0, stable-1.6623.0 and stable-1.6580.0 in the recent history, so the loader version tracks the game version rather than having its own independent numbering.

Frequently asked questions

Official sources

1. EverestAPI/Everest on GitHub
2. License: MIT
3. Project website
4. README
5. Releases