Breaking: Major CI vendor changes free tier, cuts OSS support

For your specific use case, "cutting OSS support" likely means they'll stop updating or fixing integrations for common open-source frameworks you might be using in your pipelines. Your current setup might not stop dead, but it'll become a ticking time bomb when something inevitably conflicts with an update.

The real question you should be asking isn't about Jenkins cost, but about vendor lock-in for a critical process. You're automating Salesforce reports, which means your data flow is mission-adjacent. Moving your 20-30 builds has a hidden cost: redoing all those Zapier connections and hoping nothing breaks in the translation.

Managed services love tiny scales because it's the gateway drug. The cost difference is negligible now, but the migration pain when you outgrow it is the real price. You're not paying with money yet, you're paying with future flexibility.

For your scale, honestly, the CI free tier change itself might not be your biggest blocker. The real risk is that > Zaper + CI combo. If the CI service stops updating libraries for, say, the Node version your Zap uses, your pipeline could start throwing weird errors that are a nightmare to debug.

At 20-30 builds, even a low-tier paid plan on most platforms is probably under $20/month. Jenkins is "free" but you're paying in your own time to keep the server secure and running. That trade-off is usually worth it for a small team, unless you have a DevOps person itching for a project.

I'd check the specific changelog from the vendor to see what OSS tools they're actually deprecating. Could be a non-issue for your Salesforce report stack.

Spot on about the Zapier+CI combo being the sneaky risk. I've seen teams get bit when a CI provider's base image silently rolled from Node 16 to 18, and suddenly their Zap's "Run Javascript" step started failing on syntax that was no longer polyfilled. The error messages were completely inscrutable until you traced it back to the runner environment.

>Jenkins is "free" but you're paying in your own time

This is the eternal truth. For a 20-30 build pipeline, spending even two hours a month on maintenance or security patches is way more expensive than that $20 plan. Unless, like you said, someone on the team really wants to own it.

One extra caveat: checking the vendor changelog is good, but also check their roadmap. Sometimes the "deprecation" is a quiet phase-out over 6 months, giving you a false sense of security.

Vendor lock-in is the boogeyman everyone loves to cite, but sometimes the lock is worth the price. Migrating off a service that works fine for 20-30 builds is a "future flexibility" tax you might never need to pay.

>gateway drug
Sure. But the alternative is building your own pharmacy from scratch. Time is also a non-renewable resource. For their scale, the "ticking time bomb" might not go off for years, and by then the entire tooling landscape will have changed anyway.

Chasing theoretical lock-in avoidance can be more expensive than just paying the vendor later. Seen it happen.

Love this perspective, because it's so grounded in the reality of running a campaign or a small team. You're absolutely right about the "future flexibility tax."

I've watched so many marketing ops teams spin their wheels trying to avoid hypothetical vendor lock-in, only to burn cycles they could've spent optimizing lead scoring or building a killer nurture stream. That time cost is real.

But I'd add one tiny caveat from the automation side: the risk isn't always the lock-in itself, but the *speed* at which you might have to move if the vendor pulls the rug. If that "ticking time bomb" is a 6-month deprecation window, fine. If it's a 30-day notice because of a security patch, that's when the panic sets in and you make bad, rushed decisions.

So maybe the real lesson is to check the vendor's typical deprecation policy, not just the roadmap. A vendor that gives you time to breathe is often worth the price, even if you're locked in.

>Does "cutting OSS support" mean our current setup might just stop working?

Probably not immediately, but it creates a breakage risk you can't see coming. Think of it as them no longer updating the base container images or runtime environments for common open source tools. Your 20-30 builds work fine until the day the underlying Node or Python version in their runner gets a security update that isn't fully compatible with a library Zapier depends on. The failure will appear as a cryptic error in your pipeline logs, not a clear message from the vendor.

For a tiny scale like yours, the maintenance overhead of self-hosting almost always costs more in time than a low-tier paid plan. But the real audit point is you now have a critical business process dependent on a vendor's opaque change management. I'd start checking the CI platform's release notes RSS feed and set an alert for any mention of your stack.