Forem: Brian Vallelunga

$20m Series A to build the first SecretOps Platform

Brian Vallelunga — Thu, 28 Apr 2022 01:19:19 +0000

Redefining secrets management through multi-cloud secrets sync and automation at enterprise scale.

We're excited to announce our $20m Series A round led by CRV with participation from existing investors including Google Ventures, Sequoia Capital, and Y Combinator.

40 tech leaders have also joined as angel investors and advisors including GitHub CEO Thomas Dohmke, Datadog CEO Olivier Pomel, Plaid CEO Jean-Denis Greze, Twilio CEO Evan Cooke, Postman CEO Ankit Sobti, and Okta CEO Frederic Kerrest.

By building the first SecretOps Platform, developers and security teams can leave behind the problems caused by .env files, unmanageable secrets sprawl across multiple clouds, and the lack of innovation from traditional secret managers.

The ability to securely store, transmit, and audit secrets has never been more critical as one minor error can lead to catastrophic results.

In a world where putting a single space in the wrong place can literally take down a company’s entire website, Doppler makes it easy to prevent leaks and outages with their developer-focused approach.

Murat Bicer, General Partner, CRV

A SecretOps Platform is the single source of truth for developers and their teams to manage, store, and automatically sync secrets to every major hosting platform, secrets manager, and infrastructure management tooling such as Kubernetes and Terraform.

The reality is that the legacy way of storing secrets in siloed secrets managers and .env files doesn’t make sense anymore.

With Doppler, we can put those days behind us. Just like when GitHub first pioneered the notion of a pull request,—once you see the benefits, there's no turning back.

Brian Vallelunga, Doppler CEO

Fuelling Doppler's growth are customers such as Puma, Hopin, ezCater, Toast, Gather, My Muscle Chef, OnDeck, and many others. More than 15,000 teams trust Doppler to manage their secrets with over 1.5 billion secrets synced every month.

Traditional secrets managers were never built to support a multi-cloud deployment strategy or provide developers with the management features they need as part of the software development lifecycle and deployment process.

But we don’t just need slightly better secrets managers. We need a SecretOps Platform. A platform that satisfies the requirements of both Developers and Security Engineers. Development teams and DevSecOps.

Doppler combines all of the key elements DevOps and Security teams need to control who can see and modify secrets at scale as well as an audit trail, versioning, enterprise grade encryption, secrets rotation and dynamic secrets.

Brian Vallelunga, Doppler CEO

Doppler also seamlessly integrates and syncs secrets to a growing list of infrastructure tools such as Kubernetes and Terraform, platforms such as GitHub Actions and Vercel, and cloud secret managers such as AWS Secrets Manager and Azure Key Vault.

Doppler's Series A is further confirmation that building the first SecretOps Platform is essential to making secrets automation a first-class citizen in the infrastructure management landscape.

About CRV

CRV is a venture capital firm that invests in early-stage startups. Since 1970, the firm has invested in more than 500 startups at their most crucial stages, including Airtable, DoorDash, and Iterable. Founders need more than capital to build a great company. It takes a partner who understands the entrepreneurial journey and knows what it takes to win. From founding to IPO and beyond, CRV is there every step of the way. Founders rely on CRV to be trusted, long-term, committed partners, which has helped make CRV into one of the longest-running venture capital firms in the world. Learn more about CRV and the companies shaping the future at https://www.crv.com.

The Missing Third

Brian Vallelunga — Wed, 20 Oct 2021 06:30:45 +0000

I believe every developer deserves amazing collaboration tools for managing secrets. Using a secrets manager shouldn't come at the cost of a brain aneurysm. In fact, I think a platform designed for developers of all backgrounds can bring moments of joy to your day, promote healthy security hygiene, and boost your overall developer productivity. Doppler was built from the ground up because the Universal Secrets Platform (USP) I needed simply didn't exist.

I am sure at this point you may be asking who are you? What is a secret - sounds mysterious? What is a USP? How does it differ from a traditional secrets manager or even a dotenv file? Lots of questions, I’ll start off with a simple one - who am I.

