What 'Editor-Only Plugin, Zero Runtime Overhead' Actually Means in UE5

The question every careful dev asks before installing a tool

Before you add any plugin to a project that has to ship, you should ask the obvious question: does an editor-only plugin in Unreal affect my shipping build? It is the right instinct. A tool you only ever use while authoring should not add a single byte, a single tick, or a single dependency to the game your players download. The good news is that Unreal's module system is built precisely so this can be true, but only when a plugin is structured correctly.

The phrase 'zero runtime overhead' is not marketing fluff when it is backed by the right module configuration. It is a concrete, checkable property of how a plugin declares itself. This article walks through what actually decides whether plugin code reaches a packaged build, using Easy Kanban Board as a worked example, because it is deliberately built as an editor-only tool with no runtime dependencies.

Editor modules versus runtime modules

Every Unreal plugin is a collection of modules, and each module declares a Type in the .uplugin descriptor. The two types that matter here are Runtime and Editor. A Runtime module compiles into your packaged game and runs on the player's machine. An Editor module is only ever loaded inside the Unreal Editor itself, alongside tools like the Content Browser and the level viewport. When you cook and package a Shipping build, the cook process simply does not include Editor-type modules. They are not stripped down or disabled at runtime; they are never built into the executable in the first place.

There is a related detail in the LoadingPhase field, which controls when in the editor's startup a module is loaded. A common choice for tools is PostEngineInit, meaning the module spins up only after the engine has finished initialising. For a panel you open from the Tools menu, that timing is exactly right: nothing loads until the editor is ready for it, and nothing loads in a cooked game at all because the module is Editor-type to begin with.

So 'editor-only' is not a promise the author makes verbally. It is a property you can verify by reading the descriptor. If the module says Type Editor, that code physically cannot end up in your shipping build.

How Easy Kanban Board is structured

Easy Kanban Board is a single module called 'EasyKanbanBoard', declared as Type Editor with LoadingPhase PostEngineInit and a Win64 platform allow-list. That one fact answers the headline question for this plugin: because the module is Editor-type, it is excluded from cooked games entirely, which is what 'editor-only, zero runtime overhead' means in practice. The board, the cards, the search index, the auto-saver, the Slate widgets, all of it lives in the editor process and nowhere else.

The plugin docks a visual Kanban board directly inside Unreal so you can plan features and track work without alt-tabbing to an external project-management app. You get columns and drag-and-drop cards with titles, multi-line descriptions, priority colours, and tags, plus real-time full-text search, multiple boards, debounced auto-save with dirty tracking, and JSON import and export for sharing boards with teammates. Each project keeps its own board data, and that data is written to a human-readable JSON file under the project's Saved folder, which keeps it version-control friendly and out of your packaged content.

It targets Unreal Engine 5.5 and above, with packaged plugin builds present for 5.5, 5.6, and 5.7, and it ships on Windows. Because the board state is plain JSON rather than baked assets, none of it follows your project into a cook even if you wanted it to.

The pure-C++ core behind the Slate UI

What makes 'editor-only' clean rather than accidental here is the layered architecture. Easy Kanban Board separates an engine-agnostic C++ core from the Slate UI that draws it. The core library is plain C++20 built on the standard library plus a couple of small MIT-licensed dependencies, nlohmann/json for serialization and stduuid for UUID generation, with doctest used for its tests. None of that core has any knowledge of Unreal's runtime gameplay framework, which is part of why it can stay firmly on the editor side of the line.

On top of that core sits the native Slate layer: the main SKanbanBoardWidget, plus SKanbanCard, SKanbanCardEditDialog, and SKanbanDropZone, with a KanbanStyle for theming that matches the editor's dark UI. Data flows through Slate-friendly structs such as FKanbanCardData and FKanbanColumnData, and serialization uses a versioned JSON schema so older saved boards keep loading as the format evolves. The module integration layer is what binds the core and the Slate UI into the editor via UnrealEd and LevelEditor.

The practical upshot for you is that this is a planning tool that genuinely costs nothing at runtime. You can install it on a project that has to ship, use it throughout production to track features, bugs, and asset work, and know with certainty, by reading one line of the descriptor, that none of it will ever load in the game your players run.

A quick way to check any plugin yourself

You do not have to take any author's word for it. Open the plugin's .uplugin file, which is JSON, and look at the Modules array. For each module, read the Type field. If it says Editor, that module is editor-only and will not be cooked into a packaged build. If it says Runtime, that module will ship and you should treat its cost as real. Some developer tools also use an UncookedOnly type, which similarly excludes the module from cooked shipping builds while still loading in more contexts than a pure Editor module.

Then check LoadingPhase to understand when the module loads inside the editor, and PlatformAllowList to confirm which platforms it targets. Those three fields together tell you almost everything about a plugin's footprint before you ever compile it. For Easy Kanban Board the answer is unambiguous: one Editor module, PostEngineInit, Win64, no runtime dependencies. That is the whole story behind 'zero runtime overhead'.

Module types and whether they reach your shipping build

Read the Type field in a plugin's .uplugin descriptor to know its footprint before compiling.

FAQ