Sparkle is the standard way to auto-update a native macOS app. You link the framework, set a feed URL, and Sparkle checks an appcast — an RSS file that lists your versions — downloads the newest archive, checks its EdDSA signature and installs it.

Sparkle tells you how to generate that appcast (generate_appcast), but not where to host it. Most teams end up with a bucket or a GitHub Pages site and a script that copies files around. Then come the questions: how do I pull a bad release? How do I mark an update as critical without rebuilding? Which feed do the beta testers get?

This post shows how to use faynoSync as a self-hosted Sparkle update server. The stock Sparkle client stays untouched — faynoSync hosts the appcast and the archives, and you manage releases from a dashboard or CI. Everything below was run end to end on a local faynoSync with a real macOS app before writing it down.

Velopack is one of the nicest ways to add auto-updates to a desktop app. You pack your app with vpk, and the Velopack client inside your app takes care of downloading and installing new versions. It supports delta updates, works on Windows, macOS and Linux, and has client libraries for C#, Rust, JavaScript, C++ and Python.

But there's one question every team hits sooner or later: where do the updates actually live? Velopack needs a place to host the release feed and packages. You can throw them into a bucket or GitHub Releases, but then publishing, rolling back and "which version is live on which channel" become manual chores.

This post shows how to use faynoSync as a self-hosted Velopack update server. No custom SDK, no glue code — the stock Velopack client talks to faynoSync as if it were a plain file host. We'll go through the whole flow with a ready-made example app, and everything below was run end to end on a local faynoSync before writing it down.

Update checks are the noisiest traffic an update server ever sees. Every running copy of your app polls /checkVersion on a timer, almost always with the same parameters, and each call validates the app, channel, platform, and architecture before answering. At a few hundred clients that's nothing. At a hundred thousand, it's the same handful of answers recomputed millions of times a day — and the usual fix is database clustering, replication, and heavier ops you'd rather not run for an update server.

Performance Mode already takes the first bite out of this with a Redis cache at the API layer. The next step moves the hot read path off the origin entirely: serve repeated checks from object storage at the edge, and let the API handle only cache misses and the control plane.

Telemetry tells you who's running which version. It doesn't tell you when an update fails — when the download checksum doesn't match, the installer hits a full disk, or the app panics on first launch after a release. Those failures are exactly the ones you want to catch in the first hour of a rollout, before they reach the rest of your install base.

faynoSync's report ingestion fills that gap. Clients send short operational failure reports to a public endpoint; the server validates, groups, and aggregates them into a rollout-health picture by app, version, channel, platform, and architecture. The design is deliberately narrow: cheap to ingest, stable for aggregation, and bounded in storage — not a logging pipeline, an APM, or a Sentry replacement.

Once your app is in users' hands, the obvious questions follow: How many people actually run it? Which version are they on? Which platforms should you prioritize? Shipping updates blind is guesswork — faynoSync's built-in telemetry turns those questions into data.

The best part: it's privacy-first and you already have most of the plumbing. Telemetry is collected from the same /checkVersion calls your clients already make — you just add one header. This post covers what's tracked, the critical X-Device-ID header, how to enable it, the beacon endpoint for SDK/edge flows, and how to read the data.

Shipping an Electron app is easy. Keeping every user on the latest version is the hard part. Unlike apps on the App Store or Google Play, a desktop app you distribute yourself has no built-in update channel — so you have to build one.

This guide shows how to add automatic updates to an Electron app using faynoSync, a self-hosted, open-source update server. We'll cover two approaches:

Update checks are bursty and repetitive. Every running copy of your app polls the same /checkVersion endpoint with nearly identical parameters, and each call validates the app, channel, platform, and architecture against MongoDB. At a few hundred clients that's fine. At thousands it's the same handful of database queries, repeated thousands of times a minute.

Performance Mode fixes that with caching. This post explains how it works, how to configure Redis, how cache invalidation keeps results correct, and how to stack an optional Nginx microcache on top for a multi-layer strategy.

Ever needed a download link that always points to the latest version of your app — one you can put on a landing page, in a README, or inside a CI pipeline and never touch again? That's exactly what faynoSync's /apps/latest endpoint is for.

Instead of hardcoding myapp-1.2.3.dmg and updating it on every release, you point users at a stable URL and faynoSync resolves it to the newest matching build. This post walks through the endpoint with copy-paste examples for landing pages, OS auto-detection, shell scripts, and Docker.

Want to try a self-hosted update server before putting it anywhere near production? Or hack on faynoSync itself? Either way, you start with a local setup — and with faynoSync that takes a few minutes, not an afternoon.

There are two ways to run it locally: everything in Docker, or the Go API from source with only the dependencies in containers. This post shows both, explains what each service in the stack does, and covers the first steps once it's running.

Managing a team of developers? Need to control who can do what in your faynoSync instance? Starting from version 1.4.0, faynoSync introduces a powerful Team Based Authorization Matrix that gives you complete control over your team's access and permissions.

This is role-based access control (RBAC) built for an update server: one administrator owns an isolated set of team users, each team user gets granular permissions per resource type, and no administrator can ever see another's data. This post walks through the model end to end, with copy-paste API calls verified against the Team Based Authorization docs.