Bahriya did not start as a cloud platform. It started as a frustration.
We spent years deploying containerised applications for clients and internal projects across the major cloud providers. Every time, the same pattern: weeks configuring VPCs, load balancers, IAM policies, DNS zones, certificate managers, and autoscaling groups — before a single line of application code ran in production. The tools were powerful, but the complexity was disproportionate to the task. We wanted to run containers in multiple regions with sensible defaults. What we got was a puzzle with a hundred pieces, most of which we did not need.
So we started building the tools we wished existed.
Mamluk
Bahriya is built by Mamluk, a technology company incorporated in the United Arab Emirates. The name comes from the Mamluk Sultanate — a dynasty of ghāzi-scholars who ruled Egypt and the Levant for nearly three centuries, built hospitals, schools, and trade routes, and ran an empire on merit, discipline, and the conviction that power carries responsibility.
That ethos guides how we build software. We are accountable first to God, then to our customers — not to venture capital firms or growth-at-all-costs metrics. We take deliberate care over our vendor choices, our pricing, and how we treat the people who use what we build.
Why "Bahriya"?
Bahriya means "of the ocean" or "maritime" in Arabic. It was also the name of the most elite regiment of Mamluks during the Ayyubid period — the regiment whose commanders went on to become some of history's most consequential rulers. Sultan Baybars stopped the Mongol advance at Ain Jalut. Sultan Qalawun expelled the last Crusader states from the Levant. These were not just soldiers — they were builders, administrators, and strategists who understood that strength without purpose is wasted.
The name fits what we are doing. We ship containers across the globe, much like historical navies moved fleets across oceans. And we believe a technology company can operate with that kind of uprightness — transparent pricing, honest documentation, no dark patterns, no lock-in.
Building the tools first
Before Bahriya was a product, we had to solve the infrastructure problem for ourselves. That meant building a set of internal tools and frameworks that could power the kind of platform we wanted to offer.
Kipchak
The most significant of these is Kipchak — our API Development Kit for PHP. Kipchak is a modern PHP framework designed for building structured, scalable APIs on PHP 8.4+ with FrankenPHP in worker mode. It comes with built-in support for routing, middleware, authentication (including JWKS-based JWT validation for Keycloak), OpenAPI spec generation from PHP attributes, and a driver system for databases, caching, messaging, and storage.
Both of Bahriya's APIs — the Console API that end users interact with and the Admin API that our operations team uses — are built on Kipchak. We open-sourced it because we think the PHP ecosystem deserves better API tooling, and because building in the open keeps us honest. The documentation is at kipchak.dev.
Reis
Reis (Turkish for "captain") is the Bahriya CLI. It is a single self-contained binary — no runtime dependencies, no interpreters — that lets you manage your entire Bahriya infrastructure from the terminal. It supports interactive prompts, explicit flags, and declarative YAML files for infrastructure-as-code workflows. We built Reis because we wanted a CLI that felt as complete as the console, not an afterthought bolted on after launch.
The deployment engine
Under the hood, Bahriya's deployment infrastructure is a pipeline system that takes your container configuration, generates the manifests, encrypts your secrets, provisions DNS records, and rolls out your workload across every region you selected — all triggered by a single API call or console action. We built this from scratch because we needed the deployment lifecycle to be deterministic, auditable, and fast. Every change you make is processed through the same ordered pipeline: namespace provisioning, registry credentials, secrets, container deployment, DNS.
The mission
We are building Bahriya because we believe deploying containers globally should be simple and predictable. Not simplified — simple. There is a difference. Simplified means hiding complexity behind abstractions that break when you need to do something real. Simple means there is less complexity to begin with.
Our design principles:
- Explicit controls — you see exactly what you are configuring, and there are no hidden defaults that surprise you later
- Honest pricing — hourly, per-resource, per-region billing with a calculator that shows you exactly what you will pay before you deploy
- Auditable actions — every change is logged, every deployment is traceable, every secret is encrypted
- No lock-in — you bring standard OCI container images, you get standard DNS hostnames, and you can leave whenever you want
What comes next
Bahriya today handles containers, caching, secrets, and DNS. The roadmap extends into managed databases, object storage, and persistent volumes — all following the same principles: deploy in minutes, not weeks; pay for what you use; keep your data in the regions you choose.
We are not trying to be AWS. We are building the platform we wanted to use — and we think other teams want the same thing.
If that sounds like what you have been looking for, request early access and come build with us.
