Ubicloud's company blog, covering its open-source cloud, managed PostgreSQL, bare-metal infrastructure, and control planes built in Ruby.
Commenters bring it up as a cheaper alternative to AWS for PostgreSQL and as an option on European or Hetzner infrastructure.
> One counter-intuitive thing we found is that it's slow to save and restore caches, but the machines have good CPU, so for us it's been faster to disable cache entirely and just redo everything on each build.
The link to SPDK was very interesting: https://www.ubicloud.com/blog/building-block-storage-for-cloud-with-spdk-non-replicated. I use filesystems for very high performance applications, and I've found ZFS to often be the limiting factor when compared to simpler solutions of XFS +- mdadm +- encryption.
It's a controversial point, but others have made similar findings: https://klarasystems.com/articles/virtualization-showdown-freebsd-bhyve-linux-kvm/ : "Although I suspect this will surprise many readers, it didn’t surprise me personally—I’ve been testing guest storage performance for OpenZFS and Linux KVM for more than a decade, and zvols have performed poorly by comparison each time I’ve tested them"
OpenZFS seems to be starting to consider optimizations to better perform on modern drivers (SSD, NVMe) which have very different performance profiles to what ZFS was built for (spinning rust)
In the SPDK summary they say "To make VM provisioning times go faster, we changed our host OS from ext4 to btrfs" (...) "Also, when we switched the host filesystem to btrfs, our disk performance degraded notably. Our disk throughput dropped to about one-third of what it was with ext4."
Ubicloud: the problem seems to be generic to CoW filesystems, and it's interesting you came…
We’ve been seeing the same trend. Lots of teams moving to Hetzner for the price/performance, but then realizing they have to rebuild all the Postgres ops pieces (backups, failover, monitoring, etc.).
We ended up building a managed Postgres that runs directly on Hetzner. Same setup, but with HA, backups, and PITR handled for you. It’s open-source, runs close to the metal, and avoids the egress/I/O gotchas you get on AWS.
If anyone’s curious, I added here are some notes about our take [1], [2]. Always happy to talk about it if you have any questions.
[1] https://www.ubicloud.com/blog/difference-between-running-postgres-for-yourself-and-for-others [2] https://www.ubicloud.com/use-cases/postgresql
The riskiest line in your repo isn’t in "src/", it’s in ".github/workflows/"
Self-hosted runners feel more secure at first since they execute jobs directly on machines you manage. But they introduce new attack surfaces, and managing them securely and reliably is hard.
At Ubicloud, we built managed GitHub Actions runners with security as the top priority. We provision clean, ephemeral VMs for each job, and they're fully isolated using Linux KVM. All communication and disks are encrypted.
They’re fully compatible with default GitHub runners and require just a one-line change to adopt. Bonus: they’re 10× more cost-effective.
https://www.ubicloud.com/use-cases/github-actions
One challenge is that they have a ton of usage under their free tier, especially by free and open source projects which have near zero budgets. Its an artificial economy of projects that cannot pay for their own usage.
Another challenge is that the GitHub Actions paid tier is already very expensive, the quality of service is poor, and they have major security challenges. They could load shed by raising prices, driving customers to other platforms, but they already charge 10x what others charge (https://runs-on.com/pricing/#runner-pricing, https://www.ubicloud.com/docs/about/pricing). Anyone using GitHub Actions at scale would be somewhat price insensitive already.
He raises some fair points, I find it odd how actions/checkout has to raise its version number when it drops support for older node versions, a package manager type of system could account for compatible node versions
There is competition at least. https://www.ubicloud.com/use-cases/github-actions fights on perf/price, but gets stuck being compatible
But I'm annoyed too by things like the pain involved to have docker let rust builds use a volume to cache build artifacts. cargo-chef is a hack
Ideally I could have docker images as dependencies building with actions sharing images between each other. Not sure why actions can't form a DAG of inputs/outputs
(Disclaimer: I'm a cofounder at Ubicloud.)
Hey there, we offer Ubicloud Runners that are 10x cheaper than GitHub and bill them by the minute. You get a fresh VM with each job; and we use Hetzner as our underlying provider.
If you're already setting up a Hetzner box, I'd love to get your input. Any thoughts or feedback for us?
https://www.ubicloud.com/use-cases/github-actions
https://github.com/ubicloud/ubicloud/blob/main/routes/web/webhook/github.rb (our github actions integration is also openly available)