Doppler is without a doubt my favorite secrets management platform

secrets. We've all got them. Uh some more than others. In my case, I tend to have quite a few. Uh most of which are found inside of my deployed applications. Now, whilst there's nothing wrong with having a lot of secrets, uh when it comes to managing them, this can sometimes be a little more tricky. The most common way of managing these, at least when it comes to local development, is to make use of AEMV file, which allows you to store your secrets mapped to an environment variable that your application can then use. Whilst EMV files are a great solution when it comes to local development, they're not exactly what I would consider to be perfect. In my case, I find that once you need to work with multiple developers or work across multiple machines, then sharing up-to-date files can start to become quite challenging, especially if you happen to have a highly agile team. Additionally, they're not much use when it comes to application deployment, requiring you to manually add these secrets to wherever your application is deployed, meaning that you end up no longer having a single source of truth. This becomes more complex if you need these secrets to be shared across multiple services, uh, different environments or CI/CD pipelines. Just ask anyone who's ever needed to rotate secret that's shared across different services. Oo, scary stuff. Now, there are some solutions out there that can make managing secrets a whole lot easier. These are named secret managers and include products such as AWS Secrets Manager and Hashi Corp Vault. However, I find that these don't tend to have the best developer experience. And whilst they do work well for production services, they tend to be lacking when it comes to local development. Fortunately, there is one secrets manager out there that works well for both use cases. one that allows you to have a single place to store, manage, and sync all of the secrets for a given project, whether it's for local development across multiple machines, different test environments, CI/CD, and of course, deploying an application to prod. That solution is Doppler, which is without a doubt my favorite secrets management platform. One that I have been using now for the past couple of years. not only providing solutions to all of the above problems, uh, but it also provides features when it comes to managing secrets that I didn't even know I needed. Some of these include the ability to run a project locally, injecting secrets from either your development or even production environment without needing to use av file, the ability to sync secrets across multiple different services, including cloud platforms such as for sale, railway, or netifi, Kubernetes clusters thanks to its fantastic Kubernetes operator, other secrets management platforms such as the ones I mentioned earlier, and even CI/CD pipelines such as GitHub actions. Not only this, but Doppler also provides a number of other features as well, such as audit logging for any changed secrets, automatic secrets rotation, the ability to reference secrets, and perhaps best of all, the ability to add your own automations so that you can be notified whenever a secret is changed, or as I like to do in my case, add my own integration to a system that Doppler doesn't natively support. All of this, in my opinion, makes Doppler not only a secrets manager, uh, but instead a full-blown secrets management platform, allowing you to achieve pretty much anything you might need when it comes to managing secrets. So, how does it work? Well, before I show off some of these features, as well as how I like to use Doppler when it comes to my own workflow, uh, let me give a quick disclaimer. This video is not sponsored by Doppler and I have no working relationship with them. I'm just a happy customer who's used the product now for over 3 years across various different companies and have been paying for it now or my own company for just over 12 months. Therefore, this video is entirely my own thoughts and experiences. That being said, I did reach out to Doppler just over a year ago to see if they wanted to sponsor a video. Uh, but they came back and said no. Fortunately, you don't have to feel too sorry for me as I did find a sponsor for this video so I can actually get paid. That sponsor is Hostinger, who I'll talk more about later on when we look at how I like to use Doppler when it comes to my own VPS deployments. Okay, with the disclosures done, let's take a look at some of the ways that I find Doppler improves my workflow. Uh, beginning with local development. To do so, here I have a simple Go CLI application that connects to a Postgres database and returns the number of rows found inside of the user table. In order to connect to the Postgres database, the application does so using a connection URI which is obtained from the environment variable called database URL. This is a pretty common pattern when it comes to most applications that connect to a database. Therefore, before we look at how to set this environment variable using Doppler, let's take a minute to look at some of the more typical approaches one might take. So the first of which is to just set the environment variable of database URL directly either in the current shell session using the export keyword on bash/zshell or when invoking the application. Whilst this works, it's not exactly the most convenient approach. For starters, one has to set this every time a new shell session is invoked, which can be pretty tedious if there's a lot of different secrets. And additionally, if this is done incorrectly, then this secret can be accidentally written into one's shell history, which is absolutely something one should not do. Therefore, a much more convenient and secure approach is the one that I mentioned before, which is to store this inside of av file using the following format. Setting first the variable name and the value you want to assign it to. However, just setting this by itself uh won't actually do anything. Instead, you need to add in some way for this to be loaded by the application during runtime. In Go, this is easily achieved by either rolling it yourself or by using the joo/go.v package as follows. Additionally, you also need to make sure to not accidentally commit this file into your applications repo, which can be achieved by adding in the following line into your.getit ignore. Whilst this approach of using av file is far more convenient than explicitly setting the environment variables, it doesn't work that well when it comes to needing to share these secrets with other developers or across other machines or to use them for application deployment. Therefore, let's instead take a look at how we can use Doppler for injecting secrets into our application when running it locally. To do so, the first thing we need to do is to configure a new project inside of Doppler. Now, just a note, normally I would use the Doppler CLI to do this in my own workflow. However, for this video, I'm instead going to go ahead and make use of the web UI, mainly because it's slightly easier to see what's actually happening compared to just CLI commands. Therefore, to begin, first we can head on over to the Doppler website at doppler.com, which will open up my personal dashboard with all of my projects inside. To add a new project in Doppler is as simple as clicking the following plus button, which brings up a dialogue where we can add in the project's details. Upon doing so, I'm now presented onto a screen which contains my two initial environments, dev and prod. In my case, I've actually configured my Doppler workspace so that these are the only two environments that are created when a new project is. But by default, Doppler will actually create three with the other one being staging. I'll explain how one can configure this behavior later on in the video in case you want to add your own environments or you also want to remove staging yourself. For the meantime, however, let's go ahead and add in a new secret into our dev environment called database URL. As for the value of this database URL, well, I'm going to go ahead and branch an existing database in Neon uh my Postgres provider with anonymized data. And then I can just copy and paste this URL into my environment variables value. With that, the Doppler project is now configured and I can make use of it with the Doppler CLI. To do so, you first need to install the Doppler CLI on your machine, of which the documentation provides instructions depending on which operating system that you're using. Once installed, you'll then need to authenticate it using the Doppler login command, which will initiate a device flow. With the CLI added and authenticated, we can now make use of it to inject our secrets into our application by calling the Doppler run command. followed by passing in the name of the project that we just created using the -p flag and the environment or configuration using the - C flag which in this case is dev. Then in order to specify the command that we want Doppler to actually run we use dash followed by the actual command uh which in this case is gorun dot. Now when I execute this command, you can see it's working and the application has managed to connect thanks to Docker injecting the database URL for us. Now you might be thinking this is way more steps than using AEMV file. And sure, for a one-off configuration, you're absolutely right. However, now that we have the project set up, we can use the Doppler run command in other ways that's not as easy when using av file. For example, let's say I want to access this database directly using psql rather than having to copy the URL string in from inside thev file and then pasting it into the actual command which again could be accidentally written to my shell's history. I can instead just use the doppler run command. Uh this time with the following bash command which will allow us to access the database URL environment variable that doppler injects. Now, as you can see, I've connected to my database and can run queries on it. Very cool. Not only is this more secure, but it also improves my workflow when it comes to working with other developers or across different devices. For example, here I'm sshed into another machine that has a freshly cloned project. However, rather than needing to build or copy over av file from another machine, which depending on how it's done, could again be a security concern, I can instead just use Doppler on this machine to access the same secret. This is because each secret found inside of an environment is shared across all members of your team, making it really simple for others to get set up with their own local development. However, there is a situation where you may want to have a different secret than what's configured inside of your Doppler project. Uh let's say you want to be able to test with your own database credentials, but you don't want to modify the dev environment and change it for everyone else. Fortunately, Doppler also provides the ability to set up a personal environment, which can be used to override any of the variables from the parent environment it's derived from. For example, here you can see I have a personal dev environment where I can go ahead and change the database URL and it won't affect the main configuration. Then in order to use it on the CLI with the Doppler run command, I can replace the dev environment with my personal dev one instead. Very cool. Personally, I find the Doppler run command is incredibly useful when it comes to local development. But you might be thinking, what happens if the Doppler service goes down? Well, fortunately, if this ever did happen, Doppler falls back to using a cached but encrypted secrets file, meaning that you can still use it even if the service is offline. If that doesn't reassure you, however, then fortunately, there is another option in that the Doppler CLI allows you to generate av file containing all of the secrets from a project using the following command. This basically means you can still use your existing workflow of EMV if that's what you prefer. One thing to mention is that if you happen to have a lot of environment variables already defined inside of a EMV, then Doppler allows you to easily import all of these in using either the import secrets functionality of the web UI or as I prefer to do by using the secrets upload subcomand of the CLI. Personally, however, I tend not to use files and prefer to use the Doppler run command. But there's no denying that having to specify both the project and configuration each time when doing so is kind of tedious. Fortunately, Doppler provides a solution through the Doppler setup command where we can specify a default project and configuration for the current directory. Meaning we no longer have to use these flags unless we want to override these configured defaults. With that, we've managed to cover some of the ways that I like to use Doppler as well as some of the benefits of doing so when it comes to local development. Next, let's take a look at how I like to use it when it comes to production application deployments. In order to use Doppler to manage secrets for production deployments, there's again a couple of different approaches one can take. The approach that I personally like to take is to use service synchronization, which is where Doppler will automatically sync your secrets as environment variables to a number of different deployment platforms, including Versel, Netlefi, Railway, and many others. Whilst I personally don't use these platforms, there is a large number of people that do. So let's take a look at how we can achieve this using Doppler. However, before we can set this up, we first need to define some missing secrets for our production environment. Again, I'm going to go ahead and do this using the web UI. But as I mentioned before, I would typically do this using a CLI based workflow. Uh, by the way, if you want to see my typical CLI workflow for a project from start to finish, then let me know in the comments down below and I'll draft up a video on it. To set up the production secrets, we first need to head on over to the production environment inside of our Doppler project where we can see it has the database URL secret already added, but with an empty value. This is yet another great feature of using Doppler when it comes to different environments, as it makes it really simple to see which environment variables or secrets are missing on each environment when developing or deploying. To set the value of the secret, I'm just going to go ahead and paste in my production database URL into the following field before clicking save. Okay, with the production secret now added, we can go ahead and sync it to our deployment platform of choice. As for which platform this is, well, that's going to depend on which one you prefer. However, they all share a pretty similar process. So, to get started, you first head on over to the synchronization page or the syncs page by clicking the following button, which will display any current synchronizations that you may have configured. To add a new one, you begin by clicking the add sync button, which will display a grid of all of the different platforms that Doppler has an integration for. To show what setting one of these up looks like, let's take a look at how to do this using Versel, which I'm assuming is probably the most popular one on this list, although I could very well be wrong. Uh, let me know in the comments down below. To add an integration to First Cell, you first click create new connection or you can reuse an existing one if you happen to have one already. Upon doing so, it will then prompt you to add the Doppler integration into your Versell account. Once it's done, you can then configure the rest of the integration. uh beginning with selecting the team on Versell, followed by the actual project. In my case, I only have one of each. Next, we can then select the Versell environment that we want secrets to be mapped to, followed by the Versell variable type. In my case, I'm going to set this to be encrypted, as I want these to be secure. Next, we specify the Doppler config that we want to sync to this FEL project/ environment. Uh, which in my case, I'm going to go ahead and sync prod. And then lastly, we can select whether or not to import existing environment variables from Versel. Because this is a new project, then I'm going to select do not import. Although this is a really useful feature if you're migrating to Doppler and have a bunch of secrets already kept inside of Versel's environment. With that, the configuration is now complete. And we can go ahead and click setup integration. With the integration set up, we should see an indicator letting us know that Doppler is syncing. Then once it's complete, we can check the environment variables in the versell project and see that the database URL has been set alongside a couple of other variables that Doppler uses as metadata. To test that the live synchronization is working. If I go ahead and modify the database URL secret in Doppler as well as adding in a new one, when I click save, we should see both of these changes be synchronized again to versel, which I can confirm that they are. As we saw, Doppler supports many different integrations with various different platforms out of the box. Uh, but what if you're like me and you happen to use a platform that Doppler doesn't natively support. In my case, I currently have the majority of my applications deployed using Docker through Doc Ploy running on a VPS instance. Which means in order to achieve this synchronization with Doppler, I need to set up an automation. Before I go over what that automation looks like, let me first quickly talk about both my VPS provider and the sponsor of today's video. Hostinger. Hostinger specialize in providing high resource long-term VPS instances at an incredibly affordable price. Take for example the KVM2, which is the VPS instance size that I use when it comes to my own production applications. The KVM2 comes with two vCPUs, 8 gigs of RAM, 100 GB of SSD storage, and a massive 8 TB of monthly bandwidth, making it extremely capable when it comes to deploying applications or even just self-hosting your own services. In my case, I have not only nearly all of my production services running on the KVM2, but I've also been using it for other systems such as N8N when it comes to automations and other self-hostable products, all of which can be deployed through simple Dockloy templates. As I mentioned before, all of this comes at an incredibly affordable price, as the CVM2 is available for only $7.49 a month uh when you purchase a 24-month term, making it an extremely affordable long-term option. If that wasn't good enough, however, you can actually get this price even lower by using my coupon code dreams of code when you check out, which will get you an additional 10% off the already low price. So, to get your own VPS instance to either deploy your own applications or to self-host your favorite services on, then visit hostinger.com/dreamsofcode. And make sure to use my coupon code dreams of code when checking out to get an additional 10% off the already low price. A big thank you to Hostinger for sponsoring this video. Okay, so when it comes to my own application deployments through the use of Docker, how do I manage to use Doppler with them? Well, again, there's a couple of different approaches one can take. If you're just using Docker or Docker Compose, then there are some instructions available on the Doppler documentation for how one can add this in to a Docker file using a token and then inject the secrets via the Doppler run command. Whilst this works, it won't automatically redeploy an application whenever a secret changes, which personally I think is a really valuable feature. Therefore, I like to use a different approach, one that's enabled by another feature that Doppler provides, web hooks. These allow you to respond to events whenever a secret changes, which means when it comes to docloy, I can easily add in an automation to update the environment of my application through the API and then subsequently redeploy it. As for how to build this automation, well, I've gone ahead and already implemented three different versions. The first of which is a simple Rust service that you can run yourself. The second is an N8N integration, which I've been having quite a lot of fun with recently. And the last is a feature that I'm adding to my starter kit SAS application, which will automatically set up this automation for you whenever you create an application which has both Doppler and Docky integrated. If you're interested in any of these three, I've left links to each in the description down below with instructions on how you can configure each one. To show how setting up a web hook works, I'm going to go ahead and use the Docker Bridge application, which I already have up and running on my dock ploy instance running on a VPS provided by the sponsor of today's video, Hostinger. This bridge service in my case has been configured with the following environment variables, which yes, I've actually stored in Doppler already. As for what these environment variables do and how to obtain them, again, you can refer to the documentation of the actual service found in the GitHub repo linked down below. In this case, I've configured the bridge to work with the following docloy application, which is just a simple web server again that I've written in Rust. However, if we go ahead and take a look at the environment variables of this application, you can see there's one already defined called fu with the value of bar. So, let's go ahead and get Doppler integrated with it. To do so, we just need to head on over to the project that we want to integrate with. In this case, I have one set up already called automation test. So, let's head on over down to the web hook section found on the left hand side. Inside of this section, we can create a new web hook by clicking the add button, which will present us with the following form where we can set the name of the web hook, the web hook URL, which in my case is where the service is located, and the Doppler config or environment that we want the web hook to execute on. In this case, I've set this to be prod. Next, we can then override the JSON body, which in my case, I'm not going to, as well as also defining a signing secret. In this case, I've already configured the service to make use of one. So, I'm going to go ahead and make sure to set this. Lastly, we can then define some authentication. Again, this is configurable on the actual Rust service. Uh, but in my case, I've configured it with the following bearer token. With that, we can now go ahead and save this web hook and test it out. to do. So, let's go ahead and change the value of the fu environment variable to something else. Say hello. Now, when I go ahead and press save, Doppler should send out a web hook request to our service uh which we can confirm by looking at the logs and then the configured service itself should handle the request, update the application's environment variables before restarting the service. To confirm that this has happened, if we head on over to the docloy application, we can see that the environment has actually been updated and also adding the same metadata secrets we saw when syncing with Versell. Now to check that the application is redeploying, if we head on over to the general tab, we can see that this is the case, showing us that everything is working as intended. Although because this service has been built using Rust, then this redeploy is taking its sweet time. All of this is achieved using just a web hook and my own home rolled bridge service which makes use of both the Doppler and Docloy APIs. As I mentioned, there's a link to this service in the description down below in case you want to use it yourself. And because it's been licensed using the MIT license, then it's considered open source and you can do pretty much what you want with it. Okay, with that we've covered pretty much all of the ways that I like to use Doppler in my day-to-day. However, to round off this video, I'm going to quickly share some configuration options and tricks that I found to both improve and maximize the way that I work with the service. The first of these is to configure the default environments to be a little more agreeable. By default, Doppler sets up the slug for the production config as PRD. Personally, I dislike this default configuration. So, I change it to be prod instead, which is achieved through the default environments menu, which you can navigate to from the dashboard. Additionally, as I mentioned before, Doppler also creates a staging environment by default as well with the slug of STG. However, I hardly ever use this staging environment in my day-to-day, although in a team setting, this is incredibly valuable. Again, you can disable or enable this inside of the same settings menu. In addition to configuring Doppler itself, I also have a couple of configurations set up on my local machine that I find makes using Doppler more effective in the form of Zshell functions. These include one to easily populate a database URL environment variable with the value from a project and configuration and another to do a very similar thing, but basically open up a psql connection to a project's database again using the same configuration. If you want to know how I've implemented both of these, I've left a link to where these are defined inside of my dot files in the description down below. Okay, so that covers the basics of how I like to use Doppler for both local development and when it comes to my deployed applications. However, this only touches the surface of what Doppler can do as it provides a number of other useful features, especially when it comes to a teambased setting, such as automatic secrets rotation, audit logging, secrets referencing, which is actually one of my favorite features as it allows you to reference a secret found in another config or even project. Uh, meaning that when you change the referenced secret, it will automatically change any of the pointing references. Uh basically it allows you to easily manage shared secrets across multiple services. And lastly for those who partake it's fantastic Kubernetes operator which is actually the main reason I ended up using Doppler in the first place. For me all of this makes Doppler my favorite secrets management solution that I've ever used. So much so that I happily paid $20 a month for it. Although there is a rather generous free tier that covers most personal projects needs. But in my case, I just have so many of them that it was time to upgrade. On that note, I want to give a big thank you to Hostinger for sponsoring this video. If you're looking to deploy your own applications on a long-term VPS instance, then Hostinger is a great and affordable option, one that I've been using for nearly a year and a half. If you're interested in getting your own long-term VPS instance, then make sure to visit hostinger.com/dreamsofcode or use the link in the description down below and use my coupon code dreams of code to get that additional 10% off. Otherwise, I want to give a big thank you to you for watching. I hope you enjoyed the video and I'll see you on the next one.

