Which Remote Version Does the Host Load?

Remote A 1.0.0 has been published.
Remote A 1.1.0 has been published.

Which version does the host load?

The obvious answer is often: the version whose address its configuration points to.

Host configuration
└── Remote A → /remote-a/1.0.0/remoteEntry.js

If version 1.1.0 should be loaded next, that mapping has to change:

Host configuration
└── Remote A → /remote-a/1.1.0/remoteEntry.js

If the address is part of the built host artifact, the change requires a new host build and another publication of the host. The remote may have been published independently, but in this model it cannot yet be activated independently.

An alternative model moves the concrete version mapping out of the host bundle:

Host
└── resolves an approved product composition at runtime
    └── Remote A → Version 1.1.0

Switching to a known and compatible remote version then requires no new host code release. Instead, a new product composition is activated.

That does not mean that no release decision takes place. Activating the new product composition is itself a controlled release decision.

The decisive distinction is between publishing and activation: a remote team publishes an immutable artifact. A separate approval and activation decision then determines the usage context in which that artifact becomes part of the product.

The host should therefore not automatically load the newest available version. It should resolve an explicitly approved and reproducible product composition.

Individual remotes are published independently. A product composition is activated.

When a Version Change Requires a Host Release

Whether switching from Remote A 1.0.0 to Remote A 1.1.0 requires a host release does not depend solely on whether the remote is loaded dynamically. What matters is where the concrete version mapping is managed.

With a statically embedded address, the mapping is part of the host artifact:

Host build
└── Remote A → Version 1.0.0

Changing it to version 1.1.0 changes the host. Even if the remote artifact is already available at a reachable address, the host must be rebuilt or at least republished with changed configuration.

If the product composition is resolved externally, however, the host code remains unchanged:

Host
└── loads Composition ID
    └── Remote A → Version 1.1.0

The host then only needs the ability to resolve a product composition and load the artifacts referenced by it. The switch from version 1.0.0 to 1.1.0 happens by activating a different Composition ID.

No host code release does not mean no control. Product activation does not replace the host release with arbitrariness. It introduces a separate, explicit approval layer.

A host release may still be necessary when an entirely new remote is added to the product structure for the first time, the mount contract changes, or new routes and layout areas can only be defined in the host. The same applies when the host must understand a new version of the composition manifest, shared runtime dependencies change incompatibly, or the remote requires capabilities the current host does not provide.

External activation decouples the switching of compatible versions. It does not magically free the host and remote from their integration contracts.

Published Is Not Activated

A reliable activation mechanism begins with clear terminology:

Build
→ creates an artifact

Publishing
→ makes the artifact available at a unique address

Approval
→ confirms suitability for a defined context

Activation
→ maps an approved product composition to a channel or usage context

Resolution
→ provides the active product composition to the host

Loading
→ loads the remote artifacts referenced by it

Build and publishing belong to the lifecycle of the remote. Approval and activation belong to the lifecycle of the product composition. The host executes the activated mapping.

This distinction is more than linguistic precision. Without it, technical availability, product approval, and an effective product change blur into an imprecise term such as “deployment.” It then becomes unclear which step has actually taken place.

Publishing makes a remote artifact available. It says nothing about whether that artifact is suitable for production, a particular market, a tenant, or a pilot group.

Approval confirms that suitability for a defined context. Activation makes the approved product composition effective in that context.

Published is not activated.

The host should not make this approval decision itself through an ever-growing set of country, tenant, or channel branches. It should execute an already made decision reproducibly.

Immutable Artifacts Instead of latest

For a product composition to be reconstructed later, its parts must remain uniquely identifiable.

A simple model looks like this:

/remote-a/1.0.0/remoteEntry.js
/remote-a/1.1.0/remoteEntry.js

Version 1.0.0 remains available unchanged at its address after version 1.1.0 has been published. A defect correction does not overwrite version 1.1.0. It creates a new artifact:

/remote-a/1.1.1/remoteEntry.js

A published address must not later point to different content. Otherwise, a stored URL can no longer reveal which exact bytes were delivered at an earlier point in time.

A label such as latest is therefore not a reproducible production reference. It identifies no stable artifact state, only a mutable selection rule. Two requests to the same address may return different content.

Semantic versions are useful for communication and compatibility statements. They are not always sufficient as reliable artifact evidence. A build ID, commit ID, or artifact digest can be stored as well. The decisive requirement is that the delivered content can be identified unambiguously.

