Re: Heads Up: cirrus-ci is shutting down June 1st

Hi!

On Thu, Apr 9, 2026 at 11:55 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> As the subject says, cirrus-ci, which cfbot uses to run CI and that one can
> (for now) enable on one's own repository, is shutting down.
>
> https://cirruslabs.org/ burries the lede a bit, but it has further down:
> "Cirrus CI will shut down effective Monday, June 1, 2026."
>
> I can't say I'm terribly surprised, they had been moving a lot slower in the
> last few years.
>
> The shutdown window is pretty short, so we'll have to do something soon. Glad
> that it didn't happen a few months ago, putting the shutdown before the
> feature freeze. This is probably close to the least bad time it could happen
> with a short window.

+1

>
> I think having cfbot and CI that one could run on ones own repository, without
> sending a mail to the community, has improved the development process a lot.
> So clearly we're going to have to do something. I certainly could not have
> done stuff like AIO without it.
>
>
> I'd be interested in feedback about how high folks value different aspects:
>
> 1) CI software can be self hosted
>
> E.g. to prevent at least the cfbot case from being unpredictably abandoned
> again.
>
>
> 2) CI software is open source
>
> E.g. out of a principled stance, or control concerns.
>
>
> 3) CI runs quickly
>
> This matters e.g. for accepting running in containers and whether it's
> crucial to be able to have our images with everything pre-installed.
>
>
> 4) CI tests as many operating systems as possible
>
> A lot of system just support linux, plenty support macos, some support
> windows. Barely any support anything beyond that.
>
>
> 5) CI can be enabled on one's own repositories
>
> Cfbot obviously allows everyone to test patches some way, but sending patch
> sets to the list just to get a CI run obviously gets noisy quite fast.
>
> There are plenty of open source CI solutions, but clearly it's not viable
> for everyone to set that up for themselves. Plenty providers do allow doing
> so, but the overlap of this, open source (2), multiple platforms (4) is
> small if it exists.
>
>
> 6) There need to be free credits for running at least some CI on one's own
> repository
>
> This makes the overlapping constraints mentioned in 5) even smaller.
>
> There are several platforms that do provide a decent amount of CI for a
> monthly charge of < 10 USD.
>
>
> 7) Provide CI compute for "well known contributors" for free in their own
> repositories
>
> An alternative to 6) - with some CI solutions - can be to add folks to some
> team that allows them to use community resources (which so far have been
> donated). The problem with that is that it's administratively annoying,
> because one does need to be careful, or CI will be used to do
> cryptocurrency mining or such within a few days.

It's hard for me to judge priorities, but I have a proposal on how we
can try to handle this.

Migrate to Open Source CI software, and run it on (cheap) cloud + get
sponsorship to cover the migration cost. This should protect us from
disasters like this. In worst case we would need to loop for
different cloud or different sponsor.

Provide CI workflow for GIthub Actions on our repository. This
wouldn't provide the plurality of platforms that we have now, but at
least everybody can get some basic CI coverage for free.

What do you think?

------
Regards,
Alexander Korotkov
Supabase