Hi - I am Brian 👋, an introvert who plays an extrovert in real life. I love building things (mostly through code and legos), have a passion for making weird art, and hanging with friends. I am sharing all this to show I am just another person, another developer, like you. Below are my thoughts on how the current way of managing secrets is broken and a proposed solution through what I call a Universal Secrets Platform (USP).

App = Code + Compute + Secrets

From my experience, running an application typically requires at the minimum code, compute, and secrets. Three pieces of a puzzle that form a living picture. We are lucky to live at a time where amazing collaborative source control platforms exist enabling distributed teams to build together. This paired with CI/CD and cloud-based hosting allows for fully automated deployments that can reach users in most regions at near infinite scale. But what about the other, often deemed less exciting piece to running applications — secrets?

For context, secrets are typically API keys, database urls, certificates, environment variables, and other app configuration such as a port variable. They are often used to grant access to highly sensitive data/services and thus should never be stored in an unencrypted format such as in code or dotenv file.

Responsibility to our users

Secrets are the literal keys to our digital kingdom and deserve to be treated as such. Before Doppler I didn't think much about secrets, as my job was to ship features to customers as fast as possible. Building and shipping is an adrenaline rush, and through that rush, it became easy to lose sight of what I was doing.

I thought of secrets as a means to an end, a required piece of the puzzle that let my code talk to services like Stripe and Twilio. I never stopped to think about the impact it would have if those secrets ever became "not so secret". In one decision, made now or years ago, I could have accidentally leaked all of our users data that had been entrusted with us. I often would store our production Stripe key in an unencrypted dotenv file which granted access to our customer's credit cards and bank accounts. The impact that one secret could have had on their lives if it ever got leaked would have been tremendous.

It's easy to forget that behind the UUID of a user is a real person with a life and loved ones. They trust us with their data, the least we should do is protect. While you might be thinking that a leak would never happen to you, the Twitch source code leak was a brutal reminder that the unexpected can happen at any time, to anyone. I hope this gives you a moment of pause to reframe how you think about the secrets you already have today.

.... a minute later. Pause is over, onwards!

A missing puzzle piece

It would be painful to imagine a world before the likes of GitHub, where you had to take code and share it over email/FTP and then perform surgical merge resolution to adopt the changes. This wouldn’t just happen once, but every time anyone changed code. Then to deploy that newly minted code to production, one person would need to SSH into a server and upload the code manually. Hoping and praying along the way that they didn’t mess up and accidentally bring the service down. These workflows were manual because we didn’t have pull requests, CICD, infrastructure as code, cloud computing, or other fancy automations we benefit from today.

But everything isn’t as automated as it seems, as much of the same problems exist today with secrets. Take dotenv for example… which is a file that holds a list of secrets in an unencrypted (🤦) human-readable format. Each developer and every environment (e.g. staging, production) needs its own dedicated dotenv file that is specific for that machine. This file should never be tracked by source control, leaving developers to the manual, error-prone, and time-consuming dynamics that we previously experienced with code before source control existed. These unencrypted files are then passed around Slack, email, other productivity tools that are not designed to store the literal keys to the kingdom.

Then when updating the ".env" file for production and other environments, the developer has to add the secrets manually. In the case of a medium to large company, they would need to create a task/ticket for the DevOps team who is responsible for managing infrastructure.

Environments must then be updated in a timely manner as the secrets need to be available before the new code that uses them is deployed. This creates a tricky race condition when code is automatically pushed from GitHub while secrets are configured by humans. There is also a greater chance of the service going down when secrets are touched manually as human error can strike in the moment through a seemingly innocuous typo. Secrets need to be perfect, if they are off by even a single character from what they need to be, it can cause serious problems.

Adding or updating a secret in a dotenv file may sound simple, but in reality, it’s much more complex. Changes are often made in groups where some secrets are added, while others are removed or even updated. Imagine distributing all of those changes by hand day in and day out. Sounds like a recipe for a typo.

Automated and collaborative tooling

At this point you may be asking why there isn't a tool that already exists since the conventional way is so painful. Truth be told, I asked the same question before I started Doppler. To my surprise, there are tools that exist but I hadn't heard of them because they weren't built for me. I am a developer, heart and soul, and those tools were built for the security teams. I found the user experience sucked, SDKs complex, on-premise requirements frustrating, and lack of built-in management features left the developer experience out of the equation while ticking all the right boxes for security.

