Protect what matters – even after you're gone. Make a plan for your digital legacy today.
beta environments
13 Topics.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øvring159Views2likes7CommentsEnvironments: Feedback
Today I tried fiddling with Environments beta feature on 1Password and wanted to leave some feedback. Background: We currently use AWS secrets for managing 200+ secrets in our application, but due to the lack of backups/redundancy I started looking at alternatives and considering we already heavily use 1P, I thought I'd give Environments a go. Generally speaking I love it. It is precisely what we need, however a few things came up along the way which I would like to share: [P0] The UI needs improvements (and probably soon). There's no sorting nor searching for variables, making it very diffcult to find stuff when you have 100s of variables. — on web variables don't show up at all. [P1] The AWS integration errors when the secret already exists. This made things a bit awkward for us, considering we manage our infra via Pulumi and we couldn't "create" the secret via Pulumi (had to do some hack to get around this). — this can become important if one wants to give 1P AWS role a very strict access (just the managed secret, not a wildcard policy as suggested in the docs). [P2] Ideally would be awesome to have a pulumi provider and fully manage Environments via pulumi (only the setup, not the variables). [P1] There is share with individuals but no share with "a team of people". Thanks again and keep up the good work. 🙌39Views0likes0CommentsEnvironments: Feedback
Today I tried fiddling with Environments beta feature on 1Password and wanted to leave some feedback. Background: We currently use AWS secrets for managing 200+ secrets in our application, but due to the lack of backups/redundancy I started looking at alternatives and considering we already heavily use 1P, I thought I'd give Environments a go. Generally speaking I love it. It is precisely what we need, however a few things came up along the way which I would like to share: [P0] The UI needs improvements (and probably soon). There's no sorting nor searching for variables, making it very diffcult to find stuff when you have 100s of variables. — on web variables don't show up at all. [P1] The AWS integration errors when the secret already exists. This made things a bit awkward for us, considering we manage our infra via Pulumi and we couldn't "create" the secret via Pulumi (had to do some hack to get around this). — this can become important if one wants to give 1P AWS role a very strict access (just the managed secret, not a wildcard policy as suggested in the docs). [P2] Ideally would be awesome to have a pulumi provider and fully manage Environments via pulumi (only the setup, not the variables). [P1] There is share with individuals but no share with "a team of people". Thanks again and keep up the good work. 🙌3Views0likes0CommentsEnv 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 plugin46Views2likes0CommentsEnvironments 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=uophfpanfphbofsgfoibCVHDFBahpis19Views0likes1CommentIntroducing 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? Watch the demo video below. Video not displaying? Watch it here. 💬 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.1.2KViews6likes16CommentsEnvironments: any plans for CLI/API support?
Our team would love to adopt Environments but are running into some limitations: Programmatic writes to Environments Are there plans to support creating/updating Environments and their variables via the 1Password CLI or 1Password Connect? Currently, AWS Secrets Manager is our source of truth for application secrets and we have a Lambda job that syncs those secrets into 1Password using the 1Password CLI. We’d love to switch that sync to populate Environments, but we can’t do that (yet?) without a write API/CLI for Environments. Headless/CI usage We’d like to use Environments in CI. Unless I’m missing something, mounting Environments appears to be configured solely through the UI right now. Is there a way (or plan) to support Environments in CI pipelines, e.g. via a GitHub Action? For context, today we make this work with 1Password CLI + secure notes + secret references, which is fine, but the named pipe pattern would simplify a lot of workflows for us. Thanks!67Views0likes2Comments1Password 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!159Views3likes2Comments.env not mounting on filesystem
Hi folks, Very excited to try out local Environments on my macOS system, but unfortunately I can't mount the .env on my local file system. Created new environment and added two keys Chose "Local .env file" as my destination Chose my project directory, and chose `.` Opened new terminal window. `op` active. In my project directory, tried `ls -la` and do not see `.env`. Tried `cat .env` and get file not found error. Software: Latest macOS 26 1Password for Mac 8.11.16 (81116035) op 2.31.1 op account is logged in Any thoughts?Solved55Views0likes4Comments.env file comments preventing use of .env
I really want to like the local .env handling. However the header inserted in the .env file as a "warning comment" is interfering with my usage. If I regenerate the .env file from 1Password after loading my original, it inserts a "header". ``` # 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 ``` if I try to use this file locally it immediately files to export the env vars: [13:47:14] (base) ➜ xxx git:(development) export $(< .env) export: not an identifier: 1Password. If I remove the 2 header lines (I do not need to be warned) then it works perfectly.Solved49Views0likes2Comments