9 months ago
I'm currently experimenting with NextJS environments and environment variables, and I’ve encountered an issue with Docker images pulled from a container registry (ghcr.io) not picking up the environment variables correctly.
I have two scenarios:
One where the project is cloned directly from the repository.
Another where the image is built using a GitHub workflow and then placed in ghcr.io.
In the first scenario, where the project is cloned, everything works as expected—the environment variables defined in Railway.app are successfully picked up. However, in the second scenario, where I use the Docker image from ghcr.io, the environment variables are all undefined.
I’d like to share the repository with you so you can take a look and possibly help me figure out what’s missing to get the second scenario working properly.
The repo: https://github.com/romelgomez/next-envs
5 Replies
9 months ago
Hey there Romel,
You will need to source the env vars into the docker image like so:
```
ARG RAILWAY_VAR
ARG RAILWAY_VAR_2
```
Doing so helps expose to the Docker daemon that you want to source the variables at build time.
Status changed to Awaiting User Response railway[bot] • 9 months ago
9 months ago
Hi angelo
Thanks for the quick reply. Do you have any example repositories I can check?
I made these changes, but still no luck.
https://github.com/romelgomez/next-envs/commit/df80420633b875e0495c6c0385d7b52d6ccce558
Status changed to Awaiting Railway Response railway[bot] • 9 months ago
9 months ago
Your build requires environment variables to be set at build time, Railway does this for you, but have you set the needed variables in GitHub where you build your image?
Status changed to Awaiting User Response railway[bot] • 9 months ago
9 months ago
Yes, I've defined them in the GitHub environment interface.
However, I'm not sure if I'm approaching this the right way. I recall seeing something similar in other projects using GCP, where we had an env file that was copied into the Docker build.
I'm wondering what the best production approach would be—something that’s secure, ready for distribution, and ensures that even if the Docker image were to be leaked, it wouldn’t be a problem because the secrets and environment variables are defined within the service, like Railway variables
I imagine something a flow like this:
Commit: Code changes are committed to the repository.
GitHub Workflow: The workflow in GitHub triggers automatically. Then it’s deployed to GHCR: The Docker image is built and deployed to the GitHub Container Registry (GHCR).
Cloud Service: The cloud service picks up the image and injects the necessary secrets and environment variables.
I have this working now, which is not looking so cool like the other one.
1. Commit: Code changes are committed to the repository.
2. Cloud Service: The cloud service picks up the repository update, build the image and injects the necessary secrets and environment variables.
What are your thoughts?
Attachments
Status changed to Awaiting Railway Response railway[bot] • 9 months ago
9 months ago
Hey Romel,
To be honest, I or the team won't be able to give you a final call there. They have trade-offs. Railway, although using OSS and standard primitives, a deployment on our platform will have some if not all features that will require Railway to use (like our variables management)
If you wanted to redistribute your work like for a guide: you should consider using a template. For GHCR/GitHub workflow, that's a bit hard to distribute.
End of the day it's your call. We are just happy to host your workloads.
Thanks,
Angelo
Status changed to Awaiting User Response railway[bot] • 9 months ago