Why GitHub chose Port as its internal developer portal 

April 25, 2025

Ready to start?

Why GitHub chose Port as its internal developer portal 

Introduction

GitHub’s engineering environment is fast-paced and constantly evolving. With an ever-growing number of tools, services, and teams, staying on top of essential information — without losing focus — became a challenge. 

This article explores why GitHub chose Port as their internal developer portal. You'll see how Port helps engineers stay productive and enables leadership to enforce standards seamlessly, ensuring GitHub’s internal processes remain as dynamic as the company itself.

Why Hubbers needed a portal

Imagine you’re a GitHub engineer (or Hubber, as GitHub calls it) working on a feature. GitHub is the leader in building a developer-first platform. However, with dozens (or hundreds) of tools used, thousands of cloud subscriptions, hundreds of microservices, and a few monoliths owned by hundreds of teams — it’s complex for you to get answers to simple questions such as:

  • Where is my service running?
  • Which services will be impacted by my features? 
  • Which SLOs are not being met by my team? 
  • Who owns a service? 
  • Who made the last change in production?

As an engineer, you need the information at your fingertips in order to stay in the flow state. Otherwise, you’ll have to ask colleagues in DevOps or other domains questions — via communication channels, as GitHub’s engineers work remotely — which steer you away from that state. 

To build the best developer-first platform, GitHub focuses on a developer-first way of working, continually refining its internal processes. Engineers at GitHub are proactive problem-solvers — and so they developed internal inventories, applications, and CLIs that would help developers to get answers to questions they have and improve visibility. 

But working with multiple solutions can actually lead to further challenges. How are you meant to know what the most reliable source of truth is? How can you be sure that sudden changes won’t be made that impact quarterly plans, derailing your work and causing inefficiencies?

If you don’t fully trust any one solution to provide you with reliable information, then you’ll be deterred from using it. This leads to a cycle where you end up asking colleagues for answers again.

It’s for this reason that GitHub searched for a solution. They came across Port, an internal developer portal that consolidates everything developers need to know in one place, becoming a trusted source of truth for resources and dependencies. 

With Port, Hubbers could start their day by heading to the Plan My Day dashboard:

Port's Plan My Day dashboard

In this example, first up is to fix an urgent bug. There's a link to a GitHub issue with all the details needed to dive in.

To get a better understanding of the bug, check out the service page in Port. It’s got everything:

  • Who owns the service
  • Who's on call
  • Who made the last commit
  • Related cloud resources
  • Links to documentation 

Instead of digging through multiple tools, it's all right there in one place. With a consolidated software catalog and hierarchical data groupings, it’s easier than ever to map out resources and dependencies effectively.

Having all this information in one spot makes a big difference. You can quickly see where things stand with your projects, and if you need to loop someone in, ownership details are just a click away. Plus, teams across the company — whether it's product owners or business units — can always check the status of services without needing to ask around.

Once you fix the bug, Port updates everything automatically. Your task list in the "Plan My Day" dashboard reflects the changes, and the resolution details from the GitHub issue are right there too, keeping your task list accurate and up to date. No need to switch between tools, tabs, or windows—everything you need is at your fingertips.

With Port acting as GitHub’s trusted source of truth for resources and dependencies, Hubbers no longer worry about conflicting or duplicated data. The flexible data model, powered by blueprints, ensures that everything aligns with GitHub’s business logic and quarterly goals. Real-time data ingestion from internal and external tools, enabled by Port’s open source framework Ocean, keeps everything up to date, helping Hubbers stay focused on productive work without unnecessary context switching.

With everything in one place, your workday feels more organized, and you can stay focused on what really matters: solving problems and shipping great code.

{{cta_1}}

Why GitHub’s engineering leaders needed a portal

Now, let’s look at it through the eyes of an engineering leader at GitHub. Your focus is on creating an environment where engineers can stay in the flow state — where they're productive, engaged, and able to focus on building great software without unnecessary interruptions.

