Skip to content
Merulan

Build, install, and recover

Build or select an exact Product release, install its accepted plan, and use retained state to change or recover it.

Use this guide when you build or install a release with Installable Products. As a builder, resolve its inputs, apply the checked plan, and read what the Workspace holds. Use that same evidence when you change or recover the install.

Before you start

The install needs a target Workspace, an exact Product release, and rights to change its design. Check management authority before choosing the caller. Keep the release key and version with the plan under review. Confirm that required Sources and bindings can be resolved.

Use the Console for its mounted install flow. For Merulan Code or OpenTofu, check the Infrastructure as Code guide for release and access prerequisites. A plan contract does not supply public package install steps.

Prepare the release

For an existing release, inspect its exact version in the Marketplace. Read its requirements and available profiles. For an authored Product, compile its content and exact references, then preview publication. Publish the reviewed bytes with that digest. Tenant publication is private to the publishing company. An authored distribution field cannot make it public.

Read the release after publication. Keep its receipt and digest. A local build does not prove that the registry holds those bytes.

Preview and install

In the target Workspace, preview the release with the selected profile and input answers. Resolve each blocker and accept the needed slot choices. Preview again after changing an answer. Check the plan's exact releases, namespaces, and adoption choices before accepting it.

Use the install contract with the accepted plan and a stable retry key. Keep the returned attempt and installation identity. Inspect both the attempt state and completed work before treating the install as successful.

Checkpoints

The install read must match the accepted release and plan. Use installed inspection to check owned content and reference edges. Read saved settings, Source pins, and unresolved inputs when configuration exists. A reference to another Product is not proof that its required input is ready.

Keep the plan, attempt, and readback together. If the result is partial or requires resolution, enter recovery with those facts before submitting another change.

Change the install

For an editable setting, read the current revision and use the configuration contract. Read the saved values afterward. For a release change, preview the target, resolve blockers, then apply the accepted upgrade. An open attempt must finish or be resolved before another upgrade starts.

For uninstall, inspect live consumers and retire the selected root. Check its result. Referenced Products remain installed. Removing a root does not authorize their removal.

Success

The install has reached installed, with the expected release, owned content, references, and saved inputs. A settings edit has a new saved revision. A completed upgrade reads back as its target release. A completed uninstall reads back as retired, with retained history. Use the result for the action you chose. One successful step does not prove the others.

When it fails

The install's returned code and attempt state select the repair. Preserve both before changing the request.

PRODUCT_STALE

The Product changed after the plan was accepted. Read current state, preview the intended change again, and review the replacement plan. Do not copy stale expectations into a new request.

PRODUCT_REQUIRES_RESOLUTION

The lifecycle needs an input or operator decision. Read the named blockers and retained work. Correct the missing choice or dependency before resuming or accepting a replacement plan.

PRODUCT_OPERATION_FAILED

The call failed without a successful lifecycle result. Inspect the attempt and installed state before retrying. A failed response alone does not show which work completed.

Recovery

Recover an interrupted install or upgrade from its saved attempt. A resume keeps the accepted plan and delta. It does not select a newer release. Resolve permanent failures or changed inputs before a fresh plan. Retry retirement only after checking the root's current state and remaining consumers.

Rollback is a reviewed change, not a blanket undo. If a return to an earlier release is needed, preview that exact target and accept it only when the checks pass. A failed final upgrade commit preserves the prior release but does not prove that all attempted work was reversed.

For adoption, import existing installs without mutation. Check that the next plan is empty, then request authority transfer. Read the new policy before applying design changes.

Next steps