stremio-core: the Rust engine behind every Stremio client

What stremio-core actually is, and who should build against it

The README describes stremio-core as "the single Rust codebase that contains all the logic shared between Stremio apps": user and addon state, the addon protocol, the library, notifications, playback state and deep links. The UIs are described as thin layers on top. That framing is the whole point of the project. If you are writing a Stremio client, the interesting work is the state machine and the addon protocol, not the buttons. stremio-core hands you the first two and leaves the third to you.

The audience is therefore narrow and technical. Addon authors can take src/types alone and get the vocabulary of manifests, resources, meta items, streams and subtitles without pulling in the runtime. Client authors can take the full Ctx model and treat it as the backbone of an app. If you are a Stremio user looking for a player, this repository is the wrong artifact: it is a Rust library plus a WASM bridge published to npm, not a downloadable application. The related searches for an APK or an iOS build point at the apps, which live elsewhere.

The Elm-style loop: Actions in, Effects out, NewState back

The architecture is explicitly borrowed from the Elm Architecture, and the README's own diagram makes the data flow concrete. The UI dispatches an Action to the Runtime. The Runtime routes it as a Msg to the state models, which update themselves and return Effects, described in the README as "explicit descriptions of side effects (futures) to run". Those effects execute through the Env trait and resolve back into the loop as Internal messages. Changed models are announced to the UI as NewState, and noteworthy happenings are emitted as Events.

The isolation is the design decision worth noting. Nothing in the models performs I/O directly; the platform is abstracted behind Env, which covers HTTP fetch, storage, task execution and time. That is what makes the same core run in a browser Worker and in a native client. It is also the cost: every new platform is an Env implementation before it is anything else.

Models are composed rather than hardcoded. The README points at #[derive(Model)] in stremio-derive as the way a platform composes its own model out of building blocks, and lists Ctx (profile, library, notifications), CatalogWithFilters, MetaDetails, Player, LibraryWithFilters, StreamingServer and Calendar among the pieces. Addon traffic goes through src/addon_transport, which the README says speaks modern HTTP(S) JSON plus a legacy JSON-RPC adapter. That dual transport is a maintenance burden the project has chosen to carry, presumably because older addons still exist in the wild.

Installing stremio-core and running the checks CI runs

The README's Development section gives the toolchain floor directly: Rust 1.77 or newer, which Cargo.toml repeats as rust-version = "1.77" with a comment telling maintainers to update the msrv workflow when they raise it. The local check sequence is four commands, and they are the same ones CI runs. Run them from the repository root after cloning; cargo test should finish with the unit tests passing, and cargo build should produce the crate without warnings under the clippy invocation above it.

cargo fmt --all -- --check
cargo clippy --all --no-deps -- -D warnings
cargo test
cargo build

Docs are built with the nightly toolchain pinned in docs.yml, using an unstable rustdoc flag set that the README quotes verbatim:

RUSTDOCFLAGS="--cfg docsrs -Z unstable-options --enable-index-page" cargo +nightly build-docs

For the WASM bridge the README does not repeat the steps; it defers to stremio-core-web/README.md, and that file is not reproduced here, so treat the bridge setup as something to read at the source rather than infer. What the top-level README does confirm is the published artifact: stremio-core-web is published to npm as @stremio/stremio-core-web and runs core in a Web Worker for stremio-web.

Two practical points from the README's Tips section. New actions are defined in src/runtime/msg/action.rs, and the README calls the message enums there "the public API surface of the crate", so that file is where you look when you want to know what a client can ask the core to do. And WASM output can get large, especially when Serialize and Deserialize are derived where they are not needed; the README suggests running twiggy top ..._bg.wasm to find the biggest offenders. That is a size problem you will meet only after the thing compiles.

Feature flags decide your target, and one of them breaks WASM

Cargo.toml defines four features, and the defaults matter. default = [] with a TODO comment explaining that env-future-send should be enabled by default but cannot be, because the TestEnv used by unit_tests holds a MutexGuard that is not Send. So you opt in, not out.

