Configure Strapi backend URL after build
a
ath88
Summary
It would be great to be able to configure the Strapi backend URL after the admin bundle has been built.
Why is it needed?
It will allow for a more flexible deployment, using the same build artefact for multiple deployments, when using separate URLs for backend and frontend, which we do. This will also make it easier to make a pre-built docker image.
Suggested solution(s)
I suggest making it possible to specify a URL where the backend URL can be fetched. On deployment, a file containing the URL could be placed on the specified URL, which will let Strapi determine the URL for the backend on initialization.
For example, the first thing the Strapi admin bundle would do could be a GET request to /backend-url which could respond with a URL to be used. Then on deployment, all we need to do is to deploy the backend-url-file along with the bundle.
A
Alex Sue
Any update on this? I'm looking into deploying Strapi, but run into this issue as well
R
Robbert
Looking forward to being able to use STRAPI_ADMIN_ prefixed environment variables at runtime so that we can deploy the same build to different environments.
v
vitali
also want this feature!!! people are deploying strapi on subfolders
Tjerk Haaye Henricus Dames
Rene Saare
AFAIK this is still an issue. I fail to understand why was there a need to compile this URL to the code in build time and not just set it as a variable so it could be changed at runtime.
Or why has this not been changed in over a year?
Derrick Mehaffy
Derrick Mehaffy
Merged in a post:
Enviromental Variables required at strapi build time
nharpa
Hello,
Several configuration variables are needed at build time. As far as I am aware, these are used in config/server/ & config/database. I am building a pipeline where on commit to the master branch on GitHub, GitHub actions build and push a docker image to a private registry and then post to a webhook triggering my strapi container to redeploy.
When using a CI/CD platform such as GitHub actions the build time variables are not always readily available Making those variables "hot-swappable" or triggering a rebuild when they have changed would allow them to be applied post deployment or when a docker image is reused.
My current workarounds include hard coding values &/or running build at container start time. Both of which work but have undesirable side effect.