The artifact does not change. Its mapping to a usage context does.

production-de
before   → Remote A 1.0.0
after    → Remote A 1.1.0
rollback → Remote A 1.0.0

The same approved artifact is promoted rather than rebuilt.

Three Distinct Metadata Layers

A robust activation model can distinguish three kinds of metadata: the artifact manifest, the composition manifest, and the activation mapping. This separation is not a prescribed technical standard. It is a reference model that makes responsibilities visible.

The Artifact Manifest

The artifact manifest describes one concrete published remote artifact.

{
  "name": "remote-a",
  "version": "1.1.0",
  "buildId": "184",
  "entry": "https://cdn.example.com/remote-a/1.1.0/remoteEntry.js",
  "integrity": "sha384-..."
}

It may contain further technical information, such as exposed modules, additional assets, or expected dependencies.

The artifact manifest does not answer whether the remote may be used in production. It knows neither the approval for a particular market nor the assignment to a pilot group.

The artifact manifest describes an artifact. It does not grant product approval.

The Immutable Composition Manifest

The composition manifest describes a reproducible set of approved remote artifacts for a defined host version.

{
  "schemaVersion": 1,
  "compositionId": "composition-2026-08-06-184",
  "expectedHostVersion": "5.4.2",
  "remotes": {
    "remoteA": {
      "version": "1.1.0",
      "buildId": "184",
      "entry": "https://cdn.example.com/remote-a/1.1.0/remoteEntry.js",
      "integrity": "sha384-..."
    },
    "remoteB": {
      "version": "2.3.1",
      "buildId": "92",
      "entry": "https://cdn.example.com/remote-b/2.3.1/remoteEntry.js",
      "integrity": "sha384-..."
    }
  }
}

Once published, this manifest does not change. A different combination of expected host version, remotes, and relevant configuration receives a new Composition ID.

The host entry requires one clarification: if an already delivered host loads the composition manifest, the manifest cannot retroactively replace that host. In this model, the expected host version is a compatibility condition and diagnostic information. If the host artifact itself should be activated together with the remotes, the outer bootstrap or delivery layer must already be tied to the same Composition ID.

A product composition is an immutable snapshot. It describes not only individual remote versions, but the specifically approved combination and the host context for which it is intended.

The Activation Mapping

The activation mapping associates a release channel or usage context with a Composition ID.

{
  "production-de": "composition-2026-08-06-171",
  "pilot-de": "composition-2026-08-06-184",
  "validation": "composition-2026-08-06-184"
}

If version 1.1.0 should become effective for production-de, the existing composition manifest is not rewritten. A new immutable product composition is published, and the channel pointer is switched atomically to its Composition ID.

Artifacts and composition snapshots are immutable. Only the controlled mapping from a usage context to an approved snapshot changes.

Why Entire Product Compositions Are Activated

It would be technically possible to maintain a separate mutable production pointer for every remote:

remoteA pointer changes
remoteB pointer temporarily remains old
remoteC pointer changes later

This creates transitional states. Users may receive combinations that were never validated together or deliberately approved. The problem becomes particularly serious when several pointers are distributed across different systems, cache nodes, or update paths.

An immutable composition snapshot avoids these intermediate states:

Composition 171
├── expected Host 5.4.2
├── Remote A 1.0.0
├── Remote B 2.3.1
└── Remote C 4.0.2

Composition 184
├── expected Host 5.4.2
├── Remote A 1.1.0
├── Remote B 2.3.1
└── Remote C 4.0.2

Activation changes only the mapping:

production-de
from Composition 171
to Composition 184

The smallest unit that can be activated in a controlled way is therefore not necessarily one individual remote. For reproducibility and auditability, the complete product composition is often the more important unit.

This does not mean that every remote publication rebuilds all other remotes. Existing artifacts are merely referenced in a new composition snapshot.

The model does not support arbitrary combinations of all published versions. It supports and approves concrete product compositions. That limits the combinatorial explosion.

The Host Resolves; It Does Not Decide

External version resolution provides real decoupling only when the approval policy does not subsequently move into the shell as application code.

An unfavorable model would be:

if (country === 'DE' && tenant === 'pilot') {
  loadRemoteA('1.1.0');
} else if (country === 'US') {
  loadRemoteA('1.0.0');
}

The host then becomes the owner of country, tenant, and approval logic. New activation rules may once again require a host release. At the same time, it becomes harder to determine who activated which version, when, and for what reason.

