**Sankofa Phoenix** is a sovereign cloud platform that combines corporate identity (Sankofa) with cloud infrastructure capabilities (Phoenix), providing a complete alternative to major cloud providers while maintaining sovereign identity and independence.
This document reconciles **expected intent**, **current deployment state**, and **functional role** for each public-facing or semi-public web property.
**Quick matrix (every FQDN: web vs API vs RPC, and what clients should see):** [FQDN_EXPECTED_CONTENT.md](../04-configuration/FQDN_EXPECTED_CONTENT.md).
---
## 1. phoenix.sankofa.nexus
**Service Name:** Phoenix API / Cloud Platform Portal
**Role:** Cloud Service Provider (CSP) for Sankofa
## Sankofa.nexus and Phoenix — hostname model (canonical)
### Intended Function
- Sovereign-grade cloud infrastructure control plane
- Multi-tenant resource provisioning
- Service orchestration and lifecycle management
| Hostname | Tier | Access | Expected content |
|----------|------|--------|------------------|
| `sankofa.nexus` | **Public web** | Unauthenticated visitors | **Sankofa — Sovereign Technologies:** corporate / brand public site (marketing, narrative, entry points). |
| `phoenix.sankofa.nexus` | **Public web** | Unauthenticated visitors (for public pages) | **Phoenix Cloud Services** (a division of Sankofa): public-facing web for the cloud services division. |
| `keycloak.sankofa.nexus` | **SSO infrastructure** (IdP) | Browser hits login + token flows; operators use admin | **Keycloak:** OIDC/SAML identity provider behind client SSO. Serves realm login UI, well-known and token endpoints, and **admin console** at `/admin`. **Consumes:**`admin.sankofa.nexus` and `portal.sankofa.nexus` (and other registered clients) redirect here for authentication; it does **not** replace those hostnames. |
| `admin.sankofa.nexus` | **Client SSO** | SSO (system-mediated) | **Client administration of access:** who can access what (invites, roles, org settings, access policy). |
| `portal.sankofa.nexus` | **Client SSO** | SSO | **Client workspace:** Phoenix cloud services, Sankofa Marketplace subscriptions, and other **client-facing** services behind one SSO boundary. |
| `dash.sankofa.nexus` | **Operator / systems** | **IP allowlisting** + **system authentication** + **MFA** | **Internal systems dashboard:** administration across Sankofa, Phoenix, Gitea, and additional platform systems—not the same trust boundary as client `admin` / `portal`. |
**Placement of Keycloak:** Treat `keycloak.sankofa.nexus` as the **shared IdP** for the **SSO-gated client tier** (`admin`, `portal`). Users often see Keycloak only during login redirects. **`dash.sankofa.nexus`** is a separate, stricter surface (network + MFA); it may integrate with Keycloak or other system identity depending on implementation, but the **documented intent** is IP-gated operator admin, not “client self-service SSO” like `portal`.
### Current Deployment
- **Status:** ✅ Deployed and active
- **VMID:** 7800
- **Address:** 192.168.11.50:4000
- **Access Model:** API-first (not a marketing site)
---
## 1. sankofa.nexus (public — Sovereign Technologies)
**Role:** Public corporate web for **Sankofa — Sovereign Technologies.**
**Comparable to:** Company apex domain (e.g. microsoft.com).
### Expected content
- Brand, mission, Sovereign Technologies positioning
**Role:** Public-facing web for **Phoenix Cloud Services**, a division of Sankofa.
**Comparable to:** Public cloud division landing (e.g. azure.microsoft.com style), not the raw JSON-RPC layer.
### Expected Content
-Company overview and mission
-Sankofa brand philosophy:
**"Remember → Retrieve → Restore → Rise"**
- Phoenix product introduction
- Navigation to services
- Contact and inquiry paths
### Expected content
-Division branding, service overview, how Phoenix fits under Sankofa
-Clear separation from corporate apex (`sankofa.nexus`)
### Current Deployment
- **Status:** ✅ Deployed
- **VMID:** 7801
- **Address:** 192.168.11.51:3000
- **Technology:** Next.js
### Observed Behavior
- Portal currently presents a **login-gated interface**
- Authentication handled via **Keycloak**
- Dashboard requires credentials
### Alignment Note
- ⚠️ **Decision point:**
- Either split into:
-`www.sankofa.nexus` (public marketing)
-`portal.sankofa.nexus` (authenticated)
- Or intentionally maintain a gated-first model
### Technical note (same origin today)
- **VMID 7800** historically exposes **API-first** surfaces (`/health`, `/graphql`, `/graphql-ws`). Public **marketing or division web** may be served from the same stack or split later; this document states **product intent** for the hostname. Prefer not to present the apex `sankofa.nexus` portal app as if it were “Phoenix public web.”
**Role:****OIDC/SAML IdP** for the Sankofa / Phoenix client ecosystem.
**VMID:** 7802 (typical)
### Expected content / behavior
- End-user **login** (realm themes), **logout**, **token** and **well-known** endpoints
- **Admin console** at `/admin` for realm and client configuration (operator-controlled)
### Relationship
- **`admin.sankofa.nexus`** and **`portal.sankofa.nexus`** are the **client-facing apps**; Keycloak is where **authentication** completes for those SSO flows.
**Role:****SSO-authenticated** surface for **clients** to **administer access** (users, groups, delegations, tenant access policy as productized).
### Expected content
- IAM-style administration for client orgs (not raw Keycloak admin—that remains on Keycloak’s `/admin` for platform operators).
---
## 5. portal.sankofa.nexus (client SSO — services and marketplace)
**Role:****SSO-authenticated****client portal** for day-to-day use of subscribed services.
### Expected content
- **Phoenix cloud** service entry and consoles (as entitled)
- **Sankofa Marketplace** subscriptions and management
- Other **client-facing** services behind the same SSO boundary
**Public URL policy (env):** NextAuth / OIDC public URL may be set to `https://portal.sankofa.nexus` (see `scripts/deployment/sync-sankofa-portal-7801.sh`).
---
## 6. dash.sankofa.nexus (IP-gated — system admin + MFA)
**Role:****Operator and systems administration** across Sankofa, Phoenix, Gitea, and related infrastructure.
- **dash** = **IP-gated** operator systems admin with **MFA**
- **DBIS Explorer** = public transparency + settlement inspection
- **No accidental overlap** between marketing, control, and transparency layers
- **No accidental overlap** between public marketing, client SSO, operator dash, and explorer transparency
---
@@ -154,33 +189,17 @@ This document reconciles **expected intent**, **current deployment state**, and
**Critical:** These decisions remain **explicitly unresolved**. Do not collapse them prematurely.
### 1. Public vs Gated Split for `sankofa.nexus`
**Status:** Open decision point
**Options:**
- Option A: Split into public marketing site and authenticated portal
- Option B: Maintain gated-first model with selective public content
- Option C: Evolve to unified model with public sections
**Authority:** Governance decision, not implementation drift
**Note:** Auth is a policy boundary, not a permanent architectural constraint.
### 1. Phoenix UI vs API on `phoenix.sankofa.nexus`
**Status:** Implementation may still be API-first on VMID 7800 while **hostname intent** is public division web; reconcile with a dedicated static/marketing upstream or path split if needed.
---
### 2. Phoenix UI Exposure
### 2. Rich console UI for Phoenix (beyond public division web)
**Status:** Open decision point
**Question:** Whether Phoenix ever exposes a human UI beyond operators
**Question:** Whether authenticated **Phoenix product consoles** live primarily on **`portal.sankofa.nexus`** (SSO) vs additional surfaces.
**Current State:** API-first, operator-facing
**Flexibility:**
- API-first does not preclude future UI
- Console-based access patterns are possible
- Delegated interfaces are not precluded
**Note:** Intent document states: "This does not preclude future public or delegated interfaces."
**Flexibility:** Public division web on `phoenix.sankofa.nexus` does not preclude deep consoles behind **`portal`** SSO.
---
@@ -202,7 +221,8 @@ This document reconciles **expected intent**, **current deployment state**, and
These are **possible futures**, not commitments:
-Public marketing split (`www` vs `portal`)
-NPM `www.*` → apex **301** policy vs additional marketing hostnames
-`admin` / `portal` / `dash` upstream targets on NPM (when split from legacy single-host deployments)
- Delegated Phoenix UI development
- Explorer rebrand or federation
- Additional service surfaces
@@ -221,24 +241,22 @@ Internet
↓
NPMplus (Reverse Proxy + SSL)
↓
├─→ sankofa.nexus → Sankofa Portal
│ └─→ Corporate Brand / Product Website
│ └─→ ⚠️ Currently: Login-gated
├─→ sankofa.nexus → Public web: Sankofa — Sovereign Technologies
├─→ phoenix.sankofa.nexus → Public web: Phoenix Cloud Services (division)
│
├─→ phoenix.sankofa.nexus → Phoenix API
│ └─→ Cloud Control Plane (API-first)
│ └─→ Operator-facing only
├─→ admin.sankofa.nexus → Client SSO: administer access
@@ -174,6 +174,21 @@ This document explicitly states **what Sankofa Phoenix is NOT intended to be**,
---
### 9. Phoenix IS Allowed an Internal Service Catalog (Not a Public Marketing Site)
**Clarification (2026-03-25):** Non-goal **§1** means Phoenix is **not** a **public brochure** or **anonymous consumer storefront**. It does **not** exclude:
- An **authenticated internal service catalog** (sometimes called “marketplace” in product language)
- **Entitlement management** and **provisioning APIs** for **public sector tenants**
**Wording discipline:** Prefer **service catalog** + **entitlements** in external/regulatory packs until **procurement-backed billing** exists. See [PUBLIC_SECTOR_TENANCY_MARKETPLACE_AND_DEPLOYMENT_BASELINE.md](PUBLIC_SECTOR_TENANCY_MARKETPLACE_AND_DEPLOYMENT_BASELINE.md).
**Why This Matters:**
- Reconciles [EXPECTED_WEB_CONTENT.md](EXPECTED_WEB_CONTENT.md) (“internal service catalog / marketplace”) with **§1** without turning Phoenix into a public marketing site.
---
### 8. We Are NOT Encoding Technology Choices in Names
**What We Use:**
@@ -219,6 +234,7 @@ This document does **not** mean:
-`ARCHITECTURAL_INTENT.md` — What we intend to build
-`EXPECTED_WEB_CONTENT.md` — What each service should provide
@@ -53,6 +53,8 @@ This document describes the purpose and function of each service in the Sankofa
- GraphQL WebSocket: `/graphql-ws`
- Health: `/health`
**Cross-reference:** Public-sector tenancy, **service catalog vs marketing** boundaries, and **SMOA / Complete Credential** repo pointers: [PUBLIC_SECTOR_TENANCY_MARKETPLACE_AND_DEPLOYMENT_BASELINE.md](PUBLIC_SECTOR_TENANCY_MARKETPLACE_AND_DEPLOYMENT_BASELINE.md), [../11-references/COMPLETE_CREDENTIAL_EIDAS_PROGRAM_REPOS.md](../11-references/COMPLETE_CREDENTIAL_EIDAS_PROGRAM_REPOS.md), [../../config/public-sector-program-manifest.json](../../config/public-sector-program-manifest.json).
---
### 3. SolaceScanScout (Explorer)
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
defiQUG