#How does backstage know what environment config to use?

73 messages · Page 1 of 1 (latest)

analog kindle
#

As per the title. I'm having an issue with EntraID/Azure authentication provider working. It says no configuration available for env=production in the URL. But the problem is this is my dev box and I know the app-config.yaml with dev is affecting it becaue I took out the guest provider.

On my prod app-config.yaml.production, it still has the guest {} provider in it's app config.

rustic rapids
#

Are you asking how does it know which app configuration file to use?

analog kindle
#

yeah basically.

rustic rapids
#

or how does it know which provider to use?

analog kindle
#

which app config file. cause its showing weird contradictory behavior.

my dev app-config.yaml doesnt have guest {} as a provider and its reflected in the sign on. But then it errors out on the Azure/Entra Provider saying non exists, but the pop up url has env=production which is confusing.

I have backstage deployed and configured with a private Gitlab instance currently. So trying to get it to work with Azure

rustic rapids
#

So right now how are you deploying backstage? Are you just using yarn start?

analog kindle
#

I do have a dockerfile and it has

CMD [
"node",
"packages/backend",
"--config",
"app-config.yaml", 
"--config",
"app-config.production.yaml"]

would this cause issues?

rustic rapids
#

So you’re deploying a backstage image?

analog kindle
#

I deploy it via pipelines in gitlab, it uses a docker image I build on gitlab

analog kindle
rustic rapids
#

OK, so whatever you’re building into the image, it will use in that order.. so for testing purposes, build an image with only a single active configuration file and look to see which configuration is using; it almost likely be exactly what’s in that file but if you’re passing it multiple, it’s a precedent so the last file is going to take. So if you have anything production in the last file or whatever it’ll take that.

#

Does that make sense?

analog kindle
#

Yeah that makes sense. I

#

I'll try that out. Didnt realize it just took the last config file

rustic rapids
#

You can also use yarn start and try to pass it the single file and see if that works. Typically people use the layer app configuration file so it can apply certain configurations to certain environments. So basically a base app configuration file and then it applies the production overlays, for example example. Or your development pipeline with apply the base configurations in the development overlays.

analog kindle
#

will it also just merge app-configs?

Cause now I realize I have configuration from both the app-config.yaml and app-config.production.yaml showing up in both environments

rustic rapids
#

Of course that’s what I mean. For example, your base configuration file can say use the guest authentication provider. But then in this production app configuration file use the GitHub authentication provider. So all the settings that were in the base configuration file, will apply and then when it finishes applying all the configuration files, it’ll say oh I changed the provider to GitHub because you passed me the production app configuration file:

#

yarn workspace backend start
--config app-config.yaml
--config app-config.local.yaml
--config app-config.dev.yaml

#

so locally, it will look like this

#

but you can just do the same thing your docker file and list the configuration file files in order

#

It’s best to test this stuff locally before you run it through the pipeline so you can iterate fast and not waste time

#

^ sorry that was my platform engineering self talking. I prefer my devs not to waste time lmao.

analog kindle
#

gotcha. yeah I want to do it locally but alot of the config relates to github org integration and the sign in is via our enterprise SSO. cant really test it locally but thanks ill have to test this out. I am definitely getting the multiple app configs mixed up unintentionally

rustic rapids
#

I mean, why couldn’t you test locally even with the enterprise SSO?

As long as you have the correct callback URL, client ID, and client secret, you can hit the enterprise SSO from your laptop just like I do with Keycloak. Backstage doesn’t need to run in a cluster for auth to work; it just needs valid OAuth credentials.

If you are afraid that you can’t get that information for your production enterprise SSO, then you need to create your own test version that’s set up the same way. Does it seem like a lot in the forefront yes. But this will allow you to test much faster than relying on a pipeline. We use like I said, key cloak internally and before I needed to run in the pipeline so I can have and connect to our key cloak OIDC. But I figure I can just build my own key cloak locally wire it up the same way reference that in my app configuration files and boom I’m testing locally fast faster.

So if you don’t know how to get that information then seek out the information and then build it locally yourself.

#

I’m also assuming you have that information in your production app configuration file? So build an image and then referenced that locally and you should be able to often just like you would after the pipe pipeline built it.

analog kindle
#

you wouldnt happen to know anything about the dockerfile provided by backstage on the tutorial/doc site? Im using that one.

cause i realize i dont have yarn workspace backendstart anywhere in my gitlab-ci or dockerfile

#

and it has node_env set to production

rustic rapids
#

yeah we built ours based on that with some mods...waht issue are you having

