[Feature request]: Built-in environment-based visual indicator (Dev/Test/Staging/Prod) for Swagger UI

[mtivlishvili]

Is your feature request related to a specific problem? Or an existing feature?

Yes.

When working with multiple environments (Development, Staging, Production), Swagger UI looks identical across all of them.

This creates a risk of accidentally executing requests against the wrong environment, especially Production.

While this can currently be addressed using InjectStylesheet or custom JavaScript, it requires manual setup in every project and leads to duplicated configuration across codebases.

Describe the solution you'd like

I would like an optional, built-in way to indicate the current environment in Swagger UI.

For example:

• Display a small label or banner showing the environment (e.g. "Development", "Staging", "Production")
• Optionally allow setting a color (e.g. green, orange, red)
• Configure this via SwaggerUIOptions without requiring custom CSS or JavaScript

This feature would be opt-in and would not affect existing users unless explicitly enabled.

Additional context

No response

[martincostello]

I can see the utility for this, but I don't think it's something we'd want to maintain here because UX is something people can have a lot of opinions on and a million different ways they might want it it to look.

The UI with provide is intended to be the minimum possible UI. You should be able to achieve this yourself with the existing injection points and customise whatever you like, which is what those extension points were designed for.

If copy-paste across applications is a concern for you, you could distribute your own company-branded internal extensions to minimise that.

[mtivlishvili]

Thanks for the detailed explanation - that makes sense regarding keeping the UI minimal and flexible, and I appreciate the extensibility options that already exist.

I just wanted to share a bit more context from real-world usage. In practice, when teams work across multiple environments (especially in larger systems with many micro services), this becomes less about UI customization and more about reducing the risk of accidental interaction with production APIs.

While InjectStylesheet/InjectJavascript provide a way to achieve this, the need to re-implement and maintain this setup across multiple projects makes it harder to standardize consistently across teams.

I understand the concern around expanding the scope of UI features, and I agree that flexibility is important. From our perspective, this kind of indicator is often treated as a safety mechanism rather than a purely visual preference.

Additionally, adopting an internal extension approach would likely require creating and maintaining a shared internal package to ensure consistency across multiple services.

While this is a reasonable workaround, it introduces additional overhead and complexity compared to having a simple built-in configuration, especially in larger organizations.

Thanks again for the clarification and for maintaining the project.

[martincostello]

While InjectStylesheet/InjectJavascript provide a way to achieve this, the need to re-implement and maintain this setup across multiple projects makes it harder to standardize consistently across teams.

Sure, but if we were to add this capability, you'd need to upgrade every project using it and configure it (because it's opt-in), so the net result is the same (everything needs upgrading and configuring), except you've moved the ongoing maintenance burden of that customisation to us.

it introduces additional overhead and complexity compared to having a simple built-in configuration

The same here - it reduces the complexity for you by just moving it here to us.