But your responsibilities go beyond this. You want to ensure that engineering work aligns with business priorities. You want developers to focus on tasks that drive meaningful impact and contribute directly to the company's goals. But balancing autonomy with alignment isn't always straightforward — especially at scale. Engineers need the freedom to innovate, yet their work must also fit within the broader organizational strategy.

On top of that, there's the ongoing challenge of enforcing organizational standards across multiple teams and tools. Whether it’s ensuring every repository has a CI/CD pipeline or confirming that critical services have an on-call rotation, maintaining compliance across the organization can feel overwhelming. Without proper visibility, it’s difficult to identify gaps, assign tasks, and track progress effectively. GitHub refers to these organizational requirements — things like security, privacy, and operational policies — as “non-feature work.” These requirements often vary across domains, but they all share a common goal: ensuring that teams meet company-wide standards without unnecessary friction.

Previously, GitHub lacked a centralized way to enforce these standards consistently. Teams were often left to figure things out on their own, leading to inconsistencies and inefficiencies. As an engineering leader, you need a solution that can provide a high-level view of compliance across teams while also enabling action — whether that means assigning an item, setting deadlines, or tracking progress to completion.

To address these challenges, GitHub turned to Port to enable engineering managers to enforce company-wide policies in an automated, scalable way.

With Port in place, GitHub could now implement scorecards, a structured way to define and track standards across the organization. Scorecards allowed teams to check for compliance with key requirements such as:

  • Does a repository have a pipeline?
  • Does a service have an on-call rotation?
  • Is the security policy up to date?

Scorecards aren’t just about tracking — they helped embed standards into daily workflows, ensuring new resources adhered to policies from day one. Each scorecard can be owned by a specific manager, who is responsible for making sure all requirements are met across their teams. 

Let’s use a security team lead as an example. They’re focused on ensuring that GitHub is cloud-secured. They need to ensure they’re able to monitor the status of security standards, automatically sync with security tools and GitHub’s architecture. 

In addition, they need to ensure any unmet security issues are addressed in time, across all teams. They can view all of this on a dedicated security dashboard in Port, which incorporates scorecards and initiatives — which enables them to see the current status of cloud security in GitHub. 

Services scorecards dashboard

The security lead can then gain an overview of the most common alerts in the company coming from their security tool in real-time. 

In this example, let’s say that the leader notices that there is a large amount of critical cloud alerts that can be fixed. They can create an initiative to ensure that no service has a critical cloud security issue, by the end of the quarter. 

Port automatically creates an action item for each team with the relevant due date (a GitHub issue for each team with a cloud security alert) to ensure alignment. The security manager can then use the cloud security dashboard to track the initiative, checking progress per team and domain. 

But what happens when teams can’t meet certain requirements? For example, an update may not be relevant for one team, or there may simply not be enough time left in the quarter to meet a specific requirement. Or perhaps there’s no available fix for a vulnerability.

If this was the case, they may see that the issue is impacting their service’s scorecard, dropping its security ranking to “Low.” The security lead has set the requirement for all services to reach at least a “Medium” security ranking by the end of the quarter. This leaves engineers stuck.

But with Port, you can request an exception from the team that has established the requirement. In this case, a team can request to be temporarily excluded from fixing this vulnerability. Once approved, the engineer is free to move on to their next task without unnecessary roadblocks, while the issue remains tracked for future resolution. The service now meets the required ‘Medium’ security level, keeping them compliant.

With Port, GitHub can provide an automated, dynamic way to request deadline extensions or exclusions from requirements. Each scorecard can have its own approval chain, ensuring that the right stakeholders are involved in decision-making without unnecessary delays or bureaucracy.

Port also made it easy to track and enforce compliance through features like:

  • Automated scorecard generation, ensuring standards are consistently applied.
  • Dashboards with adherence metrics, offering a clear overview of compliance across teams.
  • Integration with GitHub Issues, so teams could track and resolve compliance tasks within their existing workflows.

