The "Ticket" Problem
Even after a service is running, developers need to perform operational tasks:
- "I need to restart a stuck Kubernetes pod in staging."
- "I need temporary read-access credentials for the production database to debug an issue."
- "I need to check the build status of the latest commit."
- "I need to roll back the last deployment."
Traditionally, these required filing a Jira ticket with the DevOps/SRE team and waiting hours or days. This creates a bottleneck: the platform team becomes a human API, manually executing commands that could be automated.
The Plugin Architecture
The real power of Backstage lies in its Plugin architecture. A plugin is a self-contained React frontend (and optionally a Node.js backend) that integrates a third-party tool directly into the portal's UI.
Instead of opening 10 different browser tabs for Jira, Jenkins, the Kubernetes dashboard, and Datadog, a plugin surfaces that data directly on the service's page in the Backstage catalog. When a developer opens the payments-api page, they see:
- The last 5 CI/CD build statuses (GitHub Actions plugin).
- Current Kubernetes pod health and replica count (Kubernetes plugin).
- Open incidents (PagerDuty plugin).
- Recent deployments (Argo CD plugin).
All in one place, all scoped to that specific service.
Self-Service Actions
Plugins also enable Self-Service Actions — buttons in the UI that trigger real operations on the backend platform. A developer can click "Restart Pod" and the Backstage backend plugin securely calls the Kubernetes API to perform the restart. No ticket. No waiting. No context switch.
The critical design principle here is guardrails, not gatekeeping. The platform team does not remove the ability to restart pods — they make it safe and auditable. Every self-service action is logged, scoped to the right permissions, and available to the right teams. The developer gets speed; the platform team gets auditability.