The target model separates the decision from its technical execution:

Usage context
        ↓
Activation control
        ↓
Composition ID
        ↓
Host loads exactly referenced artifacts

The host knows the technical procedure for resolution and loading. The approval and activation decision remains outside its application code.

The concrete implementation may be an external activation manifest, a configuration service, server-side resolution, or edge configuration. Larger landscapes may introduce dedicated activation control, sometimes called an Activation Control Plane. It does not necessarily have to be a complex central microservice.

The host should not implement approval policy. It should execute the outcome of that policy reproducibly.

Release Channels and Usage Contexts

Release channels are not the same as technical environments.

Environments may include development, test, and production. They often describe separate infrastructure and operational areas.

Release channels instead express approval status or intended usage context:

validation
internal
pilot
production
restricted-production

A channel does not necessarily require its own infrastructure.

validation
└── Composition 184

pilot-de
└── Composition 184

production-de
└── Composition 171

The same immutable artifact can be promoted incrementally through several channels. Promotion does not rebuild the remote. It expands the usage context for which the same validated artifact is approved.

Besides environment and release channel, the activation context may include further dimensions:

Activation context
├── environment
├── release channel
├── market or regulatory region
├── tenant
├── product variant
├── user group
└── stable rollout cohort

Not every product landscape needs all these dimensions. Every additional dimension increases the number of active product states and therefore the effort required for governance, support, and observability.

A differentiated activation model is not an end in itself. It should distinguish only as many contexts as real approval decisions require.

Deterministic Mapping and Pinned Sessions

Dynamic resolution must not be confused with random or constantly changing compositions.

A user or tenant should not receive a different product composition on every page load without an explainable rule. For percentage rollouts, cohort assignment should remain stable:

User or tenant
        ↓
stable cohort
        ↓
Composition ID

Stability within one page load or session is even more important. During bootstrap, the host should resolve one Composition ID and use that snapshot for every remote loaded lazily afterward.

Otherwise, the following state may occur:

Remote A is loaded from Composition 171
        ↓
channel mapping changes
        ↓
Remote B is later loaded from Composition 184

The running application would then combine two product states that may never have been validated together.

Dynamic activation does not mean that the product composition should change arbitrarily during a running session. A new activation can take effect after a controlled reload or in a new session.

Pinning the Composition ID also improves diagnostics. A failure can be associated unambiguously with the product state resolved at the beginning of the session.

Controlled Approval and Auditability

In tightly controlled or regulated product landscapes, knowing only the currently active URL is insufficient. It must be possible to reconstruct how the effective product state came into being.

Typical evidence questions include:

• Which remote artifact was published?
• Which concrete version, build ID, and digest belong to it?
• Which product composition was approved?
• For which channel, market, or tenant did the approval apply?
• Which validations had been completed?
• Who approved the activation?
• Who executed it technically?
• When did it become effective?
• Which Composition ID was active before it?
• Which product composition was active at a specific point in time?
• When and why was a rollback performed?

An activation record may contain information such as:

Activation record
├── Composition ID
├── host version
├── remote versions and digests
├── target channel
├── usage context
├── approval decision
├── timestamp
├── executing identity
└── previous Composition ID

Not all of this information has to be included in the publicly delivered composition manifest.

It is useful to distinguish between the Data Plane and the Control Plane:

Data Plane
└── delivers the product composition required by the host

Control Plane
└── manages approvals, activations, roles, and the audit trail

The host needs a product composition. The organization additionally needs evidence of how that product composition came into being.

Depending on the risk model, separation of duties, four-eyes approval, or tamper-resistant audit logs may be appropriate. They are not universal legal requirements for every system.

Autonomous Publishing Despite Controlled Activation

Controlled product activation does not remove the independent development and publishing of a remote.

Remote team
├── develops
├── tests
├── versions
└── publishes Remote A 1.1.0

Approval process
└── confirms suitability for defined channels

Activation control
└── maps Composition 184 to the pilot channel

Host
└── loads Composition 184

Independent deployment does not mean uncontrolled activation.

The remote team does not have to wait for a host build before a compatible remote version becomes technically available. The organization can still control when and for whom that version becomes part of the product.

This separates two decisions: Is the remote artifact available? And for which product context should it become effective?

Parallel Versions and Their Support Costs

Activation control allows several versions to be active at the same time:

Remote A
├── 1.1.0 for validation
├── 1.1.0 for pilot-de
├── 1.0.0 for production-de
└── 0.9.4 for a temporary legacy tenant

