Envault

Envault is RDC Cloud's secret management product for API keys, credentials, and application configuration. Keep reusable values in one place, separate development and production settings, and link an application group's environment to a Container Engine workload.

Values are stored encrypted and stay hidden in lists. Workspace Envault Admin, General Admin and General Owner can create, reveal, replace, and delete secrets. Envault Viewer reads metadata; Workspace General Viewer and Secret Accessor also read values without permission to create, edit or delete secrets. Linking requires container binding permission and workspace secret-value access. Project roles alone do not grant workspace secret access. Application groups organize configuration independently of RDC projects.

Select a workspace in Console, then open Envault from Quick access or search. Envault is also available without an RDC project.

Application Secrets and Shared Secrets group lists use a fixed A–Z order by name, including when you load more groups. Environments inside a group keep their saved drag-and-drop order.

Opening an Application or Shared group shows Application secrets / group or Shared Secrets / group above its environment list, including groups with no environments. Select the section name to return to the group list.

In an Application or Shared group, drag an environment card into a new position. On touch screens, press and hold the card before dragging. Click a card or press Enter to open it. The order is saved for everyone in the workspace and remains after reloading. New environments appear at the end. Environment management permission is required. With a card focused, press Space, use the arrow keys, then press Space to save or Escape to cancel. Load all environment pages before reordering; up to 1,000 environments per group are supported. If another user changes the list first, Console refreshes it so you can retry. Reordering does not change environment names, secret values or container links.

Inside an Application or Shared environment, the path above Variables and Access shows group / environment, for example backend / production. Select the group name to return to its environment list. The path stays visible on both tabs, including environments with no secrets.

Saved keys appear in alphabetical order (A–Z) in Application Secrets, Shared Secrets and Workspace Defaults. This order is preserved when loading more keys or revealing all values. New unsaved keys stay at the top until saved.

Choose Console or CLICopy Anchor Link

See RDC CLI for login and CLI command reference for supported flags. CLI directory configuration does not change a Container Engine link.

Choose where to store a valueCopy Anchor Link

Use Shared Secrets for common groups reused by applications, with separate environments for development, production or global settings. Use Workspace Defaults only for values that should reach every supported application container in the workspace. Use Application Secrets when a value belongs to one application and environment, such as a production database URL.

For example, store PAYMENTS_TOKEN in payments-common / production and LOG_LEVEL=info in Workspace Defaults. In backend / production, create PAYMENTS_TOKEN=${shared.payments-common.production.PAYMENTS_TOKEN} alongside its own DATABASE_URL. A container linked to backend / production receives all three values.

Shared SecretsCopy Anchor Link

Organize common values into named groups with their own environments. For example:

• payments-common: develop and master
• analytics-common: develop and master
• global-common: global

1. Open Shared Secrets and choose Create shared group.
2. Name the group, open its card, and create an environment.
3. Open the environment and add its common keys.
4. In an application group or Workspace Defaults, use ${shared.group.environment.KEY} in the value to reference it. No Shared connection is needed.

Only referenced Shared values are used; creating a Shared key does not automatically inject it into every application. A connected Shared environment also delivers its inherited keys.

These groups are Envault projects, independent of RDC infrastructure projects.

Explicit referencesCopy Anchor Link

Application and Workspace values must use ${shared.group.environment.KEY}, for example ${shared.payments-common.production.PAYMENTS_TOKEN}. The group and environment must be in the same workspace. ${shared.KEY} is not supported, even if the key is unique; update any existing short references before deployment. Shared values are literal and are not recursively expanded. A missing reference stops delivery.

Workspace DefaultsCopy Anchor Link

Open Workspace Defaults and create a name/value pair. These values are common to Container Engine applications in this workspace, across projects and deployment-environment labels. They have no selectable environment. Use Application Secrets for environment-specific values.

Workspace values may reference Shared Secrets. Changing a value does not restart running workloads. Creation, start and redeployment apply the current values; a plain Restart retains the previously delivered configuration.

Application SecretsCopy Anchor Link

An application group is a named configuration container, such as backend. It contains environments like develop and production, each with its own secrets. Creating a group does not deploy an application.

1. Open Application Secrets, click Create application group, and name it, for example backend.
2. Select the application group card and create an environment, such as develop or production.
3. Select the environment card to open its secret list, then create secrets.
4. In Container Engine creation, or an existing container's Environment variables section, use Link Envault to choose the application group and environment. For an existing container, click Link Envault to save, then redeploy. Use Change link to choose another environment, or Cancel to discard changes.