With these capabilities, GitHub domain owners and managers can now start their day with confidence, checking a dashboard that provides real-time insights into which teams are meeting standards and which need attention. Instead of spending time tracking down compliance manually, they can focus on higher-level strategic goals, knowing that Port is keeping everything on track.

By leveraging Port, GitHub has transformed the way it manages compliance and alignment, making it easier for engineering leaders like you to drive impact while maintaining flexibility and autonomy across teams.

Why Port?

GitHub selected Port because it can meet all of the company’s goals from a capability and feature perspective. Here are some of the other key reasons Port was selected:

Single source of truth

  • GitHub developers juggle hundreds of tools, countless cloud subscriptions, and a complex mix of microservices and monoliths across multiple teams.
  • Answering simple questions like “Where is my service running?” or “Who last made changes?” previously required sifting through scattered tools or asking colleagues, which disrupts focus and slows progress.
  • Port consolidates everything into a single source of truth, cutting through the noise of multiple tools and manual processes.
  • Instead of switching between dashboards and messaging threads, engineers quickly find the answers they need, staying in their flow state and focusing on solving problems.

Reliability

  • Port provides real-time integrations, ensuring that data is always up to date and eliminating conflicting or outdated information.
  • Engineers trust the information they see, while leadership makes confident decisions with an accurate picture of GitHub’s internal landscape.

Meeting organizational standards

  • Compliance becomes more manageable with Port through automated scorecards that track whether resources meet organizational standards.
  • Teams gain clear visibility into what needs attention.
  • Leaders set deadlines and create a ‘fanout’ process to apply standards across various teams.
  • Engineers can request exceptions when something does not align.

Flexible data model

  • Port fits seamlessly into GitHub’s workflows with its flexible data model, powered by Blueprints.
  • It adapts to GitHub’s unique business goals without forcing unnecessary changes.

Managed as code

  • Everything in Port is manageable as code, allowing engineers to track and manage portal updates through version control, pull requests, and collaboration.

Enterprise-grade support

  • Port provides enterprise-grade support, ensuring high security standards and seamless onboarding.
  • Whether integrating a new service or meeting new compliance requirements, Port helps GitHub stay aligned with broader goals without adding friction.

Wrapping up

Ultimately, Port helps GitHub developers stay focused by streamlining processes, reducing redundant tools, and automating workflows. It brings efficiency and clarity to operations, enabling engineers to keep shipping great code, leadership to have better oversight, and compliance to no longer feel like a bottleneck.

With everything in one place, GitHub finally has what it needs: a reliable, flexible, and developer-friendly way to manage their internal ecosystem without losing time, energy, or focus. They have an internal developer portal that evolves with GitHub’s dynamic nature today and in the future.

{{cta-demo-baner}}

{{survey}}

Download your survey template today

By clicking this button, you agree to our Terms of Use and Privacy Policy
{{roadmap}}

Free Roadmap planner for Platform Engineering teams

  • Set Clear Goals for Your Portal

  • Define Features and Milestones

  • Stay Aligned and Keep Moving Forward

{{rfp}}

Free RFP template for Internal Developer Portal

Creating an RFP for an internal developer portal doesn’t have to be complex. Our template gives you a streamlined path to start strong and ensure you’re covering all the key details.

{{ai_jq}}

Leverage AI to generate optimized JQ commands

test them in real-time, and refine your approach instantly. This powerful tool lets you experiment, troubleshoot, and fine-tune your queries—taking your development workflow to the next level.

{{cta_1}}

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

{{cta_survey}}

Check out the 2025 State of Internal Developer Portals report

See the full report

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

Watch Port live coding videos - setting up an internal developer portal & platform

{{cta_5}}

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical walkthrough of Port

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

Watch Port live coding videos - setting up an internal developer portal & platform

{{cta-demo}}
{{reading-box-backstage-vs-port}}
{{cta-backstage-docs-button}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Starting with Port is simple, fast and free.

Let’s start