Foundry Release Control is now live: a first-class application for turning independently released FOLIO components into coherent, inspectable release descriptions.
It grew out of a practical frustration. Foundry already loads individual frontend applications as micro-frontends, assembling the interface at runtime rather than building one monolithic frontend. But we had taken a shortcut around organising the releases behind that flexibility.
A Dashboard fix exposed the cost. A React-runtime mismatch broke widget configuration. The repair needed a new Dashboard MFE publication, not a backend change—but discovering, tracking and selecting that corrected artifact still involved too much manual release bookkeeping. We had encountered the coordination friction we wanted Foundry to remove.
From release bookkeeping to a continuous loop
Release Control watches Git release tags and correlates them with published container images and MFE distributions. It preserves the distinction between source versions, adapter versions and the actual deployable artifacts. Existing build pipelines still produce those artifacts; Release Control tracks and selects them.
Distribution Definitions describe the software set; Channel Definitions express version-selection policy. Release Control reconciles both against the component register, producing an exact, immutable Distribution Revision when the selection changes. Unchanged inputs reuse the existing revision.
The scheduled loop runs every 15 minutes: continuously maintained release information, rather than another spreadsheet that starts ageing as soon as it is written.
flowchart TD Git["Git release tags"] --> Register["Correlate source releases<br/>with published artifacts"] Artifacts["Container images<br/>and MFE publication indexes"] --> Register Register --> Resolve["Resolve the channel selection"] Policy["Distribution Definitions<br/>and Channel Definitions"] --> Resolve Resolve --> Revision["Changed: mint an immutable revision<br/>Unchanged: reuse the existing revision"] Revision -->|"Next scheduled check · 15 minutes"| Register Revision -.->|"Delivery integration in progress"| Registry["Registry signs and publishes"] Registry -.-> Foundry["Foundry syncs release availability"] Foundry --> Choice["Stay pinned or choose an update"]
Fresh releases without forced upgrades
An up-to-date channel is not an instruction to upgrade every installation. Foundry allows users to pin versions. Release availability, choosing an update and executing that update remain separate decisions.
For a frontend-only Dashboard correction, the intended result is straightforward: publish the corrected Dashboard MFE, refresh the release description and adopt it where wanted. We still produce a new individual MFE bundle—but need not rebuild the entire frontend or change an unaffected backend.
Release Control now supplies the discovery and reconciliation layer. Signed Registry publication and Loom’s new consumption and upgrade path are the downstream integration work being completed.
That also creates a natural place for bundle smoke tests, compatibility checks and further QA stages. Having artifact evidence does not mean a release has passed those checks. Automating the lifecycle gives us somewhere explicit to add them—and a repeatable route from a small component fix to a controlled update.