How to copy files in parent directory into app source directory
I have a monorepo, and one of my railway services is the frontend, which lives under my
/frontend directory
However, I'm storing encrypted environment vars in my repo using dotenvx. These are shared across the services in my monorepo, so they live under /.env.production
My build and start command look like this:
dotenvx run -f ../.env.production -- bun run build
dotenvx run -f ../.env.production -- bun run start
the issue is, since I'm using Railway nixpacks and have my root directory set as /frontend, the /.env.production file doesn't get copied into the app source directory.
Is there a way to copy this over?12 Replies
Project ID:
bde9c131-9e19-41c5-878a-7a26a99effb4bde9c131-9e19-41c5-878a-7a26a99effb4
There are ways you can likely do this through code. But it seems like you might want to use shared variables and refer to them in your different services (instead of a physical
.env file)@Joshie I made an explicit choice to use dotenvx. All of my secrets in these files are encrypted, ex:
and I simply set a single standard env var that lets me decrypt the rest of them. I find this easier to manage, and makes it simpler to share secrets with the rest of my team.
I do have one workaround for now, which is creating a hardlink from my parent directory .env.production file to the
/frontend dirAhhh yea, I forgot that dotenvx does encryption stuff
But it would be simpler if I didn't have to do this
Another option is creating a docker image for my app, but it would be nice if I could just set one piece of config and continue to take advantage of nixpacks
afaict from the docs, nixpack config only applies after the app source directory has been created by coping everything from my project root
There are a lot of things nixpakcs can't do. I personally switch to docker quickly.
But yea, there are some solutions I am thinking of; but none that come without some level of trade off. The solutions you have mentioned are likely your best bet (aside from storing your envs through railway, but understandable why that might not be desirable)
gotcha, thanks
quick question, why would storing your variables in railway might not be desirable?
I don't mean to answer for them; but one of the selling points to dotenvx, is that you can have people contribute to the secretes without actually knowing what they are. More like, "there are reasons to use dotenvx over platform variables" vs just "not desirable"
yeah that's one reason
Main thing is that it enables easier collaboration and avoids me having to log into each platform I use to configure env vars
let's say I start doing billing stuff with stripe. I can just add my encrypted stripe api key to the .env.development and .env.production files.
i commit those changes, and now my teammates can see and use those env vars without having to take action to pull them down from somewhere
I also have ci jobs running via Github actions. I don't want to set 10 env vars in both railway and github actions. Easier to just have those env vars in my code (encrypted ofc)
could also use something like GCP secret manager or Doppler, but I like that dotenvx is all client-side and lets me see what new secrets we're introducing in PR diffs
I assume dotenvx has some kind of accompanying web UI where you and your team mates get a single auth token so they can decrypt the variables with the cli?