Determining the worker's environment context

Hello, I’m trying to figure out a chicken-and-egg problem I have with fetching configuration from within an edge process. I have a single app that I am deploying to multiple compute services for staging and production environments. When the process is running in the staging environment, I want to fetch config from the staging config store, and vice versa for the production environment. In order to figure out what environment I’m running in, I can’t store it in the config store b/c the program uses the environment to build the name the config store. There are environment variables for the FASTLY_SERVICE_ID, but not the FASTLY_SERVICE_NAME. So I could map those IDs to environment names, but that seems brittle because adding a new environment requires a code change to add the new ID mapping.

One possible solution is to always use a common name for the config store in every environment, then set the environment in there. But that makes the config stores confusing in the Web UI in a dangerous way.

I settled on injecting the environment name at build time via tinygo’s -ldflags argument, but this makes each package build environment specific.

Is there a standard way to lookup the executing context from within an edge worker?

On a related note, the REST APIs are designed to key off of IDs, while the Compute@Edge APIs key off of names. It feels like this inconsistency means I have to do extra work to get my application and resources configured correctly.


Hey Ben,

I agree with you that the ergonomics of this are not ideal. We are working on a better staging experience, and I’ve pointed that team at this thread so they can understand and factor in your use case - since you described it so well :slight_smile:

Meanwhile, I guess since you’re using a config store, one option is to create resource links on each service with the same name (eg. config), pointing to two different underlying config stores (config_prod and config_stage). I believe this use case is one of the reasons why resource links are designed in that way actually.