Why We Built Dilmune Cloud From Scratch
Every infrastructure decision tells a story about what you value. Here's ours.
When we started Dilmune, the obvious path was to build on top of existing cloud platforms. AWS, GCP, Azure — they're battle-tested, well-documented, and everyone uses them. So why did we decide to build our own?
The Problem With One-Size-Fits-All
The major cloud providers are incredible pieces of engineering. But they're designed to serve everyone, which means they're optimized for no one in particular. When you need specific performance characteristics, data sovereignty guarantees, or cost structures, you find yourself fighting the platform instead of building on it.
Here's what we kept running into:
- Pricing models that penalize small teams with unpredictable workloads
- Data residency requirements that didn't fit neatly into existing regions
- Vendor lock-in through proprietary APIs that make migration painful
- Overcomplicated IAM systems designed for enterprises with 10,000 employees
Our Approach
We took a different path. Instead of abstracting away the complexity, we embraced it. Every component in our stack was chosen — or built — for a specific reason.
1# Our infrastructure provisioning
2# is declarative and reproducible
3
4dilmune init --region me-central-1
5
6dilmune deploy \
7 --service api \
8 --instances 3 \
9 --memory 512mb \
10 --env productionThis means we can make guarantees that other platforms can't. Predictable pricing. True data sovereignty. Zero lock-in.
The best infrastructure is the kind you don't have to think about. But getting there requires thinking about everything.
What's Next
This is still early days. We're learning, iterating, and building in the open. If this resonates with you, we'd love to hear from you.
