Fully Managed Backstage
A fully managed backstage setup runs your developer portal as a hosted service. You link your code hosts and identity provider instead of running servers yourself. Engineering teams use this setup to skip tedious build pipelines and weekly upgrades. Still, teams often grant broad permissions to make portal plugins work fast. When a portal holds wide keys, any user can trigger risky backend actions. How a fully managed backstage architecture works Self-hosted portals force your platform team t
Managed Identities + Backstage Security Plugins: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A fully managed backstage setup runs your developer portal as a hosted service. You link your code hosts and identity provider instead of running servers yourself. Engineering teams use this setup to skip tedious build pipelines and weekly upgrades. Still, teams often grant broad permissions to make portal plugins work fast. When a portal holds wide keys, any user can trigger risky backend actions.
How a fully managed backstage architecture works
Self-hosted portals force your platform team to build custom code from source. You must run database servers, fix broken plugins, and patch software every week. A hosted portal removes this heavy operational work from your daily schedule. The vendor runs the core web app, the database, and the update cycle.
Your team still controls the software catalog and the daily user workflow. You link the hosted portal to your single sign-on tool for user login. Then you connect the portal to your source code hosts to read files. The portal reads metadata files from your code repos to build the catalog. It maps out which team owns each service, database, and cloud resource.
Next, you turn on plugins through a web view or simple text files. These plugins pull live status data from your build tools and cloud accounts. They also let developers create new software projects from pre-made templates.
Managing roles and plugin keys in your portal
To show live data, the portal needs keys to talk to your tools. You must give the hosted service API keys or cloud IAM roles. Most plugins use one shared service account to fetch data for all users. For example, the cloud plugin uses one role to read cluster status. Every developer who views that page sees data fetched by that single role.
The portal includes a native permission framework to control what users can do. Platform admins write rules based on user groups from the identity provider. You can let one team read catalog items while blocking another from edits. You can also restrict who can run project templates to spin up resources.
This setup works well for basic catalog views and simple project creation. Still, it creates a trust problem when plugins talk to live backend systems. The portal checks who logs into the web page at the front door. Once a user passes that check, the plugin uses its own shared key.
Managed Identities + Backstage Security Plugins: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native portal permissions solve and what they miss
A hosted portal solves the hard work of keeping the catalog app online. Native portal rules also control who can view pages or click template buttons. They help you organize software ownership without building a custom web app.
The gap appears when engineers need to run real commands or database queries. A portal is just a directory and a dashboard for your engineering team. It does not sit in the path of live database queries or commands. If a plugin runs a script, the target system only sees the portal key. Your cloud logs will not show which developer clicked the button.
Even worse, developers still need direct access to fix broken production systems. They leave the portal and log straight into databases or cloud servers. Portal rules only decide who views the catalog, not what live commands do. They cannot block a bad query or mask email addresses and card numbers. To secure live systems, you must inspect every command and query in flight.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between self-hosted and hosted portals?
Self-hosted portals require your team to write code, build containers, and run servers. A hosted service runs the core app and handles upgrades for your team.
How do hosted portals connect to private cloud networks?
Most hosted services use a lightweight agent that runs inside your private network. This agent sends metadata back to the portal without opening inbound firewall ports.
Can portal permissions secure direct database queries?
No, portal permissions only control what users see and click inside the web app. They do not inspect live database sessions or rewrite sensitive fields in results.