> For the complete documentation index, see llms.txt.
Skip to main content

Check out Port for yourself ➜ 

Resource management

Resource management is Port's approach to giving developers and AI agents full lifecycle control of infrastructure resources, while platform teams keep control of the standards.

Platform teams define golden paths, the organization's approved way of provisioning and operating resources. Developers and agents consume those golden paths to create, update, and decommission resources on demand. Because the golden path encodes your standards, engineering velocity does not come at the cost of governance.

The result is a resource layer that moves at developer speed for both humans and agents, without sacrificing platform control.

Resource management matrix crossing resource types (VM, Kubernetes, database, secret, environment) with lifecycle actions (provision, operation, decommission, governance, costs)

What problem it solves​

Controlling infrastructure resources with tickets is a major bottleneck in the software development lifecycle. Every database, bucket, or namespace waits in a queue, and developers lose momentum while they wait.

When the queue gets too long, developers bypass the platform and provision resources themselves. Those resources often fail to meet the organization's standards for:

  • Cost - untracked or oversized resources that inflate the cloud bill.
  • Compliance - resources that skip required policies, tags, or approvals.
  • Stability - misconfigured resources that cause incidents down the line.

This creates a tension between two failure modes: too slow (ticket queues and multi-day SLAs) and too loose (ungoverned provisioning that creates security gaps and cost overruns).

AI is an amplifier. Agents can request and provision resources far faster than humans, which makes the too-slow bottleneck more painful and the too-loose risk more dangerous. Resource management resolves both sides of the tension at once by making the governed path the fast path.

The speed vs control tradeoff​

Platform teams typically provide infrastructure through one of three approaches, and each forces a choice between speed and control:

  1. Tickets. The platform team writes every change, and developers wait days for each request. This maximizes control but creates a bottleneck that slows down the entire organization.

  2. Self-service templates. Developers get fast provisioning for common requests, but templates are rigid. Anything that does not fit the form, whether it is a slightly different configuration or a resource type the template does not cover, falls back to tickets or is not possible at all.

  3. Coding agents with skills. Agents can generate pull requests fast, addressing the speed problem for custom or complex requests. But those PRs pile up waiting for platform team review. Without guardrails, agents can produce changes that violate policies, exceed budgets, or introduce security risks, so manual review becomes the bottleneck again.

Every path forces a tradeoff: fast provisioning at the cost of governance, or strong control at the cost of velocity.

Speed for safe changes, control for risky ones​

Resource management resolves the tradeoff by routing requests based on risk. Safe changes flow straight through to a pull request; risky changes pause for human review. The result is a governed path from a plain-language ask to an approved Infrastructure as Code pull request.

Here is how it works:

Governed flow diagram showing five steps: ask in plain language, plan with your modules, check against your rules, human in the loop only when needed (with safe change going directly to PR and risky change requiring approval), and open the Terraform PR
  1. Ask in plain language. Developers and agents describe what they need without fitting it into a template. For example, "I need an S3 bucket for this service" or "provision a staging environment for this feature."

  2. Plan with your modules. The AI action node maps the request to your approved Terraform modules, GitOps templates, and other infrastructure definitions. The agent plans the implementation using your organization's standards, not generic defaults.

  3. Check it against your rules. The workflow evaluates the request against your policies. Is it touching production? Does it involve sensitive data? Does it break a platform rule such as cost limits or required tagging? Each policy can be defined as a workflow condition or encoded in a skill.

  4. Human in the loop, only when needed. For risky changes, a self-service trigger or approval step pauses the workflow so the right person, such as the module owner or a compliance lead, can review the request and approve it or reject it with a reason. Low-risk requests skip this step and proceed directly to the next stage.

  5. Open the Terraform PR. A coding agent, such as the Create Cursor Cloud Agent integration action, writes the Infrastructure as Code and opens the pull request. The code is already checked against your rules and, if needed, already approved, so the PR reflects a governed decision rather than an unreviewed agent output.

Safe changes, those that fit within established patterns and do not trigger risk conditions, go straight from request to pull request. The platform team reviews only the exceptions, and developers get speed without sacrificing governance.

How is this different from traditional self-service?​

Resource management is the evolution of self-service for the agentic era. The core idea is the same, enable developers through golden paths, but two things shift:

Traditional self-serviceResource management
Serves developers.Serves developers and agents alike.
Centered on a UI developers navigate to.Centered on the IDE, reached through the MCP server, wherever developers and agents already work.
Implemented as self-service actions with backend templates.Implemented as agentic workflows with guardrails and context.

Self-service in the agentic era​

The "why" and "how" do not change: engineering velocity should not come at the cost of governance, and golden paths are how you deliver both. What changes is the "what". Instead of bringing developers to a separate UI, you serve golden paths directly into the coding environment where developers and agents work.

So, how does it work? A developer or agent expresses intent in their coding environment, for example "I need an S3 bucket for this service". Port's MCP server surfaces the relevant workflows based on that need and triggers them, without the developer ever leaving their IDE. The same golden path runs, the same guardrails apply, and the same audit trail is produced.

Why Port?​

  • AI agents as primitives. AI agents are first-class citizens in Port, subject to the same catalog, permissions, and guardrails as human users.
  • Agentic workflows. Workflows orchestrate agents, humans, and tools into golden paths, with human-in-the-loop nodes wherever your policy requires review.
  • Skills. Skills package your organization's "how-to" knowledge so agents handle specialized provisioning tasks consistently.
  • Build Port with AI. Port is designed to be configured and extended with AI, so platform teams ship golden paths faster.

Customer stories​

See how platform teams use Port to govern resource provisioning at scale:

Checkmarx

97% infrastructure cost savings on developer environments.

Read case studyarrow_forward
Cybersixgill

60x reduction in time to make resource changes.

Read case studyarrow_forward
Xceptor

24x increase in average customer deployment frequency.

Read case studyarrow_forward

Next steps​

  • Getting started - build an agentic workflow that provisions a new cloud resource using Infrastructure as Code.
  • Golden paths - understand golden paths as the "how-to" of your organization, across the full resource lifecycle.

Port integrates with AWS, GCP, Azure, Kubernetes, Terraform, GitHub, GitLab, Jira, Slack, and 50+ other platforms, no migration required.