It’s Cybersecurity Awareness Month! Join our interactive training session, or learn about security and AI from 1Password experts.
.env files should support more file formats
Hey, I was incredibly excited to see the 1Password beta supporting .env files. After testing it out in the latest beta, I understand that this is incredibly useful for environments that support traditional .env files. However, as someone working with building mobile apps, specifically for iOS, I was hoping that the new feature was a tad more flexible, enabling me to use it in .swift files. Specifically, I was hoping that the new feature would replace references to secrets in existing files rather than creating a new (temporary) file. If it were replacing references in existing files, we could use the .env support in 1Password's Environment with any file template. I understand the downsides to this, but in the mobile landscape it's not uncommon to hardcode select secrets in the binary and even when doing so, we'd like to keep those secrets out of version control. Therefore, we have .swift template files that look like this: enum Secrets { enum SomeService { static var apiKey: String { "{{ op://Acme GitHub Actions/Some Service API Key/API Key }}" } } } These files are named Secrets.tpl.swift and are stored in version control. We use `op inject` to inject the secrets into these files and output them as Secrets.swift, so they're referenced at compile time. Secrets.swift is not checked into version control, of course. I was hoping that we could mount Secrets.tpl.swift or similar in 1Password Environments to have it handle the secrets for us, as .env files aren't really a thing in iOS development. I'm excited to use 1Password Environments with the new .env files in backend development, but I hope you'll consider making it more flexible, so it can accommodate more platforms too. Best regards, Simon B. Støvring
Introducing new .env file support in 1Password
Today, we’re introducing a first-of-its-kind feature available in the 1Password Desktop app. With the new local .env file destination in 1Password Environments, you can securely use and share .env files across your team, without rewriting how your app loads credentials. Here’s why it matters: Zero plaintext secrets on disk: Secrets are loaded into applications on demand. You can’t accidentally commit them. No cumbersome sharing of secrets: Teammates get instant access - no DMs or copying secrets. Built for teams: Version history, access control, and automatic updates - all in one place. Offline access: No more internet connection required to load secrets from 1Password. Secrets are sourced directly from the desktop app's local cache. Now available in beta on Mac and Linux. Interested to see it in action? Check out this demo. 💬 Share feedback, get swag We want your input on what to build next: CI/CD integrations? Docker support? Something else? 📖 Read the docs to get started 👉 Join the discussion in the 1Password Developer Community 🧢 The first 10 developers to start a discussion on the 1Password Developer Community Hub to share feedback by October 31st will get exclusive 1Password swag. Be sure to tag your post with beta-environments.
Local Environment File Partial Override and Merging
First of all I am very pleased with the announcement of the new environment feature to mount into local .env files! For our use case it would be beneficial to allow merging different environments into the same .env file or to allow partial overrides of values locally that are persisting locking of the desktop application. For local development, we have a single starter .env file with a lot of empty values and not all of these values are used by all developers. For example we have an authentication related section that contains secrets that are per-developer. For example the developer specific Github PAT, Social Auth provider App identifiers and credentials. These should be still stored in the single env file that is used during development and we would like to avoid fragmentation into multiple files at the moment, as it complicates our containerized configuration. So I have two related feature requests: Would it be possible to allow merging of different environments into a single mounted file (conflict resolution aside for now)? Would it be possible to allow partial overrides of specific values based on the employee vault or local environment?1Password Environments should enable grouping environments by service
Hi, The new .env management feature in 1Password is incredibly handy, and I can definitely see us adopting it for our backend services. It makes working with environment variables much more convenient. That said, I’d like to share some concerns regarding scalability. We have several services, each with multiple environments such as development, staging, production, and feature-specific environments. In 1Password Environments, these all of these environments appear side by side in a single list, regardless of which service they belong to. This results in naming schemes like "[Service]: [Environment]". While workable, this approach becomes harder to manage as we scale across multiple services. To illustrate, I’ve included a screenshot below showing what I anticipate the structure to look like in our setup. In this case, Service A and Service B have no relation to each other, yet their environments are intermingled. A way of grouping services would make this much clearer and easier to navigate. Best regards, Simon B. Støvring
