Environment groups: share env variables across services

If five of your services all need the same SENTRY_DSN, setting it five times means changing it five times. An environment group is a named set of environment variables that you link to as many services as you like. Change a value in the group and every linked service gets it.

Create a group

1. Open Environment Groups in the left sidebar.
2. Select New environment group and give it a name you will recognise in a list — Production or Shared API keys rather than group1.
3. Add your variables and select Save.

A group belongs to a workspace. Any service in that workspace can be linked to it.

You can also start from a project: open the project, select the Env Groups tab under an environment, and select New environment group. A group created there is limited to that environment (see below). The tab lists every group its services can use - workspace-wide ones too.

Link services

Open the group and select Link a service. You can link up to 25 services to one group, and a service can be linked to more than one group.

Unlinking a service does not delete anything — the group keeps its variables, and the service stops receiving them. Voroa redeploys that one service straight away so it stops using those values now rather than at its next deploy; if it cannot be restarted at that moment, Voroa says so.

Limiting a group to one project or environment

By default a group is available to every service in the workspace. You can narrow it to a single project, or to a single environment inside a project - so a group holding staging credentials cannot be linked to a production service by mistake.

Set the scope when you create the group, or change it later from the group page. Two things follow from it, and they are separate:

• Scope decides where the group can be used. Linking it to a service outside that project or environment is refused, and the message says why.
• Scope does not decide which value wins. When two groups linked to the same service both set the same variable, the order you put them in decides - the same as it always has. A narrower group does not quietly outrank a wider one; if you want it to win, move it up.

A service that has not been placed in a project cannot be linked to a narrowed group at all, because there is nothing to compare it against.

Narrowing a group that already has services linked to it is refused if any of them would fall outside the new scope, and the message names them. Unlink those services first, or pick a wider scope. Voroa will not quietly unlink a service that is running with the group’s variables today.

Which value wins

Two rules, and they are the whole story:

• A variable set on the service itself always wins over any group. If your service has its own LOG_LEVEL, that is the one it gets, no matter what any group says.
• Between two groups, the one lower on the list wins. Open the service’s Environment tab to see its linked groups in order and move them up or down. Moving one redeploys that service, because the change decides which value it runs with.

On the group page, a variable that loses somewhere is marked — it will tell you whether the service sets it itself or another group later in the list does. If a value is not arriving where you expect, that marker is the first place to look.

Saving redeploys the linked services

Changing a group changes the configuration every linked service runs with, so those services are redeployed to pick it up. Before that happens, Voroa shows you exactly which services will restart and asks you to confirm. Nothing is saved and nothing restarts until you do.

Deleting a group works the same way: you are shown the services that will lose those variables, and asked first. A group with no linked services restarts nothing, so there you are asked a different question - how many variables are about to be removed - because those values cannot be recovered.

Linking and unlinking a service redeploy that one service on their own, without asking: you named the service in the request, so there is nothing to show you that you did not already choose.

This confirmation is enforced by Voroa’s API, not just the dashboard — a script or command-line tool calling the same endpoint has to confirm too.

Because one save can restart up to 25 services, there is a limit on how often these actions can be repeated. Editing your configuration normally will never reach it; a script in a loop will.

If a service cannot be restarted at that moment — the build queue is busy, or your monthly build minutes are used up — Voroa saves the change and tells you which services were not restarted. Those services keep running with their previous values and pick the change up on their next deploy.

Checking which services have the latest values

You do not have to catch that message when it appears. Every linked service is marked with where it stands, on the group page and on the service’s own Environment tab:

• Sent to the last build — this service has been given the group’s current values.
• Applies on the next deploy — the group has changed since this service last received it. It is still running the previous values.

The second marker is the first place to look when a variable is not arriving where you expect. It stays accurate after you close the tab, so you can come back later and still see which services are behind.

One honest limit: the marker tells you the values were handed to a build, not that the build succeeded. If that deploy failed, check the service’s Deploys tab.

Saving can be refused outright if your build minutes for the month are gone, since a save on a linked group is a build for every service attached to it. That applies only to a save that ADDS a variable. Replacing the value of one you already have is a rotation, not new work, and is never refused - if a credential leaks you must always be able to change it, not only delete it. Removing a variable is never refused either; see below.

Values cannot be read back

Variable values are encrypted when you save them and are never shown again — not in the dashboard, not through the API. You can replace a value, but you cannot read one.

That is why an existing variable shows an empty value box with a Set marker instead of a masked field: we are not hiding a value we could show you, we genuinely cannot show it. Leaving the box empty when you save keeps the stored value, so you can change a variable’s build-time setting without retyping a secret you no longer have.

The same reason is why a saved variable’s name cannot be edited. Renaming would mean creating a new variable and deleting the old one, and the value could not come along — so you would either be left with the old name still in the group, or with a new name and no value. Remove the variable and add it again under the new name instead, supplying the value as you go.

Removing a variable

Select the remove control on the row. Removing is its own action, not something a later Save applies — so it asks you to confirm the redeploy in the same way, and the variable is gone as soon as you agree.

If you are removing a variable because a credential leaked, that removal always goes through. It is never blocked, even if your account has run out of build minutes for the month; in that case the variable is removed immediately and the linked services pick up the change on their next deploy rather than restarting now. Voroa tells you when that happens.

A new variable must be given a value when you add it. An empty box on a NEW row is refused rather than saved as an empty value, because an empty value in one group beats a real value in another that sits earlier in a service’s order - so a half-finished row would silently blank a variable that was working. An empty box on a variable you already have is different, and means “keep the stored value”.

Build-time variables

Tick Build time for a variable your build needs — for example a VITE_ or NEXT_PUBLIC_ value that gets baked into your bundle. Everything else is available at runtime through process.env.

What a group cannot do yet

Two honest limits:

• Secret files are not part of a group. You can add secret files to an individual service under Settings → Secret Files, but not to a group.
• A group cannot be scoped to one project or environment. Every group is available to every service in the workspace.

Also worth knowing: a pull-request preview does not inherit its parent service’s groups. Previews start with no environment variables by design; use preview variables on the parent service to give them what they need.

Static sites do not use environment variables at all, so linking one has no effect. Managed databases cannot be linked.

Related

• Environment variables and secrets — setting variables on a single service
• Default environment variables — what Voroa sets for you