Question

.env files should support more file formats

Forum|Forum|9 months ago
September 30, 2025
5 replies
419 views

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øvring

A

Anonymous

Hi @simonbs ,

Another great request, thank you for sharing this. It is helpful to know you are using 1Password in your development flow for iOS apps. I too used to develop iOS apps and can relate to your pain. From your note, it sounds like the request is to output different types of files that could be defined by a template and then the Environments feature would replace the secrets (like you mentioned like 'op inject' does from the command prompt).

Something like this:

1) Define a template file with 1Password URIs (could be swift, could be .env, or any other format, but basically a text file)
2) Create a new environment that knows about this template file (from #1) define the secrets linking to the URIs
3) Define a destination 
4) Attempt to run a build process, that tries to access the destination from #2.

Let me know what you think.

Regards,
Phil & Team

simonbsAuthor

From your note, it sounds like the request is to output different types of files that could be defined by a template and then the Environments feature would replace the secrets (like you mentioned like 'op inject' does from the command prompt)

Yep, exactly. I think of the new .env support as writing secrets to a traditional .env template, but it could just as well be any other template, for example, one where secrets are written to a .swift file. If the .env feature of 1Password allowed us to supply our own template, similar to `op inject`, then this problem would be solved.

I'd love to test the flow you suggest, but I'm not sure I follow it. Here's what I've gathered so far:

- I think your bullet no. 1 is the `enum Secrets { ... }` that I have in my original post.
- In #2 I create an environment in 1Password with my secrets.

However, from there, I'm unsure what to do. What's my destination in #3, and how do the secrets end up in my .swift file so I can access them at runtime in my app?

A

Anonymous

Hi @simonbs ,

Thanks for the continued input, I was thinking about this over last night, perhaps you could have a Production Environment flow using the AWS Secrets Sync outlet for your production app whereby the environment gets pushed up to AWS and then you access the secrets from the the production app through an API request.

If you have AWS as a backend, there are Swift APIs you can use to access the AWS Secret Manager.

Thanks,
Phil

G

GSala

Similar to Simon, we would like to use Java Properties files for Android development with Gradle.
`.properties` files should be easier because they are basically `.env` files but with another extension.

P

pintaf

Hello.

I have just started using .env mounting system.

I would like to know if there is a way to access environment variables stored in 1p via one of the SDK or the CLI ?It doesn't seems like it's feasible, or at least the documentation is not clear about it because it always talk about vaults. And I don't know what is the path to access the ENV variables.
Secondly, I face the same issue as Simon, and would like to be able to mount any kind to file to any destination, like we do for .env files. My use case is that I have a database which is protected via user/pwd but also some certificates. Before the user and PWD were in the local .env file which is now stored and mounted via 1Password, but I still have those certificates which sensitives and are still unprotected on my HDD. Of course, I could probably find a way to get those files via the SDK/CLI - Wait, this is what I tried in point 1. And even though it was feasible, Then I still need those plain files for my database editor for example. So the ability to mount other things than .env file is really important in many use cases. I've also read somewhere that the limit is up to 10 mounted files ? is this limit per environment ?
That would be a nice step forward but still lacking flexibility, because maybe in your dev environment you have some env variables that are for your front-end and some other ones for the back-end. For me I think the best approach is to Keep It Simple Stupid, and to treat everything as a file. A file that you can mount. Here I don't see any benefit of storing each environment variable individually, especially since as fas as I know the only way to access them from outside of 1p is by mounting them, since we can't access them via SDK or CLI. So no reason to keep them this way. Maybe there is a reason with AWS but we don't use GAFAM technlogiees
I find the concept of "environments" under used. Currently it seems you can enter as many variables for this environment, but you can only mount them in one .env file.
As explained in point 2, there could be some cases where you have multiple files per environment and so currently, I don't see how it can be feasible except by creating multiple environments: 'dev-env-vars' 'dev-root-crt' 'dev-clien-key'. I don't think this approach is maintainable and is mor like a hack. An environment is semantically speaking a grouping of files, code, secrets that work together. So maybe here you could add a new tab "files" between "Variables" and "Destinations"
This is about another topic, but while I'm at it writing this novel:
The issue about the limit of the "too many authentication failure" and the six ssh keys for connecting to a server is annoying. Of course the new bookmarks feature is nice, but we can't easily add a new bookmark, we need to do it from history. But if you have no history for this connection, then you need to download the SSH key from 1P, store it in .ssh folder, make the connection with -i option, and then you can finally add it in the bookmarks. Not easy. Why not permitting in the UI to add a new entry, select the ssh key and add the connection string?
Also, annoying thing, even though you have defined the bookmarks, that still doesn't prevent you from encountering the issue if you directly connect to the server via SSH. you MUST do it via the bookmarks tab.
Yet, I do think there are chances this can be avoided. Here is the .ssh/config file after the 1P ssh agent is configured:
Host *
IdentityAgent ~/.1password/agent.sock

As per the man pages of SSH config (https://man.openbsd.org/ssh_config#IdentityAgent) it seems the IdentityAgent can receive parameters (TOKENS). And there is a token I find particularly interesting "%h -> The remote hostname"
So maybe something like this:

Host *
IdentityAgent ~/.1password/agent.sock %h
Could permit your ssh Agent to receive the hostname (there's also %r for the user) and match this against the bookmarks to return the correct key ?
Lastly (I promise). I would love that the 1P CLI (or maybe it is not needed, just documentation) would permit to programmatically mount the .env (and others to come) files.
The reason behind that: We've streamlined our process of developer laptop bring up, and with this we could have a new developer ready to operate in minutes because in one script, his private SSH key (stored in 1 password) will be binded to git, permitting him to clone the repositories. Once cloned, the rest of the script would mount the necessary .env and other files. then, we're just one docker-compose away from a whole stack ready to operate. A nice improvement compared to the current situation where it can take up to half a day, requiring a senior dev to assist with the setup.

Regards

P

pintaf

I forgot to tell: We're under linux, and happy to be beta tester of any evolution

M

mehmood7865

Thanks for sharing this, Simon. I agree it would be very helpful if 1Password Environments could work with more file types, not only .env files. Many mobile developers use .swift templates, so having secrets added directly into those files would make things much easier. Hope the team adds this in the future.

C

cjs226

+1 I ran into a use case where support for the document item type was needed, since that's how a license file was stored.

+1 I really wish you could use a link from an existing resource in 1P. For example, I could use an API key across multiple environments that could be easily rotated. Now, I have to rotate it across numerous places...if I remember.

Sign up

1Password employees: Sign in with SSO

Login to the community

1Password employees: Sign in with SSO

Scanning file for viruses.

This file cannot be downloaded