analog kindle
#

im thinking the popup from microsoft on no configuration available with a url that is suffixed with env=production stems from this

#

not sure if you're familiar with the Provider stuff, but when I manually change env=development I hit Microsoft and a 2FA check (So somerthing is working)

rustic rapids
#

what env are you changing? where is this at?

#

dockerfile or app config

analog kindle
#

I am testing on my development build but I think thats a misleading title. I suspect theres something wrong with how our dockerfile is setting it up.

On the dockerfile, theres a line taken from that doc link I sent you,

ENV NODE_ENV=production thats present even for development deployments.

So while testing Azure EntraID provider, I hit sign in using Entra and I get a No configuration available window pop up. I notice the URL in the pop up is ending in env=production

I manually change this to env=development and I copy/paste this into a blank browser and then I am seeing Microsoft auth being hit and a 2FA being asked. I fulfill the 2FA and get the screen about permissions using this app but thats a config issue on the EntraID admin side I believe

#

which leads me to believe and ask, should I be setting ENV NODE_ENV= to development for development deployments, in the dockerfile

rustic rapids
#

I see...do u actually have a app-config.production.yaml?

analog kindle
#

I do

rustic rapids
#

and u have a development 1 as well?

#

or just the app-config?

analog kindle
#

the development one is just app-config.yaml

#

the production one is app-config.production.yaml

rustic rapids
#

do u have the same auth provider stuff in each file?

#

or just the app-config?

analog kindle
#

we have some gitlab ci pipeline variables differentiating dev or prod but thats it and I believe theres nothing on the app level of backstage differentiating dev from prod

rustic rapids
#

so is the auth provider stuff ONLY defined in app-config then?

analog kindle
#

for entra, it is ONLY in the app-config.yaml and I see the backend and frontend sign in changes reflected in the dev deployment cause I see two sign in buttons now

rustic rapids
#

ok i see the issue, gathering my thoughts

#

So the issue isn’t the Dockerfile or NODE_ENV — it’s that your Entra/Microsoft auth provider config only exists in app-config.yaml but NOT in app-config.production.yaml.

When Backstage runs in Docker, it always loads the production config and the frontend requests:

/api/app-config?env=production

Since app-config.production.yaml doesn’t contain the Entra provider, Backstage returns “no configuration available,” which is why the Microsoft login popup fails.

When you manually change the URL to env=development, it works because that endpoint loads app-config.yaml, where the provider is actually defined.

You don’t need to change NODE_ENV — that part is correct.

Fix options:

  1. Move/copy the Entra provider config into app-config.production.yaml, or
  2. Consolidate everything into app-config.yaml and simply stop passing the extra production config file to the container.

If everything is in app-config.yaml, the backend will automatically use it for production without needing a separate app-config.production.yaml at all.

analog kindle
#

(Yeah, I think I messed up the delineation of dev and prod app-configs) We are still in development, we just have two end points we deploy to for the sake of development progress and allowing experimentation on the development endpoint. but im realizing now I need to fix this

analog kindle
rustic rapids
#

Yup, just let us know if you need anymore help. #BackstageCanBeUhBitch

analog kindle
#

ill be honest, I just wholesale copied the dockerfile from Backstage.io and edited maybe one or two lines

#

so i saw the NODE_ENV and figured "maybe this is the issue"

rustic rapids
#

^ u said it...ur in development..what else would u hav done

#

we all started there

analog kindle
#

haha thanks

acoustic lichen
#

There is env BACKSTAGE_ENV which can be used to select the correct config

#

No need to pass --config. I think it was introduced in 1.44 or 1.45 🤔

rustic rapids
#

^ hard sell since many have not upgrade that high yet and from the sounnds of it K def is not updated hahah (am i right?)

#

but yes u are correct

#

tbh i would just keep all that shit in app-config for developing and then when yall decide on what production settings, then seperate it.

#

KISS method until yall get more ramped up

analog kindle
rustic rapids
#

oh i know...i know

analog kindle
rustic rapids
#

upgrading shouldnt be that bad.. just test and make sure stuff works but it may break some custom themeing you might have if you do but everything else should be fine

#

dont turn that upgrade into tech debt if you dont have to

acoustic lichen
#

Oh yeah, try to keep up with upstream, it's getting harder and harder to update

analog kindle
#

will do. once I had gitlab auth and organization integration working, I got pulled to do something completely unrelated for months lol

#

now suddenly asked to do this EntraID Auth stuff

rustic rapids
#

i feel that