Developer Self-service Actions

Self-service actions are often the first thing that developers associate with internal developer portals. There’s a good reason for that: self-service actions make developers more productive (and happier), by promoting autonomy along with guardrails and golden paths. 

Self-service actions promote developer productivity and engineering standards

Enabling self-service developer actions achieves several goals:

1. Provides developers with autonomy to perform routine tasks themselves (e.g., spinning up a dev environment) without filing tickets or waiting for other teams
2. Ensures compliance with organizational security policies and best practices 
3. Enables actions in context (e.g., a developer can see all runtime details on related microservices before scaffolding a new microservice)
4. Provides a “golden path,” reinforced through the UI and role-based access control
5. Enforces guardrails around organizational policies (e.g., TTL for ephemeral environments, approval processes)
6. Supports engineering quality standards by enforcing them in the scaffolding phase

Self-service actions drive efficiency and developer productivity by allowing developers to execute tasks independently and asynchronously, without having to rely on DevOps teams. This is achieved through a curated UI in the developer portal – with an abstraction of underlying workflows configured by the DevOps or platform engineering team, guided by organizational best practices. 

Two keys to powerful self-service actions

Self-service actions should be loosely coupled (deliberately segregated) from the underlying infrastructure of the platform. This separation ensures that regardless of how the infrastructure evolves (e.g., if the underlying cloud resources, CI or CD systems are replaced), developers will still have the same experience built with a product mindset and designed to reinforce golden paths. For a variety of technical and security reasons, it’s considered best practice for the portal to remain loosely coupled from underlying GitOps platforms. 

Another important aspect of self-service actions is that they are reflected in the catalog, which is always kept up-to-date. In this sense, the catalog serves as a dynamic reference point—a repository for deployed services, environments, and other critical entities. Every self-service action affects catalog entities: creating, modifying, or deleting them. 

By aligning self-service actions with the catalog's status, developers gain informed, real-time insights into the development environment.

Examples of self-service actions

• Microservices SDLC (examples: scaffold a new microservice, add secret, feature flag, lock deployments, add package version)
• Developer environments (examples: spin up developer environment for 5 days, ETL mock data to environment, invite developer to environment, extend TTL by 3 days)
• Cloud resources (examples: provision a cloud resource, modify cloud resource, get permissions to access cloud resource)
• SRE (examples: update Pod Count, update auto-scaling group, execute Incident Response Runbook automation)
• Data & ML (examples: train model, spin up remote Jupyter notebook, pre-process dataset, run Airflow DAG)

Manual approval and run logs

While self-service actions increase independence and efficiency of developers, certain critical processes may require oversight and approval from DevOps teams. In these cases, enabling manual approvals is crucial. Manual approvals require that developers ask for permission before taking certain actions, which helps ensure compliance over critical processes. 

For all actions developers take (whether or not they require manual approvals), run logs allow for visibility and enable them to detect and fix any issues easily – and understand the status of a long-running developer self-service action which is performed asynchronously. Run logs also make it possible to abstract the complexity that usually lies within the complete CI/CD pipeline log, providing a curated log of actions that a developer might actually care about.