feat: environment access (#172)

Author: StashBank

docs/features/tags-environments.mdx

@@ -335,3 +335,26 @@ Tags and environments integrate seamlessly with your existing [CI/CD pipelines](
 Many teams configure their CI to automatically update a "latest" tag when tests pass, trigger staging deployments when code merges to main, and provide promotion tools for moving releases to production.
 
 Since everything works through Zephyr's API, you can integrate with any CI/CD system and create custom workflows that match your team's processes exactly. Learn more about [automation workflows](/features/automation).
+
+## Deploying to Specific Environments
+
+Zephyr now allows you to precisely control deployments to individual environments. To deploy to a specific environment, you can pass the `ZE_ENV` variable during your build process. For example:
+
+```bash
+ZE_ENV=production pnpm nx run team-blue:build
+```
+
+To enable environment-targeted deployments:
+
+1.  Create an Application Tag with the condition: environment is `{ENVIRONMENT_NAME}`
+2.  Create an Application Environment associated with that tag.
+    For example, if your environment name is `production`, you would set the tag condition to environment is production and run the build using `ZE_ENV=production`.
+
+### Managing Who Can Update an Environment
+
+You can also control who has permission to deploy or update each environment:
+
+- Enable the “Make environment protected” option on the environment settings page.
+- Add individual users or teams under the Members section.
+
+When protection is enabled, only the users or teams explicitly listed as members will be allowed to update that environment. This is especially useful for safeguarding production environments.