I am a visual person, I want a dashboard. I don’t like repeating high-risk mundane tasks. I want integrations like GitHub where my secrets are automatically deployed alongside my code. Lastly I am human, I forget things and make typos. I want a tool that has my back by catching my mistakes before they become costly. And in the event I do mess up, I should be able to instantly roll back the changes from a click in a dashboard. I want the automation benefits that have revolutionized how we build and ship software applied to the one area that developer tools forgot—secrets.

We as an industry need to define a new devtools category that captures what we as a development community need for managing secrets securely, from individual developers to enterprise organizations.

I propose that we need a Universal Secrets Platform (USP). A single source of truth for developers and their teams to manage, store, and automate secrets syncing to every major hosting platform and cloud provider. Universal is the differentiating prefix and comes with four requirements:

Universally accessible and useable for developers of all skill levels and specialties. From junior developers to the most senior.
Universally empowers least privilege access. Developers and machines should only have access to the secrets they need.
Universally provides a full-featured and easy-to-use dashboard and CLI that takes minutes, not days or weeks to learn.
Universally supports every operating system and infrastructure, from Serverless to Containers, static-sites to Virtual Machines, and everything in-between.

So how does this differ from the secrets managers that exist today? AWS and GCP both have secrets management offerings while new cloud providers like Vercel and Netlify also allow for securely storing secrets. To see the difference, we need to separate storage from management to match reality. The secret “managers” we have today actually only offer simple Key-Value storage and lack support for the workflows developers need in practice. In our new model, we should treat them as storage destinations. The USP becomes the central source of truth, responsible for distributing secrets to the corresponding storage destinations. This also serves as a multi-cloud solution for a modern-day data center.

Let’s take a look at an example through the lens of a project. Straight off, we notice that every environment, including local development, is supported. Not only that, but every developer gets their own isolated secrets store. There is automated testing in place through CircleCI while Netlify is used staging and production deployments. Each one of these environments (development, staging, and production) has at least one destination ranging from a developer’s laptop to CircleCI and Netlify.

A Universal Secrets Platform is the hub where all those secrets are stored, managed, and versioned across environments. When they are changed in the USP, secrets automation updates them in each linked platform (CircleCI and Netlify in this case) with the option of automatically triggering a rebuild or redeploy. This model mirrors what source control platforms provide today. When code is pushed to a branch, GitLab pushes those changes to the destination infrastructure such as AWS.

Measuring success

As an industry, we will have a strong signal that this category is going to be successful when developers treat it like they would a source control platform. As essential as code reviews through pull requests are in today’s software development life cycle, so too will be managing secrets at the cloud and platform level. From the collaborative features enabling distributed teams to work effectively together, to the automations that enable CICD workflows, there is a lot left to do.

Use a Universal Secrets Platform

My hope is that you as a developer walk away from this long-winded article looking to add a Universal Secrets Platform to your toolbox. It's a completely different way of thinking about managing secrets, but just like when GitHub first pioneered the notion of a 'pull request’, once you see the benefits, there's no turning back. Together let's make the internet a more secure place for the projects we work on and the users they serve.

Goodbye ENV Files

Brian Vallelunga — Mon, 09 Aug 2021 23:37:06 +0000

Three months ago we stopped using ENV files as the default export option in the Doppler CLI. This change led to a number of benefits including supporting multi-line variables and a deterministic schema. Before going too deep on the technical choices we made, let's first go over what ENV files are and how they're used.

What are ENV files?

ENV files are plain text files that store variables and secrets that you would not want hardcoded in your codebase. These variables could be a port number or a database url, and may change depending on where your code is deployed. For example, when developing locally you may use port 3000, but when deployed to Heroku your application will need to use the port it's dynamically assigned. An example ENV file when developing locally could look something like this with the schema of KEY=VALUE:

