Frustrations with .env File Handling and Environments in 1Password

Honest question: what's the value of this Environment feature, over having actual .env committed in the repo, where each variable is a 1password reference like `MY_VAR=op://vault/item/field` ? That's what I'm using right now, and quite happy about it?

...and here is another customer, who pulls his hair on the environments implementation. What on earht have you done?? It just has NOTHING to do with 1Password usability and practicability I am used to! The feature is plain unusable at the moment. Seriously. There is NO use for ANY developer to manually dump secrets here. I'm not a full-fledged dev but I do code a lot and toss dozens of repo's, projects, contexts...hundreds of files leveraging secrets that need encryption, bringing 1Password into my central spot of daily work and life! And that's where you have to live up to very high standards of usability and practicability, keeping the other strong aspects like stability etc. of your product. I really value it! 

To be concret:
I know, the feature is beta and needs to grow. But: you suddenly cut out a critical detail some time beginning of July: I was able to reference the Variables from an environment via the CLI with op://ENVIRONMENTS/<Environment-name>/<item-name>
- > An Expected and useful behaviour reflecting the behaviour of secrets stored in other vaults. The feature was even documented but mid-July it suddenly didn't work anymore. Huh? I tested, researched my head off, double-checked my implementation (and my github workflows, which had been using it) - but the CLI never returned a value anymore. **bleep**! Why??? I had shifted dozens of secrets into about 12 Environments I had configured. I used the references all across my CI/CD pipelines successfully and was so grateful I found a solution to centralize my secrets while complying to latest security regulations.
That is impossible now. at least to some extent. You silently kill-switched the feature flag in the background, wiped the documentation from the doc pages. That is a clear sign of product strategy shift in the background. Fair enough! Your product, your call. But: what is the alternative? And where is the communcation? And why on heavens earth would any product manager go down that miserable route? Did I miss something?

What Environments SHOULD be:
A central hub for .env secrets across a multitude of projects, that can be referenced server-side, within CI/CD Workflows and locally. 
The integration to AWS secrets is a nice start - though I never used AWS before. Useless for me. But that's just my perspective.
Native integrations are a nice product polish but they should be much more generic to start with before you start implementing vendor-specific APIs.
Now that .env files can be dumped onto public servers again when all secrets are reflected by 1Password references, devOps life becomes a LOT easier and it makes sense, to keep those files updated/ in sync with a central secret repository (1Password Environments/Vaults). I don't want to manually update hard-coded secrets in a .env.tpl file for example. Ideally I would like to use wildcard patterns on secrets on those files to reference a whole cluster of secrets. ie: op://ENVIRONMENTS/WEBSITE-EXAMPLE/*
That way I can maintain my secrets in the 1Password app locally and always be sure, the server-side has access to the latest secrets within a project/ set - even if they get renamed. If I have to specify every single secret, that might be feasible in small projects but adds up overhead fast on bigger projects, besides introducing braking deployments when a secret name or location had to change locally. 
I am bewildered, that there is no real standard solution out there for this. I mean - GDPR, CCPA, etc. etc. all these data-privacy regulations introduced in the past years, continuously enforce stronger security measurements (for a good reason, mostly), make solutions like these extremely valuable on the market, if done right! Why is there not more focus on it? Why not push hard to gain exposure on the market and help millions of engineers to gain market-share?
I know, other platforms, providers etc. have to adapt and implement your server-side implementations but as long as it stays generic and powerful enough, a lot of vendors would do that (My assumption).
Juggling secrets in complex CI/CD pipelines is a nightmare. No standard solution out there! Looking at you, Portainer people...frown. I can see secrets leaking everywhere because developers are overworked, pissed off, technical constraints adding massive overhead to projects -> humans take the short route, if things don't work or take too much time, even if it is insecure. No matter the regulations. Not  good!
Environments are essentially projects. But what about sub-projects, nested applications?
Managing secrets is critical to keep an overview. Control and overview = Security. Added manual labour = insecure, if it scales.
A lot of words, forgive me. But the idea of having 1Password as my central Environments stash, is super! Stick to it! Build it as strong as the rest of the app. Make it usable - you have all the ingredients on the table already! 

Feature requests:
- Bulk Import is there, add bulk export please.
- add the very same action to the environments secrets as available to secrets from other vaults: let me copy the secret reference!!
- add bulk copy or export of all secrets within an environment as references so I can export them to .env files
- Destinations: add custom servers, VPS providers via SSH, SFTP etc.
- add native integration to Github secrets without using the workaround via the github service token
- extend the SSH Agents with the ability to reference all secrets from an environment (wildcards)
- make the integration of service accounts or the 1password server easier for containerization - that's still a nightmare (not a 1Password specific problem per se). Container -> host communication is the issue, when the 1password agent runs on the host and not within the container. The 1password CLI needs to be installed within a container in order to fully leverage it's potential...difficult or impossible in many situations where containers can't be customized due to rolling updates. Giving containers full host access is a security no-no, leaving me with a not smart, very limited broken solution.
- A remote sync functionality essentially exists via service accounts or 1password server - good!
- Optional: add nested environments

My temp. Workaround(s): 
I started creating vaults for my most important projects I require .env secrets for, shifting secrets from my private vault into them, sometimes I have to duplicate them to make them available across many vaults - super messy!
Now half a dozen vaults clutters up my 1Password space. Holy cow! No! I already have different Vaults for family members, customer projects etc. - that's more then enough to make my space look messy.
I might be a power-user but you're targeting them with such features, right?
Using other secret types as user tez4 did, is not a route I would like to take - too many constraints - and he is right. 

Decision making:
I stopped using environments, shifted the most important project to dedicated vaults, hoping you relieve me of this extremely underwhelming situation by extending the existing Environments solution with the basic requirements needed for devOps operations FAST. It's not optional, it's a necessity. You can ditch the feature without the mentioned additions.
I started looking into alternatives on the market, digging into their feature-set.

Hoping for a step forward on this feature sooner than later. 
Cheers,
James

Thanks tez4​ for trying the Environments beta and providing feedback! Some functionality you mention is in fact already available (but apparently not easy enough to discover?):

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

If you press Edit in an environment, you can toggle the eye icon to change whether the value should be masked or not.

Importing and exporting environment files should also be seamless, currently, it’s anything but

Importing can be done using the Import .env file button which brings up a dialog to select a local .env file to import. If you tried that out and think it's not seamless enough, could you describe what exactly went wrong or what you think could be improved?

Exporting is indeed not supported yet, but is coming soon.

What’s the point of having them at all if they can’t be shared?

If you click Manage environment > Manage access, you can invite users to collaborate in the environment. You can give them access to read, write or manage the environment.

Let me know if thats helps!