Presenting Dboxed
Vendor lock-in with big cloud providers is hotter than ever in 2025, sparking endless debates online. Devs and companies are sharing nightmare tales: surprise AWS bills for minimal usage, multi-hour global outages (AWS Outage , Azure Outage ) costing millions in lost revenue, sudden API price hikes locking out startups, and even geopolitical headaches like trade wars potentially disrupting access.
Realizing your entire operation hinges on one vendor, or worse - the whims of a single country or person - can keep you up at night.
Sure, new cloud players are popping up, promising to be the ‘better’ alternative.
But let’s be real: That’s just trading one lock-in for another.
We need a new approach to this problem.
What is Dboxed?
Dboxed is my attempt to achieve true cloud independence and sovereignty. I believe that my approach is different to how others tried to solve it, and maybe it turns out that I’m onto something.
Instead of building just another cloud or PaaS provider, I wanted to implement a solution that truly allows you to choose, whenever you want and need to.
I want you to choose the underlying providers, I want you to painlessly switch between those, and I want you to migrate back and forth between my own cloud offering and the self-hosted offering.
Oh, and it’s Open Source , without any enterprise features that force every company into a paid plan. My goal with the cloud version is to shine with ease of use, reliability, support, and good pricing. If it’s enough to pay my bills, while allowing healthy growth, I’ll be happily continuing building Dboxed forever.
Features & Concepts
Dboxed lets you create boxes, which then can be run on machines. A box can be stopped and then moved to another machine. Such a machine can be on any provider, and moving can also be done between any provider. You can also move those boxes between cloud/VPS providers and on-prem/bare-metal machines.
You define the workloads running inside a box via Docker Compose. Future versions of Dboxed will also allow you to link a Box to a Git(hub) repository, allowing you to define your workloads via files (e.g. docker-compose.yaml or Dockerfile) in the repository.
A box can also have volumes attached, which are also moved to the new machines when you move the boxes.
You can also attach boxes to networks. Networks are software defined solutions that allow you to easily connect the workloads inside a box to any other workload in any other box from the same network. This means that boxes can communicate between machine boundaries, so your box running in AWS can communicate with the box running on your homelab machine or on-prem server. This even works without your machines having inbound public internet access, as the technologies used (right now, Netbird ) internally allow P2P connections even when NAT is involved.
This set of features allows you to be very flexible. For example, you could run a database and some core-services on-prem, using inexpensive and fast hardware for the CPU and storage intensive workloads. At the same time, you can leverage the dynamic properties of your favorite cloud provider to scale on high loads, or use cloud servers for the internet facing services or webservers.
How my approach is different
The goal of Dboxed is to provide cloud-like features, while not requiring any cloud-like dependencies. At the same time, if cloud-like features are present, Dboxed should be able to leverage these for optimization, without ever getting dependent on those.
These are some points that try to make this more clear:
- Dboxed is able to use any hardware, this includes virtual servers from any cloud provider and your own bare-metal hardware
- Networking works independent of the underlying hardware and cloud features, but it can use things like AWS VPC or Hetzner Cloud Network to dramatically speed up performance and reduce traffic cost
- The same applies to local networks in your own datacenter, homelab or office. If present, traffic should be routed in a way that traffic stays local.
- Storage is easily movable between machines. This also applies when moving between providers or between the cloud and bare-metal.
- As moving around storage is slow over the internet, Dboxed can use cloud-features like Elastic Block Devices to optimize for speed when not leaving cloud-provider boundaries, while still allowing to move to other providers or bare-metal.
These are just a few examples of how things are solved in Dboxed. The idea is to keep this philosophy for all existing and future features, so that Dboxed stays as cloud-independent as possible forever, while still giving you a cloud-like experience.
Business Model
As already mentioned, Dboxed is Open Source and fully self-hostable. This is how it is now and how it will be kept forever. I strongly believe that even if thousands of users use it for free, I will find ways to monetize it in other ways, allowing me to continue working on it.
The most obvious way to monetize it is by offering a cloud version. It will allow you to create an account and immediately start creating boxes, connecting your own bare-metal/VPS machines and run your boxes on these. You’ll also easily be able to auto-create machines on supported cloud providers.
Yes, you can do all this in the self-hosted version as well, but you’d have to setup the control plane first, setup backups (and actually test restores!!111oneone), consider high availability needs, and so on.
In the end, the cloud version will be more convenient, and pricing will be attractive enough to make using it the better option for enough users/customers so that I can operate in a profitable mode.
Other ways of monetization include enterprise support for on-prem installations, consulting, and so on. I’ll find ways.
I have decided against the VC route, and thus will be able to grow slowly and naturally. My expenses will be low and I won’t be forced into any shenanigans by any external influence. I’m a bootstrapper and indie hacker. Growing a team is something I will be able to do based on demand, not based on having too much money that I don’t even own.
About me
My name is Alex, and you can find me on X (@codablock ) and Github . I run a tiny (one-man show) consulting company specialized in DevOps and Kubernetes.
I also do as much Open Source as I can. Another Open Source project I do is Kluctl , a GitOps solution for Kubernetes that works via the CLI and via an Operator.
My largest client right now is one of two globally the largest aerospace companies, and I’m providing them with a customized Kubernetes solution meeting the very special demands and requirements an airplane brings.
My consulting business is working well, and I could easily continue this for the rest of my life, earning enough money to keep my lifestyle and constantly improve.
But I don’t want to continue this for the rest of my life, even if it’s always interesting and challenging.
I want to build my own product, take care of it, make my own decisions about it, feel the pain when it struggles, help it start running, feel the joy of it taking off…and so on. 🥹
And Dboxed is something in my head for years already. I believe it has the potential to be exactly this product. Since I started watching the bootstrapping and indie hacker scene, I believe even more that Dboxed is the right thing for me.
What’s Next
I’m starting to get public about my work now. Posting to different places (that’s probably how you came here) and interacting with other people online, trying to become more visible without becoming too pushy or annoying.
At the same time, I’m finalizing a few features that I had to disable for the moment. Especially, the integration of automatic machine creation needs to get finished. Also, features like Git(hub) integration for box specs, box templates (so that you can create a database) need to be implemented as early as possible, as these are features people use to try out such a product.
Stability and production readiness are also high on the list. I need to be able to remove the warning banner at the top of the application as fast as possible.
I have many ideas in my head when it comes to additional features, which will make Dboxed even more powerful. I’ll post about these from time to time.