PORT="3000"
DATABASE_URL="psql://postgres@localhost/db_name"
AWS_KEY="rfiunb34fu93n49iufgn3o2o0ini2ef"
BUGSNAG_API_KEY="33dasdk34bsf23f35871as0fa27"
INTERCOM_KEY="ndeiovnkofrnij30490398u39RIBF39IOENIOWF3ENWKEWENVIO"
MAILGUN_KEY="fdjnbvjoenvlmswsdnjoelfv"
NEW_RELIC_LICENSE_KEY="b583d4eab955872122843a067faca9db5d4202af"
NEW_RELIC_LOG="stdout"
SALESFORCE_TOKEN="feojkvndfjkovnskfn3eni32one"
STRIPE_KEY="sk_test_ejidsfnvoiuebnfvoi3enjkdNCJSB"

Having the file is not enough though, you would also need a tool like foreman to parse the file and inject those variables into the environment.

Benefits

So what are some of the benefits of using an ENV file? Well these files live on your local machine which means you do not need a network connection to fetch your secrets. The schema is also quite simple so it's easy go into a file and add a new variable. Lastly, everyone knows this format so there is a ton of support by the open source community for parsers and managers.

Downsides

From our time working with ENV files and adding support for various use cases, we have found that there isn't a standardized schema all libraries use. For example, take a look at the sample ENV file below:

PORT = 3030

Notice that this ENV file that contains a spaces between the KEY and the VALUE. If we were to use bash to inject the variable into the environment with the source command we would get an error.

source spaces.env
# >> bash: PORT: command not found

Now if we use another tool like foreman we would see it parse without an error. This is because each library is deciding the schema of a ENV file instead of strictly following an open standard. These inconsistencies causes other problems to arise as well, such as parsing multi-line secrets. In this example a variable uses encoded newlines through \n:

CERT="-----BEGIN RSA PRIVATE KEY-----\nMIIEogIBAAKCAQEA6ONkkK5eT0wUIjV4CyeO5yQ4AMmCTUyfahKq3gOto4UVhtHE\nlw6GnZwbvRUSwpqGi1X8iTo1GKjcYBVNvRf6Hw5zk9wGTImwNBAlEF7K1aYnelMk\nqDLJ7T0vHAVEvAq2Wz24SljMWgdv9d83KOvuTjZE04H7YlBS4w3OeRu7D2+kgkAr\nR3fqCNEUOvafikwqThHV27xSMaj7uvvm+eMv9ztNb8VauSnZ9zPXtLOPSNy7HGQr\n9S3rqwg7Hif9yLQ2iWVa9R6ACc2I9oK27Olq8AvyHsIz4gktBqLpV3rfBc5muReG\nBO+kdsSpCxpQBQ1W4gU8gTi7Qgr9+bEeaN2bfwIDAQABAoIBAG+J2PRiTtDzwwDP\nUvskqxCRDDF0UW/sLr2Cy0shv9v9NV4owVsHnfmGdtKMcTu6/o1lVVn0AtIYrdNm\n4KCcBzMwnLJIQswNddK5mMbKX6MLvQSdJYVZLdTt5M4qx8y35La2TLlu5hCIV1sO\n2UBEHxJec4BJVLi1d70/M5BVc7Xj/ImqPgHtJhNv5gaej3s/vS1j5YmtCHwGnwbY\ndqVLiY9NgHKO3EOFa0vJplxwR0sIj0WumtkLLwjAfEmt0ivZ3D1fJ9hCFrfpJYwf\nzq9Nv1RL0Jry4SfnWTpXKPlF4N+ateXkNhrZILRg8xmOJSQduYt0wo2KxkAbgxtf\nSidoWIECgYEA+/Ggv0LsqxwmsiR991BA2aurYlJwzEFHL/YUc/j+317yj+vdpOmE\nCCV3mAa9tAgMf+BJvQS1RGS2bnnVe5CcjuoEJ1gQ3LdU9LA1H14880TjMsuxEKkB\nVLHkhiS1yG4lo01H8Aml2EAn1Hz84BazubxMy8vWu6xqm6wT0LIxuI8CgYEA7KM6\ndBtrkWSbj1lpLR8zeLhQkcQP94biLcrH0xEONpphNdTy2DW/Ne6qQWQ9y171iMvU\nOOq+3AcyNf/hZxhRAcTN5Qb3qGUqZn4tRXuVzhKd3CQ5Ijiq7EAfSUI+NBKGPChL\ndX7unhIgJVgcuuo/qg6J5vOV+FGGpm5Zbu9zBhECgYBBcAruYnWSI+exEWVeXQva\n/YmwKfV+N95DiMjbLmsUnVanJv4UnUpby096vxV6szR76kd8vsJOF1KC80YNqAvh\n2splZaxLh5qbS0Eg+pseHGBeiyVcTGk6FFJkvRgyDNndxm7O29KljlRKDoSnt33K\n2iugKzuE102BTXqAFChx5QKBgEyJeuWE3OTYwou54o/KkK5SBxUuce+ge9VNyhXV\nZWB5zElKCAWwVJkQCZc+4dG+c/H74zdJjdPCrBXVHkVnEwRccC/MchvQJMejtebM\nUyak1NQYDzanV3k0QCpEt7PF7g7VBZsKJAmSWT1a42f9Tfwl2aqOTIpVbBS2ikyc\nO/rRAoGARmMBi0jfi1m3DpRt35QyCWJXd8YNGxsaB1cc/NorBPOX5cIP3YGn1b6F\n6kS0HEz1SOpENczi+C5hJiyldVIkek9sjoW7+6030HZlb0U2nnTFCTNfjhcD2+Xa\nNxB4RWiMLTgeDmGICV4U+1qIFLyiuZxabLxw0q5O2kkyGGKlpeQ=\N-----END RSA PRIVATE KEY-----\n"

