# ZopDay VM Container Secrets Live in Your Cloud's Secret Manager > A secret is safe only if there is no later screen where it can be read. ZopDay VM services now let an org admin mark an environment variable as Secret, in a service's Settings and in Deploy a new… Source: https://zop.dev/resources/blogs/zopday-vm-secret-env-vars-stored-in-your-cloud-secret-manager Published: 2026-10-14 · Author: riya-mittal · Tags: cloudops, secrets, zopday --- A secret is safe only if there is no later screen where it can be read. ZopDay [VM services](https://zop.dev/resources/blogs/zopday-push-to-deploy-vms-managed-load-balancer) now let an org admin mark an environment variable as Secret, in a service's Settings and in Deploy a new revision. The value is stored in [your cloud's Secret Manager](https://zop.dev/resources/blogs/leveraging-robust-secrets-management-for-secure-data-handling-in-modern-applications) and is never shown again. The row keeps the key and shows a masked value. This works on ZopCloud too, where the secret is stored under the account that runs the shared pool. A write-once secret is a value that can be set and replaced but never read back through the product. The sections below show how each part of the design keeps that promise. ## The Browser Gets a Reference, Never the Value When an admin saves a Secret row, the provisioner writes the value to the cloud's secret store and hands back a reference. The service configuration keeps that reference, not the value. Every later read of the service therefore returns a reference and a masked row. The write needs the deployment it belongs to. The secret's name is built from a short hash of the organization, a short hash of the deployment and the variable's key. A value must be a single line of at most 32 KB. Architecture diagram The name carries the owner. Because the organization and deployment hashes are part of it, ownership can be checked from the name alone, without a separate lookup table. ## On a Shared Pool, Ownership Is Checked on Every Reference On ZopCloud, many [tenants run on one pool](https://zop.dev/resources/blogs/container-isolation-on-zopcloud-one-network-per-app), and the secret lives in the pool owner's cloud account. That makes the ownership check the important part: a reference on a shared pool is accepted only if the tenant owns it. | Kind of secret | Can a tenant reference it? | |---|---| | Its own VM environment secrets | Yes | | Its own database passwords | Yes | | Its own VM [basic auth](https://zop.dev/resources/blogs/basic-auth-for-services-needed-one-endpoint-not-four) | Yes | | Another tenant's secret | No | Both configuration and the deployer run the check. A reference that fails it is refused instead of mounted. Without the check, a tenant who guessed another tenant's reference could point a service at someone else's value. This works when every reference goes through one of those two gates. It stops protecting a tenant if a new code path stores a reference without passing through them. That is why the old path that wrote a VM secret by resource id has been removed. ## Secrets Are Deleted When Their Owner Goes A secret that outlives its service is a value nobody is watching. Configuration publishes an event whenever an update drops a reference, and again when a service, an environment or an organization is torn down. A subscriber in the provisioner deletes the secrets named in those events. Cloning follows the same rule: a cloned service has its VM secret references stripped. A clone therefore never points at a secret that another service owns, and deleting the original cannot break it. For assistants, MCP gains set_service_secret and delete_service_secret, both requiring organisation update permission. App secrets for Helm and cluster workloads are unchanged, and there is no migration.