Interesting. While it doesn’t seem that unreasonable, this change would really add up if you already had a lot of droplets, and I kind of did. I suppose it’s good luck that I’ve been migrating workloads to Fly lately. Maybe I should finish the job.
To be fair, once you pass the Fly free tier, I can only guess it is more expensive, but in my case it’s made up for by being able to do much smaller VMs. Digital Ocean’s a bit more limited on how you can cut up memory and disk space (and the dynamics of k3s or kubernetes at this scale is awkward.)
I operate a service called RunBuildRun that sells managed GitLab runners that run on DigitalOcean droplets. I have lots of droplets. I may need to bump up my price a bit :)
Sorry for the tangent, but can you provide more info on your service? Without signing up from an account on your site, I'm unsure on how the interface here compares to GitLab runner registration (which I always felt was a bit convoluted due to how GitLab structures their user and organization accounts) and how the hardware compares to what GitLab offers.
RunBuildRun makes creating a runner a one click operation. We give you a registration token for your runner, which you then register in the GitLab interface like usual.
The primary value over GitLab's runners is that RunBuildRun doesn't have any CI/CD minute quota. With GitLab, you get a finite quota (e.g. 400 minutes on the free tier) and then you have to upgrade to a per seat premium plan or buy additional CI/CD minutes.
Also, RunBuildRun gives you a dedicated runner so you don't have to wait on shared runners and you don't have to setup/manage a runner on your own server.
To be fair, once you pass the Fly free tier, I can only guess it is more expensive, but in my case it’s made up for by being able to do much smaller VMs. Digital Ocean’s a bit more limited on how you can cut up memory and disk space (and the dynamics of k3s or kubernetes at this scale is awkward.)