Hi
That issue was locked just now as it’s not considered a bug, but it is a design problem.
@DMehaffy It’s counter intuitive to have an environment variable only valid in build-time but not in run-time. What is more important, having configuration hard-coded instead of using actual environment variables goes against best practices. Take as an example the 12factor application:
Store config in the environment
An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes:
- Resource handles to the database, Memcached, and other backing services
- Credentials to external services such as Amazon S3 or Twitter
- Per-deploy values such as the canonical hostname for the deploy
…
As mentioned in some comments, building the application in a Continues Integration system and deploying the code to different environments will not work with Strapi, as it’s hard-coding the url value from config/server.js; even if it is being set to read the value from environment, as it is shows in the server documentation example. So this breaks the III of the 12factors application, which is a bad practice.
The result is that you end up with different code bases for each and all environments, which leads to many different sort of problems, such as it hinders debugging, or simply testing different configurations based on environment variables, or changing the domain name.
It would be very nice to have Strapi follow this practice and read such values from environment on run-time.
Thanks