Replies: 2 comments 1 reply
-
A couple things you could try to get around this. If using multiple destinations, you can use dedicated deploy config files for each: Like you've discovered, kamal doesn't pull from your
This way you can control what |
Beta Was this translation helpful? Give feedback.
-
I'm trying to avoid hard-coding the IPs on the deploy files
I'm not sure I follow, how should I then set the deploy.yml file for this to work? How do I 'tell' kamal that it needs to run dotenv for its other commands (deploy, redeploy, etc..) to work? |
Beta Was this translation helpful? Give feedback.
-
In kamal 1, having multiple destinations (default, production), I'd have something like this:
Then in the
.env
and.env.production
I'd have different values forSERVER_IP_ADDRESS
I'm having a hard time trying to replicate this on kamal 2.
If I include the
<% require "dotenv"; Dotenv.load(".env") %>
I can make it work for the default destination, but even if I add<% require "dotenv"; Dotenv.load(".env.production") %>
to the.env.production
I still end up with the value from.env
I've also tried getting it from the secrets: adding
SERVER_IP_ADDRESS
to both.kamal/secrets
and.kamal/secrets.production
, addingSERVER_IP_ADDRESS
under theenv.secret
key on thedeploy.yml
and trying to set it like:Yet that results with the literal string
'SERVER_IP_ADDRESS'
instead of the actual secret being used.What's the right way of doing this in kamal 2?
Beta Was this translation helpful? Give feedback.
All reactions