What "early access" actually means on Bahriya

"Early access" is one of those phrases that means everything and nothing. Some platforms use it to mean "still a prototype, don't run anything important." Others use it to mean "feature-complete, we just haven't bothered to take the badge off." We use it to mean something specific, and the distinction matters if you're deciding whether to put real workloads on Bahriya today.

The short version: the surfaces you interact with — the API contract, the CLI, the Terraform provider, the console — are still moving. The platform underneath them, the part that actually runs your containers, is not. Production workloads are safe to run today.

Here is the longer version, in four points.

1. API contracts may change, sometimes in breaking ways

While we're in early access, the API is allowed to break. A field can be renamed. A required field can become optional, or vice versa. An endpoint can be split, merged, or replaced. We try to be additive whenever we reasonably can — new optional fields and new endpoints don't break anyone — but we will not contort the shape of the API to avoid a clean fix.

The reason is straightforward: this is the cheapest moment to fix an API. The few teams using Bahriya today told us early what was awkward, and we'd rather correct it now than carry the wart for years. Once we exit early access, the API contract is locked. After that, breaking changes mean a /v2/ and a coordinated migration — the normal industry deal.

If you're integrating now, the practical implication is to pin to a known good version of the Reis CLI and the Terraform provider in your own pipelines, and to read release notes before bumping. We'll call out breaking changes explicitly.

2. Reis, Terraform, and the console may have rough edges

The CLI, the Terraform provider, and the console UI all sit on top of the API. When the API changes, those three need to change in lockstep — and most of the bugs you'll hit in early access live in that seam. A field gets renamed in the API; the CLI catches up the same day; the Terraform provider catches up the next; the console gets there a week later. That's how it goes.

So in practice, you may see:

• A Reis command that errors with a confusing message after an API change has landed but the CLI hasn't been republished yet.
• A Terraform plan that wants to recreate a resource because an attribute name moved.
• A console form that submits successfully but renders the result oddly until the UI catches up.

If you hit something like this, tell us. The fix is usually a same-day release. None of these affect what's already running — they're a problem with the management surfaces, not with the workloads.

3. The console UI may change shape, sometimes drastically

We're learning what the console should be by watching people use it. That means whole sections can move, get merged, get split, or get replaced. When a layout isn't working, we'd rather rebuild it now — while the cost of changing course is low — than commit to it and watch every new feature inherit the same awkwardness.

If you've bookmarked a deep link, it may move. If you've written internal docs that reference "click the third tab," that sentence will go stale. The URL structure is the most stable part — entity URLs (/o/<org>/p/<project>/c/<container>) we treat as long-lived — but everything else is fair game while we're still finding the right shape.

We'll keep doing this until the console stops feeling like it needs it. After early access, the rate of layout churn drops sharply.

4. Your workloads are not at risk

This is the part that matters. None of the above touches the part of the platform that actually runs your containers.

The runtime — the Kubernetes clusters across our regions, the ingress and TLS termination, the routing, the autoscaler, the secrets injection, the Helm-driven deploy pipeline, the per-region failover — is stable, has been running in production for a long time, and is currently serving millions of requests a day across customer workloads. None of the things we're calling "early access" sit anywhere near that path. The API may change shape; the runtime executing your container does not.

If you deploy a container on Bahriya today, the realistic risk profile is:

• Runtime risk — the same as any mature container platform. The autoscaler, ingress and failover are stable; the architecture is already battle-tested and serving real traffic today.
• Management surface risk — your terraform apply might need a syntax tweak after an upgrade, or a console layout you knew has moved. Annoying. Not production-impacting.

That asymmetry — moving surfaces, stable runtime — is the whole point of being in early access right now. We're collecting feedback on the parts that can still be changed cheaply, while the parts that need to be rock-solid already are.

What this means if you're evaluating Bahriya

Run things on it. The workloads will be fine. Just expect to keep your tooling current, read the release notes before upgrading, and tell us when something on the API or console surface feels wrong — because right now is when we can still fix it without ceremony.

When we exit early access, the API freeze and the layout stabilisation happen on the same day. Until then, we'd rather get it right than get it shipped-and-stuck.