The Future of Community Patch

Community Patch was my first real serverless application. It started as a Slack conversation between myself and one of our developers where we identified the need to have a “stupid simple patch server” to allow people to get a cloud hosted external source running without having to do a lot of the upfront work.

I wrote the StupidSimplePatchServer that day. An S3 bucket for the JSON definitions with an API Gateway to serve and manage them. It was more proof of concept than production ready service, but everything was there to transform it into a full blown resource for the Jamf community.

I launched Community Patch in April of 2018 where it has been serving Jamf admins for three years. The vision was to have a place where anyone can create and share patch definitions completely publicly. It was API driven with the hope to enable better automation, and that did eventually happen as Jamf admins began integrating patch feed updates into their AutoPkg workflows. There are ~1,500 active feed subscriptions as of today. I’m really quite proud of how this has grown, and of the value it gave to others.

For the first year of its existence, Community Patch operated entirely within AWS’s free tier. Eventually usage went above those limits and the service cost a few dollars per month. Not an issue. Over time, with the kind of organic growth it has seen, Community Patch started costing more. The beautiful thing about serverless apps is that consistent workflows scale linearly in price so I was never subject to sticker shock. I could see the trend and knew what to expect.

As fortune would have it, the next two years of Community Patch would be funded by AWS through a combination of general use and open source credits I received. I focused during this time on where I wanted to take the project, and what to do once those credits ran their course.

This has been discussed a lot in the #communitypatch channel in the MacAdmins Slack, but I had been working on a major overhaul meant to address everything that was an issue, and everything that was learned with Beta 2 (the current iteration). This new architecture would be more cost effective (basing it on metrics and billing data I gathered), more performant, and fill in the gaps on many use cases my users brought up: API tokens, delegating permissions to other contributors, creating a unified patch feed instead of subscribing to many, etc. Much of the code for this next version is out in the repo today.

Then Jamf bought Kinobi just before JNUC 2020. 

I took a week to figure out where I go from here. Kinobi has a lot of tech for Jamf to take advantage of including custom definition support – the key feature of Community Patch. With the Kinobi team now bringing their know-how and their stack to Jamf I was left wondering if it was a valuable use of my time to keep working on my version. At first I decided not to change course. I committed to updates to my Patch Server project, which enables self-hosted patch sources, and said I would revisit the funding question of Community Patch another day.

Today’s that day. The new architecture for Community Patch no longer makes sense to invest the time and effort into a migration of the current user base. In fact, I don’t even know who all is using it! I am able to reach out to the contributors as they signed up to be able to host definitions, but the service is public and open (back to the ~1500 feed number). That makes migrating and retiring the old stack even more difficult.

It has been suggested I setup something like a Patreon, but the truth of the matter is I won’t be iterating fixes or features for Community Patch going forward. People would be giving me money to keep the lights on, and that doesn’t sit well. Plus, it doesn’t change that the service’s use continues to increase at a steady rate which means the cost will continue to creep up over time if it’s still running.

This leads me to my decision: Community Patch will be shut down. My intent is to have this message shared as widely as possible, the web page updated to inform browsers of this, and ultimately shut down the APIs after JNUC 2021. When that happens your Jamf Pro server will error when attempting to retrieve updates, but it won’t lose the latest version of those definitions it has stored.

Between now and then, there are options out there for migrating your custom patch titles. The Patch Server project can be run on your own hosts if you’re feeling up to managing your own. Jamf just announced more than 500 software titles are now available in the official feed (which is just the beginning), and we should expect to see more out of the integration of Kinobi in the future.

It is not lost on me that this is going to be a disruption to a lot of Jamf customers, . I do very much apologize for that. I’m looking forward to seeing what the future of Jamf’s patch service becomes with the people who I know are behind it, but my chapter in this is coming to a close.

Author: Bryson Tyrrell

AWS serverless developer from the Twin Cities. Former benevolent Casper Admin at Jamf, helped cofound Twin Cities Mac Admins @MspMacAdmns,, avid Python coder.

One thought on “The Future of Community Patch”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s