Skip to content

Solutions resource self service #2518

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions docs/solutions/resource-self-service/_category_.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
{
"label": "Resource Self-Service",
"collapsible": true,
"collapsed": true,
"position": 4,
"link": {
"type": "generated-index",
"title": "Resource Self-Service"
},
"customProps": {
"description": "Resource Self-Service"
}
}
127 changes: 127 additions & 0 deletions docs/solutions/resource-self-service/create-golden-paths.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,127 @@
---
title: "Create Golden Paths"
sidebar_position: 1
---

# Create Golden Paths

Golden paths are a foundational element of effective platform engineering They're your organization's standardized, opinionated way of doing things that developers actually want to use. Think of them as the "happy path" that guides developers toward best practices while eliminating decision fatigue and reducing cognitive load.

## Why Golden Paths Matter

As a platform engineer, you're constantly balancing standardization with developer productivity. Golden paths solve this by providing:

- **Consistency at scale**: Every team follows the same patterns, making your platform predictable and maintainable
- **Reduced cognitive load**: Developers don't waste time deciding between 47 different ways to create a service
- **Built-in compliance**: Security, observability, and operational requirements are baked into the path
- **Faster onboarding**: New developers can be productive immediately without learning tribal knowledge
- **Reduced support burden**: Fewer "how do I..." questions and fewer production issues from misconfigurations

## The Golden Path Philosophy

Golden paths aren't designed to restrict choice, they're focused on making the right choice the easy choice. When you provide a clear, well-documented approach that follows your organization's standards, developers will naturally gravitate toward it because it's easier, faster and safer than figuring things out on their own.

The best golden paths are:
- **Opinionated but flexible**: Clear defaults with escape hatches for edge cases
- **Self-service**: No tickets, no approvals, just instant gratification
- **Well-documented**: Clear examples and troubleshooting guides
- **Continuously improved**: Feedback loops that make the path better over time

## From Chaos to Clarity

Without golden paths, you get:
- 47 different ways to create a service
- Inconsistent security configurations
- Missing observability instrumentation
- Production issues from misconfigurations
- Endless support requests

With golden paths, you get:
- A few approved patterns to do the majority of things correctly
- Consistent, secure, observable services
- Happy, productive developers
- More time for platform innovation

Golden paths transform your platform from a collection of tools into a cohesive developer experience that scales with your organization.

## Our Opinions on Golden Paths

### Scaffold New Respositories and Services

There is no better opportunity to set up developers up for success, than a greenfield use case, where the developer is configuring a new repository or service. At this point, you as a platform engineer can give them all the best configuration out of the box, such that it's easier for them to ship their code with confidence from the outset.

<iframe
width="560"
height="315"
src="https://www.youtube.com/embed/sE6XI0XDtQI"
title="Scaffolding with Port"
frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
allowfullscreen
></iframe>

