Issues with HostedDependency in GitLab Pipeline Using Realm 20.0.1

[lokalathlet]

Hello everyone,

We are currently using Realm (Dart) in version 20.0.1 and setting up a CI/CD pipeline in GitLab. We have a custom PUB_HOSTED_URL configured, pointing to our own Artifactory instance.

However, when running the command fvm flutter build apk, the process tries to fetch a HostedDependency: ^20.0.1, which results in the following error due to restrictions:

HostedDependency: ^20.0.1
Directory: '/Users/admin/.pub-cache/hosted/myHub.com%47artifactory%47api%47pub%47pub-remote%47/realm-20.0.1/android/src/main/cpp/lib'
Downloading Realm binaries for 20.0.1 to /var/folders/cp/j2_0cyr95090tmf6wc711cym0000gn/T/realm-binary-5d3hRn/android.tar.gz
ERROR: ERROR: Unhandled exception:
SocketException: Network is unreachable (OS Error: Network is unreachable, errno = 51), address = static.realm.io, port = 49665

It appears to be trying to download binaries from static.realm.io, but fails due to network restrictions.

My Questions:

1. Is there a way to bypass or resolve this issue?
2. Would it be possible for us to host the dependency binaries ourselves to avoid this restriction?
3. Has anyone encountered a similar situation and found a solution to it?
4. Due to the deprecation of Device Sync, versions 20 and higher of the Realm SDKs are considered community releases. As of September 30, 2025, Device Sync and the Realm SDKs will reach their end-of-life. Will it still be possible to access the hosted dependencies from static.realm.io after this date? Furthermore, is the maintenance of this repository something the community will rely on?

Any guidance or suggestions would be greatly appreciated!

Thank you in advance.

[nirinchev]

Hey, let me try and answer your questions:

1. If you download the binaries locally prior to running the command, it would avoid the download. You can see the correct locations here:

   realm-dart/packages/realm_dart/lib/src/cli/install/install_command.dart

   Line 44 in 5baa62f

   Directory getBinaryPath(Directory realmPackagePath, Flavor flavor) {

   . Not super familiar with artifactory, but imagine you can just host them there and modify your CI script to download them to the correct locations
2. I believe hosting them in artifactory and downloading them would be best, but alternatively, I guess you can setup a proxy that handles static.realm.io requests and redirects to your own server.
3. Can't answer this - I don't believe we've seen other similar issues before, so either nobody hit it or they managed to workaround it without reaching out.
4. Those binaries will remain available on static.realm.io indefinitely. We expect the community to be maintaining and contributing to the repository with minimal involvement from MongoDB (e.g. I don't mind cutting releases or merging PRs when necessary). One thing we discussed but never got to was to just stash the binaries in the package itself so we wouldn't have to do the extra download. Obviously, that would increase the size of the package, but will reduce some of the complexity of getting the binaries. If you (or someone else) is down to getting their hands dirty, I'd be happy to review a PR that moves the binaries inside the package.

[lokalathlet]

Hi @nirinchev Thank you for your comprehensive and detailed response to the issue I raised. Your insights are very helpful, and I appreciate the time taken to share them.

Regarding the binaries and their maintenance by the community:

I understand that the binaries will remain indefinitely available on static.realm.io. This continuity gives some level of confidence in the medium term. However, as the Realm SDKs are transitioning into community-supported versions, my concern is specifically about the upkeep of the binaries themselves—either in their current form or through community contributions.

To clarify:

• Will the binaries, or more ideally their source code, also transition into community management, or will they continue to be maintained solely by MongoDB?
• If the community takes over the responsibility, would updates to the binaries be anticipated during future releases, such as those necessitated by advancements in domain compatibility or dependency versioning? Without these updates, the binaries could risk becoming outdated or even incompatible due to evolving software landscapes.
• Based on this, does MongoDB perceive the software (specifically referring to the Realm SDK and not the Sync feature) as being truly "end of life" by 2025? If so, would you recommend transitioning to an alternative technology to avoid potential long-term issues, especially given the fundamental importance of stability in persistent data storage?
• Lastly, might there be a definitive point after which binaries stop being available entirely as hosted dependencies from static.realm.io? Even with indefinite availability mentioned, it’s good to have a clear understanding of future risks.

We do not use Sync and rely solely on the standalone Realm SDK. From your perspective, in light of these facts, is the Realm SDK the best tool to carry forward, or would preemptively exploring other solutions for local data persistence be wise?

Your thoughts and recommendations would be greatly appreciated. Thank you once again for your response and for offering to collaborate on potential updates, including moving binaries into the package.

[nirinchev]

Hey @lokalathlet, the binaries represent the built native source code at a specific commit. You can always recreate them by checking out the repo and then running one of the build scripts here: https://github.com/realm/realm-dart/tree/main/packages/realm_dart/scripts.

To answer your comments in depth:

1. The binary source code is already publicly available and open for the community to contribute to. The dart/flutter native binaries are built from the realm_dart/src folder: https://github.com/realm/realm-dart/tree/main/packages/realm_dart/src, which combines the very thin layer we have in realm-dart with the much more complex C++ database in the realm-core repo.
2. The binaries are always tied to a specific version of the realm-dart package. E.g. the binaries for realm-dart 20.0.1 are published and are immutable. If there are e.g. changes in iOS/Android that would make those binaries incompatible with new OS versions, then we'd need to make the necessary changes in realm-core, then release a new version of realm-dart and as part of the release, publish new binaries that will be compatible with the new OS-es.
3. From MongoDB's perspective, we're not actively investing in the further development of the Realm SDKs, and they are delivered as-is with all the current features and potential deficiencies. If members of the community are willing to invest time and fix issues and/or develop new features, we'd be happy to assist on a low-commitment basis to make the transition as smooth as possible.
4. There's no definitive point as there's no plan to ever discontinue serving them at static.realm.io. The hosting and ongoing maintenance costs are fairly low, which is why MongoDB is willing to continue bearing them for as long as possible to avoid inconveniencing the community of Realm developers. Obviously, this is not binding, and there are once-in-a-lifetime circumstances that may result in these binaries eventually becoming unavailable (e.g., MongoDB/AWS going out of business, a data corruption issue on S3 that affects all backups, etc.). I don't expect any of these to come to pass, but I also want to be upfront that hosting these binaries is a courtesy and not something I can sign in blood under. However, I'd like to reiterate that rebuilding these binaries or backing them up is always an option.

Speaking personally - and not as a MongoDB employee - I would still choose and recommend the Realm database for new projects. Take that with a grain of salt, however, because I have a deeper understanding of how the project and the database work, so I am confident I can make minor tweaks/fixes with low effort. There's obviously a risk involved as the ecosystem evolves, and in the event it becomes cumbersome to maintain things or there's a very compelling alternative, I'd be eager to adopt something else, though.