--- title: "Platform Engineering with GitHub: How to Build an Internal Developer Platform Using Copilot, IssueOps, and Golden-Path Starter Repos" description: "Stop building Backstage. Your IDP already exists — it's GitHub with Copilot extensions, IssueOps workflows, and golden-path starter repos." date: 2026-05-21 tags: ["Platform Engineering", "GitHub Copilot", "GitHub Actions", "Developer Experience", "Deep Dive", "Enterprise"] canonical: https://htek.dev/articles/platform-engineering-github-internal-developer-platform --- The platform engineering movement is accelerating — and most teams are building it wrong. They're adopting Backstage, standing up Kubernetes operators, hiring dedicated portal teams, and spending 6-12 months before delivering any real value to developers. Meanwhile, the actual developer platform — the thing engineers use every single day — is sitting right in front of them. It's GitHub. I built an enterprise-scale internal developer platform at a Fortune 500 energy company. Thousands of developers, hundreds of repos, strict compliance requirements. We didn't need a separate portal because **GitHub already IS the platform** — the service catalog, the self-service automation, the golden paths, the governance layer. All native primitives, composed together. Here's the overview of how that architecture works — and the 7 open-source repos that make it real. > **Want the complete implementation?** This article covers the architecture and approach. The full step-by-step guide — with IssueOps workflows, Copilot extension code, and hookflow governance configs — lives in [Issue 008 of the htek.dev newsletter](/newsletter/issues/008-platform-engineering-with-github). **[Subscribe to get it →](/newsletter)** --- ## The Platform Engineering Movement Is Real — But the Tooling Is Wrong Platform engineering isn't a trend. It's a structural response to a measurable problem: developer teams spend [30% of their time on operational tasks](https://humanitec.com/blog/state-of-platform-engineering-report-volume-2) instead of shipping features. The [CNCF Platform Engineering Maturity Model](https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/) formalized this, and [Team Topologies](https://teamtopologies.com/key-concepts) gave us the vocabulary — platform teams exist to reduce cognitive load for stream-aligned teams. But the industry made a wrong turn. Everyone assumed platform engineering meant **Backstage**. Backstage is powerful — and it's also a React application requiring a PostgreSQL database, a dedicated team to maintain, a plugin ecosystem with varying quality, and months of customization. The [2025 Backstage Adopter Survey](https://backstage.io/blog/2025/03/25/adopter-survey-results-2025/) showed most teams take 6-12 months to reach "useful." Many never get there. If your developers already live in GitHub — PRs, issues, Actions, Codespaces — why send them to a separate portal? --- ## The 4 Capabilities Every IDP Needs Every internal developer platform, regardless of implementation, needs four core capabilities: ### 1. Self-Service Provisioning Developers need to spin up environments, repos, and infrastructure without filing tickets. On GitHub, this means **IssueOps** — open an issue with a structured template, and GitHub Actions provisions everything automatically. ### 2. Golden-Path Templates Opinionated, well-lit routes through your stack. Developers *can* deviate — but the default path is fast, correct, and maintained. On GitHub? These are **starter repos with embedded AI context** via `copilot-instructions.md`. ### 3. Governance & Guardrails Policy enforcement that doesn't require developers to remember rules. On GitHub, this is **Copilot hooks and extensions** — guardrails that intercept dangerous operations before they happen, not after. ### 4. Unified Developer Experience One place where developers see their services, their environments, their compliance status. On GitHub, you already have the repo as the unit of ownership — what's missing is the composition layer, which [GitHub Copilot extensions](https://docs.github.com/en/copilot/building-copilot-extensions) now provide. --- ## Why GitHub-Native Wins Over Backstage The fundamental advantage: **zero adoption friction**. Your developers are already authenticated to GitHub. They already know how to open issues, review PRs, and trigger Actions. A GitHub-native IDP doesn't require new logins, new UIs, new mental models, or new SSO integrations. Here's the architectural comparison: | Capability | Backstage Approach | GitHub-Native Approach | |---|---|---| | Service catalog | Custom plugins + PostgreSQL | Repository topics + `CODEOWNERS` + org-level metadata | | Self-service | Software templates + scaffolder | IssueOps + reusable Actions | | Golden paths | Template catalog | Starter repos + copilot-instructions | | Governance | TechDocs + manual reviews | Copilot hooks + required workflows | | Developer UI | Custom React portal | GitHub UI + Copilot chat extensions | The GitHub-native approach isn't "less capable." It's **differently capable** — and it ships in weeks, not months. --- ## The 7 Starter Repos I've open-sourced the building blocks as 7 starter repositories. Each handles one piece of the IDP puzzle: 1. **copilot-instructions-starter** — Golden-path context engineering templates that shape how AI agents interact with your codebase 2. **copilot-hooks-starter** — Hook configurations and safety guardrails for controlling what AI agents can and cannot do 3. **copilot-agent-starter** — Multi-agent delegation patterns and orchestration templates for PR review, deployment, and triage 4. **issueops-starter** — Self-service provisioning workflows triggered by structured issue templates 5. **github-governance-starter** — Organization-wide policy enforcement via required workflows, rulesets, and compliance checks 6. **platform-catalog-starter** — Service catalog metadata conventions using repository topics, custom properties, and CODEOWNERS 7. **golden-path-app-starter** — A complete application template wired with all of the above — the "new project" button for your platform Each repo is standalone but designed to compose. The platform team maintains the starters; stream-aligned teams consume them through `gh repo create --template`. > **Newsletter subscribers get the full implementation details** — complete IssueOps workflow YAML, Copilot extension source code, hookflow governance configs, and the composition patterns that wire all 7 repos together. **[Subscribe to Issue 008 →](/newsletter)** --- ## How This Connects to Context Engineering If you've read my piece on [context engineering](/articles/what-is-context-engineering-practical-guide-50-agents), you already understand the core insight: **the quality of AI output is determined by the context you provide, not the prompts you write**. Golden-path starter repos are context engineering at the organizational level. Every new repo created from a starter inherits: - Architecture decisions (via `copilot-instructions.md`) - Safety guardrails (via hook configurations) - Governance rules (via required workflows) - Agent behaviors (via agent definitions) This is what I call [the three layers your AI agent is missing](/articles/three-layers-your-ai-agent-is-missing) — scaled to the platform level. And it ties directly into the [governance stack](/articles/7-layer-ai-governance-stack) I wrote about recently. --- ## The Blueprint: Part 4 — Platform Engineering I'm releasing a new **Part 4: Platform Engineering** chapter in [The Agentic Development Blueprint](https://htek.dev/blueprints/the-agentic-development-blueprint). It covers the full architecture — from IssueOps provisioning flows to Copilot extension development to hookflow governance patterns — with production-ready code and configuration you can deploy this week. If you're already running the blueprint patterns from Parts 1-3 (agent harnesses, multi-agent orchestration, context engineering), Part 4 shows how to scale those patterns across your entire organization as a platform team. --- ## The Bottom Line You don't need Backstage. You don't need a 6-month implementation timeline. You don't need a dedicated React portal team. You need GitHub — which you already have — composed with IssueOps, golden-path starters, Copilot extensions, and hook-based governance. The platform is already there. You just need to wire it together. **This was the overview.** The newsletter issue has the full step-by-step implementation — complete IssueOps workflows, Copilot extension code, all 7 repos explained in depth, and the composition patterns that make them work together. **[→ Subscribe to the htek.dev newsletter to get Issue 008](/newsletter)** --- *Related reading:* - [Context Engineering: Practical Guide with 50+ Agents](/articles/what-is-context-engineering-practical-guide-50-agents) - [Agent Hooks: Controlling AI Agents in Your Codebase](/articles/agent-hooks-controlling-ai-codebase) - [53 Agents, Zero Chaos: Multi-Agent Orchestration](/articles/53-agents-zero-chaos-multi-agent-orchestration-patterns) - [The 7-Layer AI Governance Stack](/articles/7-layer-ai-governance-stack)