Re-seed Environment

Re-seeds the Develop Environment of another deployment chain by copying Configs into it from any Environment, in a single step.

Each Develop Environment roots its own deployment chain, and the chains are independent - nothing deploys between them. Until now, moving work across meant exporting a .bra package from one and importing it into the other. This page does the same thing without the file.

Where you can copy from and to

Source can be any Environment, not just a Develop one. Copying from Production brings across the Configs as they are running live, rather than as they stand in Develop with work in progress.
Target must be a Develop Environment, as that is the only kind whose Configs can be written.
The main chain is never a Target. That is the chain rooted at the primary Develop Environment, and any chain that deploys through to Production. Copying another chain's work into it is refused, because a copy would land it wholesale, one deployment away from going live. Copying out of it, including from Production, is fine. To bring work into the main chain, export a .bra package from the other chain and import it into the main Develop Environment, where you choose what comes across.
The two must be in different chains. Within one chain Configs already move by deploying, which keeps them linked as versions of the same Config, so the Target list leaves out the Source's own Develop Environment.

The page only appears when the system holds more than one Develop Environment, which is a licensed feature. See Multiple Develop Environments and Licensing.

The copies are new Configs

A copy is a new Config, not a version of the one it came from. Nothing links the two afterwards: they carry no shared history, a compare between the two chains will not pair them up, and each drifts as its own chain is worked on.

Nothing is updated in place

A re-seed never updates what the target already holds. If something you have ticked already exists in the target with the same type and name (ignoring case), it is deleted and added again from the copy, as new. That goes for Code Libraries as well as Configs. Unless Metadata Only is on, a deleted Config's warehouse objects are dropped with it - the table behind a Load, Stage or Code Config, the view behind a View, and the table, procedures and view behind an Archive, including its history.

Items that are identical in both Environments have nothing to copy, so they are left alone. Everything you have not ticked is left alone too, unless you delete everything first.

The preview lists what will be replaced, and Import asks you to confirm before anything is deleted. Each replaced Config's last state is kept in config history, so Restore Develop can bring it back - but not dropped warehouse data or a Code Library's DLL.

A Code Library still used by a Code Config that is not being replaced cannot be deleted, so it is updated in place instead and the result says so.

This differs from importing a .bra package, which updates a Config of the same name in place and keeps its id.

Deleting everything in the target first

Turn on Delete Everything In The Target First to have the re-seed start by deleting every Config and Code Library the target holds, along with their warehouse objects unless Metadata Only is on. The target then ends up holding only what you copy in. Anything in the warehouse that no Config owns is left alone.

Because it deletes, it comes with safety valves:

It is off by default, and turning it on throws away any preview, so the preview you act on always reflects it.
The preview says what will be deleted, by type, and compares what you are copying against an empty target.
Import asks you to tick a box confirming everything in the target will be deleted.
Each Config's last state is written to config history before it is deleted, so Restore Develop At a date and time from before the re-seed can bring the Configs back.
If anything is still in the target once the delete has run, the copy stops there rather than writing onto a half-cleared target, and the result lists what could not be deleted.

Metadata Only

By default a copy builds the warehouse objects to match: the table behind a Load or Stage, the view behind a View, the procedures behind a Code Config. Turn Metadata Only on and the whole re-seed sticks to the Configs. Nothing is created, dropped or altered in the target's warehouse, and nothing is read from it either, so the target does not need a warehouse behind it at all.

Use it when the target Develop Environment is a record of another Environment's metadata rather than a working chain - a backup of what the Configs looked like, held somewhere you can compare against or copy back out of later.

If the target has no value for the Warehouse connection string, Metadata Only is switched on and cannot be turned off, and the page says why. Picking a target that has a warehouse puts the switch back how you left it.

A Config copied this way carries no warehouse object, so it cannot run. If the target is later turned into a working chain, Validate each Config and Repair it to build the objects it needs.

Re-seeding

Pick the Source and Target, in either order. See Where you can copy from and to. Each list narrows to the choices that fit the other side, and when only one is left Bragi fills it in for you. If the system has only one Develop Environment that can be copied into, it is already picked as the Target when the page opens.
Decide whether to turn Metadata Only on, and whether to delete everything in the target first.
Press Preview Copy. Bragi lists what would be copied and checks it against what the target holds, without writing anything.
Tick what to copy. Include everything at the top ticks every row with something to copy, and clicking it again clears the lot. Rows the target already holds are replaced. The requirements button on a row pulls in everything that row needs, the same way the Compare page does, and a row whose sources are not ticked is flagged as a warning.
Press Import and confirm. A progress window counts each type of Config in as it goes, for example Loads 15 / 200, and names the Config being written. A count marked to retry is usually a Config waiting on another one to go in first, and it is tried again once that has happened.
Read Deployment Results. Every item the copy was given has a row saying whether it was added, updated, failed or never reached, with the reason alongside a failure.

Reading the result

Configs are written one at a time, and a failure moves on to the next rather than stopping the run, so a copy can work for most of what it was given and still fail for some of it. The result table is the record of which is which:

Status	Meaning
Added	Written into the target as new. A row that says it replaced one of the same name had one deleted and re-added.
Updated	Written over one already there. Only happens when that one could not be deleted first; the messages say which.
Failed	Not written. The words on the row say why.
Not attempted	The run stopped before reaching it, so it is untouched.

A Config that needs another Config in first is retried once the run has made progress elsewhere, so a row saying it went in on a later attempt is ordinary rather than a problem.

Nothing is rolled back when a row fails. The Configs that went in stay in. Fix what the row complains about and re-seed the rest again.

02 October 2026