This can be useful for pilot groups, market-specific approvals, different introduction dates, controlled rollouts, or temporary compatibility windows.

Parallel versions are not a free permanent state.

Every additional active version expands the support matrix and the number of observable product combinations. APIs must remain backward compatible for longer. Failures may occur only in particular usage contexts. Diagnosis, monitoring, and retirement become more difficult.

Clear questions must be answerable for every older active version:

• Why is it still active?
• For whom is it active?
• Who owns it?
• Which APIs must continue to support it?
• By when will it be retired?
• Which conditions currently prevent promotion?

Parallel versions need an owner and an expiration date.

They are a controlled release tool, not an invitation to combine an arbitrary number of versions indefinitely.

Compatibility with Limited Version Skew

Dynamic activation can reference a version. It does not automatically make the referenced combination compatible.

Relevant considerations include:

• the mount contract between host and remote,
• the active host version,
• APIs and data models,
• shared runtime dependencies,
• required browser or platform capabilities,
• other parts of the product composition.

A manifest can reference a version. It cannot by itself guarantee its technical and domain compatibility.

Approving a product composition may therefore require automated and, where necessary, manual validation. Which checks are needed depends on the integration contracts and the risk model.

The central point is not to support every theoretically possible combination. Concrete product compositions are supported and approved.

That keeps version skew deliberately limited. A remote may be active in versions that differ from the host or other remotes, but only within defined compatibility windows.

Atomic Activation

Switching to a new Composition ID should be treated as an atomic decision.

Problematic states would expose only part of a product composition or make individual remote mappings visible one after another. With distributed caches, however, it may be legitimate for some clients still to receive Composition 171 while others already receive Composition 184—as long as both snapshots are complete, approved, and internally consistent.

A possible sequence is:

1. Create a new immutable product composition.
2. Validate the schema, artifact sources, and references.
3. Complete approval.
4. Publish the Composition ID.
5. Switch the channel pointer atomically.
6. Record the activation in the audit trail.

The new composition is prepared completely before it becomes visible.

Atomicity applies to the effective mapping. It does not mean that every cache worldwide switches at the same instant. Each individual resolution must point either to the previous complete product composition or the new one—never to a partially updated intermediate state.

Caching, Failure, and Last Known Good

An externally resolved composition manifest adds a new dependency to the startup path. That dependency needs a deliberate cache and failure model.

The different kinds of data have different properties:

Remote artifacts
→ cacheable long-term because they are immutable

Composition manifests
→ cacheable long-term because they are immutable

Channel or activation pointers
→ shorter-lived or deliberately invalidatable cache

The host does not have to contact a central service synchronously for every remote loaded later. At startup, it can resolve the channel pointer, load the immutable composition manifest, and pin the Composition ID for the session.

One possible model is:

Host startup
├── load active channel pointer
├── load immutable composition manifest
├── validate schema, integrity, and references
├── pin Composition ID for the session
├── mark as Last Known Good after successful startup
└── on failure:
    └── use the last known good composition

A Last Known Good can allow startup when activation control is temporarily unavailable. A composition should not qualify as a valid fallback merely because its manifest is syntactically correct. Previously defined startup or health criteria must have been met. Which artifacts must already have been loaded depends on which remotes are critical to initial product startup.

Last Known Good is still only one possible strategy.

Depending on the risk model, a system may instead use a built-in safe baseline composition, fail in a controlled manner, or prevent access to particular product areas.

Important questions include:

• Where is the last known good composition stored?
• What happens on a first visit without a cache?
• How is a syntactically valid but incomplete manifest handled?
• How quickly does an activation become visible?
• How quickly does a rollback become visible?
• Which cache lifetimes limit reaction time?
• Do older artifacts remain retrievable?

An Activation Service in the critical startup path requires a deliberate failure model.

Integrity and Protection of Activation Control

A dynamic manifest is not automatically safer than a static mapping. It improves controllability, but becomes an availability and security boundary itself.

Activation control must not become a mechanism through which the host loads arbitrary remote sources.

Possible safeguards include:

• only approved and trusted artifact sources,
• encrypted transport,
• schema validation,
• unique artifact digests,
• integrity metadata,
• signed manifests or product compositions where required by the risk model,
• restricted write permissions for activation mappings,
• traceable approval and activation identities,
• protection against loading unapproved sources.