- [Scaffold a New Service](/guides/all/scaffold-a-new-service): Learn how to quickly generate a new service with all the recommended defaults and best practices built in.
- [Scaffold Repo with Cookiecutter](/guides/all/scaffold-repositories-using-cookiecutter/): Use Cookiecutter templates to standardize repository creation and ensure consistency across projects.
- [Scaffold Bitbucket Repo with Cookiecutter](/guides/all/scaffold-bitbucket-using-cookiecutter/): Follow this guide to create Bitbucket repositories using Cookiecutter, streamlining setup and enforcing organizational standards.
- [Deploy New Service and Infra](/guides/all/create-eks-cluster-and-deploy-app/): See how to deploy a new service and its infrastructure together, enabling fast, reliable onboarding for new projects.
- [Create EKS Cluster and Deploy App](https://docs.port.io/guides/all/create-eks-cluster-and-deploy-app/): Follow this step-by-step guide to provision a new EKS cluster and deploy your application, ensuring a production-ready environment from day one.

### Cloud Resources

#### Architectural Patterns

Before diving into guides, it's important to pause and outline the two general patterns that exist for self-service actions (for Cloud Resources). With the adoption of Infrastructure as Code, many organizations maintain that the source-of-truth for their infrastructure configuration in their Git repositories, rather than in their cloud environments directly.

It's important to build self-service that conforms with your organizational standards and best practices. Failing to match your ways of working will just lead to further resource sprawl and complexity for your Platform Engineering team.

We'll explore 2 types of self-service below - RESTful Self-Service and Gitops-based Self-Service.

##### RESTful Self-Service

RESTful self-service actions directly create resources in your cloud provider or other upstream systems through their APIs. This approach is straightforward and immediate—when a developer requests a resource through Port's self-service interface, the action makes API calls to create the resource directly in the target system (like AWS, Azure, or GCP). This pattern works well for organizations that prefer direct resource creation or when you need immediate provisioning without the overhead of Git-based workflows. The trade-off is that you lose the audit trail and version control benefits that come with GitOps, but you gain simplicity and speed for teams that don't need the full GitOps workflow.

- [Create an S3 Bucket via Webhook](/guides/all/s3-using-webhook): Learn how to provision an S3 bucket instantly using a webhook integration.
- [Deploy CloudFormation Template](/guides/all/deploy-cloudformation-template/): See how to deploy AWS resources by triggering CloudFormation templates through self-service actions.
- [Create an EC2 Instance](/guides/all/create-an-ec2-instance/): Follow this guide to spin up new EC2 instances directly from Port's self-service interface.
- [Create Azure Resource](/guides/all/create-azure-resource/): Discover how to provision Azure resources on demand using RESTful self-service.
- [Add EC2 Volume](/guides/all/add-ec2-volume/): Learn how to attach additional storage to your EC2 instances with a simple self-service action.
- [Deploy Azure Resource](/guides/all/deploy-azure-resource/): Deploy Azure resources quickly and consistently using Port's self-service workflows.
- [Manage Kubernetes Namespaces](/guides/all/manage-kubernetes-namespaces/): Enable developers to create and manage Kubernetes namespaces without manual intervention.

##### GitOps-based Self-Service

GitOps-based self-service actions create resources by leveraging your existing Infrastructure as Code (IaC) files and modules. Here, an existing GitOps pipeline (like ArgoCD, Flux, or Terraform Cloud) picks up the changes and provisions the resources in the target cloud environment. This approach maintains the benefits of version control, audit trails, and the ability to review changes through pull requests, while still providing developers with a streamlined self-service experience. The trade-off is that resource creation takes longer due to the GitOps pipeline cycle, but you gain better governance, compliance, and the ability to enforce organizational standards through code review processes.

- [Create Cloud Resource Using IaC](/guides/all/create-cloud-resource-using-iac): Provision cloud resources by updating Infrastructure as Code files and letting your GitOps pipeline handle deployment.
- [Deploy S3 Bucket CrossPlane](/guides/all/deploy-s3-bucket-crossplane): Use CrossPlane to declaratively manage and deploy S3 buckets through GitOps workflows.
- [Create Github Pull Request](/guides/all/create-github-pull-request/): Automate the creation of GitHub pull requests to trigger infrastructure changes and reviews.
### Create Secrets

Secret leakage remains a huge issue in the industry. The fact that developers have to manually handle secrets is like a process in a nuclear plant requiring the manual handling of uranium. It's an error prone workflow, that often leads to a security incident and in worse cases, supply chain security issues and data loss.

The best protection against secret leakage is the design of a secure workflow, in which secrets are securely handled and developers are unlikely to make an error.

- [How to securely create a GitHub Secret](/guides/all/create-github-secret/): Follow this guide to add secrets to your GitHub repositories safely and prevent accidental exposure.

<iframe
width="560"
height="315"
src="https://www.youtube.com/embed/QO45jaeAA2o"
title="Secure Secrets Management"
frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
allowfullscreen
></iframe>

## Real-world benefits

Golden paths provide a standardized, secure, and efficient way for developers to provision resources and services. By implementing golden paths in Port, organizations can achieve:

- **Reduced cognitive load**: Developers don't need to understand complex infrastructure details or remember specific commands
- **Faster provisioning**: Self-service actions eliminate back-and-forth with platform teams for common requests
- **Consistent standards**: Every resource follows organizational best practices and security policies
- **Better governance**: All resource creation is tracked, auditable, and follows approved patterns
- **Reduced errors**: Predefined templates and validation prevent common mistakes and misconfigurations
- **Improved developer experience**: Teams can focus on building features rather than managing infrastructure complexity

Golden paths transform your platform engineering team from a bottleneck into an enabler, allowing developers to move faster while maintaining the security and compliance standards your organization requires.
50 changes: 50 additions & 0 deletions docs/solutions/resource-self-service/day-2-resource-lifecycle.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
---
title: "Day 2 - Resource Lifecycle"
sidebar_position: 2
---

# Day 2 - Manage the Full Resource Lifecycle

Managing the lifecycle of cloud resources is a critical aspect of platform engineering, often referred to as "Day 2 operations." After resources are provisioned—whether they're databases, compute instances, storage buckets, or Kubernetes namespaces—they require ongoing management to ensure reliability, security, and cost-effectiveness.

<img src="/img/guides/autoscalingDashboard1.png" alt="Autoscaling Dashboard Example" width="100%" style={{border: "1px solid #ddd", borderRadius: "4px", marginBottom: "1.5rem"}} />

Day 2 management includes tasks such as:
- **Scaling resources** up or down based on demand
- [View ECS tasks and scale on-demand](/guides/all/manage-and-visualize-ecs-tasks)
- [Scale Autoscaling Groups](/guides/all/manage-and-visualize-aws-autoscaling-groups)
- [Start an EC2 Instance](/guides/all/visualize-and-manage-aws-ec2-instances#start-an-ec2-instance)
- [Start a GCP Compute Engine Instance](/guides/all/manage-and-visualize-gcp-compute-engine-instances#start-a-compute-engine-instance)
- [Stop a GCP Compute Engine Instance](/guides/all/manage-and-visualize-gcp-compute-engine-instances#stop-a-compute-engine-instance)
- [Start Azure Webapp](/guides/all/manage-and-visualize-azure-web-apps#start-an-azure-web-app)
- [Stop Azure Webapp](/guides/all/manage-and-visualize-azure-web-apps#stop-an-azure-web-app)
- [Start an Azure Virtual Machine](/guides/all/manage-and-visualize-azure-virtual-machines#start-an-azure-virtual-machine)
- [Deallocate an Azure Virtual Machine](/guides/all/manage-and-visualize-azure-virtual-machines#deallocate-an-azure-virtual-machine)

- **Patching and updating** software or configurations
- [Toggle a Feature Flag](/guides/all/manage-and-visualize-your-launchdarkly-feature-flags#toggle-a-feature-flag)
- [Archive a Feature Flag](/guides/all/manage-and-visualize-your-launchdarkly-feature-flags#archive-a-feature-flag)
- [Add Tags to an EKS Cluster](/guides/all/manage-your-eks-clusters#add-tags-to-an-eks-cluster)

- **Restarting or Resyncing** to resolve issues
- [Manage Kubernetes deployments](/guides/all/manage-your-kubernetes-deployment/)
- [Reboot an EC2 Instance](/guides/all/visualize-and-manage-aws-ec2-instances#reboot-an-ec2-instance)
- [Reboot RDS instances](/guides/all/visualize-your-aws-storage-configuration#reboot-an-rds-instance)
- [Restart Azure Webapp](/guides/all/manage-and-visualize-azure-web-apps#restart-an-azure-web-app)
- [Restart an Azure Virtual Machine](/guides/all/manage-and-visualize-azure-virtual-machines#restart-an-azure-virtual-machine)

- **Decommissioning or archiving** resources when they're no longer needed
- [Terminate an EC2 Instance](/guides/all/visualize-and-manage-aws-ec2-instances#terminate-an-ec2-instance)
- [Delete an RDS instance](/guides/all/visualize-your-aws-storage-configuration#delete-an-rds-instance)
- [Delete a Kubernetes namespace](/guides/all/manage-kubernetes-namespaces)
- [Delete an SQS queue](/guides/all/manage-and-visualize-aws-sqs-queues#delete-an-sqs-queue)
- [Delete an EKS Cluster](/guides/all/manage-your-eks-clusters#delete-an-eks-cluster)

- **Monitoring usage and health** to detect issues early
- [Monitor and Purge SQS queues](/guides/all/manage-and-visualize-aws-sqs-queues#purge-an-sqs-queue)
- [Redrive messages from a DLQ](/guides/all/manage-and-visualize-aws-sqs-queues#redrive-messages-from-dlq)

- **Rotating secrets and credentials** to mitigate risks
- [Renew an ACM Certificate](/guides/all/manage-and-visualize-acm-certificates#renew-an-acm-certificate)

By automating these processes and providing self-service capabilities for Day 2 operations, platform teams empower developers to manage their own resources safely, while maintaining governance and compliance. Port enables you to define self-service actions for common Day 2 tasks, set up approval workflows, and enforce policies—ensuring that your cloud resources remain well-managed throughout their lifecycle.
37 changes: 37 additions & 0 deletions docs/solutions/resource-self-service/self-service-environments.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
---
title: "Self-Service Environments"
sidebar_position: 4
---

# Self-Service Environments

Automating the creation of development environments is crucial for engineering teams. Manual setup is slow, error-prone, and often leads to inconsistencies that can delay development and cause integration headaches. By enabling self-service environment provisioning, teams can spin up the resources they need—on demand and with the right guardrails—freeing up developers to focus on building features instead of wrangling infrastructure.

<iframe
width="560"
height="315"
src="https://www.youtube.com/embed/1OLXdVAmee4?si=-Wtb-Y5KWkKRECrA"
title="Self-Service Environments with Port"
frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
allowfullscreen
></iframe>

## Get started with self-service environments

Explore these step-by-step guides to automate environment creation and management:

- [Manage a Developer Environment Lifecycle](/guides/all/create-dev-env/)
Create a Terraform based Development Environment and show its details in Port

- [Create a new AWS account with GitLab](/guides/all/create-new-aws-account-gitlab)
Instantly provision isolated AWS accounts for your teams using a GitLab-driven workflow.

- [Manage a Kubernetes namespace](/guides/all/manage-kubernetes-namespaces)
Empower developers to create, update, or delete Kubernetes namespaces on demand—no tickets required.

- [Trigger Terraform Cloud via webhook](/actions-and-automations/setup-backend/webhook/terraform-cloud)
Automate infrastructure changes by kicking off Terraform Cloud runs directly from Port.

- [Trigger a Spacelift stack](/guides/all/trigger-spacelift-stack)
Launch and manage Spacelift stacks with a single click for streamlined environment provisioning.
41 changes: 41 additions & 0 deletions docs/solutions/resource-self-service/setup-approval-workflows.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
---
title: "Setup Approval Workflows"
sidebar_position: 3
---

# Setup Approval Workflows

Effective platform engineering requires oversight at every level—whether it's a human developer requesting a production database or an AI agent automatically scaling infrastructure. Without proper controls, self-service can quickly become a security and compliance nightmare. Port provides three complementary layers of governance: Role-Based Access Control (RBAC) for user permissions, approval workflows for human oversight, and dynamic permissions for context-aware access control.

<img src="/img/self-service-actions/setup-backend/github-workflow/approveAndApplyTerraform.png" border="1px" width="100%" />

## Role-Based Access Control

**Role-Based Access Control (RBAC)** ensures that users can only access the resources and actions they're authorized to use. Port's RBAC system allows you to define granular permissions based on user roles, team membership, and organizational hierarchy. Whether it's restricing access to a self-service action to a specific team or limiting certain infrastructure to senior engineers, RBAC provides the foundation for secure self-service by ensuring users can only perform actions within their scope of responsibility.

- [Configure Permissions for Actions](/actions-and-automations/create-self-service-experiences/set-self-service-actions-rbac/#configure-permissions-for-actions)


## Approval Workflows

**Approval Workflows** add a human oversight layer to automated processes and self-service actions. When developers request high-risk resources like production databases or expensive cloud instances, approval workflows ensure that designated approvers can review and approve requests before they're executed. This human-in-the-loop approach maintains accountability while still providing the speed and efficiency of self-service, allowing organizations to balance developer productivity with governance requirements.

- [Configure Manual Approvals for Actions](/actions-and-automations/create-self-service-experiences/set-self-service-actions-rbac/#configure-manual-approval-for-actions)

We have some guides that illustrate this capability:

- [Provision Cloud Resource using Terraform](/guides/all/terraform-plan-and-apply-aws-resource)
- [Manage Kubernetes namespaces](/guides/all/manage-kubernetes-namespaces)
- [Manage service deployments using GitLab and ServiceNow](/guides/all/approval-workflow-for-gitlab-deployment)
- [Notify users upon approval of self-service actions](/guides/all/notify-users-upon-approval-of-action)

## Dynamic Permissions

**Dynamic Permissions** take access control to the next level by making permissions context-aware and automatically adjusting based on real-time conditions. For example:
- a developer might have permission to deploy to staging environments during business hours, but require additional approval for production deployments or after-hours changes.
- changes may be restricted to non-business critical applications during the Christmas holidays
- feature flags can only be toggled without approval where they relate to non-ga features, or are not active for a set of critical customers

Dynamic permissions can also consider factors like resource costs, security posture, or organizational policies to automatically escalate or restrict access when needed.

- [Dynamic Permissions for Actions](/actions-and-automations/create-self-service-experiences/set-self-service-actions-rbac/dynamic-permissions)