Backstage Infrastructure: CBA practice questions

Backstage infrastructure is about how the platform is assembled and what it needs to run. The architecture overview splits it into three parts: core, the base functionality provided by the open-source project; the app, an instance of Backstage that an organization configures and deploys; and plugins, which add the features. The frontend is a client-side application that is a thin wrapper around a set of plugins, each of which usually owns a route such as /catalog.

Plugins differ in what they talk to. Standalone plugins run entirely in the browser without API calls. Service-backed plugins call a service that the organization operates, and third-party-backed plugins call an external service, for example a hosted CI system. To avoid browser CORS restrictions, calls to third-party services are passed through a proxy that Backstage provides.

The backend wires things together. Backend plugins operate independently of each other, and the documentation stresses that there can be no direct communication between plugins through code. The backend entry point is packages/backend/src/index.ts, where createBackend from @backstage/backend-defaults creates the backend, backend.add registers each plugin through a dynamic import such as import('@backstage/plugin-catalog-backend'), and backend.start runs it. Modules extend a single plugin, which must be installed in the same backend.

State lives in databases accessed through Knex, and each plugin gets its own logical database so it stays isolated and can migrate its schema independently. SQLite is mainly for development and testing, and PostgreSQL is the production choice, configured under backend.database with client pg and connection details supplied from environment variables. Plugins also get their own cache connection; memory is intended for local development, while stores such as Redis, Valkey or memcache are recommended in production.

Authentication is configured under auth.providers in app-config, with settings kept per environment and selected by auth.environment. Backstage ships providers including GitHub, GitLab, Google, Okta, Microsoft Azure, Auth0 and others. Sign-in must be configured in the frontend, with a SignInPage component that must yield a valid Backstage user identity, and in the auth backend, where sign-in resolvers map the external identity to a user; when several providers are enabled they must resolve to the same identity. Guest access helps when testing and is not meant for production.

The Kubernetes deployment guide shows a minimal production shape. It creates a backstage namespace, runs PostgreSQL with a Secret holding POSTGRES_USER and POSTGRES_PASSWORD, a PersistentVolume and claim, and a ClusterIP Service on port 5432. Backstage itself runs as a Deployment of the container image, which serves frontend and backend together on port 7007, with a second Secret for values such as a GitHub token, both loaded with envFrom. A Service maps port 80 to the pod's http port, and the guide leaves exposure outside the cluster to an Ingress or external load balancer. It also reminds readers that Kubernetes Secrets are base64-encoded, not encrypted.