It’s Cybersecurity Awareness Month! Join our interactive training session, or learn about security and AI from 1Password experts.
New Item Type recommendation: API Keys
I would like to see a new item type: API Key for securely storing machine-to-machine credentials used in development and automation. It would include fields for the key, environment, service name, expiration, rotation schedule, and scope. This would help developers separate API credentials from personal passwords, reduce misuse, and support compliance best practices. This important because API keys are generally created and shared only once. Being able to store these safely in 1Password would be a big help. By having a new Item type, these can be more easily browsed as a group. Recommended Required Fields Field Name Type Purpose Service Name Text Identifies the platform or API (e.g., “OpenAI API”). API Key Concealed The actual secret string; hidden by default, revealable on demand. Environment Text/Selection Helps differentiate between “Production,” “Staging,” or “Development.” Key Type Text/Selection Identifies the key’s purpose — e.g., “Secret,” “Public,” “Bearer Token,” “Client Token.” Created Date Date Tracks when the key was generated. Recommended Optional Fields Field Name Type Purpose Description Text (multiline) Freeform notes about usage, permissions, quotas, etc. Service URL / API Console URL URL Direct link to the managing website or API dashboard. Expiration Date Date Useful for keys with rotation or expiration requirements. Key Owner / Issued To Text Identifies who or which system owns the key. Scopes / Permissions Text Lists the granted permissions or access scopes. Rotation Schedule Date or Text Next planned rotation or rotation policy (“every 90 days”). Linked Account Reference or Text Optional link to the related Login item or user account. Tags Text (multiple) Categorization (e.g., “AWS,” “internal,” “low risk”). Attachment File (optional) Store related configuration files like .env or key manifests.Mark environment variable value as optional
Hey community! The Environments feature came into a very fitting point for our team’s new project. We’re currently experimenting with it in order to replace the .env.template file conventionally used to denote the list of variables needed in a local dev env. There’s a small issue however (very similar use case to Tillman’s). Not all developers need all variables, and additionally there are variables that are personal to each user. So, after short experimentation we thought of the following suggestion: What if, alongside the key/value pairs that are persisted in the .env file (common for all users that have access to the .env file), there was a different entry type whose value wasn’t synced to the upstream? This way, 1. all users with access to the .env file would always have the up-to-date list of all variables used in the project, but 2. would be able to leave some values empty and let the code decide how to handle this case, and 3. would be able to add personal values (eg. API keys even via secret references) without leaking them to the rest of the users. What do you think?
1Password Environments Beta is awesome
Just wanted to drop some feedback after playing around with the new Environments Beta in 1Password. Honestly, I’m loving it so far. The local .env file mounting is just brilliant. Secrets are easy to access without having to run extra commands, but still secure – exactly what I want. Makes switching between machines seamless, too. A couple of things I’d really like to see next: 1. CLI Integration - being able to create/edit/list environments and variables from the terminal would make this so much more useful, right now, having to click around in the desktop app is a bit of a pain for dev workflows. 2. More integrations: AWS Secrets Manager is a great start, but would love to see GCP and other major providers such as GitHub, etc. A plugin system for integrations would be awesome also to help cover more niche players like Modal.com Overall, this is a huge step in the right direction for 1Password. Can’t wait to see where this goes next!
Fingerprint sensor support on remote systems?
Hello, maybe I missed something. Hence, I am asking before buying a new Mac Keyboard with sensor ... I use 1Password for: local stuff on my Mac on remote systems over ssh Visual Studio Code (VSC) remote over ssh VSC Docker devcontainers on remote Linux systems (In VSC open a folder on a remote system, open the project folder in docker devcontainers) Typing in the vault password is a cumbersome thing, when done too often, and restarting and rebuilding the containers, are new shells / terminals requesting entering the 1Password vault password often. Hence, I am looking for a way to make this simpler and hoped for support of the fingerprint sensor on remote systems.
CLI access for team members in a read only mode
Hi, i've been wondering if there is an option to create a group in your Team where you give users the option to use cli with limited access to only let it do non changing things like reading secrets/variables as from my understanding so far cli access mostly came allong with the permission to manage things. Is there any way to do that currently as otherwise i wouldnt really know how to do that. Kind regards, -kiru
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?.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øvring1Password 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
New Feature Request: Copy Item Reference
When we right click on a secret there's a function called "Copy Secret Reference" in a UI application. We need similar thing to copy item title as "Copy Title Reference"... ex: Vault: STAGING Title: PROD_URL Copy reference will return "op://STAGING/PROD_URL" Believe me people need this.
console logs: unable to filter out 1password logs in local development
As a front end developer, I have a feature request: the ability to turn off logs from the 1password extension. This could be just a checkbox to enable/disable logs, maybe a developer mode for debugging implementation which enables logs, anything! Maybe logging them as `console.debug` instead of `console.log`? A checkbox for disabling logs on `localhost` only? I love 1password, don't get me wrong. But the logs have been the bane of my existence when working on any web app involving authentication, because there's no way to filter out the logs. Example output: background.js:80 📤 Sending <NmLockState> message to native core <2920926948> 11:00:39.169 background.js:80 📥 Received message <NmLockState> from native core <2920926948>. Duration: 4.3ms 11:00:54.167 background.js:80 📤 Sending <NmLockState> message to native core <1746240738> 11:00:54.171 background.js:80 📥 Received message <NmLockState> from native core <1746240738>. Duration: 4.6ms 11:01:09.172 background.js:80 📤 Sending <NmLockState> message to native core <4161527562> 11:01:09.183 background.js:80 📥 Received message <NmLockState> from native core <4161527562>. Duration: 11ms 11:01:21.119 background.js:80 📤 Sending <NmLockState> message to native core <951950119> 11:01:21.151 background.js:80 📥 Received message <NmLockState> from native core <951950119>. Duration: 31.7ms 11:01:24.171 background.js:80 📤 Sending <NmLockState> message to native core <2174341925> 11:01:24.176 background.js:80 📥 Received message <NmLockState> from native core <2174341925>. Duration: 5.8ms 11:01:39.173 background.js:80 📤 Sending <NmLockState> message to native core <1407972505> 11:01:39.186 background.js:80 📥 Received message <NmLockState> from native core <1407972505>. Duration: 12.6ms 11:01:54.171 background.js:80 �� Sending <NmLockState> message to native core <2421987558> 11:01:54.184 background.js:80 📥 Received message <NmLockState> from native core <2421987558>. Duration: 13.1ms 11:02:09.172 background.js:80 📤 Sending <NmLockState> message to native core <630129950> 11:02:09.188 background.js:80 📥 Received message <NmLockState> from native core <630129950>. Duration: 15.8ms 11:02:21.119 background.js:80 📤 Sending <NmLockState> message to native core <964956985> 11:02:21.123 background.js:80 📥 Received message <NmLockState> from native core <964956985>. Duration: 4.5ms 11:02:24.171 background.js:80 📤 Sending <NmLockState> message to native core <3234675529> 11:02:24.177 background.js:80 📥 Received message <NmLockState> from native core <3234675529>. Duration: 5.8ms 11:02:39.170 background.js:80 📤 Sending <NmLockState> message to native core <714895378> 11:02:39.176 background.js:80 📥 Received message <NmLockState> from native core <714895378>. Duration: 5.5ms 11:02:54.171 background.js:80 📤 Sending <NmLockState> message to native core <1997105720> 11:02:54.178 background.js:80 📥 Received message <NmLockState> from native core <1997105720>. Duration: 7.5ms 11:03:09.173 background.js:80 📤 Sending <NmLockState> message to native core <1243253266> 11:03:09.199 background.js:80 📥 Received message <NmLockState> from native core <1243253266>. Duration: 26.2ms 11:03:21.175 background.js:80 📤 Sending <NmLockState> message to native core <3734071001> 11:03:21.181 background.js:80 📥 Received message <NmLockState> from native core <3734071001>. Duration: 6.5ms 11:03:24.171 background.js:80 📤 Sending <NmLockState> message to native core <1854610928> 11:03:24.173 background.js:80 📥 Received message <NmLockState> from native core <1854610928>. Duration: 2.6ms 11:03:39.171 background.js:80 📤 Sending <NmLockState> message to native core <3181823558> 11:03:39.176 background.js:80 📥 Received message <NmLockState> from native core <3181823558>. Duration: 4.7ms 11:03:54.171 background.js:80 📤 Sending <NmLockState> message to native core <3797715197> 11:03:54.180 background.js:80 📥 Received message <NmLockState> from native core <3797715197>. Duration: 8.8ms 11:04:09.171 background.js:80 📤 Sending <NmLockState> message to native core <2885493011> 11:04:09.177 background.js:80 📥 Received message <NmLockState> from native core <2885493011>. Duration: 5.5ms 11:04:18.049 background.js:80 📤 Sending <NmLockState> message to native core <386599336> 11:04:18.052 background.js:80 📥 Received message <NmLockState> from native core <386599336>. Duration: 3.2ms 11:04:24.171 background.js:80 📤 Sending <NmLockState> message to native core <3057763534> 11:04:24.177 background.js:80 📥 Received message <NmLockState> from native core <3057763534>. Duration: 6.6ms 11:04:39.171 background.js:80 📤 Sending <NmLockState> message to native core <3449831082> 11:04:39.174 background.js:80 📥 Received message <NmLockState> from native core <3449831082>. Duration: 3.1ms I've also found these other relevant posts on the same issue with no solution: How to silence 1Password noise in the browser console | 1Password Community Chrome extension background.js logs and/or errors in console | 1Password Community Sending <NumLockState> messages | 1Password Community