Groups and their environments appear as cards with a name, creation date, and an actions menu (…). Group cards also show the number of environments. Open the menu to rename a group or environment, or delete an eligible item. Deleting a group permanently removes all its environments and secret records, including reserved names, and disconnects its container and Shared source links. Audit history remains available. Running containers retain previously delivered values until their next deployment. References in other secrets are not rewritten; missing references must be fixed before deployment or CLI export. Secrets appear as bordered key/value rows. Click Create secret (+) to add a yellow draft row at the top of the list. Click again to add more draft rows. Enter each name and value, then use Save changes next to the eye icon to save all new rows and edited values. Use a row’s cancel icon to discard only that draft. New rows and edited values are saved together. If any create or edit conflicts or fails, none of those creates or edits are saved and their drafts remain available for correction and retry. Each save supports up to 100 new rows and 100 edited values, subject to the request size limit. Type ${ in a value to choose a Shared Secrets reference. Reopen the environment to see newly added Shared keys without reloading the browser. Click a masked value or use the eye button to reveal values and immediately edit secrets you can manage. Inherited secrets remain read-only. Click a key or value to edit it inline, or choose Delete in the row toolbar to mark the secret for deletion. All new and edited rows use the same toolbar Save changes action.

Application group names use lowercase ASCII letters, numbers and hyphens, start with a letter, and have up to 50 characters. Application group names are unique within a workspace; environment names are unique within an application group. Use Rename in the card’s actions menu to change a name. Container links and connected Shared sources remain connected. Explicit references such as ${shared.group.environment.KEY} and CLI configurations that use the old name are not rewritten; update them before the next deployment or export. Reopen the secret editor to refresh reference suggestions after renaming. These groups are independent of RDC infrastructure projects.

Each environment has independent values. One container connects to at most one application group environment. An environment cannot be deleted while connected to a container, while it is connected as a Shared source, or while it contains active or deleted secret records.

Long values do not wrap automatically. Scroll horizontally to read a long line. Revealing or editing a value with actual line breaks expands only its value box; the name box stays aligned at the top. Pressing Enter adds a line, and removing line breaks shrinks the editor. Masked values stay on one line. Literal \n text is not converted to a line break.

Environment IP allowlistsCopy Anchor Link

Restrict Developer API and CLI secret downloads/runtime fetches to approved networks. Console access continues from any network with your signed-in account and IAM permissions. Automatic container injection is unchanged.

Open an Application Secrets or Shared Secrets group, select an environment, and open its Access tab to edit the Firewall Policy. Environment management permission is required. The Variables tab contains the environment's secret editor. Switching tabs within the same environment preserves unsaved variable and access-policy edits.

• Add up to 100 IP addresses or CIDR ranges. Each row can have an optional name, such as Office or VPN, up to 100 characters. Names are saved with the environment.
• Select Add address for another row or Use my IP to add your current public IP. Single IPv4 addresses receive /32; IPv6 addresses receive /128.
• Use the remove button to delete a row. Discard changes restores the saved list. Changes take effect only after saving. Duplicate addresses, invalid ranges and rows with a name but no address cannot be saved.
• Enter the public egress IP of your office, VPN or automation runner, rather than its private LAN address.
• Select Save changes to replace the list. An empty list permits any network, subject to IAM.

Downloads must satisfy the application's policy and all applicable inherited or explicitly referenced Shared source policies. Missing or unverifiable client addresses cannot read restricted environments. These rules do not revoke values already downloaded or injected into workloads.

If a CLI download is denied, use an approved network or ask an environment manager to review the application and its Shared sources. Managers can update policies in Console regardless of their current IP. Contact support if an approved network is still denied.

Effective container valuesCopy Anchor Link

You can paste a service-account JSON document directly into a secret value. Multiline JSON objects and arrays are compacted during container delivery while preserving their JSON meaning, including private-key newline escapes. The value stored and revealed in Envault remains unchanged. Redeploy the container to refresh delivered values; a plain Restart keeps the previous configuration.

Inherited Shared keys cannot be overridden. For other keys, priority is:

1. A container's individual runtime variable.
2. The connected application group environment.
3. Workspace defaults.

Only effective values are resolved. A lower-priority value overridden by a container or application group value is not delivered.

Inherited variables appear as managed by Envault in the container environment list, without their plaintext. Application-local and Workspace values can be replaced with container-local overrides. Inherited Shared keys must be edited at their source. Delete a local override to use the inherited value again on the next deployment. Remove inherited values at their source in Envault; they cannot be deleted directly in the container editor.

Clicking Unlink Envault saves the disconnection immediately. The next deployment removes the inherited application group values. Workspace defaults still apply. That deployment also removes previously managed keys that no longer have a source; container-local keys remain intact. A failed synchronization stops the deployment and can be retried. A failed attempt does not start a new workload; fix the reported issue before retrying.

Current delivery supports Container Engine Application resources. Imported Compose services and managed databases retain their own configuration and are not injected. Secrets are runtime-only, not build-time variables. CLI download includes the resolved Application environment.

Container operators can use values granted to their workload when they start or deploy it. Runtime and terminal access can expose a workload's own environment; Envault management permissions does not isolate a delivered value from that workload's operators.

View, rename, replace and deleteCopy Anchor Link

Secret names use uppercase ASCII letters, numbers and underscores, starting with a letter or underscore, up to 100 characters. Values allow multiline text and empty strings, up to 16,384 characters. Resolved runtime values must not contain a null byte or exceed 65,536 bytes.

Lists and Overview initially fetch metadata only. Click a masked value or the eye button to reveal values. Secrets you can manage immediately become editable; inherited secrets remain read-only. Changed rows have a blue border. Use Save changes in the toolbar to save changed rows. Displayed values and drafts remain when switching tabs and have no automatic timeout. Use the hide button to hide a value; leaving the page or changing scope also clears local plaintext. Names and environment labels are visible metadata; do not put sensitive values in them.

Click a key name to edit it, then select Save changes. You can rename a key while its value remains masked; renaming preserves the stored value. Press Escape in the name field to cancel that name edit. Name and value changes can be saved together. Names must be unique in their environment and must not conflict with inherited Shared keys. Edit inherited keys at their Shared source; viewing permission alone does not allow renaming.

Renaming does not update application code or explicit ${shared.group.environment.KEY} references. Update those references and redeploy affected containers to use the new name. A failed save keeps your draft available for correction; a concurrent-edit conflict requires refreshing and re-entering the change against the current revision.

Saving a value edit permanently replaces the current value. There is no version-history restore. Conflicting edits require refreshing the list. Hover over a local value cell or focus its controls, then choose Delete in the grouped toolbar beside Generate to mark it for deletion. The row stays visible with a red border and Pending deletion — save to apply. You can mark several rows and use Undo deletion to restore any row and its unsaved edits. Only Save changes commits the deletions; inherited rows must be changed at their source.

New and edited rows are saved together first, then marked rows are deleted one at a time. Marked rows are excluded from updates. The combined operation is not all-or-nothing: if a deletion fails, saved edits and completed deletions remain applied, while remaining marks stay available for retry. A saved deletion removes the value and retains its reserved name. Deleting a Shared value that is referenced makes subsequent deployments fail until those references are fixed. Use Audit to review secret activity.

Update a running applicationCopy Anchor Link

Generate a random secret valueCopy Anchor Link

Hover over a value or focus its controls with the keyboard, then select Generate to open the centered popup. On touch devices, the button is visible without hovering. Generation is available for new keys and local keys you can edit; inherited Shared keys must be changed at their source.

Choose Random string, Hex, or Base64url, and a length of 32, 64, or 128 characters. Random strings let you select allowed lowercase letters, uppercase letters, numbers and symbols. These choices define the allowed characters; they do not guarantee that every selected group appears. Changing an option clears the preview until you generate again.

Select Use value to replace the selected draft, then Save changes to persist it. Closing the generator without applying leaves the draft unchanged. Generation and preview happen locally in your browser, and the existing stored value is not fetched. Generated values are suitable for application-managed secrets; API keys issued by another service must still be obtained from that service.

After saving a replacement, redeploy affected applications as described below. Replacing a credential does not update other systems that use it.

Redeploy with saved changesCopy Anchor Link

1. Open the secret's Shared Secrets, Workspace Defaults, or Application Secrets section and click its value to reveal and edit it.
2. Save the new value. Existing running containers keep their current environment.
3. Redeploy each affected container. For Shared Secrets, these are containers using a connected Application or an explicit reference to that key; for Workspace Defaults, check the applications that inherit that default.
4. Check the container's deployment result and application behavior. A plain Restart does not refresh secrets.

To change the environment a container uses, open its Environment variables, select Change link, choose an application group and environment, and select Save link. Cancel discards your selection without changing the saved link. Redeploy to apply the new environment.

TroubleshootingCopy Anchor Link

Continue with Container environment variables or Deploy a container.

Container permissionsCopy Anchor Link

Container changes and deployment require the corresponding Container Engine or General role. Deletion requires Admin or Owner. Project authority does not grant Workspace Envault access. Linking requires both target-container binding authority and workspace secret-value access. Delivery rechecks project deployment permission before sending values.

CLI configuration, download and runtimeCopy Anchor Link

Follow RDC CLI login, then run these commands from your application's directory. The API address is configured automatically:

rdc login
rdc secret configure

Select your workspace, application group (the Envault project), and environment. The selection is saved under ~/.rdc/envault/ and associated with the current directory. It contains the directory, workspace, application group and environment selection, never secret values. Commands use the nearest configured directory, including a parent directory. Configure a subdirectory separately to override its selection; sibling directories remain independent. No configuration file is created inside your project. rdc secrets and rdc envault are aliases of rdc secret.

# CI / non-interactive configuration
rdc secret configure --workspace <workspace-uuid> --group backend --environment develop

# Run directly with secrets as child-process environment variables; no .env file is created
rdc secret runtime -- npm run dev
rdc secret runtime --environment production -- node server.js

# Download to .env (mode 0600 on POSIX); existing output is preserved by default
rdc secret download
rdc secret download --format json --output secrets.json
rdc secret download --force
rdc secret download --format json --stdout

Group downloads include Workspace defaults, all connected Shared environments and Application values, and resolve ${shared.group.environment.KEY} references. Application values take precedence over Workspace defaults. Only Application environments can be downloaded; direct Shared or Workspace downloads are not supported. runtime inherits local environment variables, then overlays the resolved Envault values. It excludes the reserved RDC_TOKEN variable from the child environment, including an Envault value with that name. The command after -- is executed directly without shell evaluation. Use an explicit shell when shell syntax is needed. Child output and exit codes are preserved; interruption is forwarded to the child. Programs started this way can access and print their environment, so their output is under that program's control.

Envault automatically supplies ENVAULT_GROUP and ENVAULT_ENVIRONMENT with the selected group and environment names. These reserved output values override colliding stored secrets and local runtime variables. CLI selection flags determine which environment is requested. They are also present in dotenv and JSON downloads. See automatic environment metadata.

CLI selection requires envault.collections.read; downloading or running with values requires envault.secrets.access at workspace scope. Workspace General Viewer and Envault Secret Accessor provide value access. Project permissions alone do not grant workspace secret access. Access is checked again before values are returned. Downloads are limited to 1,000 source keys and 4 MiB of plaintext. No offline secret cache is maintained. Missing references, invalid scope, permission revocation or a service error prevent output and runtime execution. Dotenv serialization preserves literal values and refuses values it cannot represent losslessly; use JSON for those values. Dotenv files are data files, not shell scripts to source. Keep exported secrets out of version control. On Windows, file access is governed by directory ACLs; POSIX mode 0600 is not a Windows ACL guarantee.

CLI troubleshootingCopy Anchor Link

See CLI command reference for shell completions and flags.

Import secretsCopy Anchor Link

Open Workspace Defaults, or select an environment in Shared Secrets or Application Secrets, then open More actions (⋮) and choose Import secrets.

1. Choose File format: .env or JSON.
2. Choose a UTF-8 file or paste its contents into Or paste secrets.
3. Choose Preview import and review the names. Values are hidden in the preview.
4. Choose Import secrets to save the complete batch, or Edit input to revise it.

Imports accept 1–100 secrets and up to 32 KiB of source text. Names use uppercase letters, digits and underscores, start with a letter or underscore, and are at most 100 characters. Values are at most 16,384 characters; empty strings are allowed. Null characters are not supported. JSON must be a flat object with string values:

{
  "API_KEY": "example-value",
  "LOG_LEVEL": "info"
}

Dotenv supports KEY=value, export KEY=value, comments and quoted multiline values. Quote values containing #. Variable expansion and shell commands are not executed during import. Envault's existing Shared reference rules still apply when Application or Workspace values are delivered.

Duplicate input names, existing names and inherited-key conflicts reject the whole batch. Nothing is overwritten, and no subset of secrets is imported. A key created by another user after preview can also cause the import to fail. Edit existing secrets individually or remove conflicting entries from the file before retrying. Secret management permission is required. Importing does not redeploy running containers. Closing the dialog or leaving the browser tab clears the import draft.

Reveal all secretsCopy Anchor Link

Use the eye icon (Reveal all secrets) above the list to display values in the selected scope, including inherited rows. This also loads secrets beyond the first page. Secret access permission is required; inherited values remain read-only. The icon changes to Hide all secrets while values are visible.

Toolbar actions use icons with tooltips: the plus icon creates a secret, the save icon saves changes, and More actions (⋮) contains Import secrets. Save or discard edited values before revealing or hiding all secrets.

Values remain visible until you hide them or leave the scope or page. Switching browser tabs alone does not hide them. A failed bulk request does not display a partial result; retry after resolving the error.

Key descriptionsCopy Anchor Link

Add an optional description of up to 50 characters to explain what a key is used for. Select Add description in the row action group beside Generate and Delete, or select its existing description to edit it. Choose Save changes to apply the edit; clear the field and save to remove it. New keys can include a description before saving.

Descriptions are visible to members with secret metadata access, even when they cannot reveal values. Do not include passwords, tokens or other secret values in a description. Editing requires secret management permission. Inherited Shared descriptions must be edited in their source Shared environment.

Descriptions do not change runtime values, container configuration or downloaded secrets. If another person changes the key before you save, refresh and review their changes before retrying.

Audit historyCopy Anchor Link

Open Audit to review key creation, changes and deletion. Reveals, downloads and runtime exports do not create audit records. Audit stores names and revisions without values; it does not restore old values.

Secret remindersCopy Anchor Link

Reminders are available for individual secrets in Application Secrets, Shared Secrets and Workspace Defaults, without a plan upgrade. They help you track review dates; they do not expire a credential, rotate its value or stop an application.

1. Hover over the secret value or focus its controls, then select Set reminder in the grouped toolbar.
2. Select a date from the calendar. The reminder uses the start of that day in your browser's time zone, shown in the dialog.
3. Save the reminder. The secret row displays its date and whether it is upcoming or overdue.

Workspace members with secret management permission receive grouped reminders as dates approach: 30, 15, 5 and 1 day before the selected date. Each secret appears in its nearest period only, and the same stage is not repeated. For example, a reminder first set three days ahead starts at the 5-day stage; missed 30-day and 15-day alerts are not sent.

Each workspace and recipient receives at most one digest per UTC calendar day, containing eligible counts and a link to Reminders. Emails show separate counts for 15–30 days, 5–15 days, 1–5 days and within 1 day; boundary dates belong to the closer period. Names and values are not included. Secrets added after that day's digest can appear in the next day's digest. No message is sent when there are no new eligible stages.

Console notifications are available independently of email success. Failed emails may be retried during that UTC day. Once a date passes, review the overdue entry in Reminders; no additional overdue email is sent. Changing the date creates a new reminder occurrence, still subject to the daily limit.

Open Reminders to search by secret name, filter by reminder status or date range, change dates, or dismiss reminders. Dismiss all overdue includes every overdue reminder in the workspace, even outside the current filters; a confirmation dialog appears first. A dismissed reminder remains in the dismissed list. Remove reminder cancels it. Changing a date replaces the active reminder. Setting a past date makes it immediately overdue.

Inherited shared keys display the original reminder; edit it in the source Shared Secrets environment. A reminder is not duplicated for each inheriting application. Reading the list requires workspace secret metadata access; changing reminders requires workspace secret management permission.

Dismissing a reminder acknowledges it only. It does not assert that you rotated the secret. Replacing the secret value does not automatically dismiss or reschedule its reminder. Secrets remain usable after the reminder date, after dismissal, and after removing the reminder.

Automatic runtime contextCopy Anchor Link

When a Secret Group environment is delivered through Link Envault or downloaded through the CLI, Envault automatically includes ENVAULT_GROUP and ENVAULT_ENVIRONMENT with the group and environment names. These are generated values, not stored secrets, and do not appear as generated rows in the Envault secret list or Container Engine environment-variable list.

The two names are reserved for delivery metadata and take precedence over colliding stored or local values. Container Engine does not allow creating or editing them through its environment-variable controls. Your running application can read them normally from its process environment.

Link changes apply on the next start or redeployment that synchronizes Envault. Changing the linked environment updates the values; unlinking removes them on the next synchronization. Containers without a linked Secret Group environment receive no generated group context. Linking alone does not restart a running container, and a plain restart does not refresh the delivered values.

Group and environment creation opens in a panel on the right. Enter a name and submit; the panel closes after success and retains your entry if saving fails. Group and environment rename and delete actions remain in a central dialog. Secret values continue to be edited inline on their environment page.

Product navigationCopy Anchor Link

The sidebar keeps Overview, Shared secrets, Workspace secrets, Application secrets, and Reminders available alongside Getting started. When a successful overview query confirms that the workspace has no resources, the default entry opens Getting started. Select Overview to inspect an empty workspace explicitly. This check uses resource counts and does not read secret values.

Lists and resource details use the available workspace width. Getting started links to the existing creation or management flow and documentation; existing permissions still apply.