Backstage Development Workflow: CBA practice questions

The development workflow covers creating a Backstage app, running it locally, configuring it and packaging it for deployment. The getting-started guide asks for an Active LTS release of Node.js, with 22 or 24 recommended, and Yarn 4 enabled through corepack, plus Docker and git. A new app is created with npx @backstage/create-app@latest, which asks for a name and uses it as the directory.

The generated repository is a monorepo. app-config.yaml is the main configuration file, catalog-info.yaml holds entity descriptors for the app itself, and the root package.json is not the place for npm dependencies. packages/app is the frontend and packages/backend is the backend that powers features such as authentication, the catalog, Software Templates and TechDocs. A dependency is added to the workspace that needs it, for example yarn --cwd packages/app add followed by the package name for a frontend plugin; backend plugins go into the backend package instead. New plugins are generated with yarn new.

Running yarn start in the app directory starts the frontend and backend as separate processes in one terminal; the frontend is served on http://localhost:3000, and the backend listens on port 7007. The out-of-the-box database is an in-memory SQLite database with demo content, which the guide says is not ready for production; PostgreSQL is configured under backend.database with client pg and connection values for host, port, user and password, typically read from environment variables such as POSTGRES_HOST.

Configuration loading has precise rules. Without any --config flag, app-config.yaml is loaded and app-config.local.yaml overrides it, which suits local secrets. If any --config flag is given, the default files are not loaded, and among the given files the last one wins. Objects are merged deeply, while primitive values and arrays are replaced as a whole, and an explicit null blocks the fallback to lower-priority files. Values can reference environment variables as ${VAR}, with ${VAR:-default} for a fallback, and if a variable is missing the whole value becomes undefined. $env, $file and $include read a value from a variable, a text file or a JSON or YAML file, and they are resolved only at startup. Single values can also be overridden with variables prefixed APP_CONFIG_, where underscores become dots, for example APP_CONFIG_app_baseUrl for app.baseUrl. Environment variables take priority over files.

For deployment the recommended path builds on the host and packages the result. yarn install --immutable, yarn tsc and yarn build:backend produce a bundle in packages/backend/dist, and docker image build . -f packages/backend/Dockerfile --tag backstage creates the image, with the repository root as build context. The container listens on 7007, and by default the backend also serves the built frontend through the app-backend plugin. A multi-stage Dockerfile that builds everything inside Docker is the alternative when Docker in Docker is not available, at the cost of speed. Before containerizing, set up a real authentication provider and PostgreSQL, since the guest provider is not intended for containers.