Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
FR: Allow Environments to reference Vault Items
Description: Currently, 1Password Environments and Vault Items are two completely separate systems with no connection between them. This creates a fundamental problem for professional workflows: Environments provide fast, secure secret delivery via Named Pipes – great for local development Vault Items provide rotation, audit trails, access control, and CLI management – great for operations But you have to choose one or maintain both in parallel, which means either giving up rotation or giving up fast secret delivery. Proposed Solution: Allow an Environment variable to be linked to a Vault Item. The Environment would act as a structured view over Vault Items, not a separate data store. Benefits: Single source of truth – secrets live in Vault Items, Environments just expose them Rotation works automatically – rotate the Vault Item, the Environment reflects the change immediately Audit trail remains intact – all access and changes tracked in Vault Items Named Pipe delivery stays fast – no change to the developer experience
Environments should quote .env values
I just started experimenting with Environments to mange my .env files. I use https://direnv.net/ to load my .env files into my shell and it immediately started complaining. As it turns out, my previous plain text .env had quoted values in some cases, for instance a secret that contains a "&" and another one with ")". It would be nice if Environments either quoted values by default or offered the option to do so. Would also be nice if my #comments were preserved on import.
1Password 'Environments' and monorepos/collocated deployment configuration
I'm fiddling with Environments today to see how it would work for my workflows, and immediately ran into two fairly significant blockers: ## Multi-environment orchestration The only way I can see to get an environment-ID into an `op run` command is as a flag/env-var pre-dispatch; but for something like Ansible, where an entire inventory of tasks require a complex mapping of projects/apps/secrets/teams, that would require centralizing all of the "environment IDs" into one top-level invocation, irrespective of what actual tasks the given Ansible command might run. (This isn't Ansible-specific, "ansible" here could be any complicated orchestration tool that makes intelligent decisions about what to do for multiple potential environments.) Yes, I'm sure the blessed path, or what would be ideal for 1P, is that each possible orchestration tool in existence use the 1P SDK, have a built-in, or a plugin, or something like that, so that 1P is separately queried for each target/environment - but there will always be *some* tool that doesn't (up to an ad-nauseum target of "all of our deployment is bespoke by scripting.") At the moment, this situation is still better served by the previously-extant `op://` references in static env-files: they're "discoverable" during the process, in that anything/everything present in the environment is substituted at launch-time; but that's also worse in its own way - they're less isolated, and it leaves a similar "collect all the environment for all possible targets first, before executing the orchestrator." I don't necessarily have a specific feature-request or a way I imagine this working, right now; I just wanted to surface the annoyance for you to consider as you're working on the feature. (Related issue, similar vein, but not exactly the same architectural problem - there's only one `OP_ENVIRONMENT_ID` env-var; and while the `op run` can take multiple environment-flags, that's again a single-point-of-invocation issue. Ways to construct partial environment-based assignments pre-invocation is missing here, unless you store them manually and construct some method of passing them to `op run` - i.e. there's no equivalent of `op://` references, where multiple different scripts and wrappers can all happily contribute multiple `op://` references into the environment without coordinating, and one final `op run` can consume/resolve all of them for some sort of commit/apply process.) ## Duplication of secrets This one is the much bigger one, and kinda a dealbreaker, at least for me. For basically any given secret, I *already* have a central, authoritative 1Password entry as the source-of-truth for that - it has version-history, shared notes, access permissions for people, it autofills browsers and logins and CLI invocations ... but at the moment, "1Password Environments" only allows me to put in 'dumb strings' as variable-values. Which means that I need to, say, *duplicate* a database-user password in both 1. a 1Password vault-entry, and 2. a 1Password environment-variable. (... and then document somewhere that it's been duplicated; and establish process to make sure anybody modifying it knows to go modify both; and, and, and ...) I assumed when starting this out that the entire point of 1Password environments would be, effectively, something like a templating system: include, inline in the definitions, the equivalent of `op://` references to other *existing* secrets, such that they're filled in when actualized onto the filesystem or requested from SDK apps. (Think, "username" and "password" are already in a database vault-entry; so the `DATABASE_URL` env-var configures how to construct the database-url from those keys.) Without that functionality, I'm actually a little lost as to the value/purpose of environments (not to criticize anyone's hard work, or anything; I'm sure there's a pictured use-case that makes sense, I'm just not currently managing to see it, haha.) So, the request here is a little more direct: let me configure references to other 1Password items in environment-variables - at a minimum as a 1:1 correlation (i.e. `DB_USER` being configured directly to `op://Team Secrets/Database - Prod/Postgres/username`); but ideally, with some minimal templating, so additional content/simple structure can be hardcoded into the env-vars that are *mostly* derived from secrets (Postgres connection-strings/URLs; or derivation from other env-vars to avoid duplication on that end either, such as configuring `USER_PW` to `op://Team Secrets/${HOSTNAME}/password`.) Hope this is helpful feeback about the issues somebody ran into in the real-world trying to apply this! I *do* love the promise of ditching env-files-full-of-`op://`-references-hardcoded-into-repos, in favour of something more auditable / sited-with-the-secrets-in-question / dynamically-configurable.
Domain Migration/Merge
I am not sure if there was an option, may of the settings became unavailable once 1P was connected to an IDP(Rippling). 1- We are rebranding and migrating from domain W to domain A, is there a way to rename users from user @ w.com to user @ a.org while keeping their access and accounts? 2-I've also seen a few users having both a.org and w.com accounts, is there a way to merge the two under a.org? 3-When a user is offboarded they may have passwords not saved in a shared vault, I would manually login as the user to access those. Is there an admin tool/function to transfer those vault items to their manager? Thanks!
Support for Imput's Helium Browser
Hiya! I'm an avid 1Password user and I utilize every possible corner of it. BUT there's a certain issue that I'm facing when I'm using it with unsupported browsers. Mainly, Helium Browser (https://github.com/imputnet/helium) which includes unbiased privacy at no compromise to webpage functionality isn't supported. This is an issue because there's no other browser I'd use. The problems that arise are apparent on all platforms, like: Manual addition in the 1Password app on macOS (which, lately, seems to spaz out when using it with the extension) Inability to use with the system app on Windows which inconveniences users by making them log into their vault twice (which, if I guarantee, many have a complex password for and can't bore themselves typing it out multiple times per session) Broken behaviour on Linux, where even with the custom browser config it still can't unlock the vault if it's unlocked on the system. No, I wasn't running the Flatpak version. IMHO 1Password is better than the competition in terms of UX, but seeing my daily driver struggle with that with no way to fix without resorting to this is awful.Prioritizing Multiple Accounts
I am the travel arranger for my family, so I have multiple accounts with one airline saved in my 1Password. The unfortunate bit is that now when I log into my account, 1Password chooses my kid's account as the default instead of mine. Is there a way to order them so that my account comes up as the default? If I could just ask it to not sync family's passwords to my phone, but leave them on my computer only, that would be another way to fix it.iOS App does not allow Account Change
I would have simply submitted this as a bug via your app, but apparently 1Password does not make things easy so here I am submitting on the forum. I recently had to switch my Family account from I password US to 1Password Canada and that meant logging into the new account on all my devices. On the iOS based devices though I could not simply log out of the old account and then log into the new account. The only option was to enter my password so I have to delete the app and re-install.How do I get rid of these annoying popups?
Often when I have just logged in to a site on Safari, one or the other of these popups, shown here, comes up. They are unnecessary, particularly the first one, since I know how to do these actions on the 1Password site on the rare occasion they are needed. How can I turn these off?
