Sinytra Connector: running Fabric mods on a NeoForge server

A translation layer between two mod loaders

Minecraft has two dominant mod loader ecosystems, and a mod written for one does not run on the other without work. The reason is not that the mod code differs, it is that the surrounding platform APIs differ, so a mod that calls into loader specific interfaces breaks when moved.

Sinytra Connector is a translation and compatibility layer for exactly that problem. The README states that it allows running Fabric mods on NeoForge, and that its goal is to bring the two platforms closer together so developers save time maintaining mods for multiple platforms at once, and so players can use all their mods in one modpack.

That framing matters for what to expect. Connector is not a second loader and it does not ask mod authors to change anything. It sits under NeoForge, translates what a Fabric mod expects, and hands the result to the NeoForge runtime. The repository layout backs this up: alongside the usual src directory there is a transformer directory at the root, which is where the translation work lives, and the project builds with Gradle through build.gradle.kts and the wrapper scripts.

The audience is two groups. Players who want a single modpack that works regardless of which loader their friends run, and mod developers who want their existing Fabric mod to reach NeoForge players without writing a second implementation.

Two companion pieces have to be installed first

Connector does not work alone. The usage guide has three steps: install NeoForge, install Connector and its dependencies, and then drop Fabric mods into the mods folder. The dependency list is the part that trips up first-time users, because each piece comes from its own repository release page:

The README recommends installing the latest stable version of NeoForge. For the other two, Forgified Fabric API supplies the Fabric API surface that many mods expect, and Launchpad is the piece that handles loading Fabric mods into the NeoForge environment. Both have their own release pages, and their versions have to line up with the Minecraft version you are targeting.

The guide then says that with all dependencies installed you can take your favourite Fabric mods and just drop them in the mods folder like you would with any NeoForge mods, because Connector handles loading them with no additional steps. From the player's point of view the install is three downloads and a file copy, and from the mod developer's point of view it is nothing at all.

Version support moves with every Minecraft release

The compatibility surface is tied to the Minecraft version, so the project publishes a support table with three channels. The Supported channel means latest fixes and compatibility improvements and covers all new features and bugfixes. The LTS channel is critical bugfixes only, with the warning that the latest compatibility fixes might not be available. The EOL channel means unsupported.

The current table marks 26.2.x and 26.1.x as supported, 1.21.1 as LTS with some bugfixes, and 1.20.1 as EOL. The README explains the policy behind it: the maintainers do their best to support in-demand versions and backport compatible changes where possible, while unsupported versions receive no further updates from the maintainers, although pull requests for them are still welcome.

That last clause is the interesting one for a server operator. If you are pinned to an old release because of a pack, the project will not maintain a branch for it, but the mechanism for fixing it by hand is open. The default branch in the repository tracks the newest Minecraft line, 26.2.x, which tells you where the active work sits.

Not Planned is a real answer, not a delay

The issue policy states that, due to limited work capacity, issues are prioritised by priority and complexity, and that issues deemed too complex to solve or out of scope for Connector's patching system may be marked as Not Planned.

This is the sharpest limitation of the project, and it is a structural one rather than a temporary shortage of maintainers. Connector works by translating between platform APIs, and a mod whose behaviour depends on something that has no counterpart on the other side cannot be translated into a patch. No amount of priority changes that.

The project's own answer in those cases is to use an alternative such as a NeoForge port of the mod you were trying to play. That is the moment to stop expecting Connector to help and start looking for a port, or for a different mod.

For reporting, the README asks for details: confirm you are on the latest available version, check for an existing issue, consider whether the problem is caused by Connector rather than another mod, and try reproducing the same issue on Fabric to isolate it. Issue templates exist in the issues tab and details are explicitly requested so the problem can be reproduced.

Launchpad and Forgified Fabric API as the developer path

Players are not the only audience. For a mod developer, the interesting question is whether to write one mod for both loaders or maintain two.

The related projects section points at two ways forward. Launchpad is aimed at developers building cross-platform mods, and Forgified Fabric API is the Fabric API port that makes Fabric-flavoured libraries work on NeoForge. There is also Connector Extras, a separate project to install for improved compatibility with third-party libraries and APIs.

The difference in approach between the two routes is where the work sits. Maintaining two native mods means writing and testing each loader integration yourself, with every API difference handled by hand on both sides. Going through the Connector stack means you keep a Fabric codebase and let the translation layer absorb the platform differences, at the cost of staying inside the subset of behaviour the layer can handle, and of shipping a NeoForge-compatible build rather than a universal one.

For a small mod with heavy loader specific logic, the translation approach is often the smaller commitment. For a large mod that leans on deep platform internals, a native port may be more honest, which is also the advice the issue policy gives for out of scope mods.

A developer guide for running Connector in a dev environment

The repository carries a developer guide for people who want to run Connector inside their own mod development environment, described as possible in just a few steps, and the first subsection covers ModDevGradle usage. The guide is cut short in the README, so the specifics of the build setup live in the docs directory rather than in the front page.

The build itself is a Gradle project. The root holds build.gradle.kts, settings.gradle.kts, gradle.properties, the gradle directory with the wrapper configuration, and gradlew and gradlew.bat for Unix and Windows, plus the transformer directory where the translation work sits and the src directory for the mod code. The project builds on GitHub Actions through the build workflow, which is where the release artifacts and the nightly build come from, and the README links a nightly mod jar download from the dev workflow.

The practical point for a contributor is that this is not a small patch set. Translation logic for a new API surface has to be written in the transformer module and verified against the Minecraft version in the branch you are working on, which is why the project asks contributors to discuss major changes before starting.

MIT licensed, beta releases, one branch per game version

The project is MIT licensed, which is the permissive end of the scale for code that other people's mods depend on. The repository also carries a LICENSE file and its own documentation directory.

The releases are still beta. The recent list shows 3.1.0 beta 3 for the 26.2 line on 2026-10-16, beta 2 on 2026-10-14 and beta 1 the same day, and the last push was on 2026-10-16. Three betas in three days says the 26.2 line is still settling, so a pack that pins a beta is pinning something that is expected to change.

The versioning scheme is tied to the Minecraft version rather than to a simple counter, so each supported game line gets its own build, and the default branch follows the newest one. For a server operator this means the upgrade path is per Minecraft release rather than per Connector release, and you should expect to swap the whole set of jars, Connector, Launchpad and Forgified Fabric API, when you move game versions, because the three have to agree.

There is also a community around the project: an official Discord for support and development talk, GitHub Discussions for questions, and a Patreon and Bluesky presence for the maintainers.

Editorial conclusion

Sinytra Connector fits players building one modpack for both loaders and developers who want a single Fabric codebase to reach NeoForge servers without maintaining a second port, provided their mods stay inside what the patching system can translate. It does not fit a server that needs long term support for an old release, since 1.20.1 is marked EOL and 1.21.1 receives critical bugfixes only, and it does not fit a mod whose behaviour is out of scope, where the project asks you to use a NeoForge port instead. Before you commit, check the supported version table against your Minecraft release and confirm the specific mod is listed as compatible on connector.sinytra.org.

Frequently asked questions

Official sources

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