know.2nth.ai Tech MuleSoft
tech · OCI & Johannesburg · Skill Leaf

Oracle's cloud, in the country.

For a South African Oracle estate, the modernisation story only closes if it can run in-country. Oracle Cloud Infrastructure's South Africa Central (Johannesburg) region — af-johannesburg-1, live since January 2022 as Oracle's first African region — is what makes that possible: Autonomous Database, APEX, ORDS, and Fusion apps on local infrastructure. This leaf is the residency answer for the whole cluster, with the honest read on what a single-AD, Oracle-first region does and doesn't give you.

af-johannesburg-1 GA 2022 Autonomous DB Residency Fusion apps

Oracle's first African region, and what's in it.

OCI is Oracle's public cloud. The South Africa Central (Johannesburg) region — region identifier af-johannesburg-1, key JNB — became generally available in January 2022, Oracle's first cloud region on the continent. Oracle states it carries the full service catalogue: Autonomous Database, Container Engine for Kubernetes, the Oracle Cloud VMware Solution, and the Fusion Cloud Applications suite among more than a hundred services.

For this cluster, that list is the point. It means the Oracle system of record (26ai / Autonomous Database), the app layer (APEX), and the integration seam (ORDS) can all run on infrastructure physically in Johannesburg — the difference between "modernise the estate" and "modernise the estate without the data leaving the country."

The residency answer, made concrete.

Because APEX runs on the database and ORDS runs in front of it, where the database sits decides where the whole stack sits. Put the database in af-johannesburg-1 and the app layer, the REST/agent seam, and the vectors are all in-country by construction — there is no separate residency question for each tier. That is a cleaner story than a hyperscaler deployment where the data is local but the managed AI service that reads it may not be. For an Oracle-first organisation, the in-country region is what turns residency from an aspiration into a deployment choice.

One region, one availability domain, one vendor.

Three caveats, stated plainly. First, the Johannesburg region has a single availability domain; hyperscalers' SA regions offer multiple availability zones. In-region high availability leans on fault domains rather than separate AZs, and a true multi-region DR posture means pairing with another OCI region — abroad — which reopens the residency question for the disaster-recovery copy. Plan DR deliberately.

Second, this is an Oracle-first cloud. It is the right place to run an Oracle estate; it is not a general-purpose alternative to AWS or Azure for non-Oracle workloads, and choosing it for the database usually means running the rest of the stack there too. Third, the ordinary cloud caveats — lock-in and egress — apply, and they bite hardest exactly when you later want to leave. The residency win is real; price the exit before you commit to it. And note that an in-country region is a data-location fact, not a POPIA certification — residency helps the compliance case, it doesn't complete it.

The region is the enabler for everything else here.

Every residency argument the other leaves in this cluster make — keep APEX on the in-country database, keep the vectors with the records, expose ORDS locally — depends on there being an in-country place to run it. For SA banks, insurers, and government already standardised on Oracle, af-johannesburg-1 is that place, and it is why the "no rewrite, no export" story is a real option rather than a slogan. The trade you are making is Oracle-cloud lock-in in exchange for local Oracle-managed infrastructure; whether that trade is worth it is a procurement decision, but the residency half of it is genuine.

Where OCI links in the tree.

Primary sources only.