Protect what matters – even after you're gone. Make a plan for your digital legacy today.
Environments with custom text file
So nice, I discovered the feature as I was about to develop a custom solution around 1Password CLI! Mounting a file is definitely the best path forward to get people to migrate to proper secrets management for local dev. Got some issues when used for the `.dev.vars` of a Cloudflare Worker project, but I'd bet that's a bug in `@cloudflare/vite-plugin`. What would be really awesome is to be able to have arbitrary text file stored securely in 1P and mounted at their destination. While the `.env` format covers most of our uses cases, we do have secrets in other formats like json files and a few other. this could be helpful for secrets in code source as well this would also help with people wanting to preserve their original .env formatting
FeatureRequest: SSH Agent Key access confirm
When using 1password as ssh agent, I miss the lack of possibility to define an ssh key as something like "confirm on each access". Not only like the current setting options "allow for all apps", "this app" and "this terminal session until closed". PRO of that feature request: better control of usage of a critical key, really on each usage. even with ssh agent forwarding the key would be usable on the remote host but also remain secure due to a second confirm request if it's used again f.e. by another connection created on the remote host. Would such a feature be possible in near future? What do you think about that idea? Best regards, Sam
Custom aliases and OpenSSH fields for SSH Bookmarks
SSH bookmarks is a great feature - one I was intending on building myself until I found 1Password's docs for it. However, it is missing a couple important features for me to be truly happy with it. I setup aliases for my common SSH hosts, and would like to be able to add these into 1Password. In particular, I want to be able to set custom names for each bookmark. For instance, I SSH to my university's servers typically with `ssh unsw`, not the far longer `ssh zXXXXXXX@loginX.cse.unsw.edu.au`, which is what the bookmark matches on. In addition, some of these bookmarks are for trusted hosts, where I want to enable `ForwardAgent yes` or similar additional OpenSSH options, and being able to use bookmarks to set these across my devices would be extremely helpful. Currently, I have a config file local to each computer that contains something like the following for each host: Host unsw User zXXXXXXX HostName loginX.cse.unsw.edu.au ForwardAgent yes CanonicalizeHostname yes This converts `unsw` to the long form user and host that is matched by the bookmark config. Ideally, these could all be configured via 1Password. A generic syntax for custom OpenSSH options would also solve other missing properties mentioned by others on this forum (e.g. ports).
Frustrations with .env File Handling and Environments in 1Password
To whom it may concern, I just tried to add some basic .env files to 1Password and was honestly surprised at how difficult and unsatisfying the experience was. I’ve always considered 1Password a premium, polished product, and I’ve really enjoyed using it so far. But in this case, the lack of functionality is pretty disappointing. I know you recently launched the Environments beta, which seems like a step in the right direction, but it’s clearly not fully fleshed out. Most programming projects of mine include multiple environment files, not just one. Some values in these files are sensitive, and others aren’t, so we should be able to choose which fields are masked (as passwords) and which are shown normally. Importing and exporting environment files should also be seamless, currently, it’s anything but. But the biggest issue with Environments right now is that they apparently don’t belong to vaults. That means I can’t share them with coworkers, which makes them basically useless for team projects. What’s the point of having them at all if they can’t be shared? So I tried workarounds: First, I attempted to store the variables in a secure note. While you can manually add fields, that’s clunky and time-consuming. Then I tried uploading the .env file to the note, but on macOS, the file picker doesn’t show hidden files, and apparently there’s no way to make it do so. This made it impossible to upload the file with its original name, a really basic oversight, and one that shouldn’t exist in a premium product. Next, I tried using a Document item. At least the drag-and-drop upload worked (unlike Secure Notes), but now I’m locked into a document type that only allows a single file. That’s just not workable when a project has multiple secret environment files. Even worse, if I want to replace the file, the drag-and-drop UI disappears entirely, so I can’t upload a hidden file again. I’d have to delete the entire document and start over. That’s absurd. I genuinely respect the work you’ve done on 1Password; it’s one of the few tools I’ve used that felt reliable and trustworthy out of the box. But these gaps in functionality around something as basic as handling environment files are frustrating. And for a product at this price point, I expect this sort of workflow to just work. It’s hard to believe these limitations haven’t already been addressed. On top of that, it was surprisingly difficult to even find a proper way to give feedback like this. That feels like a mistake, if users can’t easily tell you where the product falls short, you miss the chance to improve it. Anyway, I needed to get this off my chest. I hope this feedback is helpful, and that we’ll see improvements to these features soon. Best regards, Joël Grosjean.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øvringAPI key storage
In the new "Developer" tools, I'd love to see proper API key storage. Honestly a lot of this can be accomplished with standard 1Password tools but I want to keep passwords separate from API keys whether by category or just plain feature separation into developer tools. It would be great if the browser extension could differentiate between an API key / token and a password. Even if it can't it would be great to have an option to specify API vs password. One key difference between passwords and API keys is that on one site you generally have a single login/password but with API keys you have one site and many keys usually with key/value pairs. -- Example -- Type: API Site: Anthropic URL: console.anthropic.com Key name: Project A Key value: [32bit key value] Key name: Project B Key value: [32bit key value] Key name: Project C Key value: [32bit key value] --- \ Example --- Again, I understand you can make this work with existing passwords but API keys should be treated differently and have their own feature space. This is a good feature for developers, and when evaluating a 1password for Business feature space an IT admin has to deal with a lot of API keys and it would be good to store them securely and easily be able to identify which API keys they may need to rotate. API keys could also be worked into Watchtower as API keys that have been leaked or exposed in data breaches. API keys are not just used within .env files, it could be website and even AI desktop tools like MCP server settings.Password generator when exporting ssh keys
It would be nice to integrate the password generator when exporting ssh keys to create a random passphrase saved in the key entry in 1Password. The workflow for this is clunky currently as I create a new password field in the entry with a randomly generated password and then use that as the passphrase when exporting the key. Now, when the key is exported 1 password saves an entry of the passphrase used to export the key. Now I’ve got two entries for the same phrase. it would be a much simpler flow if the passphrase could be randomly generated inside the export key dialogue instead.
Environments feature request: Add notes to variables & insert them as comments in the final .env
Hey folks! I'm really liking the Environments Beta, but one thing I'm missing is the ability to keep the comments I had in my old manual `.env` file. For example I have an API key that has no indication of which actual account it's for, so it would be really nice to be able to add this as a note in 1Password and have it end up in the resulting .env file. So in this example, the "API_KEY" variable would have a note attached in 1Password that said "Associated account is frobulator@example.com" and the resulting .env file would look like this: $ cat .env # This file was generated by 1Password. Any manual edits will be lost. # For more information, visit: https://developer.1password.com/docs/environments/local-env-file BASE_URL=https://prod.example.com # Associated account is frobulator@example.com API_KEY=uophfpanfphbofsgfoibCVHDFBahpis
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!
