Zealot: a self-hosted Rails app for distributing iOS, Android and desktop builds

The distribution gap Zealot fills between CI and testers

A build pipeline that produces an .ipa, .apk, .aab, .dmg or .exe still leaves the last mile unsolved. Someone has to get that artifact to testers, tell them what changed, and keep a record of which build went to whom. Commercial services handle this, but they hold the binaries and the tester list. Zealot is aimed at teams that want that last mile on their own infrastructure. The README describes it as a self-hosted platform for distributing mobile, macOS, Linux and Windows applications, with a REST API, iOS and Android SDKs, and a fastlane plugin. The intended user is an engineering team that already has a CI system (the topics list Jenkins and GitLab) and now needs a place for builds to land. It is not a build runner. Nothing in the material suggests Zealot compiles your code; it receives what your CI produces.

What happens to a build after your CI uploads it

Zealot is a Ruby on Rails application, and the feature list implies a fairly conventional Rails data flow: an upload arrives through the REST API, an SDK, or the fastlane plugin, and the server parses it. The README states that Zealot can read metadata from iOS and Android applications as well as iOS provisioning profiles. That parsing step is what turns an opaque binary into a record with a bundle identifier, version, build number and signing information. From there the build is assigned to a channel. Channels are how the project separates product forms and scenarios, so a nightly Android channel and a release-candidate iOS channel can coexist without mixing tester lists or install pages. Notifications are handled by an outgoing webhook: the README says data can be pushed to any notification service through a custom webhook, which means Zealot does not ship a fixed set of chat integrations you are stuck with. On the iOS side there is a device sync feature that pulls tester device information and lets you register new devices with the Apple Developer portal from the interface. That is the piece that usually forces teams to keep a spreadsheet of UDIDs, and here it is a first-class object.

Getting an instance running: Docker, environment variables and the first admin account

The repository points to a self-hosted install page at zealot.ews.im/docs/self-hosted rather than embedding the commands, so the exact Compose file is not in the material I have. What can be confirmed is the shape of the deployment. The README advertises multi-architecture images for amd64 and arm64, and the badge links to ghcr.io/tryzealot/zealot, so the container is published to GitHub Container Registry. A Rails deployment of this kind normally needs a database and a cache; the topics list includes docker, and the project is offered as a self-hosted service rather than a gem you embed. For CI integration, the documented entry points are the REST API, the iOS SDK at github.com/tryzealot/zealot-ios, the Android SDK at github.com/tryzealot/zealot-android, and the fastlane plugin at github.com/tryzealot/fastlane-plugin-zealot. If your pipeline is fastlane-based, the plugin is the shortest path: it uploads the artifact and lets Zealot do the metadata extraction. If your pipeline is a Jenkins or GitLab job that just produces a file, the REST API is the path. Authentication for the web interface supports Feishu, GitLab, GitHub, Google, LDAP and OIDC, so an existing identity provider can usually be reused instead of creating local accounts. Treat the install doc as the source of truth for environment variable names and volume mounts; I cannot list them from the material supplied.

Where Zealot stops: no device cloud, and an operational surface you own

The README headline mentions testing on thousands of real devices, but the feature list underneath does not describe a device farm. What it describes is distribution plus iOS device registration: you collect UDIDs and add them to the Apple Developer portal. Actually running a test suite on a rack of phones is a different product category, and nothing in the material indicates Zealot does it. That gap matters if your reason for looking at distribution tools was to escape both the app store and the device lab. The second limitation is operational. Zealot is a Rails application, and the topics include ruby-on-rails and rails. A Rails app means database migrations on upgrade, background workers, and a web server to keep alive. The release history shows 6.2.0 in December 2025, then 6.2.1 and 6.2.2 in July 2026, so the cadence is real but not weekly. Anyone adopting this should expect to read changelogs before pulling a new image, not click an auto-update button. The third limitation is scope: Windows and Linux are listed as supported platforms, but the developer tooling described (iOS SDK, Android SDK, fastlane plugin, provisioning profile parsing) is clearly concentrated on the Apple and Android ecosystems. If your product is a Linux desktop app, expect to use the REST API and the web interface rather than a purpose-built client.

Zealot against a managed distribution service

The obvious alternative is a hosted beta distribution service such as TestFlight for Apple platforms, or a commercial over-the-air provider. The difference is not a feature checklist, it is where the artifacts and the tester graph live. With TestFlight, Apple runs the service, handles the signing expectations, and you accept its review and expiry rules. With a commercial OTA provider, someone else operates the upload endpoint and the install page, and you pay per seat or per build volume. Zealot inverts that: the install page, the build database and the tester list sit on your servers, and the cost is the server plus your time. That trade is worth it when the binaries are sensitive, when the tester list is something you do not want to hand to a vendor, or when you need channels and webhooks shaped to your own process. It is a bad trade when nobody on the team wants to run PostgreSQL backups and Rails upgrades, because a distribution service that is down is worse than a vendor you are paying.

Upgrades, maintenance and the MIT licence in practice

Zealot is MIT licensed, which in plain terms means you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and permission notice are preserved. That is a permissive licence with no copyleft obligation on your own code. It is not legal advice, and if you fork the project or ship it inside a product, have counsel read the LICENSE file at the repository root rather than this paragraph. Maintenance cost is where self-hosting shows up on the balance sheet. You are responsible for the container image, the database, the object storage or disk holding the uploads, and the TLS certificate in front of the install page. The project itself is active: the last push recorded is 2026-09-08 on the develop branch, and 6.2.2 landed in July 2026. Version numbers 6.x suggest the schema has had years of changes, so a jump from an old release to the current one is likely to involve migrations. Pin a version tag in your Compose file instead of tracking latest, and read CHANGELOG.md before moving the pin.

Who should install Zealot and what to check before you do

Install it if you have a CI system that already produces signed artifacts, a server or cluster you are comfortable operating, and a requirement that builds and tester data stay inside your network. The combination of channel management, iOS device registration, metadata parsing and a webhook output covers the daily work of a release engineer without a vendor contract. Skip it if you need automated test execution on real hardware, if you have no appetite for Rails operations, or if your distribution needs are so small that a shared folder and a chat message would do. The first things to verify are practical: open the self-hosted install documentation for the current release and confirm the image tag and required services; confirm that your CI can reach the instance over HTTPS, since iOS over-the-air installs depend on a reachable manifest URL; and test the provisioning profile parsing against a real build before you migrate a team onto it. The demo instance at tryzealot.ews.im resets its data daily, so use it to check the interface, not to plan a migration.

Editorial conclusion

Adopt Zealot if you already run your own CI and want beta distribution, device registration and build metadata parsing on servers you control, and you are willing to operate a Rails stack with PostgreSQL and Redis. Do not adopt it if you need real-device test execution, or if nobody on the team wants to own Docker Compose upgrades and database migrations. Before committing, verify the current self-hosted install doc against your architecture, confirm which upload path your CI uses (REST API, fastlane plugin, or the iOS and Android SDKs), and check whether the OTA install flow works for your provisioning profile and certificate setup.

Official sources

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