How do you send email? (Mailgun)
I have AWS SES and Mailgun accounts -- I prefer Mailgun just because it's not in the AWS ecosystem, which scares me.
I've hired a few upwork folks to do some stuff for me, but I'm trying to figure out how to share credentials with them the proper/secure way - if that's even possible.
I was able to add one person as a dev role to my account - seems sane enough.
But another person I tried to add, Mailgun said "That user already exists."
Huh? I'm assuming that means, they (their email address) exists as a Mailgun user account. So I guess I can't add them or give them access to my account.
So then....should I just send them my private key? (which i think is all that is required to send email with Mailgun). Seems a bit strange. But maybe not.
Thanks for any ideas!
You can create another temporary email only for this project (preferable with your domain name ex:- [email protected] because you will have full control over that email, you can cancel, pause...etc) and give this email to devs.
You can create and share a domain sending key. That should be enough for sending, but not good for changing anything in the system.
It seems I was able to figure this out today and set it up after doing some reading and googling and verifying the account. Thanks.
...updating with some instructions for how to do it with the current mailgun interface. Prob mainly helpful for nocoders, and pseudo devs like me who hate dev.
https://www.awesomescreenshot.com/image/13438122?key=b890b71b9fd99d7993ed00d148dbd945
https://www.awesomescreenshot.com/image/13437777?key=a1f9d89ff955f3e10ddf2d65740afcca
We use SES for 95% of our transactional emails in our SaaS. We actually also use MailGun for a small sub-component of our stack. Both systems are great and have positives.
But as far as your quandary of sharing credentials, I would urge you to look at a system like EnvKey.com - we use them, and it makes bringing developers on board (and off boarding them later) a complete no brainer. They never see the actual credentials, and you can set up a set of developer, staging, production etc. credentials and share whichever is appropriate with them.
I wouldn't do any sort of remote development work with a team without it.
This sounds very interesting, thanks.
Hey Peter,
I wouldn't recommend sharing your private keys.
What's your goal? If you want your contractors to implement the feature that sends emails, either share the sandbox API key with them, or ask them to register a free account and use their sandbox keys.
Important here is that they should parameterise the application (environment variable, or configuration file), where you can then add your private key after or before deployment.
Does it make sense? Happy to follow up on this with you.
This makes sense, yes, but what if I don't want to have to go into any code or do much of anything?
That is, I want to do a deal with someone - let's say on Upwork - they build it, we all check everything off after it's delivered to my liking, then I want to be able to do minimal anything to have a fully-functional and just working.
I have to check out more of EnvKey.com, mentioned above, to see if that might do what I'm looking for.
There are a bunch of things like that regarding logistics that I felt like I could have used a simple guide for -- maybe I'll do that once I'm done with this next round of dev. It stemmed from a previous project of mine being fully delivered except for the non-functional email -- dev was using mailtrap or similar, which is fine-ish for dev, but I wanted a fully-functioning product/mvp, not a semi-functional one.
And from the dev's point of view, trying to chase down access and keys and whatever else is probably a maddening waste of time when you're trying to get things done and move onto the next gig/client/project.
I got your points, Peter.
Yes, in this case EnvKey is something to try out, should be convenient.