releaseflow
PricingLog in

Help

On this page

  • Getting started
  • Licenses
  • Troubleshooting
  • Billing
  • Contact

Getting started

Create an app

Sign in and open /apps/new. Give the app a name and a slug, then choose Electron for apps using electron-updater or Sparkle for native macOS apps. The slug becomes part of the public URLs, together with your username: /{username}/{slug}.

For Sparkle apps you can add an EdDSA public key and a minimum macOS version. The public key is what Sparkle uses to verify appcast.xml; see unsigned builds if the feed has no signature.

Connect GitHub releases

Connect your GitHub account and select the repository that holds the app’s releases. ReleaseFlow reads the repository’s GitHub releases and their assets; private repositories work through the same GitHub connection.

Sync releases

Open the app and press Sync Releases to import releases immediately. Update feeds also start a background sync when their data is older than about an hour, so a new GitHub release shows up without pressing anything. Each release row has a switch: disabled releases stay in the dashboard but are left out of the update feeds, and GitHub drafts are never imported as feed candidates.

Beta and alpha channels are off unless you enable them for the app. A feed requests a channel with ?channel=beta or ?channel=alpha; the default is stable. When a channel is not enabled, the feed falls back to the next lower channel.

Sparkle update feed

Point Sparkle at https://releaseflow.net/{username}/{slug}/sparkle/appcast.xml. The feed is RSS 2.0 with Sparkle extensions and only includes macOS assets from enabled releases. Add ?channel=beta or ?channel=alpha for an enabled pre-release channel. To force a refresh on request, add ?sync=1.

Electron update feed

The update route follows the electron-updater request shape:

  • Check for updates: https://releaseflow.net/{username}/{slug}/update/{platform}/{version}
  • Fetch a metadata or asset file: https://releaseflow.net/{username}/{slug}/update/{platform}/{version}/{fileName}

{platform} accepts darwin, windows and linux, plus aliases such as mac, win32 and appimage. {version} must be SemVer. The response is JSON with name, notes, pub_date and url when a newer compatible release exists, and 204 when there is nothing newer. Add ?arch=x64, ?arch=arm64 or ?arch=universal when you need a specific architecture, and ?channel=beta or ?channel=alpha for a pre-release channel.

For diagnostics, add ?debug=1 to get a JSON body instead of an empty response, and read the x-releaseflow-debug-reason response header. Add ?sync=1 to force a GitHub sync before the lookup.

Licenses

Selling licenses

Each public app can have a hosted checkout at https://releaseflow.net/{username}/{slug}/checkout. It uses the app’s connected payment provider and product configuration; prices and products are managed there, not on this page.

Customers manage their purchases at https://releaseflow.net/{username}/{slug}/portal. They enter the email used at checkout, receive a login link, and can view their license keys, downloads and activations. There is no password on the portal.

Validate a license key

Validate keys from your app with a POST request to https://releaseflow.net/api/license/validate:

curl -X POST https://releaseflow.net/api/license/validate   -H "Content-Type: application/json"   -d '{"license_key":"YOUR-KEY"}'

The response is {"valid": boolean, "message": string}. A key is valid: true only while the provider reports it as granted; revoked, disabled or missing keys come back valid: false with a message. A missing license_key returns 400. If license validation is not enabled or the provider is unreachable, the endpoint returns valid: false with an error message.

Troubleshooting

The feed returns no release

no_release means no enabled release can serve the requested platform and version. Check that:

  • the release was synced — press Sync Releases on the app page and check the counts it reports;
  • the release is enabled and is not a GitHub draft;
  • the release has an asset ReleaseFlow recognises for that platform:.dmg, .pkg or .zip for macOS, .exe or .msi for Windows, and .AppImage, .deb or .rpm for Linux;
  • the app is the right type: the Sparkle feed only serves apps created as Sparkle, and returns an error for other app types.

no_newer_release is different: a release exists, but its version is not greater than the version your app sent. missing_asset means the release exists but has no asset matching that platform and architecture. unknown_platform means the platform segment is not a recognised alias.

Re-run the request with ?debug=1 to see the reason, the resolved release, the latest version and any forced-sync error in one JSON response.

Releases are disabled

Disabled releases are excluded from both update feeds even though they remain listed in the dashboard. Open the app, find the release and turn its switch back on. GitHub drafts are also excluded: publish the draft on GitHub, then sync again.

Unsigned Sparkle builds

Sparkle verifies updates with EdDSA. ReleaseFlow does not sign your build; it looks for a signature file next to an asset in the GitHub release, for example MyApp.zip.sig. The appcast item uses the signature that belongs to the selected macOS asset, and the .zip is preferred over the .dmg for updates. If that signature file is missing, the item has no sparkle:edSignature and Sparkle refuses the update when the app has a public key configured.

Sign the update archive with Sparkle’s sign_update tool, upload the resulting .sig file to the same GitHub release, then sync again and check that the appcast item now contains sparkle:edSignature.

Billing

Plans and current pricing: /pricing.

Payment, refunds and plan terms: /terms.

Contact

Email hi@kitze.io with the app’s username and slug, the feed URL and the x-releaseflow-debug-reason header if you have one.

releaseflow
PrivacyTermsChangelogSupport