This newline is treated differently depending on which tool you use. Using the bash source command the \n in the string would not be converted to newline characters. On the other hand, using Python's most popular ENV library dotenv will convert the \n to newlines automatically. Now let's look at the inverse:

CERT="-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEA6ONkkK5eT0wUIjV4CyeO5yQ4AMmCTUyfahKq3gOto4UVhtHE
lw6GnZwbvRUSwpqGi1X8iTo1GKjcYBVNvRf6Hw5zk9wGTImwNBAlEF7K1aYnelMk
qDLJ7T0vHAVEvAq2Wz24SljMWgdv9d83KOvuTjZE04H7YlBS4w3OeRu7D2+kgkAr
R3fqCNEUOvafikwqThHV27xSMaj7uvvm+eMv9ztNb8VauSnZ9zPXtLOPSNy7HGQr
9S3rqwg7Hif9yLQ2iWVa9R6ACc2I9oK27Olq8AvyHsIz4gktBqLpV3rfBc5muReG
BO+kdsSpCxpQBQ1W4gU8gTi7Qgr9+bEeaN2bfwIDAQABAoIBAG+J2PRiTtDzwwDP
UvskqxCRDDF0UW/sLr2Cy0shv9v9NV4owVsHnfmGdtKMcTu6/o1lVVn0AtIYrdNm
4KCcBzMwnLJIQswNddK5mMbKX6MLvQSdJYVZLdTt5M4qx8y35La2TLlu5hCIV1sO
2UBEHxJec4BJVLi1d70/M5BVc7Xj/ImqPgHtJhNv5gaej3s/vS1j5YmtCHwGnwbY
dqVLiY9NgHKO3EOFa0vJplxwR0sIj0WumtkLLwjAfEmt0ivZ3D1fJ9hCFrfpJYwf
zq9Nv1RL0Jry4SfnWTpXKPlF4N+ateXkNhrZILRg8xmOJSQduYt0wo2KxkAbgxtf
SidoWIECgYEA+/Ggv0LsqxwmsiR991BA2aurYlJwzEFHL/YUc/j+317yj+vdpOmE
CCV3mAa9tAgMf+BJvQS1RGS2bnnVe5CcjuoEJ1gQ3LdU9LA1H14880TjMsuxEKkB
VLHkhiS1yG4lo01H8Aml2EAn1Hz84BazubxMy8vWu6xqm6wT0LIxuI8CgYEA7KM6
dBtrkWSbj1lpLR8zeLhQkcQP94biLcrH0xEONpphNdTy2DW/Ne6qQWQ9y171iMvU
OOq+3AcyNf/hZxhRAcTN5Qb3qGUqZn4tRXuVzhKd3CQ5Ijiq7EAfSUI+NBKGPChL
dX7unhIgJVgcuuo/qg6J5vOV+FGGpm5Zbu9zBhECgYBBcAruYnWSI+exEWVeXQva
/YmwKfV+N95DiMjbLmsUnVanJv4UnUpby096vxV6szR76kd8vsJOF1KC80YNqAvh
2splZaxLh5qbS0Eg+pseHGBeiyVcTGk6FFJkvRgyDNndxm7O29KljlRKDoSnt33K
2iugKzuE102BTXqAFChx5QKBgEyJeuWE3OTYwou54o/KkK5SBxUuce+ge9VNyhXV
ZWB5zElKCAWwVJkQCZc+4dG+c/H74zdJjdPCrBXVHkVnEwRccC/MchvQJMejtebM
Uyak1NQYDzanV3k0QCpEt7PF7g7VBZsKJAmSWT1a42f9Tfwl2aqOTIpVbBS2ikyc
O/rRAoGARmMBi0jfi1m3DpRt35QyCWJXd8YNGxsaB1cc/NorBPOX5cIP3YGn1b6F
6kS0HEz1SOpENczi+C5hJiyldVIkek9sjoW7+6030HZlb0U2nnTFCTNfjhcD2+Xa
NxB4RWiMLTgeDmGICV4U+1qIFLyiuZxabLxw0q5O2kkyGGKlpeQ=
-----END RSA PRIVATE KEY-----"