A hash can demonstrate that loaded content matches the expected content. It does not automatically replace trusted approval or origin verification.

Whether and how specific browser mechanisms for integrity verification can be used depends on the actual loading process and technical integration. Not every setup offers the same capabilities.

Rollback by Reverting a Mapping

With immutable artifacts and composition snapshots, a rollback does not require rebuilding an old artifact.

Artifact store
├── Remote A 1.0.0
└── Remote A 1.1.0

Before activation:

production-de → Composition 171
               └── Remote A 1.0.0

After activation:

production-de → Composition 184
               └── Remote A 1.1.0

Rollback:

production-de → Composition 171

Neither Remote A 1.0.0 nor the host is rebuilt.

The technical rollback changes the activation mapping. It reverses the previous activation decision and points the channel to an earlier composition snapshot that is still valid.

Why a Rollback Can Still Fail

Immutable artifacts enable a fast rollback. They do not guarantee a safe rollback.

Returning to an older product composition is possible only if the older remote artifact remains available. Its dependencies and integration contracts must continue to work as well.

A rollback can fail when:

• older artifacts or dependent assets have been deleted,
• APIs are no longer backward compatible,
• data models or server-side state have changed incompatibly,
• the current host can no longer mount the older remote,
• shared runtime dependencies are no longer compatible,
• the cache strategy does not make the reverted activation mapping visible quickly enough.

A rollback can be triggered technically within seconds and still be impossible in domain terms.

Immutable artifacts are a prerequisite for fast rollbacks, but not a substitute for backward-compatible contracts.

An earlier Composition ID should therefore not be considered a safe fallback merely because it still exists. Its technical and domain validity must be preserved for the intended rollback window.

Observable and Reconstructable Product Compositions

A dynamically resolved product composition must be diagnosable.

At minimum, the following should be traceable:

Composition ID
host version
Remote A 1.1.0 / Build 184
Remote B 2.3.1 / Build 92
release channel
relevant usage context
resolution timestamp

This information can appear in technical logs, error reports, support information, telemetry, incident records, or a diagnostic view.

Anyone operating parallel product compositions must be able to say which concrete composition was affected by a failure.

Outputting only production or latest is insufficient. Those values describe a mutable pointer, not the product state that was actually loaded.

For later reconstruction, the channel mapping active at the time, the referenced immutable composition manifest, and the remote artifacts named by it all need to be retained.

Feature Flags Are a Different Control Layer

Version activation and feature flags solve different problems.

Version activation
→ Which implementation of the remote is loaded?

Feature flag
→ Which behavior inside the loaded implementation is active?

A usage context can load Remote A 1.1.0 while a new function within that version remains disabled:

production-de
└── loads Remote A 1.1.0
    └── Feature flag disables Function X

That differs fundamentally from continuing to load Remote A 1.0.0:

production-de
└── loads Remote A 1.0.0 instead of 1.1.0

A feature flag does not replace controlled artifact activation. A composition manifest does not replace domain feature flags.

Both mechanisms can be used together. They should, however, remain separately observable, owned, and reversible.

Which Version Does the Host Load, Then?

A remote team can publish version 1.0.0 and version 1.1.0 independently. Whether and when the host loads version 1.1.0 depends on where the mapping between product context and remote version is managed.

If the remote address is hard-coded into the host bundle, the switch requires a host release.

If the host instead resolves an external, approved product composition, a compatible remote version can be activated without a new host code release. Activation still remains a controlled product approval.

For reproducible and tightly controlled product landscapes, it is more robust to publish immutable remote artifacts and immutable composition snapshots and change only the mapping from a release channel to a Composition ID under controlled conditions.

The host should use exactly one Composition ID for the duration of a session. This ensures that remotes loaded lazily later originate from the same approved product state.

Parallel remote versions remain possible. They require limited compatibility windows, traceable ownership, and a planned retirement date.

A fast technical rollback is safe in domain terms only if older artifacts remain compatible with APIs, data models, the host, and runtime contracts. A rollback is a new activation decision pointing to an earlier composition snapshot that is still valid.

Published is not activated. Independent remote releases and controlled product activation do not conflict. The host should not implement approval policy as country and tenant branches. A concrete product composition is activated, not an abstract version named latest.

Dynamic resolution therefore needs more than a mutable manifest: atomic mappings, a clear cache strategy, integrity checks, observability, an audit trail, and a deliberate failure model.

The host does not load the newest remote version. It loads the version explicitly approved for the current usage context.