Managing secrets in Backstage configuration starts with knowing where each token lives
Before you choose how to store a credential, list every token and secret your Backstage instance holds. A typical instance needs source control tokens for catalog discovery and scaffolder actions, client secrets for each sign-in provider, credentials for cloud APIs, and a database password for PostgreSQL. For each one, record which plugin reads it, which file references it, who issued it, what scopes it carries, and how it is rotated today. Teams often find the same personal access token copied into several places, or a provider secret that nobody has rotated since the first deployment. That inventory sets the scope of the work and tells you which tokens need their own owner and expiry date.
Backstage keeps these references in configuration files such as app-config.yaml, and the config loader can substitute environment variables into values when the process starts. With that pattern, the file names the variable and the running process supplies the value, so the committed file holds no plaintext secret. Two limits matter. The value still lives in the process environment and in memory, so anyone who can read the pod spec, container runtime or host process can see it. Also, substitution happens once at startup, so a rotated token needs a restart or redeploy to take effect. Confirm the exact substitution syntax, the fallback behavior for missing variables, and which config keys accept it against the current Backstage configuration documentation before you write your standard.
A dedicated secrets store becomes worth its cost when environment variables stop meeting your controls. Typical triggers are a requirement to record who read a credential and when, rotation that must happen without a redeploy, one credential shared across several services, or an existing enterprise store that your security team already operates. Before you decide, ask the platform team how secrets reach the pod, who can change them, and whether a failed sync blocks startup. Sign-in secrets need particular care: the Backstage authentication documentation expects every provider to resolve to one identity, so rotating a provider secret also means checking the sign-in resolver still works afterward.
Which secret pattern fits your Backstage deployment
Backstage reads credentials from app-config files, so the real decision is where each token value lives before it reaches the pod. The four patterns below differ mainly in who writes the value, how it is delivered, and which exposure remains after delivery. Compare them against your cluster, your GitOps practice and your rotation obligations before choosing.
Environment variable substitution
Config references such as ${GITHUB_TOKEN} are resolved from the process environment at startup, so the app-config file in source control holds only the placeholder. Whoever deploys the pod supplies the value, usually through a Kubernetes Secret or CI variable. It keeps tokens out of Git but does not protect them inside the pod: anyone who can read the container environment or run printenv in it sees the value. Check who can exec into Backstage pods and whether logs ever echo configuration.
Kubernetes Secrets with encryption at rest
A Kubernetes Secret is created by a platform engineer or pipeline and mounted into the Backstage deployment as a file or environment variable. Encryption at rest for etcd must be enabled at the cluster level, and access is governed by RBAC on the Secret objects. This protects stored values from casual reads of the datastore but leaves them readable by anyone with get secrets rights in the namespace. Confirm your distribution's encryption configuration and restrict who can read Secrets in the Backstage namespace.
SealedSecrets for GitOps workflows
SealedSecrets encrypts a Secret with a public key so the resulting manifest can be committed to Git and decrypted only by the controller inside the target cluster. The team that owns the integration token encrypts it, and the controller produces the plain Secret that Backstage consumes. It fits GitOps delivery well, but the key pair that decrypts sealed values becomes the most sensitive item to protect and back up. The value still exists in cleartext inside the cluster, so rotation means resealing and redeploying. Confirm how your team stores and recovers the controller's private key.
External secrets manager such as OpenBao or Infisical
A dedicated secrets manager holds integration tokens, issues access through authenticated machine identities, and can record versions of each secret. OpenBao, an MPL-2.0 fork of Vault, and Infisical, which is MIT-licensed outside its ee directory, both support Kubernetes-based identity. Delivery into Backstage typically goes through a sync operator or agent, so the platform team must operate that path too. The main risks are the availability of the manager and the security of its root and unseal material. Confirm which features your chosen edition or license covers before relying on them.
Choosing between the patterns
Most teams combine patterns: environment substitution for the application config, a Kubernetes Secret or SealedSecret as the delivery vehicle, and an external manager where rotation and audit demands exceed what Git and cluster RBAC can provide. Write down who creates each token, who can read it at each hop, and how a compromised token is revoked. A small team with one integration may not need an external manager. A regulated team that must show rotation history usually does. Ask your DeployOpen contact to map your token inventory against these four patterns during scoping.
Options for storing and injecting Backstage secrets compared
This table compares where each secret option keeps integration tokens, how Backstage receives them, and what rotation and audit work each one adds. Read each row against your own cluster and governance rules, because the right choice depends on who must approve secret access and who runs the store. The main takeaway is that environment substitution is the simplest start, while a dedicated store adds audit and rotation at the cost of another system to operate.
| Option | Where the value is stored | How Backstage receives it | Rotation effort | Audit trail | When it fits |
|---|---|---|---|---|---|
| Environment variable substitution | Process environment or the platform's runtime configuration | app-config references environment variables at startup | Manual restart or redeploy for each change | Limited to deployment logs unless you add your own tracking | Small installs with few tokens and strong control over the runtime |
| Kubernetes Secrets with encryption at rest | etcd, encrypted only if the cluster enables encryption at rest | Mounted as files or injected as environment variables into the pod | Update the Secret and restart pods to pick up changes | Depends on Kubernetes API audit logging you configure | Teams already running Kubernetes that can confirm encryption at rest is enabled |
| SealedSecrets | Encrypted in Git as SealedSecret resources, decrypted in the cluster | The controller creates a standard Kubernetes Secret that Backstage reads | Re-seal and commit a new value, then redeploy | Git history shows who changed the sealed value | Teams that want secrets in GitOps workflows and accept controller key management |
| Self-hosted OpenBao | Encrypted before writing to storage, under MPL-2.0 with community governance | Backstage or an operator fetches values through the OpenBao API with an auth method such as AppRole or Kubernetes | Automated through dynamic or rotated secrets, with leases revoked automatically | Audit devices record access if you enable them | Organizations that want an open-source store and can operate its HA and backup themselves |
| Vault Enterprise (licensed) | Vault storage backends, with Enterprise features such as replication and HSM support needing a license applied to the cluster | Same API integration pattern as OpenBao, with licensed features enabled on the cluster | Automated rotation, with licensing and sales engagement for Enterprise features | Audit devices and Enterprise controls, subject to your license terms | Organizations that already hold a license and need Enterprise features such as HSM or disaster recovery replication |
| Infisical (MIT core, self-hosted) | Encrypted store in PostgreSQL with Redis, deployed from Docker, Compose or the official Helm chart | Kubernetes operator syncs secrets into the cluster and reloads deployments, or an agent injects them | Secret rotation and syncs are available in the core, with dynamic secrets for supported databases | Event logging in the platform, with some enterprise features such as SSO requiring a license | Teams that want a managed-style dashboard, MIT-licensed core code and can confirm which features they need are enterprise-licensed |
| Hosted secrets service | Vendor-operated store under the vendor's terms and data location | Vendor SDK, operator or sync into the cluster | Depends on the vendor's rotation features and integrations | Depends on the vendor's audit export options | Teams that accept a third party holding secret material and have confirmed that contract and data location terms |
How to choose between an external secrets manager and Kubernetes Secrets
Start with the operating burden, not the feature list. Kubernetes Secrets are already in your cluster, so the first cost is encryption at rest, RBAC on the namespace and a rotation process that someone owns. An external secrets manager adds a service you must run, patch, back up and make highly available, and it becomes a dependency for every deployment that reads a token. If your team has no secrets manager today, the question is whether it can carry that load. For OpenBao, the storage choice shapes that load: integrated storage (Raft) is the path the documentation presents as the default, while PostgreSQL is described as easier to operate safely than Raft and is a supported HA backend. Confirm with your platform team which database service they already run and back up well before choosing PostgreSQL.
Next, decide how workloads will authenticate. A Backstage pod that reads its integration tokens from a vault needs an auth method that fits the platform. OpenBao documents Kubernetes and JWT/OIDC auth methods, and it recommends AppRole for servers, so a cluster-hosted Backstage would typically use the Kubernetes method. Check which method your cluster and identity provider support, and whether a human operator can read the same secrets. Also resolve licensing and support before you commit. HashiCorp moved Vault to the Business Source License 1.1 for releases from 1.15.0, and IBM now owns HashiCorp, so confirm the terms that apply to your use and to any Enterprise features you need. OpenBao is MPL-2.0 and community governed, and its migration guide was tested only against Vault 1.14.1 Community Edition, so ask for evidence before assuming Enterprise compatibility.
Finally, put the decision in writing. DeployOpen does not publish prices. A quote follows from a written scope that names the secrets manager, the HA design, the auth methods, the rotation procedure and who operates the system after go-live. Ask any partner, including us, to separate one-time build work from recurring support, upgrades and infrastructure. A scope that lists those items gives you a comparison you can defend to your CISO and to your auditors.
Setting up secrets for Backstage step by step
This sequence moves every integration token out of Backstage configuration files and into a store you control, so the app reads credentials at runtime and no secret is baked into an image, log or frontend bundle. Each step ends with a check you can run before moving on.
Inventory every token referenced in configuration
Search every app-config file, including the base file and any environment-specific overrides, for keys that hold credentials. Cover source control integrations, identity providers, catalog and scaffolder tokens, database passwords, cache credentials, backend signing keys and any notification or cloud access settings. Record each entry with the plugin that uses it, the owner who can rotate it and the identity it authenticates as. The step is done when the list accounts for every credential the running app uses, which you can confirm by comparing it against the integration settings in your Backstage version's configuration reference.
Separate secrets from non-secret settings
Split each config file into two groups: values that identify something without granting access, such as hostnames, organization names and feature flags, and values that authorize access, such as personal access tokens, client secrets and private keys. Non-secret settings can stay in version-controlled files. Secret values must never be committed, even in example files or commented-out lines. The check is a clean scan of the repository for high-entropy strings and key patterns, using a secret scanning tool your team already trusts, with no matches in tracked files.
Choose the injection method and secret store
Decide how values reach the running container. Environment variable substitution in config is the simplest option and works with any runtime that can inject variables. A Kubernetes Secret gives the cluster a native object, and enabling encryption at rest for the API server protects its stored form. SealedSecrets lets you commit encrypted values to Git, and an external secrets manager such as OpenBao or Infisical centralizes issuance and rotation. Record who administers the store, who can read values, and how an operator would revoke a credential. Confirm the store's audit and access controls with the vendor or your platform team before you commit to it.
Move values into the chosen store
Create each secret in the store, using a naming convention that maps one secret to one integration so rotation affects a single consumer. Restrict read access to the service account or workload identity that runs Backstage, and remove the plain-text values from your working copies and shell history. For Kubernetes Secrets, confirm the object lives in the Backstage namespace with limited role bindings. The step is complete when the store lists every secret from the inventory and a test read succeeds only from the Backstage workload identity.
Reference secrets by environment variable
Replace each literal value in configuration with a reference to an environment variable, using the substitution syntax documented for your Backstage version. Keep variable names generic and tied to the integration, for example a token variable per provider, so the config file stays readable and portable across environments. Map each variable from the store into the deployment manifest or container runtime. Confirm the exact substitution syntax and key names against your version's configuration documentation before relying on them. The check is that a rendered configuration, with secrets masked, shows variable placeholders and no literal credentials.
Verify startup and integration authentication
Start Backstage in a non-production environment with the injected variables and watch the startup logs for missing-variable errors or failed authentication to each integration. Confirm that each source control, identity and catalog connection returns successfully, and that an unset variable causes the app to fail clearly rather than fall back to an empty credential. Test one rotation in staging by replacing a value in the store and restarting the workload to confirm the new credential is picked up. The step is done when every integration authenticates and a deliberately removed variable produces a visible error.
Confirm no secret leaks into images, logs or the frontend
Inspect the built container image for embedded credentials by searching its layers and its configuration files. Check that logging does not print configuration objects or request headers that carry tokens, and review how your log pipeline stores startup output. Confirm that no secret is referenced in the frontend build, because values prefixed for browser exposure ship to every visitor's browser. Repeat the scan after each release. The check is a clean image scan, a log sample with no credential strings, and a browser-side review showing no token values in the delivered JavaScript.
Security risks to close when Backstage holds integration tokens
A Backstage instance usually holds tokens for source control, cloud, CI and catalog providers, so one leak can reach many systems. The risks below cover where those tokens can end up, how far they reach and who can read them, and each card names the check to run before go-live.
Secrets committed to Git
Integration tokens written directly into app-config.yaml or its production variant end up in version history, forks and CI logs, where they stay even after a later commit removes them. Keep only references to environment variables or secret files in committed config, and check the repository history for tokens that were pasted in during early setup. Review pull requests that touch configuration files, and rotate any token that has ever been committed, because deleting it from the current branch does not invalidate it.
Secrets echoed in logs and errors
Plugins and the backend can print configuration values, request URLs or failed API responses into logs and error pages, and a token placed in a URL query string is especially exposed. Ask each integration team which requests carry credentials in headers versus URLs, confirm log levels in production, and test a deliberately broken integration to see what the error page shows. Treat log platforms and support tickets as places where tokens may end up.
Plaintext Secrets without encryption at rest
A Kubernetes Secret is base64 encoded, not encrypted, unless the cluster enables encryption at rest for Secret resources. Confirm with the platform team that the API server encryption configuration covers Secrets, that etcd backups are encrypted, and that access to read Secrets in the Backstage namespace is limited to the service account that needs it. Ask who else can run kubectl get secret in that namespace.
Over-broad token scopes
A token created for catalog discovery often gets write or admin rights because the setup guide used a broad example. Each integration should use the narrowest read scope its plugin needs, such as repository read access for catalog import, and avoid organization-wide admin rights. Write down the scope granted to each token and compare it against what the plugin actually calls, then remove any permission the plugin never uses.
Shared credentials instead of per-purpose tokens
One service credential reused across the catalog, scaffolder, search and CI integrations means a single leak exposes every system at once, and rotation becomes a coordinated outage. Give each purpose its own token with its own owner and expiry, and record which Backstage component uses it. Confirm that rotating one token does not break the others, and that the owner can be reached when the token expires.
Secrets leaking to the frontend
Anything placed in a configuration key under the frontend section is compiled into the JavaScript bundle that every signed-in browser downloads, and the bundle can also be read by anyone who can reach the sign-in page. Keep integration tokens in backend-only configuration, and search the built bundle for token prefixes as part of the release check. Confirm that no frontend plugin receives a credential it does not need to call a service directly.
How to rotate integration tokens without downtime
Rotate integration tokens by adding the new credential before the old one is removed. Each token that Backstage uses to read catalog data, call a source control API or reach a scaffolder target should have a named owner, a documented scope and a rotation record. Start by issuing the replacement with the narrowest scope the integration still needs, for example read-only access to the repositories the catalog reads. Where the provider lets two tokens be active at once, as many Git platforms and cloud identity providers do, keep the old token valid while you roll out the new one. Confirm this behavior with each provider before you schedule the change, because some providers invalidate the previous token the moment a new one is created.
Next, write the new value into your secret store under a new version, then roll the Backstage deployment so the pods read it through the ${ENV_VAR} substitution in app-config.production.yaml. Environment variables are read at process start, so a plain config reload is not enough. Verify each integration after the restart: catalog processing for the affected locations, scaffolder actions that call the provider, and any backend plugin that uses the token. Only after those checks pass should you revoke the old token at the provider and record the change, including the date, the old and new token identifiers, the owner and the verification result. Keep the revocation as a separate, later step so a failed verification has a working credential to fall back to.
If your secrets manager issues short-lived or dynamic credentials, the runbook changes in two ways. The renewal happens in the manager, so the owner's task shifts from copying values to confirming that the lease or renewal process works and that Backstage picks up new values without a restart, which you need to test for your chosen integration. Rotation frequency is then set by the lease policy rather than a calendar entry. Before you adopt either model, ask your platform team which rotation interval they require for each token class, and confirm with the vendor of your secrets manager how renewal interacts with running pods. The Vault documentation and the OpenBao documentation describe lease and dynamic secret behavior in their own terms.
Limits to confirm before you commit to a secrets design
Several choices in a Backstage secrets design depend on details that change by version, edition and platform. The cards below list what to confirm with the vendor, the plugin maintainers or your own platform team before you commit to an approach.
Environment substitution per config key
Backstage lets you reference environment variables inside app-config.yaml, but not every key accepts substitution in every version. Check each integration key you plan to externalize, such as a token or client secret, against the configuration documentation for the Backstage release you run. A key that does not substitute will either fail at startup or be written in plain text into a file that teams commit. Test the exact key in a non-production instance before you standardize on the pattern.
Where each plugin reads its secrets
Some plugins read credentials from the shared config file, others from their own store or from a dedicated secrets interface. Before you design the flow, confirm with each plugin's maintainers which mechanism it uses and whether it logs or echoes configuration values in errors. A plugin that reads from its own store will not pick up a secret you rotated only in the environment, so rotation runbooks must cover each one separately.
Vault or OpenBao version and edition
Confirm which secrets manager version and edition your organization can run, and whether that edition supports the features your design needs, such as the auth methods, high availability backend or read scaling you intend to use. Enterprise features such as namespaces, seal wrapping and automated upgrades need a license on the cluster. The OpenBao migration guide was tested against a specific Vault community release, so verify compatibility with your own version before any migration. Ask the vendor for licensing terms in writing.
Infisical edition and self-hosting features
Confirm which Infisical features your self-hosted deployment will use and whether they require enterprise licensing. The vendor's self-hosting documentation states that items such as SSO and gateways need an enterprise license, and the repository uses a separate license for its ee directory. Check that your intended Kubernetes operator and machine identity methods are included in the edition you plan to run, and get the terms for each in writing before you rely on them.
Encryption at rest on your cluster
A Kubernetes Secret is only base64 encoded by default, so encryption at rest must be enabled on the API server through an encryption configuration, or on the managed control plane through your provider's option. Ask your platform team whether this is on, which key provider protects it, and who can read the etcd backups. Sealed or externally synced secrets still end up as Kubernetes Secrets unless the workload reads them another way, so this check applies to every pattern you pick.
Audit requirements and Enterprise features
Decide which events your auditors need to see, such as who read or rotated an integration token, and confirm whether your chosen secrets manager records them in its base edition or only in an Enterprise tier. Ask the vendor which audit devices are available, where logs are stored, and how long they are retained. If the requirement depends on an Enterprise feature, include that license cost and its approval in the design before the build starts.
Questions teams ask before managing Backstage secrets
What does managing Backstage secrets cost, and how is a quote built?
A quote follows from the written scope, because DeployOpen does not publish a price list and most engagements are fixed-scope. The main cost components are the design of where each token lives, the setup of the chosen secrets path (environment variables, Kubernetes Secrets with encryption at rest, SealedSecrets or an external secrets manager), the rewiring of each integration, and testing that the portal still signs in and reads its sources after the change. Costs rise with the number of integrations, the number of environments, and whether a secrets manager must be deployed from scratch. Ask for the quote to list each deliverable, what is one-time work, and what is an optional retainer for rotation. Backstage itself carries no license fee under Apache-2.0, so the cost is in the work and in any tooling you choose.
How long does Backstage secrets setup take, and what drives the duration?
Duration depends on the scope agreed in writing, so no fixed timeline applies across all portals. The largest drivers are the number of integration tokens (source control, identity directory, cloud accounts, CI systems), whether your cluster already has an encryption-at-rest configuration you can confirm, and whether a secrets store must be installed and hardened first. Teams that already run a secrets manager usually shorten the work because the main task becomes mapping each token to a path and an owner. Plan for review cycles with the people who own each credential, since they must approve scopes and confirm revocation. Ask the vendor for a schedule that shows which tasks depend on access you have not yet granted.
What does the client team need to provide for this work?
The work needs three kinds of input from your side. First, cluster access with permissions to create Secrets, deploy controllers and read deployment specs in the namespace where Backstage runs. Second, a named owner for the secrets store, who approves policies, unseal or key procedures and audit access. Third, token owners for each integration, who can create or scope tokens in GitHub, GitLab, Azure, your identity provider and other systems. Confirm early who holds the root or admin credentials for each platform, because those people must act during cutover. Missing owners are the most common cause of delay, so name them before the scope is signed.
Can our own team manage Backstage secrets without a partner?
Yes, a capable platform team can do this alone, and the decision depends on skills and capacity rather than on Backstage itself. Your team needs working knowledge of Kubernetes Secrets, encryption at rest in your cluster, and the chosen secrets approach, plus the discipline to rotate tokens and test revocation. If you choose an external secrets manager such as OpenBao, you will also need to operate its high availability, storage backend and auth methods. A partner adds value when the team lacks these skills, when deadlines are fixed, or when an independent review of the design is required. Whichever path you take, document each token, its owner and its rotation procedure so that the knowledge outlives the project.
Is Backstage free, and do the secrets tools carry license terms?
Backstage is released under the Apache License 2.0 (Apache-2.0) and the project offers no paid edition of its own, so the framework itself has no license fee. The secrets tooling is separate and can carry different terms. HashiCorp moved future Vault releases to the Business Source License 1.1, and OpenBao is a community fork under MPL-2.0. Infisical's repository is MIT Expat except for content in any ee directory, which uses a separate license, and its enterprise features such as SSO or gateways need enterprise licensing for self-hosting. Read the license file for each tool you adopt, confirm whether the features you need are community or enterprise, and have legal review any restriction on hosted or embedded use before you commit.
How much rotation effort recurs after launch?
Rotation is recurring work, and the effort scales with the number of tokens, their lifetimes and how many systems read each one. Each integration token needs a scheduled replacement, a check that Backstage picks up the new value, and a revocation of the old one. Dynamic credentials reduce the manual share, because the secrets manager issues short-lived values instead of static ones, but they add operational work to keep the issuing backend healthy. Ask for a rotation runbook as a deliverable, agree which tasks your team owns and which a retainer covers, and budget time for the first rotation cycle, since it tests every step. Record the cadence for each token in your catalog so audits can see it.
What should an engineer check after moving tokens out of app-config files?
Start by confirming that no secret remains in any committed app-config file, in container images or in build logs, and that the running pod reads values only from the intended source. Then verify that each integration still authenticates, that the catalog ingests from each source, and that sign-in works for your identity provider. Test one rotation end to end: create the new token, update the secret, restart or reload Backstage, confirm the portal works, and revoke the old token. Finally, check that access to the Kubernetes Secret or secrets manager path is limited to the Backstage service account and to the people who administer it.
Does DeployOpen guarantee that the secrets setup will pass an audit?
DeployOpen does not guarantee audit outcomes and does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. DeployOpen can prepare the system, the controls and the evidence, such as token inventories, rotation records and configuration diffs, so that an auditor can test them. Ask your auditor which evidence they expect for secrets handling before the work starts, and agree that evidence list as part of the written scope.
Official sources for Backstage and secrets tooling
Start with the Backstage authentication documentation before you decide where any secret lives, because sign-in configuration decides which identities can reach the integrations that need tokens. The Backstage authentication documentation explains how sign-in resolvers should map every provider to the same identity and why guest access should not be offered in production. Read it alongside your app-config.production.yaml file to confirm that the token-bearing integration settings are reachable only by the identities you intend to allow, and to record which resolver each provider uses.
Next, compare secrets backends against your own operating model. The OpenBao storage documentation lists integrated storage (Raft), PostgreSQL, PebbleDB and in-memory backends, and notes that PostgreSQL is easier to operate safely than Raft. The OpenBao auth methods documentation describes AppRole, JWT/OIDC, Kubernetes and other methods, and recommends AppRole for servers. Confirm with your platform team which methods your Backstage backend can authenticate with, and whether your Kubernetes cluster provides the identity the pods need.
The Infisical self-hosting overview covers deployment options, including the Helm chart and reference deployments, and states that features such as SSO or gateways need enterprise licensing. Before choosing it, check that license terms match your use. For Vault, the Vault storage documentation explains that integrated storage and Consul are the officially supported backends, while external backends have limited support. Treat these pages as the source of truth for support boundaries, and verify version-specific behavior against the release you plan to run.
How DeployOpen scopes and delivers Backstage secrets management
DeployOpen approaches secrets in Backstage as a scoped engagement: we inventory every token the portal uses, choose a secret source your organization can operate, and wire it into the configuration without leaving credentials in app-config files. The work is planned in writing before any change is made, and it is delivered into infrastructure you control.
How we scope
- Inventory every integration token, database password and signing key that the Backstage configuration references today.
- Agree in writing which secret source fits your environment, such as Kubernetes Secrets, SealedSecrets or an external secrets manager.
- Define the rotation owner, rotation cadence and the teams that must be notified when an integration token changes.
- Record the scope, deliverables and timelines in a written statement of work before work starts, since most engagements are fixed-scope.
How we build
- Replace hard-coded values in app-config files with environment variable substitution wired to your chosen secret store.
- Configure encryption at rest for Kubernetes Secrets or the chosen external store, and confirm access is limited to the Backstage workloads.
- Test that the backend starts, each integration authenticates and no secret value appears in logs, the catalog or the frontend bundle.
- Build the token rotation procedure and run it once in a non-production environment so the steps are verified before handover.
How we hand over
- Document where each secret lives, who can read it, and how each integration consumes it at runtime.
- Provide a rotation runbook with step-by-step instructions for each integration token and the rollback steps if a rotation fails.
- Walk your platform and security teams through the configuration so they can add new integrations without reintroducing plaintext values.
- Deliver the configuration and documentation into your own repositories and infrastructure, so your team owns the result.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering secret store changes that follow Backstage upgrades.
- Review new plugins and integrations for secret handling before they are added to the portal configuration.
- Confirm with your secret store vendor or project the supported versions, licensing terms and features your deployment depends on before each change.
