> ## Documentation Index > Fetch the complete documentation index at: https://docs.hiveku.com/llms.txt > Use this file to discover all available pages before exploring further. # Share Variables Across Sites > Keep the variables several sites use in one group, and change them once An environment group is a named set of environment variables that several of your sites share: a shared API key, the address of a service every site calls, a mail provider's settings. You keep the values in one place, link the group to each site that needs them, and a change to the group reaches every linked site. A site's own variables always come first. Groups only fill in what a site does not set itself. ## Where to Find Them Go to **Settings > Environment groups** (under **Developer**). Each group lists its variables, the sites it is linked to, and its history. Each site's **Environment Variables** page has an **Environment groups** card under the variables. That is where you link a group to the site. You need the **Env & Secrets** permission in your role: viewing groups needs read access, and creating, editing, linking or deleting them needs manage access. Owners and admins always have both. ## Creating a Group In **Settings > Environment groups**. For example `Shared API keys`. A name is 1 to 64 characters (letters, digits, spaces, dots, dashes and underscores) and starts with a letter or digit. Two groups in one workspace cannot share a name. The group starts empty. To add a description, use the **More actions** menu (**Edit description**). A workspace can have up to 100 groups. ## Adding Variables Open the group and click **Add variable**. * **Name**: capital letters, digits and underscores, starting with a letter (`STRIPE_SECRET_KEY`). What you type is turned into that form. * **Tier**: **All tiers**, or only **Development**, **Staging** or **Production**. The same name can hold a different value per tier, as on a site's own variables page. * **Value**: the value itself. * **Sensitive (never shown again)**: makes the variable write-only. See below. When you save, every linked site's deployed functions get the new value in the background, without a redeploy. Build-time variables (`NEXT_PUBLIC_*`) only reach the browser after you redeploy the site, as with a site's own variables. If the group already has a variable with that name for that tier, Hiveku asks before it replaces the value. Values are hidden until you click **Show value**. To change one, click its edit icon. The name and tier stay fixed; to move a variable to another tier, remove it and add it again. ### Sensitive variables A sensitive variable is write-only, exactly as on a site's variables page: after you save, its value is never shown again, to you, your team, Hiveku staff or any AI tool. Your sites still receive it. * To change a sensitive variable, edit it and enter the new value. An empty value never replaces it: Hiveku refuses the save. * You can make an existing variable sensitive without changing its value: edit it, tick **Sensitive**, and save. The message says the variable is now sensitive. * Nothing makes a sensitive variable readable again. If you lose the value, create a new one at the provider and replace it. ### What a group cannot hold * **Database addresses** (`DATABASE_URL`, `DIRECT_URL`, in any tier). Each site keeps the address of its own database in its own variables. * **Hiveku's platform credentials**, such as `SUPABASE_SERVICE_ROLE_KEY`, `HIVEKU_PYTHON_API_KEY`, AWS keys and `EXPO_*` names (`EXPO_PUBLIC_*` names are fine). Hiveku sets these for each site. Hiveku refuses the save and names the variables it could not take. ### Size A group holds up to 60KB of variables. A site's own variables plus all its linked groups can also total at most 60KB for any one tier, because that is what a deployed site can run with. A link or a save that would go over is refused, and the message names the site. ## Linking a Group to a Site The **Environment groups** card lists the groups linked to the site and their variables, by name and tier. The site's deployed functions get the group's variables right away. The message tells you if they could not be updated; in that case the site gets them at its next deploy, so redeploy if you need them now. A site can link up to 10 groups. **Which value wins.** If the site sets a variable itself, its own value wins in every tier where it sets one. The card shows those group variables struck through, so you can see which ones the site replaces. **Two groups, one name.** Two groups linked to the same site cannot set the same variable for the same tier. Hiveku refuses the link (or the save that would cause it) and says which variable and which group clash. Rename or remove the variable in one of the groups. **Tiers.** Groups follow the same environment rules as a site's own variables, including the way deployed Development and Staging sites fill gaps from each other. See [Configure Environment Variables](/how-tos/env-vars#choosing-environments). **Previews.** A new preview gets the linked groups' Development and All tiers values when it starts. A preview that is already running keeps the values it started with: click **Rebuild preview** in the editor to give it the group's current values. ## Unlinking Click **Unlink** on the group in the site's card, or next to the site under **Linked sites** on the group's page. The site's deployed functions stop using the group's values as soon as they are updated, or at the next deploy; the message tells you which. A variable the site also sets itself is not affected. ## Deleting a Group Use **More actions > Delete group**. A group that is still linked to a site cannot be deleted: unlink it from each site first, so no site loses values nobody chose to remove. Deleting removes the group's values and cannot be undone here. ## History Open **History** on a group's page to see the latest changes: who created, renamed or deleted it, set, removed or replaced which variable and for which tier, marked one sensitive, and linked or unlinked which site. History never shows a value. ## Moving a Site to Another Workspace Groups belong to their workspace, so they do not move with a site. When you transfer a site, the transfer screen names the groups it uses and the variables it will lose. Copy any variable the site still needs into the site's own variables before you move it. Hiveku takes the site's previews down as the move starts, so none keeps running with the old workspace's values. After the move it clears those values off the site: it updates the deployed functions and rebuilds the previews. Until that is done, the site's runtime logs and preview logs are not shown in the new workspace, and the AI tools that read a running preview wait; afterwards logs from before the move stay hidden, because they may contain the old workspace's values. ## Working With AI AI tools you connect (Claude Code with the Hiveku plugin, the VS Code extension, Codex, Hiveku Sync) can manage groups through Hiveku's tools, within what your role allows: * **Read**: `env_groups_list`, `env_group_get`, `env_group_history` and `project_env_groups` show groups, names, tiers, linked sites and history. None of them returns a value. A group's non-sensitive values reach an AI tool only through a site's reveal (`project_secrets_reveal`), which a person approves, as for the site's own values (see [Configure Environment Variables](/how-tos/env-vars#working-with-ai)). * **Change**: `env_group_create`, `env_group_update`, `env_group_delete`, `env_group_set`, `env_group_link` and `env_group_unlink`. Values go in, never out, and are kept out of Hiveku's activity log. Claude Code with the Hiveku plugin, Claude Code in folders the VS Code extension sets up, and Codex ask you before every change to a group: creating, renaming, deleting, saving variables, linking and unlinking. Hiveku AI (the chat in the editor) does not manage groups yet. ### Local development Pulling a site's variables for local development (`/hiveku:env`, **Hiveku: Pull Env to .env.local** in VS Code, or `hiveku-sync pull-env`) includes the values the site gets from its linked groups, under the same approval as its own: a person approves every pull, sensitive variables are never written (their names are listed as comments), and the site's own value wins over a group's. Each pull of a group's value is recorded in that group's **History**, naming the site. ## Troubleshooting Two groups linked to one site cannot set the same variable for the same tier. Remove or rename the variable in one of the groups, or set it in the site's own variables instead (a site's own value always wins over a group's). A site's own variables plus its linked groups can total at most 60KB for one tier. The message names the site and tier. Remove or shorten some values, or move large blobs (a certificate chain, a JSON config) to storage and keep only a reference in a variable. It is still linked to at least one site. Unlink it from each site listed under **Linked sites**, then delete it. Check, in order: 1. The site sets the same variable itself: its own value wins. On the site's card, the group's variable is struck through. 2. The variable is for another tier than the one you are testing. 3. It is a `NEXT_PUBLIC_*` variable: redeploy the site. 4. The save or link message said the deployed functions could not be updated: redeploy. 5. You are looking at a running preview: click **Rebuild preview**. The variable is sensitive (or you ticked **Sensitive**), and a sensitive variable cannot be emptied. Enter the new value. To remove the variable, use the remove icon instead. If Hiveku cannot confirm which variables are sensitive, it hides every value and saves nothing, rather than risk showing or emptying one. This is temporary; reload the page in a moment. Hiveku is still clearing the old workspace's group values off the site. Logs come back once that is done, usually within a few minutes, and lines from before the move stay hidden. ## What's Next? A site's own variables, tiers and sensitive values Ship build-time changes This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.