How GitHub scaled engineering with Port

Scorecards for security, privacy, and accessibility have been part of GitHub's engineering culture from the start. But as the company scaled, their internal tooling needed to keep up. Adding a new resource type to their homegrown developer portal took three to four months. That wasn't sustainable.

"It's not our main focus," says Meirav Feiler, VP of Engineering. "We needed to grow into a proper platform, something flexible enough to grow with GitHub."

They needed more than a service catalog. They needed a foundation: a single source of truth for engineering data, a way to enforce standards without slowing teams down, and operational dashboards that help managers prioritize work instead of searching for information. Port gave them all three, and a path toward AI-assisted engineering workflows.

About GitHub

GitHub is the world’s leading platform for agentic software development — powered by Copilot to build, scale, and deliver secure software. Over 180 million developers, including more than 90% of the Fortune 100 companies, use GitHub to collaborate, and more than 77,000 organizations have adopted GitHub Copilot.

Internally, GitHub holds its own engineering organization to the same standards it enables for customers worldwide. The company runs a multi-cloud environment, monitors hundreds of applications and SLOs, and operates programs for security, privacy, and accessibility compliance across its engineering teams.

The Challenge

GitHub had already built an internal developer portal. They'd been running scorecards for security, privacy, and accessibility compliance for years. But the platform was rigid, built for a smaller organization, and required constant investment just to maintain.

Every time GitHub's engineering organization evolved, the internal portal had to catch up. New resource types, new integrations, new reporting requirements meant months of work from teams whose primary job wasn't building internal tools.

Meanwhile, engineering managers were spending too much time finding information. Service health data lived in one place. Scorecard compliance lived in another. Incident history, SLO breaches, and ownership information scattered across different systems. Managers couldn't see the full picture without manually stitching together data from multiple sources.

"We want visibility into everything," Feiler says. "We want to be able to do all our day-to-day engineering work in one place."

KTLO (Keeping The Lights On) work consumed time without moving the business forward. Engineering managers spent hours each week on information gathering that should have been instant.

GitHub also saw where the industry was heading. AI agents and autonomous workflows were becoming real. But you can't give an AI agent access to your engineering systems without context and guardrails.

Why a Solution

GitHub required 3 things:

First, a source of truth. All engineering inventory, services, resources, ownership, dependencies, visible in one place. Not a static wiki that drifts out of date, but a living system that reflects reality.

Second, standardization. With an accurate inventory, you can enforce standards programmatically, instead of through manual audits.

Third, operational intelligence. Dashboards that help people make decisions. Engineering managers see service health. VPs see organizational patterns. Program owners see compliance trends.

And looking ahead, a foundation for AI. Once all the information sits in one place, you can build intelligent automation on top of it.

"The thing that we think a developer portal should solve is, first of all, having a source of truth," Feiler explains. "Then you can start building on top of it. Standardization. Operational dashboards. And then AI and agentic flows, which is much more futuristic, but I can see how that becomes an end-to-end story."

Why Port

GitHub evaluated multiple options: open source portals, managed platforms, and continued investment in their internal tooling. Two things set Port apart: flexibility and user experience.

GitHub already had a service catalog and compliance programs. They didn't need a vendor to dictate how those should work.

"Many vendors out there have a very rigid opinion of how a developer portal should look," Feiler says. "We wanted something less opinionated, because we are pretty opinionated. We know what we want to see."

Port's blueprint architecture delivered that flexibility. Blueprints let GitHub model any resource type without waiting for vendor support or custom development. Services, cloud resources, secrets, infrastructure, all configurable. Dashboards and views the same way.

The second differentiator was usability. GitHub evaluated solutions on how quickly their teams could understand and adopt them. A powerful tool that nobody wants to use doesn't solve the problem.

"The UX was amazing," Feiler says. "People came in and understood how to use it right away. That matters when you're rolling out to a wide audience."

Implementation

GitHub's original plan was sequential: build the full inventory first, then add scorecards, then roll out to users. That changed.

"We had this notion that we're going to do inventory first, then scorecard, then start using Port," Feiler recalls. "But in reality, we shifted in order to move faster and start showing value."

GitHub pivoted to end-to-end experiences. They focused on services first and started getting users into Port while the broader data model was still being built. The platform evolved as GitHub learned what worked.

The implementation connected Port to their multi-cloud environment to build a comprehensive picture of their engineering assets. GitHub's existing fundamentals program migrated into Port. And Port's interface flexibility enabled GitHub to build different experiences for different stakeholders: engineering managers could see their team's services, VPs could see their organization. All using the same underlying data surfaced for each role.

Port's team supported the pivot. When GitHub changed their strategy, they adjusted together.

"We did change our strategy, and Port flexed to support us," Feiler says. "Being okay with change and leading that change, that's important. We're still going to get to our North Star, just in a different way than we initially planned."

Impact

We expect the daily workflow for engineering managers to change. They open Port and immediately see their services, health status, SLO breaches, and scorecard compliance. Prioritization happens in minutes instead of hours.

"They see their services, operational dashboards, understand health, and prioritize decision-making," Feiler describes. "Then they look at fundamental scorecards, security, privacy, AI responsibility, and they become more proactive."

When managers spend less time finding information, they spend more time making decisions. When developers can self-serve context, they interrupt fewer colleagues. When leadership has visibility, they can intervene earlier on problems.

"We reduced the KTLO burden for engineering managers who need to find all this information," Feiler says. "If we have everything in one place, they can actually reduce that burden in their day-to-day. Overall, the expectation with this project is to be more productive in our day-to-day."

The Port platform also addressed the original scaling problem. Adding new resource types no longer takes months. Port's blueprint architecture means GitHub can model new resources as their environment evolves.

Future: AI and Agentic Engineering

GitHub sees Port as infrastructure for the AI era.

"Port has all the information in one place," Feiler says. "You can bring more context to AI agents.

But context alone isn't enough. As AI agents take on more autonomous work, they need guardrails: rules about what they can do and when human review is required.

"How do we make sure agents use standards correctly? Scorecards in Port bring standardization. It's a world where rules guide agents, so humans don’t have to."

The same scorecards that track human compliance can govern agent behavior. The same inventory that helps managers understand their systems can give agents the context they need to act appropriately. GitHub isn't waiting for that future. They're building toward it with the platform foundation already in place.