GitHub Actions Pivot

I’ve recently shipped a number of changes to restyled-io/restyler and corresponding restyled-io/actions to make Restyled’s primary use-case be within a GitHub Actions workflow. I’m encouraging all users to migrate to this approach instead of the GitHub Marketplace App and jobs that run on Restyled-maintained infrastructure. Eventually, I plan to decommission that infrastructure and support only GitHub Actions usage. Restyled will no longer be a source-available business with a free offering and paid features; it will just be an open source project. As such, I will likely re-license it AGPL, stop with the CLA, etc.

Why #

I started Restyled in August of 2017 because I wanted a thing like it to exist. In the ensuing 6 years, I managed to build an extremely robust and automated architecture that I’m very proud of. This robustness and automation allowed me to spend time on it when I wanted, but only when I wanted. I’d go months or years without committing anything, then spend a weekend rewriting some huge component to experiment with a new technology. Despite having 72,000+ repositories, with 5,000+ unique owners, running 1,000+ Restyled jobs every day, I still managed to keep the all-in costs to me under $100 per month, and I can count on one hand the number of times I had to respond to any kind of “outage”. All the while, I (with some help ) maintained about 60 individual Restylers through a robust CI/CD process. Paid Restyled usage fluctuated around $30-60 a month, so I was happy to pay the difference for this “hobby” that also provided a service to that many users.

During that time, GitHub Actions was created and grew massively. It’s clear that if I were to do it over, that’s what I would’ve done. For users, implementing via GitHub Actions would mean:

  1. We get features like concurrent build cancellation and retry for free
  2. Inherit all the effort and support put into the official actions/checkout action, instead of our own clone logic
  3. Control over resource constraints , including going as far as self-hosting
  4. Ability to DRY config through Shared Workflows
  5. Leverage everything the peter-evans/create-pull-request action does to avoid issues like this , this , this , and this
  6. Free up complexity budget to tackle other things , either ourselves or via contributions in completely independent actions
  7. Safety in updates from the conventional @v{major} tagging
  8. With no hosting costs to me, Restyled can be available for free without restriction

This effectively closes every open issue and obviates many documented “common error” scenarios. With all of that opportunity, and with yet another email from Heroku about how my Redis add-on is end-of-life and I have to update, I think it’s time.

When #

You are able to convert your projects away from hosted restyling and to a GitHub Actions workflow right now. How well this works will depend on your specific use-case and change over time as I continue to iterate. I plan to leave things in this state for at least 3 months collecting feedback, particularly from paid users.

Date Action Status
2024-07-23 GHA usage available
2024-07-26 Paid plans no longer available from GitHub marketplace
2024-07-30 Warning visible on restyled.io
2024-11-01 Hosted usage emits an error status to PRs
TBD Hosted usage stops accepting webhooks

How will this affect me? #

If you are a user of Restyled for PRs that are “same origin” (so not from forks). Your experience should be largely the same; you gain all the benefits mentioned above and lose nothing. With a small GitHub workflow that runs Restyled, the behavior of fixing style and managing a sibling PR is the same. I encourage users in this group to make the switch as soon as possible.

If you are a user of Restyled for PRs that are forks, you’re experience may change. Forks are difficult for Restyled to handle generally , and we’ve landed on a workflow whereby Restyled makes changes and stores a patch file that can be applied by your contributor through a simple curl|git command. Doing things through GitHub Actions doesn’t give us the best options for storing the patch file. I hope to explore this problem during the “beta” period. Users in this group can hold off, or dive in and help decide our future.


To my many users and contributors, thank you! Any questions, please email .