# Platform Overview Forge is SAIF's internal developer platform β€” the cloud-native foundation teams use to build, deploy, and operate applications. > **πŸ”— See Also:** [Platform Principles](./principles.md) Β· [Platform History](./history.md) Β· [Release Notes](../release-notes/index.md) --- ## πŸ“‹ Overview Forge was created to solve a structural problem: every team was solving the same infrastructure, security, and deployment problems in different ways, creating inconsistency, risk, and toil. Forge consolidates those solutions into a single, opinionated platform so development teams can focus on business outcomes rather than infrastructure plumbing. The platform launched in 2025 and is currently at **version 3.0**, running in production across SAIF's cloud environment on Microsoft Azure. --- ## ✨ What Forge Provides ### Golden Path β€” From Code to Production A new application follows a single, standardized path from scaffolding to production deployment. The SAIF CLI (`saif new`) generates a complete project including source code, infrastructure-as-code, CI/CD pipelines, authentication, and API contracts. Same-day first deployments are the target. | Stage | What Forge Automates | | ------------------ | ------------------------------------------------------------------- | | **Scaffolding** | Project structure, build, lint, test configurations | | **Infrastructure** | Azure resources via pre-built, security-hardened Terraform modules | | **Authentication** | Okta (external) and Microsoft Entra ID (corporate) out of the box | | **Authorization** | API scopes, app roles, and business role mappings via YAML | | **Deployment** | Azure DevOps CI/CD pipelines targeting Azure App Service | | **Observability** | OpenTelemetry + Dynatrace wired in by default | | **Secrets** | Azure Key Vault via managed identity β€” no credentials in code | | **API Contracts** | TypeSpec-first design with auto-generated clients and documentation | --- ## 🧱 Technology Foundation Forge standardizes on a modern, Microsoft-aligned technology stack. These are not suggestions β€” they are the platform defaults enforced by templates and infrastructure modules. > **πŸ”— See Also:** [Technology Vision](technology-vision.md) for how these technologies compose into a layered model and where we're heading. | Capability | Technology | Notes | | ------------------------- | ----------------------------------------- | ---------------------------------------------------------------- | | **Runtime** | .NET 10 (LTS) | C# across all workloads (APIs, functions, workers) | | **Frontend** | React | SPA pattern via Forge templates | | **Local Orchestration** | Aspire 13.x | Service discovery, mocking, telemetry locally | | **Hosting** | Azure App Service (Linux) | Containerized, VNet-integrated | | **Edge / CDN** | Azure Front Door | Public entry point; routes to APIM via Private Link | | **API Gateway** | Azure API Management | Auth, rate limiting, policies β€” centrally managed | | **Database (Relational)** | Oracle via Entity Framework Core | EF Core is the data access standard | | **Database (Document)** | Azure Cosmos DB via Entity Framework Core | Optional; same EF Core pattern | | **Messaging** | Azure Service Bus | Events and async workflows | | **Identity (External)** | Okta | Customer and partner-facing | | **Identity (Corporate)** | Microsoft Entra ID | Internal users; delivered in Forge 3.0 | | **Secrets** | Azure Key Vault + Managed Identity | No stored credentials anywhere | | **Observability** | OpenTelemetry β†’ Dynatrace | Logs, traces, and metrics unified | | **IaC** | Terraform (Terraform Cloud) | Modules published via `iac-azure-modules` and `iac-okta-modules` | --- ## πŸ”’ Security by Default Security in Forge is not a configuration option β€” it is a platform constraint. - **Zero public access by default** β€” All new resources are private; teams explicitly grant access - **No hardcoded credentials** β€” Managed identities replace service accounts and stored passwords - **Auth enforced at the gateway** β€” Azure API Management handles authentication and authorization so application code doesn't carry that responsibility - **True Authorization model** β€” Access requires both an authorized application *and* an authorized user via overlapping scope + app role checks (see [Authorization reference](../reference/authorization.md)) - **On-premise bridge** _(planned)_ β€” Legacy applications authenticating via Windows Auth/NTLM will integrate with Forge Experience APIs through a platform-managed API key pattern. Designed in [ADR-0009](../reference/decisions/0009-on-premise-authentication-to-forge.md); tracked in [#455](https://github.com/saif-corp/forge/issues/455) --- ## 🌍 Environments Forge provides a structured, consistent set of environments from developer workstation to production. | Environment | Purpose | Deployment | | -------------- | --------------------------- | -------------------------------------- | | **Local** | Active feature development | Developer machine (Aspire) | | **Test** | Integration validation | Continuous, automatic | | **QA** | QA team testing | Continuous with peer approval | | **UAT** | Business acceptance testing | Continuous with product owner approval | | **Production** | Live workloads | Blue/green slot swap with approval | Blue/green deployments use Azure App Service deployment slots β€” new versions are warmed up in a slot and swapped into production with approval, enabling instant rollback. Local development mirrors production topology via Aspire service orchestration and WireMock-based service mocking β€” no VPN or cloud dependencies required. --- ## πŸ“ˆ Platform Maturity Forge is in active production and under continuous delivery. | Metric | Value | | ------------------------- | ------------------------------------------------ | | **Current Major Version** | 3.0 | | **Production Since** | 2025 | | **Release Cadence** | Continuous (semantic versioning) | | **Templates Available** | API, Event Service, Test Tools, Frontend (React) | | **Auth Providers** | Okta (external), Entra ID (corporate) | --- ## πŸ’Ό Platform Economics The shared Azure infrastructure that Forge runs on is managed centrally by the platform team and carries a **largely fixed monthly cost** β€” covering Azure API Management, Front Door, Service Bus, Azure AI Search, and observability. The more teams adopt Forge, the cheaper it gets per team; teams that go it alone provision and pay for equivalent services themselves. Azure App Service hosting, by contrast, is provisioned per team β€” each team's App Service plan is its own cost, scaling with that team's workload rather than being amortized across the platform. | Cost Driver | Behavior | | -------------------------------------------------- | ---------------------------------------------------------------------------------- | | **Azure API Management, Front Door, Service Bus** | Fixed-tier β€” adding more services has no marginal cost | | **Azure AI Search, App Configuration** | Flat tier β€” utilization improves as adoption grows | | **Azure App Service** | Per-team β€” each team provisions and pays for its own plan; compute scales with that team's load | Because the cost base is largely fixed, doubling the number of onboarded services would increase costs by an estimated 15–20%, not 100%. ### Financial Stewardship Forge reduces total cost of ownership across the portfolio by: - **Eliminating duplicate infrastructure** β€” teams do not provision their own API gateways, CDN layers, or observability pipelines - **Replacing point tools** β€” standalone pipeline tools and bespoke auth integrations are consolidated into a single platform - **Reducing delivery drag** β€” same-day first deployments via `saif new` mean engineering time goes to features, not plumbing ### Consistency and Service Quality Every application built on Forge ships with the same environments (Local β†’ Test β†’ QA β†’ UAT β†’ Production), the same deployment model (blue/green slot swap with instant rollback), and the same observability stack (OpenTelemetry β†’ Dynatrace). There is no configuration to get wrong. This is not a style guide β€” it is enforced by the platform. A team that follows the golden path cannot accidentally skip a QA gate, omit telemetry, or deploy without an approval step. ### Risk Profile Forge's security posture is a constraint, not an option: - **Zero public exposure** β€” all resources are private by default - **No credentials in code** β€” managed identity everywhere - **Auth enforced at the gateway** β€” Azure API Management handles authentication and authorization so application code does not carry that responsibility - **Dual-tenant identity** β€” Okta (external) and Entra ID (corporate) are handled by the platform; individual teams do not implement auth The cost of a misconfigured auth implementation, an exposed credential, or a deployment pipeline that skips security scanning is not reflected in the platform cost baseline. Forge makes those failure modes structurally difficult. --- ## πŸ—ΊοΈ What's Next Planned work is tracked in [GitHub Issues](https://github.com/saif-corp/forge/issues). See the [release notes](../release-notes/index.md) for what has shipped. --- ## πŸ’¬ Engaging the Platform Team | Channel | Use For | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | | [Teams β€” Platform Support](https://teams.microsoft.com/l/channel/19%3Acb611810fb0b42b080cfff5590bdd51c%40thread.tacv2/Support?groupId=514d2dac-2d62-48ce-bf99-0fa0ce39469c&tenantId=a86cb8ed-369b-4df5-ace5-43811f6e08cf) | Questions, troubleshooting, general discussion | | [GitHub Issues β€” forge](https://github.com/saif-corp/forge/issues) | Feature requests, bug reports, roadmap input |