If you keep Staging, Production, and a personal sandbox environment in HarborClient, you already know the pain: the same baseUrl, timeouts, and feature flags copied into every environment—then updated three times when something changes.

HarborClient now supports environment inheritance. One environment can extend another, pick up its variables automatically, and override only what differs. Chains can go as deep as you need (with a safety cap), so a shared base can feed Staging, which can feed your personal Staging override.

Why inheritance?

Environments are app-wide variable bags. Without inheritance, each one is a flat list. Teams often end up with near-duplicates—or they use Copy down / Merge down as one-shot bulk edits that still leave values out of sync later.

Inheritance keeps a single source of truth for shared keys and lets child environments win on conflicts. You activate one environment as before; HarborClient walks the parent chain and merges variables at send time.

How it works

Each environment optionally inherits from one parent (linked by portable uuid, not sidebar position). When that environment is active, HarborClient merges variables from the root down to the leaf:

• Later environments override earlier ones on the same key
• An enabled child row wins even if its value is empty (HarborClient still uses that row’s Default, same as today within one environment)
• A disabled child row does not override—so the parent value passes through

Overall send-time precedence is unchanged outside the env chain: globals → collection → folder → merged environment chain (environment still wins over folder and collection).

Script writes with hc.environment.variables.set still persist only on the active environment—they create local overrides, not edits to the parent.

How to set it up

1. Create a base environment (for example Shared) with the keys every environment should share.
2. Open a child environment’s Settings (double-click the row, or Settings from the row menu).
3. Under Inherit from, choose the parent. HarborClient shows a breadcrumb such as Shared → Staging.
4. Add or edit only the child’s own variables. Inherited keys appear below in a read-only list—use Override to insert a local row that shadows a parent key.
5. Use the first-column Enable checkbox on a variable row to include or exclude it from resolution. Uncheck Enable on a child key to let the parent value through without deleting the row.

The Environments sidebar now shows the hierarchy like collections and folders: parents expand and collapse with a chevron, and children nest underneath. Drag-and-drop reorders siblings under the same parent. Linking inheritance by dragging one environment onto another is not in this release—use Inherit from in settings.

Tips and limits

• Single parent only — For “mixins,” chain multiple levels (Base → Team → Personal) rather than multiple parents.
• Cycles are blocked — You can’t inherit from yourself or from a descendant.
• Deleting a parent — Allowed; direct children become roots (their Inherit from is cleared). HarborClient warns how many children are affected.
• Copy down / Merge down — Still available as bulk edit tools between siblings; they are not how inheritance is defined.
• Enable on all variable scopes — Globals, collection, folder, and environment tables share the Enable column; disabled rows are skipped at resolve time.

Get started

Open Environments, put shared keys on a base environment, then set Inherit from on Staging or Production and keep only the differences local. Less duplication, fewer stale copies—and the tree in the sidebar shows how everything connects.

Learn more about environments on harborclient.com, and grab the latest build from GitHub Releases.