We can use dotenv files to manage different environment variables per stage. That’s a common approach to tackle this kind of situation.
Let’s say we deploy a service to two stages,
prod, additionally to a
local development environment.
This is our
# the name for the service (will be part of the service's HTTP endpoint)
# the cluster and stage the service is deployed to
# the file path pointing to your data model
# seeding your service with initial data
Notice that we’re using environment variables for the
secret properties. Now we can create a separate
.env file per stage, where we pass in different values.
This is how it could look like for my
This is how
.env for the
dev stage could look like:
# this is a fake cluster
And this could be my
# here, I chose the same cluster as for `dev`, but that's not required
You can then pass in the correct
.env file when deploying like so:
graphcool deploy --env-file .env # or --env-file .env.prod