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 · Platform History · Release Notes
📋 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 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)
- 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; tracked in #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 newmean 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. See the release notes for what has shipped.
💬 Engaging the Platform Team¶
| Channel | Use For |
|---|---|
| Teams — Platform Support | Questions, troubleshooting, general discussion |
| GitHub Issues — forge | Feature requests, bug reports, roadmap input |