> Markdown version of https://tuna.am/en/blog/secrets-change-requests/. Documentation index: [llms.txt](https://tuna.am/en/llms.txt), full text in one file: [llms-full.txt](https://tuna.am/en/llms-full.txt). Any page is available as Markdown: append `.md` to its URL without the trailing slash.

[Blog](https://tuna.am/en/blog.md)|[New features](https://tuna.am/en/blog/tags/features)

# Secrets change requests — prod edits through review

November 2 · 4 min

A common scenario before a release: a developer needs a new Stripe key in `prod` but has no access to `prod`, and rightly so. So they post in the chat, "please update `STRIPE_API_KEY`," and someone copies the value from the message. The key stays in the chat history, and a month later nobody remembers who changed it, when, or why.

[Secrets](https://tuna.am/en/docs/secrets.md) now have change requests. An edit like this goes through review, just like code in a merge request: the developer proposes a change, and a `prod` editor reviews and applies it.

![Change request: prod block under review with new and modified secrets and an 'Approve' button](/blog/img/2026-11-02-secrets-change-requests/request-review.webp)

## How it works

The author opens a configuration and, without write access to it, sees **Propose a change** instead of **Save**. They can propose an edit even in an environment they have no access to, but they won't see that environment's current values or secret names.

![New request form: title, description, project, and prod configuration block with a new variable](/blog/img/2026-11-02-secrets-change-requests/form.webp)

Reviewers get an email with the request title, the project, and the secret names, but no values. The request also shows up on the dashboard home page in the **Needs attention** block.

An environment editor reviews the diff — before and after for each secret — and clicks **Approve**, then **Apply**. The new values are written to the configuration immediately, and the change history gets an entry that links to the request, so a month later it's clear who changed the secret, when, and why.

A single request can cover several configurations. Each one becomes a separate block with its own approvals: the change in `stg` can go out right away, and `prod` after the release.

## Other people's edits are not overwritten

While a request is waiting for review, someone might change the same secret directly. Applying the request on top of that edit would silently wipe it out. So we apply changes strictly: the block is marked **Outdated** and can't be applied until the author or a reviewer updates it against the current values. This resets the approvals, and the review starts over.

![Block marked 'Outdated: secrets changed after creation' with an 'update' link](/blog/img/2026-11-02-secrets-change-requests/outdated.webp)

## Approval policies

By default, one approval from any environment editor is enough. For critical environments, a team admin can set a policy: how many approvals are needed and from whom, whether authors can approve their own requests, and who gets assigned as a reviewer automatically.

A policy applies to the entire team, to selected projects, or to specific environments and configurations. For example, "two approvals and no self-approval" for `prod` in selected projects.

!['Production' policy form: two approvals from any environment editor, the author cannot approve their own request](/blog/img/2026-11-02-secrets-change-requests/policy.webp)

## Important details

* Change requests only work in the dashboard: you can't create or approve them through the API, the CLI, or service keys. Approval must come from a person, not a leaked key or a script.
* Policies don't block direct edits: environment editors can still change secrets right away. Requests add a path for those without write access.
* You can create requests on paid plans.

One more update for those who work with secrets through the API: all methods are now documented in [Swagger](https://my.tuna.am/swagger/?lang=en).

Change requests are already live under [Secrets → Change requests](https://my.tuna.am/secrets/requests?lang=en). Roles, statuses, and policy setup are covered in the [documentation](https://tuna.am/en/docs/secrets/change-requests.md).

## Leave feedback

If you enjoy using Tuna, or on the contrary you are not happy with something, please [leave feedback](https://my.tuna.am/?show_feedback=1&lang=en).

![](/blog/img/2024-08-22/feedback.gif)

## News

We announce new features and posts on our [Telegram channel](https://t.me/tuna_am). Subscribe so you don't miss anything.

## Help

We value our users and carefully review every request. If you have any problems with tuna, please contact us in one of the following ways:

* [Email](mailto:info@tuna.am)
* [Telegram community](https://telegram.me/+Kgbtt0_gJwI5ZmEy)

Categories: [New features](https://tuna.am/en/blog/tags/features)

[older →🌐 Apex domain with fault tolerance](https://tuna.am/en/blog/apex-domain-redirect.md)