Backend
Owns
Identity, catalog, prices, orders, access, release policy
Does not own
Desktop process state
Boundary
/api/releases/current · /api/plugins/manifestRLPlugins support
Help with plugins, downloads or your order. Our team replies from Discord.
System boundary
RLPlugins separates commercial truth in the backend from launch work on the desktop. The boundary keeps price, access, release, and runtime state auditable.
Release path
The arrows move release information and artifacts. They do not move payment credentials into the launcher.
Ownership contract
A layer is easier to audit when the architecture records what it must not decide.
Identity, catalog, prices, orders, access, release policy
Desktop process state
/api/releases/current · /api/plugins/manifestStarting and updating the launcher
Plugin selection or payment state
/downloadAuthentication, release-set install, RuneLite discovery, launch
Store pricing or operator approval
rlplugins.* launch contextManifest consumption, class loading, plugin lifecycle, health
Granting an entitlement
Signed manifest + runtime bridgeThe host client and game-facing plugin environment
RLPlugins checkout or release policy
Local RuneLite JARTrust controls
Managed delivery reduces untracked release drift. It does not make a blanket promise that software can never fail or contain a defect.
The bootstrap and managed loader validate release metadata instead of trusting a redirect or filename alone.
The backend filters access from the authenticated RLPlugins session; the launcher does not invent local ownership.
Downloaded manager, runtime, and plugin artifacts are checked against the release records used for that launch.
Users receive the stable set. Canary is an operator staging lane, not a second storefront choice.
Public and staging
Canary exists for operator validation before promotion. The public launcher keeps channel selection out of the customer workflow.