and it's absolutely changed the way I manage secrets in ways I didn't even know I needed. To get your own VPS instance to host all of your services on, then visit https://hostinger.com/dreamsofcode and use my coupon code DREAMSOFCODE to get an additionally 10% off. Managing secrets is one of those things that only gets more complex with time, and whilst there are solutions out there that work well when it comes to deploying on production, they tend not to be suited when it also comes to local development. Fortunately, there is one solution out there, and it happens to be my favorite. A portion of this video is sponsored by Hostinger Links:- - Doppler: https://doppler.com - Doppler Bridge (Rust 🦀): https://github.com/zenstarthq/doppler-bridge - Doppler Bridge (n8n ): https://github.com/dreamsofcode-io/doppler-bridge-n8n-workflow - Zenstart: https://zenst.art 🚨 Want to learn Go? I've just added interactive coding lessons to my courses: https://dreamsofcode.io/courses/cli-apps-go/learn 👈 My Gear: - Camera: https://amzn.to/3E3ORuX - Microphone: https://amzn.to/40wHBPP - Audio Interface: https://amzn.to/4jwbd8o - Headphones: https://amzn.to/4gasmla - Keyboard: ZSA Voyager Join this channel to get access to perks: https://www.youtube.com/channel/UCWQaM7SpSECp9FELz-cHzuQ/join Join Discord: https://discord.com/invite/eMjRTvscyt Join Twitter: https://twitter.com/dreamsofcode_io 00:00:00 Secrets 00:04:07 Local Development 00:06:24 Configure a Project 00:07:53 Setup Doppler CLI 00:10:15 Personal Config 00:12:24 Doppler for Prod 00:14:06 Config Syncs 00:16:45 Hostinger 00:18:18 Docker Deployments 00:18:55 Webhooks 00:22:37 Doppler Config Tips 00:24:04 Other Useful Features