In this example we have the same cert but with newline characters. Surprisingly the bash source command respects the newline character but the Node dotenv library does not. More interestingly is how the Node library breaks. It parses the value as "-----BEGIN RSA PRIVATE KEY----- and disregards all the other lines. I also find it funny that because it is a multi-line variable the quote detection algorithm broke, which can be seen by the first character being a quotation mark. If the quote detection algorithm was working correctly, you would see the value be stripped of it's quotation marks at the beginning and end of the string.

Alternatives

After realizing ENV files are problematic, we started looking at alternatives. We wanted something that has a universally accepted schema with no room for interpretation and a large community for support. The two data formats we focused on were YAML and JSON.

Let's start off with YAML. One of the primary advantages of YAML is that it is incredibly easy to read and write. It uses indentation and nesting as a way to designate structure. Let's look at a sample YAML file:

PORT: 3000
DATABASE_URL: "psql://postgres@localhost/db_name"
AWS_KEY: "rfiunb34fu93n49iufgn3o2o0ini2ef"
CERT: |
  -----BEGIN RSA PRIVATE KEY-----
  MIIEogIBAAKCAQEA6ONkkK5eT0wUIjV4CyeO5yQ4AMmCTUyfahKq3gOto4UVhtHE
  lw6GnZwbvRUSwpqGi1X8iTo1GKjcYBVNvRf6Hw5zk9wGTImwNBAlEF7K1aYnelMk
  qDLJ7T0vHAVEvAq2Wz24SljMWgdv9d83KOvuTjZE04H7YlBS4w3OeRu7D2+kgkAr
  R3fqCNEUOvafikwqThHV27xSMaj7uvvm+eMv9ztNb8VauSnZ9zPXtLOPSNy7HGQr
  9S3rqwg7Hif9yLQ2iWVa9R6ACc2I9oK27Olq8AvyHsIz4gktBqLpV3rfBc5muReG
  BO+kdsSpCxpQBQ1W4gU8gTi7Qgr9+bEeaN2bfwIDAQABAoIBAG+J2PRiTtDzwwDP
  UvskqxCRDDF0UW/sLr2Cy0shv9v9NV4owVsHnfmGdtKMcTu6/o1lVVn0AtIYrdNm
  4KCcBzMwnLJIQswNddK5mMbKX6MLvQSdJYVZLdTt5M4qx8y35La2TLlu5hCIV1sO
  2UBEHxJec4BJVLi1d70/M5BVc7Xj/ImqPgHtJhNv5gaej3s/vS1j5YmtCHwGnwbY
  dqVLiY9NgHKO3EOFa0vJplxwR0sIj0WumtkLLwjAfEmt0ivZ3D1fJ9hCFrfpJYwf
  zq9Nv1RL0Jry4SfnWTpXKPlF4N+ateXkNhrZILRg8xmOJSQduYt0wo2KxkAbgxtf
  SidoWIECgYEA+/Ggv0LsqxwmsiR991BA2aurYlJwzEFHL/YUc/j+317yj+vdpOmE
  CCV3mAa9tAgMf+BJvQS1RGS2bnnVe5CcjuoEJ1gQ3LdU9LA1H14880TjMsuxEKkB
  VLHkhiS1yG4lo01H8Aml2EAn1Hz84BazubxMy8vWu6xqm6wT0LIxuI8CgYEA7KM6
  dBtrkWSbj1lpLR8zeLhQkcQP94biLcrH0xEONpphNdTy2DW/Ne6qQWQ9y171iMvU
  OOq+3AcyNf/hZxhRAcTN5Qb3qGUqZn4tRXuVzhKd3CQ5Ijiq7EAfSUI+NBKGPChL
  dX7unhIgJVgcuuo/qg6J5vOV+FGGpm5Zbu9zBhECgYBBcAruYnWSI+exEWVeXQva
  /YmwKfV+N95DiMjbLmsUnVanJv4UnUpby096vxV6szR76kd8vsJOF1KC80YNqAvh
  2splZaxLh5qbS0Eg+pseHGBeiyVcTGk6FFJkvRgyDNndxm7O29KljlRKDoSnt33K
  2iugKzuE102BTXqAFChx5QKBgEyJeuWE3OTYwou54o/KkK5SBxUuce+ge9VNyhXV
  ZWB5zElKCAWwVJkQCZc+4dG+c/H74zdJjdPCrBXVHkVnEwRccC/MchvQJMejtebM
  Uyak1NQYDzanV3k0QCpEt7PF7g7VBZsKJAmSWT1a42f9Tfwl2aqOTIpVbBS2ikyc
  O/rRAoGARmMBi0jfi1m3DpRt35QyCWJXd8YNGxsaB1cc/NorBPOX5cIP3YGn1b6F
  6kS0HEz1SOpENczi+C5hJiyldVIkek9sjoW7+6030HZlb0U2nnTFCTNfjhcD2+Xa
  NxB4RWiMLTgeDmGICV4U+1qIFLyiuZxabLxw0q5O2kkyGGKlpeQ=
  -----END RSA PRIVATE KEY-----

