Default blueprints
Every Port account comes with a set of default blueprints, used to represent common concepts in your organization.
See the list below for a description of each blueprint.
You can view and edit blueprints in the data model page of your portal.
Service
service - a flexible blueprint representing a piece of software that is owned by a team/group in your organization.
This blueprint serves as a single component with rich context about all the resources related to the software, such as:
- The code itself - a repository or a specific folder in a monorepo.
- Incident management components, such as a PagerDuty service.
- Code scanning components, such as Snyk Targets or Sonar Cloud projects.
- Project management components, such as Jira projects and issues.
- Runtime components, such as workloads.
Services are the core component of R&D operations within a developer portal, providing each team with a unified view of its services and their status across different domains, such as security, stability, access management, and more.
Environment
environment - represents a deployment environment in your organization.
In addition to this blueprint, 3 default entities will be created: Production, Staging, and Test.
You can modify the default environments and/or create additional ones.
Workload
workload - represents a service running in a specific environment, with context of the relevant related components.
For example, a frontend service in your organization can have frontend-prod and frontend-test workloads, each with its own Kubernetes namespace, Sentry project, and owning team.
Deployment
deployment - represents a production deployment, created each time a PR is merged to the default branch.
Deployment entities provide traceability from code change to production, helping you track delivery frequency and link deployments back to the services and teams responsible for them.
User
_user - represents a user in your organization.
This blueprint can be related to other "user" blueprints coming from your data sources, such as github_user, allowing you to manage a user across multiple tools from a single component.
Team
_team - represents a team in your organization.
This blueprint can be related to other "team" blueprints coming from your data sources, such as github_team, allowing you to manage a team across multiple tools from a single component.
Users in Port can be assigned to teams, allowing you to implement ownership of components in your portal.
Organization
organization - a logical grouping of teams and services in your catalog.
Organizations represent higher-level business units in your company hierarchy, making it easier to manage ownership and visibility across multiple teams and their services.
Scorecard
_scorecard - represents a scorecard in Port.
Scorecards enable you to define and track metrics and standards for entities in your catalog. Each scorecard evaluates entities based on a set of rules and assigns them a level, such as Basic, Bronze, Silver, or Gold.
Scorecard rule
_rule - represents an individual rule within a scorecard.
Each rule defines one or more conditions that an entity must meet to reach a specific level in its scorecard.
Scorecard rule result
_rule_result - represents the evaluation result of a scorecard rule for a specific entity.
Rule results track whether each entity passes or fails each scorecard rule, giving you a clear view of where entities stand and what needs to be improved.
AI agent
_ai_agent - represents an AI agent registered in your portal.
AI agents are the primary interface for interacting with Port using natural language. This blueprint tracks the agents available in your organization.
AI invocation
_ai_invocations - represents a single interaction with an AI agent.
Each time an agent is invoked, a corresponding AI invocation entity is created, providing a record of agent usage. Permissions on this blueprint control which users in your organization can access Port AI features.
MCP server
_mcp_server - represents an external MCP (Model Context Protocol) server connected to Port.
MCP servers extend Port's AI capabilities by providing additional tools and context that AI agents can use. Registering MCP servers in Port allows AI agents to discover and use their tools dynamically.
System blueprints reference
Port includes protected system blueprints (identifiers starting with _) that power core platform features. These blueprints have specific constraints that differ from user-created blueprints.
| Identifier | Display name | Purpose | Can delete | Can extend |
|---|---|---|---|---|
_user | User | Represents users in your organization | No | Yes (relations only) |
_team | Team | Represents teams in your organization | No | Yes (relations only) |
_scorecard | Scorecard | Tracks scorecards defined in Port | No | No |
_rule | Scorecard Rule | Individual rules within scorecards | No | No |
_rule_result | Scorecard Rule Result | Evaluation results of scorecard rules | No | No |
_ai_agent | AI Agent | AI agents registered in your portal | No | No |
_ai_invocations | AI Invocation | Records of AI agent interactions | No | No |
_ai_conversation | AI Conversation | Groups related AI invocations into conversations | No | No |
_mcp_server | MCP Server | External MCP servers connected to Port | No | No |
System blueprints are managed by Port and cannot be deleted or have their core schema modified. They are automatically created and maintained to support platform functionality.
The _user and _team blueprints can be extended with additional relations to link Port users and teams to entities from your integrations (for example, linking _user to a githubUser or pagerdutyUser). You can also configure permissions on system blueprints to control user access to features (for example, restricting AI access via _ai_invocations permissions).
In addition to system blueprints, Port uses special identifiers for navigation:
$home: References the portal home page in URLs and navigation contexts.