It's tough to avoid the time savings that vendor lock-in buys you these days. I have had to grudgingly accept that, despite the fact that I absolutely hate giving in to it. Look at what Apple has done with lock-in (or Google for that matter in other areas of the ecosystem) and you can see the reasons why.
However you can take steps that even when you give in to lock in, you structure your code/projects so that switching to another standard is straightforward: include non-vendor build scripts that would work on any Docker/VPS/baremetal server, isolate the locked-in config and scripts from the rest of the app as much as possible (even if it means running separate external scripts to execute them), etc.
Once you've done it a couple times you build up a suite of small tools and it gets easier.
I got bit hard by Zeit/Vercel, and then by GCP, and then by AWS. All of them do one thing or another to manage to find a way to extract more money. My goal is to make it so that if one day I decide we simply need to leave the platform, we can at a minimum of effort.
Because this actually does happen 1-2 times a year, thanks to exactly the issues raised by OP, it's paid dividends to put in the small time it takes to keep things mostly agnostic on the code side.