At first glance the syntax looks very similar to the ENV format but when we look closer we see subtle differences. The YAML syntax uses colons instead of equal signs and has native support for multi-line strings. The one downside when using multi-line secrets is that indentation really matters. The fabled debates of how many spaces equals a tab come into play. With developers each having their own style, it can make YAML files prone to parsing errors when sharing.

JSON on the other hand has a wildly different syntax then YAML. Wikipedia has an accurate description of the language:

JavaScript Object Notation is an open standard file format, and data interchange format, that uses human-readable text to store and transmit data objects consisting of attribute–value pairs and array data types (or any other serializable value).
Let's take a look at the same config of variables in JSON format:

{
  "PORT": "3000",
  "DATABASE_URL": "psql://postgres@localhost/db_name",
  "AWS_KEY": "rfiunb34fu93n49iufgn3o2o0ini2ef",
  "CERT": "-----BEGIN RSA PRIVATE KEY-----\nMIIEogIBAAKCAQEA6ONkkK5eT0wUIjV4CyeO5yQ4AMmCTUyfahKq3gOto4UVhtHE\nlw6GnZwbvRUSwpqGi1X8iTo1GKjcYBVNvRf6Hw5zk9wGTImwNBAlEF7K1aYnelMk\nqDLJ7T0vHAVEvAq2Wz24SljMWgdv9d83KOvuTjZE04H7YlBS4w3OeRu7D2+kgkAr\nR3fqCNEUOvafikwqThHV27xSMaj7uvvm+eMv9ztNb8VauSnZ9zPXtLOPSNy7HGQr\n9S3rqwg7Hif9yLQ2iWVa9R6ACc2I9oK27Olq8AvyHsIz4gktBqLpV3rfBc5muReG\nBO+kdsSpCxpQBQ1W4gU8gTi7Qgr9+bEeaN2bfwIDAQABAoIBAG+J2PRiTtDzwwDP\nUvskqxCRDDF0UW/sLr2Cy0shv9v9NV4owVsHnfmGdtKMcTu6/o1lVVn0AtIYrdNm\n4KCcBzMwnLJIQswNddK5mMbKX6MLvQSdJYVZLdTt5M4qx8y35La2TLlu5hCIV1sO\n2UBEHxJec4BJVLi1d70/M5BVc7Xj/ImqPgHtJhNv5gaej3s/vS1j5YmtCHwGnwbY\ndqVLiY9NgHKO3EOFa0vJplxwR0sIj0WumtkLLwjAfEmt0ivZ3D1fJ9hCFrfpJYwf\nzq9Nv1RL0Jry4SfnWTpXKPlF4N+ateXkNhrZILRg8xmOJSQduYt0wo2KxkAbgxtf\nSidoWIECgYEA+/Ggv0LsqxwmsiR991BA2aurYlJwzEFHL/YUc/j+317yj+vdpOmE\nCCV3mAa9tAgMf+BJvQS1RGS2bnnVe5CcjuoEJ1gQ3LdU9LA1H14880TjMsuxEKkB\nVLHkhiS1yG4lo01H8Aml2EAn1Hz84BazubxMy8vWu6xqm6wT0LIxuI8CgYEA7KM6\ndBtrkWSbj1lpLR8zeLhQkcQP94biLcrH0xEONpphNdTy2DW/Ne6qQWQ9y171iMvU\nOOq+3AcyNf/hZxhRAcTN5Qb3qGUqZn4tRXuVzhKd3CQ5Ijiq7EAfSUI+NBKGPChL\ndX7unhIgJVgcuuo/qg6J5vOV+FGGpm5Zbu9zBhECgYBBcAruYnWSI+exEWVeXQva\n/YmwKfV+N95DiMjbLmsUnVanJv4UnUpby096vxV6szR76kd8vsJOF1KC80YNqAvh\n2splZaxLh5qbS0Eg+pseHGBeiyVcTGk6FFJkvRgyDNndxm7O29KljlRKDoSnt33K\n2iugKzuE102BTXqAFChx5QKBgEyJeuWE3OTYwou54o/KkK5SBxUuce+ge9VNyhXV\nZWB5zElKCAWwVJkQCZc+4dG+c/H74zdJjdPCrBXVHkVnEwRccC/MchvQJMejtebM\nUyak1NQYDzanV3k0QCpEt7PF7g7VBZsKJAmSWT1a42f9Tfwl2aqOTIpVbBS2ikyc\nO/rRAoGARmMBi0jfi1m3DpRt35QyCWJXd8YNGxsaB1cc/NorBPOX5cIP3YGn1b6F\n6kS0HEz1SOpENczi+C5hJiyldVIkek9sjoW7+6030HZlb0U2nnTFCTNfjhcD2+Xa\nNxB4RWiMLTgeDmGICV4U+1qIFLyiuZxabLxw0q5O2kkyGGKlpeQ=\n-----END RSA PRIVATE KEY-----\n"
}

One of the main beauties of JSON is that it is strictly enforced and there is only one way of accomplishing each task. For example, when we look at the variable PORT, we can see the value is wrapped in quotes to state it is a string. Unlike YAML, which will guess if the line should be cast to a string or number, JSON only has one way of notating strings and numbers. One other stark difference between YAML and JSON is how they handle multi-line variables. In JSON we can see it uses the encoded newline characters \n which we think is a safer bet than trusting humans with indentation.

Choosing JSON

We ended up going with JSON because it has a far stricter schema and has strong native support in most languages. After making the switch, we saw our customers' issues with parsing downloaded config files flat line. Since the Doppler CLI creates a fallback of your secrets by default when running your application, we decided to go one step further by enabling encryption by default.

We strongly believe that you are always going to be worse off having secrets on disk, but if you are going to, it is imperative that they are encrypted.

Doppler Ad

Tired of managing a fleet of secrets by hand using copy/paste? Want an end-to-end managed secrets manager that vaults all your secrets in one place, has built-in versioning and access control? Try out Doppler. It works great in local development (say goodbye to ENV files) and in production, plus it effortlessly scales with you as your team and products grow. Take a look at our quick install guide to see if it is a fit for your team.