Hi there.
Our team is using Doppler and love it - great product 
We are currently looking into setting up Github Codespaces - to make it really easy for new developers to get started.
But this made me think - how would you approach the Doppler integration? I came up with 2 ideas:
The normal flow
When the Github codespace is done setting up, a post-install script installs doppler. The new user will now have to run doppler login, and can now access secrets.
The automated flow
While setting up the codespace, the user is automatically logged in based on the Github profile token.
The automated flow would be so cool - because the user would not have to “understand” how/where, but could simply start coding. Would be amazing for freelancers.
Question
Is it somehow possible to build the automated flow - or is logging in a user simply not possible? Maybe there is a 3rd way I did not think about. A service token of some sort? Thanks for your input 
Hi @alexbjorlig!
With regard to getting the Doppler CLI installed – having a post-install script do it is probably the best way right now. I’m opening up a dialog with our product team to discuss getting an official Doppler dev container feature created that would allow you to specify that in your devcontainer.json file without having to worry about doing anything in a custom script. For now, we don’t have one though.
When it comes to the login flow – the only way to avoid a direct login via CLI by the end user would be to either set the token via doppler configure set token or by populating the DOPPLER_TOKEN environment variable with a valid CLI or Personal token for the user (you could also use a service token if this was for a specific project and environment). If neither of those will work for you, then I’m afraid the user will have to do a doppler login to get going.
Regards,
-Joel
1 Like
Hi @watsonian - thanks for such a great answer.
Do you think it would be possible to create a “freelance user”, and then have the codespace logged in with a token set by doppler configure set token?
Then if someone “converts” into a more long-term developer, they could have their own account for better audit trails?
@alexbjorlig You could probably get away with just using a service token right now for freelance developers that you have working on specific projects. Since Codespaces are oriented more around individual repositories anyways, you could set up a specific service token for that repo and the dev config and pre-populated that in the container. From an auditing perspective, anyone using that codespace would appear as the same user (from Doppler’s perspective), but it should get you going.
We expect to have a new “Service Account” feature out in the next few months that will also let you create service tokens with access to multiple projects and configs, so if you have freelance developers who work on multiple projects in the same codespace, that would work for them too when it’s out.
2 Likes
Hello! is there any update on getting a doppler integration for codespaces? using a service token (AFAIK) doesn’t plays well with how our stack is run with doppler run -- docker compose up to inject secrets in dev and doppler integrations in prod.
The only alternative that doesn’t require changing our dockerfiles looks like manually adding Codespaces secrets (please correct me if I’m missing something)
@Nick_Bradford We actually just looked at this recently. Adding a sync for this is something we want to do, but it turned out being a bit more involved than we’d hoped, so it’s still going to be a while yet before we get one out. In the mean time, using a Service Account token might work depending upon how you’re using Doppler in your Docker Compose setup. If you’re not using service tokens already, then I presume it’s being run with a CLI token on developer machines. In that situation, you’d already be having to specify which project and config is being used for your services, so a Service Account token would work fine there so long as it was added to the appropriate project+configs with read access.
If that won’t work for you and you don’t want to update your Dockerfile to use the other method we have documented, then one other option you might have is doing it “manually” via automation. For example, you could have a CI job that runs on-demand that manually syncs your secrets to Codespace secrets. You could then use webhooks to trigger those runs. Obviously not as convenient as just setting up a sync in Doppler, but it should be an option. Depending on how complex your setup is, this may be a viable solution.
1 Like