env-future-send adds Send bounds to Env methods and EnvFuture. The Cargo.toml comment states plainly that enabling it for wasm causes a compile error, and links the wasm-bindgen issue behind it. If you are building the browser bridge, leave it off. The derive feature re-exports #[derive(Model)] from stremio-derive. analytics enables the analytics module. deflate forwards to stremio-official-addons/deflate, and stremio-official-addons is pinned to =2.1.2 in the dependency list, an exact-version pin rather than a caret range. That pin is a deliberate choice to avoid surprise breakage, and it also means a security or protocol fix upstream does not reach you until someone edits Cargo.toml.

The release profile is tuned for size, not speed: lto = true and opt-level = 's'. For a core that ends up inside a WASM bundle shipped to browsers, that trade is defensible. For a native desktop client doing heavy catalog work, it is a decision you may want to revisit in your own profile rather than inherit.

Where stremio-core is the wrong dependency

The clearest boundary is that this is not an application and does not pretend to be. There is no binary, no installer, no APK, and no iOS target in the repository layout. The top-level entries are .cargo, .github, src, stremio-core-web, stremio-derive and stremio-watched-bitfield. Someone searching for a Stremio core download will not find one here, and the README does not claim otherwise.

The second boundary is the Env trait. Every platform must implement HTTP fetch, storage, task execution and time before the core does anything useful. If your platform cannot supply those, or if you wanted a batteries-included player, the abstraction is overhead rather than help. The env-future-send situation compounds this: the default feature set is empty precisely because the project's own test environment cannot satisfy the Send bounds, which tells you the trait surface is sensitive to the runtime you plug in.

The third is ecosystem drift. stremio-core-kotlin, the Kotlin/JNI bindings for Android, is listed in the README's Ecosystem table as archived. Anyone planning an Android client around JNI bindings should read that as a signal about the path they were considering, not as documentation of a supported route. The README does not describe a replacement.

How this differs from building on stremio-addon-sdk

The README lists stremio-addon-sdk as the way to "build your own addon in Node.js", and the contrast with stremio-core is a contrast in direction. The SDK is for producing content that Stremio clients consume: you write an addon, you serve a manifest and resources, and clients call you. stremio-core is for consuming that content: it holds the addon protocol client in src/addon_transport, the models that track catalog and meta state, and the playback state machine.

So the choice is not which is better but which side of the protocol you are on. If you want your catalog to appear inside Stremio, the SDK is the shorter path and stremio-core is irrelevant to you. If you want to build something that talks to addons, renders catalogs and manages a library, the SDK gives you nothing and stremio-core gives you the protocol plus the state models. A project that needs both is possible, but it would be two codebases in two languages, and the README does not describe a shared path between them.

There is a third option the README also names: use src/types alone. If all you need is the shape of a manifest or a meta item, taking the types without the runtime avoids the Env obligation entirely.

Licence, release cadence and what upgrading costs

The licence is MIT, held by Smart Code OOD with a copyright range of 2019-2026, and the LICENSE.md file sits at the repository root. MIT is permissive: it allows reuse in closed products provided the copyright notice and permission notice are preserved. That is a factual statement about the licence text, not legal advice, and anyone shipping a commercial client should have their own counsel read it.

On cadence, the release list shows stremio-core-web versioned separately from the core crate, and it moves quickly: 0.63.0 on 2026-09-17, 0.63.1 on 2026-09-20, 0.63.2 on 2026-09-24, with the last push to the repository on 2026-09-24. The core Cargo.toml still reads version = "0.1.0", so the version you track as a consumer is the bridge's, not the crate's. That asymmetry is worth knowing before you write a dependency policy around it.

The upgrade cost is concentrated in two places. The message enums in src/runtime/msg/action.rs are the public API surface, so action-level changes reach every client. And the exact pin on stremio-official-addons = 2.1.2 means the deflate feature tracks whatever that version offers until someone bumps it. The README does not document a deprecation policy or a migration guide, so a version bump is something you evaluate by reading the changelog and the diff.

Editorial conclusion

Adopt stremio-core if you are building a Stremio client or an addon-facing integration and can implement the Env trait for your platform; the MSRV is 1.77 and the crate compiles to WASM only when env-future-send is left off. Do not adopt it expecting a downloadable player: there is no APK, iOS build or Android binary here, and stremio-core-kotlin is archived. Before you commit, check that your target can supply fetch, storage, exec and time through Env, and read stremio-core-web/README.md for the Worker bridge rather than guessing at the WASM setup.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Stremio/stremio-core on GitHub