Patreage

I built Patreage to provide preview access to my MiSTer FPGA fork of Deskflow, among other tools I hope to build in the future. I wanted Patreon supporters to be able to try the fork while I continued developing it, with access tied to their membership. That meant connecting Patreon to private GitHub repositories in a way that would work through the terminal and installation scripts. My aim was to make distributing previews straightforward enough that I could spend my time on the software itself.

The scope is deliberately focused on a single creator and a configured set of repositories. Patreon provides identity and membership information, and a GitHub App supplies limited, read-only repository access. I built the service in Python with FastAPI, a separate background worker, and PostgreSQL, deployed together with Docker Compose behind a reverse proxy. The client is Bash, with browser authentication connecting a Patreon account to the terminal session.

I designed the major features around the full journey from signing in to obtaining software, with enough operational visibility to investigate problems along the way. The main capabilities are:

• Patreon sign-in and repository access rules for paid tiers or explicitly permitted free members.
• Private Git clone and fetch operations, source archive downloads, release downloads, and read-only file access.
• A standalone shell client and an embeddable Bash module for installers and automation.
• Membership rechecks, background recovery, and session revocation after confirmed loss of eligibility.
• Operator diagnostics, access controls, and tools for validating recovery after a backup restore.

One of the central implementation challenges was deciding when membership information was still trustworthy. Someone can subscribe after first signing in, change tiers, or cancel; meanwhile, Patreon can be unavailable or rate-limit requests. I addressed that by storing membership decisions separately from their freshness and using signed webhooks to mark decisions for rechecking. Access requests can trigger a targeted lookup, and a background worker handles follow-up attempts with backoff. A limited grace period can preserve previously confirmed access during a temporary failure, but invalidated or excessively old decisions require successful verification. Tests using simulated Patreon and GitHub services exercise those transitions, including the distinction between a confirmed denial and an upstream failure.

Patreage is live and in service, but it currently has no users. I would like that to change: I built it so people could get preview access to my Deskflow fork, and that part still needs an audience. The service and client are ready to support that workflow. The next milestone is having people use them, find the previews useful, and give me feedback on how the experience holds up outside my own testing.