Environments

There are two environments: UAT and production. This page is the single source for which branch reaches which environment and at what URL. Every other page links here rather than restating it.

The matrix

	UAT	Production
Branch	uat	main
Role	Business testing and the pre-production gate	Live
Front end (all four personas)	https://odh-uat.my.orascomdh.com	https://my.orascomdh.com
Backend API	https://api-orascom-uat.my.orascomdh.com	https://api.my.orascomdh.com
CRM middleware	https://crm-orascom-uat.my.orascomdh.com	https://crm.my.orascomdh.com
Media CDN	https://media.odh-uat.my.orascomdh.com	https://media.my.orascomdh.com
Deploy rail	GitHub Actions → CodeDeploy; Amplify for the frontend	same

Note the production hostnames have no .orascom segment while the UAT ones do (api.my.orascomdh.com versus api-orascom-uat.my.orascomdh.com). It is an easy difference to miss.

The four apps share one hostname

This surprises people coming from the old setup, which used a separate hostname per persona. Each environment now serves all four apps from a single host, with the persona as a path:

Persona	UAT	Production
Shopper	https://odh-uat.my.orascomdh.com/	https://my.orascomdh.com/
Broker (and sales-manager)	https://odh-uat.my.orascomdh.com/partners	https://my.orascomdh.com/partners
Sales-man	https://odh-uat.my.orascomdh.com/salesman	https://my.orascomdh.com/salesman
Shopper Analytics	https://odh-uat.my.orascomdh.com/analytics	https://my.orascomdh.com/analytics

The shopper app is served at the site root — it is the base of the deployed artifact, and the other three are built into subdirectories underneath it. The paths come from the frontend’s NX_BROKER_PATH, NX_SALES_MAN_PATH and NX_SHOPPER_ANALYTICS_PATH build variables, which are identical in both environments.

Do not set NX_SHOPPER_PATH

There is deliberately no NX_SHOPPER_PATH value in either environment, and the frontend README listing it alongside the other three is inaccurate. The shopper app hardcodes its base path and falls back to / when the variable is unset. Setting it to / would also change the translation loader’s path from /locales/… to //locales/…, which breaks it. Leave it out of your .env.

What each environment is for

• Local is where developers test their own work. There is no shared development environment and no per-PR preview environment for the Laravel applications — the deploy rail has no preview concept.
• UAT is where business testing happens, and it is the gate a change passes through before production. Merge to uat, verify there, then promote uat → main.
• Production is live.

UAT is a close rehearsal of production, but not an exact one

Four differences are worth knowing before you treat a UAT result as proof:

• UAT and production share subnets and the load balancer. They are separated by ALB host rules and security groups, not by a network boundary — so a security-group or ALB change affects both.
• UAT has no alarm-based deployment rollback; production does (though it fails open).
• UAT health checks are stricter than production’s — a failing instance is ejected in 60 s against production’s 100–150 s, and UAT’s health-check timeout is 5 s where production allows 10 s, so an instance that would survive production can be killed in UAT.
• The UAT frontend does not build the way production does — its build specification differs, so the artifact is not produced identically.

Details on all four are in Infrastructure.

Staging, and the develop branch

Staging was decommissioned on 2026-08-16. The instance was terminated, its CodeDeploy applications deleted, and its Amplify branch removed. Anything that tells you to deploy to staging, point at a *.robustastudio.com host, or verify on a staging portal is describing an environment that no longer exists. Business testing moved to UAT; developers test locally.

develop is retired and frozen, but it still exists. It is the GitHub default branch on none of them — uat is, on all four application repositories (this docs site and the two unmigrated repos still default to main/master) — and it triggers no deployment anywhere. A push to develop is rejected outright — the branch is locked read-only (lock_branch=true, enforced even for admins), so git refuses it immediately. Nothing is lost quietly; you simply cannot push there. Branch from uat and open your pull request against uat.

Two protection mechanisms are live at once

develop uses GitHub’s classic branch protection, while main and uat are governed by a ruleset. That is exactly why GET /branches/<b>/protection returning 404 is such a trap: for develop it returns data, and for main and uat it does not — yet those two are the protected ones.

The branch tips were tagged staging-final-2026-08-16 in all four repositories before the change, so the parked work is preserved.

Where to go next

How deployment worksWhat happens between merging a PR and the change being live.

Ship your first changeThe whole loop end to end, on a real change.

InfrastructureThe AWS estate — and the four ways UAT differs from production.