Protect what matters – even after you're gone. Make a plan for your digital legacy today.
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 var loading and validation for 1Password (open source!)
If you are using 1Password to manage any dev/application secrets, you might be interested in our open source tool - https://varlock.dev We just released a new update that introduces a plugin system and our first plugin is for 1Password (of course) - see https://varlock.dev/plugins/1password/ Our tool lets you define a .env.schema file, which can contain decorator style comments to add additional metadata to your env. This is then used to do validation, generate types, etc. The tool also introduces a new function call syntax, and while you can talk to any external cli using the exec() function, the new 1Pass plugin also adds a new op() function which fetches items from 1Password. So how is this different from using `op run`? Uses the SDK and service account tokens for deployed environments, and (optionally) uses op CLI for local dev (with biometric auth via the desktop app) Adds validation and coercion Automatic type generation (right now just for TypeScript, more to come) Understands which items are sensitive, and adds leak detection when possible Supports loading multiple env-specific files (.env.local, .env.production, etc) Supports explicit imports to break up files however you like Drop in integrations for many frameworks You can also use Varlock alongside the new https://developer.1password.com/docs/environments/ by syncing your environment to a local file (such as `.env.local`) and varlock will automatically load those values, and apply its validation on top. Would love for y'all to take a look, and to hear what you think! Oh and please give us a ⭐ on GitHub @ https://github.com/dmno-dev/varlock --- An example .env.schema file using the new 1Password plugin
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!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?
"op inject" does not find item in vault
Hi, I'm currently trying to generate a .env file locally using a .env.reference containing secret references, but I keep getting an error when running op inject. Any help on this would be much appreciated. --- .env.reference APP_ENV="op://Env_Server_Local/APP_ENV/password" FRONTEND_APP_URL="op://Env_Server_Local/FRONTEND_APP_URL/password" SERVER_URL="op://Env_Server_Local/SERVER_URL/password" > When running op read, it works % op read op://Env_Server_Local/APP_ENV/password development > When running op inject to generate the .env file, it fails. The secret does exist and was not deleted or archived. % op inject -i packages/server/.env.reference -o packages/server/.env [ERROR] 2025/06/13 08:45:14 could not find item APP_ENV in vault Env_Server_Local, because it has been deleted or archived. Please restore the item if you want to use it with secret provisioning. I feel it might be due to adding new items to the vault / updating existing items. --- 1password-cli : 2.31.1 desktop app: 1Password for Mac 8.10.80 (81080023) ---- This is blocking us from fully integrating 1password as secrets manager. Any help appreciated 🙏
CLI Slow Performance
I have the 1Password desktop app installed and up to date on my macBook Pro, the `op` CLI is also installed, up to date, and working properly. All expected CLI queries work but they are surprisingly slow. After a bunch of trial and error, it seems that it is making a round-trip online as part of every single CLI query. I added the --debug flag and I can see cache hits, but the round trip online is still occurring. Disabling the network interface causes all queries to fail. Is it possible to get the 1Password CLI working fully offline to avoid all of this unnecessary round-trip business? Surely with the desktop app installed and CLI integration turned on, there has to be a way to make efficient (and offline) use of my 1Password vaults. Otherwise automation tasks that require secrets are simply too cumbersome to handle with 1Password, and I will require a secondary solution. And in that case, I may as well give up on 1Password.
Terraform plugin troubleshooting
I am troubleshooting some credential issues with the 1Password CLI terraform plugin. The plugin is in beta, I use `op` version `2.31.1-beta.01` as the latest beta version with the plugin at the time. Issue: the terraform output command does not get credentials. Baseline execution, credentials defined in environment, export AWS_ACCESS_KEY_ID="..." export AWS_SECRET_ACCESS_KEY="..." terraform init # works terraform apply # works terraform output # works unset AWS_ACCESS_KEY_ID="..." unset AWS_SECRET_ACCESS_KEY="..." Executing using the same credentials but stored in 1Password: op plugin init terraform # Choose key from 1Password op plugin run -- terraform init # works op plugin run -- terraform apply # works op plugin run -- terraform output # Error: No valid credential sources found The expected behaviour is that terraform output also works. Here's an example Terraform script that I used for testing: terraform { required_version = ">= 1.9.0" required_providers { aws = { source = "hashicorp/aws" version = "~> 6.0" } } backend "s3" { bucket = "something-something-terraform-prod" key = "test/terraform.tfstate" region = "eu-central-1" use_lockfile = true encrypt = true } } provider "aws" { alias = "bootstrap" region = "eu-central-1" } data "aws_caller_identity" "current" { provider = aws.bootstrap } provider "aws" { region = "eu-central-1" assume_role { role_arn = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/terraform-prod" } } data "aws_key_pair" "test" { key_name = "test-key-that-already-exists" } output key { value = data.aws_key_pair.test.key_name } Note that I use "assume-role" in the script, but this had no issues when using environment variables. I did NOT request a session token manually. I let terraform do the session management itself. The AWS provider is a bit overcomplicated, but this is what I had at hand. Terraform output works when using environment variables, and does not work when using the 1Password plugin. I ran terraform with trace level logs. I compared a working and a non-working log and the only difference is one line: 2025-09-19T21:14:32.935+0200 [TRACE] Meta.Backend: BackendOpts.Config not set, so using settings loaded from provider.tf:11,3-15 This makes me assume that the plugin does not hand over credentials to terraform when the "output" command is run. Since the state file can be stored on S3, credentials are essential for the output command. For completeness sake, here's the non-working log (with some redactions): 2025-09-19T21:14:32.934+0200 [INFO] Terraform version: 1.13.2 2025-09-19T21:14:32.934+0200 [DEBUG] using github.com/hashicorp/go-tfe v1.74.1 2025-09-19T21:14:32.934+0200 [DEBUG] using github.com/hashicorp/hcl/v2 v2.24.0 2025-09-19T21:14:32.934+0200 [DEBUG] using github.com/hashicorp/terraform-svchost v0.1.1 2025-09-19T21:14:32.934+0200 [DEBUG] using github.com/zclconf/go-cty v1.16.3 2025-09-19T21:14:32.934+0200 [INFO] Go runtime version: go1.24.5 2025-09-19T21:14:32.934+0200 [INFO] CLI args: []string{"terraform", "output"} 2025-09-19T21:14:32.934+0200 [TRACE] Stdout is a terminal of width 144 2025-09-19T21:14:32.934+0200 [TRACE] Stderr is not a terminal 2025-09-19T21:14:32.934+0200 [TRACE] Stdin is a terminal 2025-09-19T21:14:32.934+0200 [DEBUG] Attempting to open CLI config file: /Users/user/.terraformrc 2025-09-19T21:14:32.934+0200 [DEBUG] File doesn't exist, but doesn't need to. Ignoring. 2025-09-19T21:14:32.934+0200 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins 2025-09-19T21:14:32.934+0200 [DEBUG] ignoring non-existing provider search directory /Users/user/.terraform.d/plugins 2025-09-19T21:14:32.934+0200 [DEBUG] ignoring non-existing provider search directory /Users/user/Library/Application Support/io.terraform/plugins 2025-09-19T21:14:32.934+0200 [DEBUG] ignoring non-existing provider search directory /Library/Application Support/io.terraform/plugins 2025-09-19T21:14:32.934+0200 [INFO] CLI command args: []string{"output"} 2025-09-19T21:14:32.935+0200 [TRACE] Meta.Backend: BackendOpts.Config not set, so using settings loaded from provider.tf:11,3-15 2025-09-19T21:14:32.936+0200 [TRACE] Meta.Backend: built configuration for "s3" backend with hash value 3136668788 2025-09-19T21:14:32.936+0200 [TRACE] Meta.Backend: working directory was previously initialized for "s3" backend 2025-09-19T21:14:32.936+0200 [TRACE] Meta.Backend: using already-initialized, unchanged "s3" backend configuration 2025-09-19T21:14:32.936+0200 [TRACE] backend-s3.aws-base: Resolving AWS configuration: tf_backend.operation=Configure tf_backend.req_id=8226a33c-d509-ad12-e84b-1a3c69daf0c1 tf_backend.s3.bucket=something-something-terraform-prod tf_backend.s3.path=test/terraform.tfstate 2025-09-19T21:14:32.936+0200 [DEBUG] backend-s3.aws-base: Resolving credentials provider: tf_backend.operation=Configure tf_backend.req_id=8226a33c-d509-ad12-e84b-1a3c69daf0c1 tf_backend.s3.bucket=something-something-terraform-prod tf_backend.s3.path=test/terraform.tfstate 2025-09-19T21:14:32.936+0200 [TRACE] backend-s3.aws-base: Building default HTTP client: tf_backend.operation=Configure tf_backend.req_id=8226a33c-d509-ad12-e84b-1a3c69daf0c1 tf_backend.s3.bucket=something-something-terraform-prod tf_backend.s3.path=test/terraform.tfstate 2025-09-19T21:14:32.936+0200 [DEBUG] backend-s3.aws-base: Loading configuration: tf_backend.operation=Configure tf_backend.req_id=8226a33c-d509-ad12-e84b-1a3c69daf0c1 tf_backend.s3.bucket=something-something-terraform-prod tf_backend.s3.path=test/terraform.tfstate 2025-09-19T21:14:32.936+0200 [DEBUG] backend-s3.aws-base: Retrieving credentials: tf_backend.operation=Configure tf_backend.req_id=8226a33c-d509-ad12-e84b-1a3c69daf0c1 tf_backend.s3.bucket=something-something-terraform-prod tf_backend.s3.path=test/terraform.tfstate ^[[31m╷^[[0m^[[0m ^[[31m│^[[0m ^[[0m^[[1m^[[31mError: ^[[0m^[[0m^[[1mNo valid credential sources found^[[0m A few questions in random order: Did anyone else experience similar behaviour? Is there a ticketing system where I can open an issue? Can anyone else reproduce the issue? Is there a known solution? Is there anything else I can do to provide information that could help solve this?Service Account Security (feature request)
I just started using service accounts, so forgive me if this has already been discussed. I did not find anything while searching the forum. A few things that would greatly improve the security of service accounts from the top of my head: IP-limits for access Alerts (watchtower?) for unauthorized access attempts I think there should be a way to limit service account access to only certain IP-addresses and environments. My proposal is a combination of pre-defined environments (maintained by 1Password) like AWS region XXX, AWS region YYY ... Lists publicly available here: https://ip-ranges.amazonaws.com/ip-ranges.json Github Actions, Github Copilot ... Lists publicly available here: https://api.github.com/meta Other relevant environments you can think of And one should obviously also be able to create private lists of IP-addresses/prefixes (both IPv4 and IPv6) that can be allowed to use a certain service account. This will seriously limit the amount of damage that can happen IF (when) a service account token is leaked somewhere. When this is in place, watchtower (or similar functionality) should be able to alert you if someone tries to use a service account from outside the limited environments where it is allowed to be used. That way, you will immediately be notified if a token might be compromised, and can rotate it. Of course, if you have limited a service account to only be used from a github action, and the evil hacker also uses a github action to access your secrets, you will not know - but that is no worse than the current situation. In best case, the evil perpetrator will test the token from an invalid location first, so you will be notified and can hopefully act before any other secret data has been compromised.
