Set up your context lake
With your Git provider connected and your platform set up, the next step is to bring in more real data. This involves connecting additional tools and using Port AI to populate your context lake - your unified catalog of engineering knowledge.
Connect your tools
Once you land on the services page, the chat panel will walk you through whatever is left to get real data flowing, including connecting the tools relevant to your use-case.
If you want to install a tool beyond what the chat suggests, go to the data sources page and install it from there. You can also skip this step and install integrations later - keep in mind that the dashboard pages created for your use-case will remain empty until you connect your tools and bring in your data.
Installation methods
Port supports several installation methods - varying in hosting environment and resync mechanism - so you can choose the one that fits your organizational standards. The available methods for a specific integration can be found on its documentation page. For a full list of available integrations, see the integrations catalog.
What happens after installation
Once an integration is installed:
- Data from the connected tool starts flowing into your catalog, creating entities as defined in each blueprint.
- Since your data is now ingested into Port, dashboards that rely on the relevant entities will now display real data. According to the use-case you selected, default dashboard pages will be created in your catalog.
Port supports integrations with tools across Git, cloud providers, incident management, observability, security, and more. See the full list in the integrations section.
Connect MCP tools
In addition to native integrations, you can extend your context lake by connecting MCP connectors. While integrations sync persistent data into Port as entities, MCP connectors give Port AI real-time access to live or unmodeled data from external tools - such as Notion pages, Slack threads, or raw logs - without storing it in Port.
In many cases, you will benefit from using both for the same tool.
To set up MCP connectors, see the MCP connectors documentation, and Integrations vs. MCP connectors to understand when to use each.
Discover entities using Port AI
Port's catalog auto-discovery capability uses Port AI to discover entities and their relations. It is particularly useful for discovering entities that are not automatically created through integrations, such as services and users.
To discover entities, follow these steps:
- Go to the catalog and open the page for the blueprint you want to discover.
- Click the
button in the top right corner of the page. - Fill in the Additional information field to describe what the entity means in your organization.
Providing a prompt is highly recommended - it gives the AI context to identify patterns relevant to your organization and significantly improves discovery accuracy. - Optionally, enable Advanced configuration to select which blueprints Port should analyze.
- Click the discover button to start the process.
- Once the discovery process is complete, review, edit, approve, or decline the suggested entities individually or in bulk.
Examples
Example 1: Discover services from a monorepo
If you have a monorepo structure with multiple services, you can discover service entities by analyzing your GitHub repositories.
Recommended prompt:
Services are represented as code in a repository.
Check the file structure of each repository to identify services.
Services may be found in specific folders, such as "apps" or "services".
Add the relevant blueprints to base the auto discovery on, for example: GitHub Repository.
Example 2: Discover services from individual repositories
If you have individual repositories and want to identify which ones represent services, you can use catalog auto-discovery with both GitHub and PagerDuty data.
Recommended prompt:
Focus on repos that have keywords that can indicate they are services (e.g., "service", "ms", "srv").
Ignore repos of libraries and packages. Having also a PagerDuty service with a similar name as a repo
is a strong indication that this is a service.
Add the relevant blueprints to base the auto discovery on, for example: GitHub Repository, PagerDuty Service.
Example 3: Discover users from development activity
If you want to identify users who contribute to your codebase but don't yet exist in your catalog, you can analyze pull requests and issues.
Recommended prompt:
Check "Jira issues" assignees and "pull requests" to identify developers in the organization.
Add the relevant blueprints to base the auto discovery on, for example: Jira Issue, Jira User, Pull Requests.
For more information and configuration details, see the auto-discovery documentation.
Assign service ownership
Once your services are in the context lake, assign an owner to each one. Ownership makes it easy to route alerts, requests, and responsibilities to the right team.
To assign an owner manually:
- Go to the Services page in your catalog.
- Click on a service entity to open it.
- In the Owning Teams relation, select the team responsible for the service.
You can automate ownership by adding a mapping rule to your integration configuration - for example, setting the owner based on a CODEOWNERS file, a repository team, or a label. See configure mapping for details.
To model how your teams are structured across the organization, see Visualize organization hierarchy.
Next step
With your context lake populated, proceed to view your dashboards.