System guide

RLPlugins architecture

This page is the public source of truth for how the launcher, the RuneLite manager plugin, the backend release control, and the Kraken runtime fit together.

Open Kraken docs Open MCP guide

Stable

Default lane

Stable remains the default channel and the safe choice for normal users.

Runtime

Manual Kraken

Kraken runtime updates are published separately from the RuneLite release pipeline.

Runtime

Kraken-backed

Kraken becomes the shared runtime and the canonical API surface for docs and MCP.

MCP

Docs first

The MCP server should search the Kraken docs first, then help blueprint the plugin work.

Platform layers

Keep the moving parts separate.

Each layer has one job. That keeps the product easier to reason about and easier to test when the runtime changes.

Launcher

Stable-only boot flow

The launcher always resolves stable metadata and carries the stable session snapshot into the child JVM and session bootstrap.

Stores the active stable release locally so restart behavior stays predictable.

Downloads the matching launcher, client, manager, and runtime release set.

Passes the stable session snapshot through to the RuneLite client and managed plugin loader.

Manager plugin

Manifest-first plugin loading

The RuneLite manager plugin reads the launcher session snapshot, requests the signed stable manifest, and keeps the managed plugin set isolated from manual runtime work.

Uses the launcher session state instead of asking the user to pick a separate in-client channel.

Caches the stable manifest and download set so the public path stays simple.

Loads the shared runtime before dependent plugins so the classloader contract stays intact.

Backend

Signed release control

The backend signs manifests, publishes the stable RuneLite bundle automatically, and keeps rollback paths available for launcher, client, manager, and runtime releases.

Serves launcher, bundle, and manager downloads from the stable release set.

Keeps Kraken runtime publication and runtime docs separate so they can be reviewed manually.

Keeps publish and rollback actions deterministic so admins can promote or revert without ad hoc patching.

Runtime

Kraken-backed shared runtime

The shared runtime is moving from the Ethan/PacketUtils bundle to Kraken-backed support code. The packaging changes, but the runtime-first contract stays the same.

The runtime is delivered first, then dependent plugins attach to it.

Kraken becomes the canonical API reference and the MCP source of truth.

Legacy Ethan/PacketUtils terminology survives only as a compatibility alias during rollout.

Stable

This is the only public lane. It is what users get by default.

Internal alias

The backend can keep a compatibility alias behind the scenes while the public UI stays stable-only.

Manual Kraken

Kraken runtime releases stay separate from the RuneLite client pipeline and are published only when intentionally approved.

Docs

Kraken docs and MCP are the two references the team should use first.

If the code or the design disagrees with the docs, the docs win until the runtime has been deliberately changed.

Kraken Javadocs

Read the canonical shared-runtime API surface before writing or reviewing plugin code.

Open Kraken docs

MCP guide

Use the AI docs endpoint when you want a model to search the Kraken docs, blueprint a plugin, or scaffold starter code.

Open MCP guide

Operating rules

The rollout stays smooth when each lane does one job.

That means stable is the public lane, the shared runtime is separate, and Kraken updates happen only when intentionally approved.

Keep the runtime-first classloader contract intact while the support layer changes.

Keep stable releases separate from manual runtime publication so testing does not spill into production.

Keep MCP read-only so the AI can reason about code without touching live accounts.

Keep the architecture page and Javadocs updated when the runtime surface changes.