GitHub link: https://github.com/dboxed/dboxed/
The idea behind Dboxed came after working with Kubernetes and different Cloud providers for many years. I was not willing to accept that the solutions always kept running into some form of vendor-lockin, even with Kubernetes involved.
My thought was always that the things provided by cloud-providers should be possible to implement without the dependence on the individual cloud-providers. At the same time, I was not happy to just build an abstraction on-top.
You can try it on https://app.test.dboxed.io or self-host by following the docs (please report back on how this went).
Main features:
1. "Boxes" run on "machines" (any server with a recent Kernel and at least outbound internet access). A box is fully sandboxed and uses and uses Docker Compose for the workload definition.
2. "Networks" based on P2P VPN (Netbird to be specific, so it's Wireguard under the hood) are used to connect boxes, crossing machine and provider boundaries.
3. "Volumes" are used kind of like volumes in a cloud (e.g. EBS), but internally use incremental backups into S3. Volumes can seamlessly move between boxes and machines.
4. "Load Balancers" auto-created internet-facing boxes running in networks and can expose other boxes to the public internet. Using Caddy and Letsencrypt here.
My philosophy is: Don't get dependent on cloud-providers, but leverage their features for optimisation. For example, a VPC would drastically improve network performance, but won't stop you from moving to a another provider (or bare-metal). I will later also use EBS (and other providers volumes features) to improve reliability of volumes and speed up moving between boxes, but it will always be seamless to move away from AWS.
My future cloud SaaS/PaaS offering will follow the same principle. Not make you dependent, but still optimise for convenience (e.g. built-in S3, built-in Netbird, build-in machines, and so on...).