Releases and maintenance
A template release is a frozen configuration and documentation snapshot. Installed stacks record the exact originating release; public catalog changes do not silently change your running installation.
Three versions to keep distinct
| Identity | Example | What changes it |
|---|---|---|
| Template release version | 1.1.0 | A publisher submits a new configuration/documentation snapshot |
| Upstream software version | The application version stated by the release | The selected software and image content |
| Stack revision | Your saved configuration revision | Applying a reviewed stack update |
Published images are pinned to reviewed digests. A later tag change does not rewrite an immutable release. New metadata, images, inputs, documentation, icons, or screenshots need a new reviewed release.
Submission lifecycle
Drafts remain private. Save draft changes the draft; Submit for review freezes a candidate and assigns it to a template version that cannot be reused for different content.
| State | Meaning |
|---|---|
| Queued | Submitted and waiting for review |
| In review | Staff review is in progress |
| Changes requested | Read the reason, update the draft, and submit a successor with a new version |
| Rejected | The candidate was declined; inspect the reason before preparing another |
| Withdrawn | An eligible pending candidate was withdrawn; published releases are unchanged |
| Approved | The candidate met approval requirements; it may still await publication |
Publication is recorded separately from review state. A release is installable only when published, approved, available, and associated with an eligible template and active publisher. Publisher verification does not bypass this condition.
Submission and approval require the exact content snapshot and current evidence. Ordinary staff cannot approve or publish their own submission; the superuser exception retains all required evidence and audit checks. Saving another draft cannot rewrite an earlier candidate.
What publication evidence means
Static validation checks metadata and supported Compose configuration. Rights review covers configuration licensing and permitted branding/assets. Image scans, fresh installation tests, and persistence tests require actual external results for every declared architecture.
The portal records operator-run checks; it does not run the submitted software. Image-scan evidence is current for seven days for approval/restore requirements; rights, installation, and persistence evidence for 90 days. These windows are evidence requirements, not continuous scanning or a guarantee that a published application remains secure. Missing or expired evidence needs staff follow-up.
Availability and advisories
| State or action | New installations | Existing installations |
|---|---|---|
| Available release in a public template | Eligible, subject to normal checks | Keep their saved configuration |
| Unlisted template | Removed from catalog discovery; direct eligible release links can remain installable | Services and data remain |
| Deprecated release | Not eligible for new registry installation | Read the advisory and plan maintenance |
| Blocked release | Not eligible; remaining service submissions from a new installation can stop | Services and persistent data remain |
| Archived or suspended template, or suspended publisher | Not eligible for new registry installation | Running services and data remain; consult the advisory or maintainer |
Availability is checked at selection, during application of a new plan, and before each further service submission. A registry decision cannot recall a deployment already accepted by the pool. An installation stopped partway through can retain earlier deployed services and their data.
Existing stack configuration remains editable when its origin is blocked or archived. That preserves the customer’s ability to operate their own installation; it does not mean the original software or a new custom configuration is recommended or newly reviewed.
Applicable installed-stack members receive release advisories through their notification preferences. Also inspect Template origin and the release’s public explanation when planning maintenance. A notification is not an automatic patch or shutdown command.
Plan an upgrade deliberately
New template releases never automatically update installed stacks. There is no automatic replacement of the installed release snapshot with the catalog’s current release.
- Record the installed publisher, release, customization state, image versions, and data locations.
- Read the successor release notes and the publisher’s operations/upgrade instructions.
- Compare service layout, inputs, image versions, ports, resource needs, and persistent mount paths with your installation.
- Take independent backups and verify how to restore them. Test the upgrade with appropriate non-production data in a separate stack or environment.
- Choose the documented application upgrade path: deliberate configuration edits for a compatible in-place update, or a new installation and separate data migration when required.
- Review all affected services and downtime, apply the change, and verify application behavior and data before traffic cutover.
Editing an installed stack retains its original release identity and marks service-manifest differences as customized. Changing an image manually does not relabel it as the newer registry release. Creating a new installation also creates separate storage; it does not attach or migrate production data automatically.
Reverting an image does not undo a database schema migration or restore files. Follow the upstream recovery procedure instead of assuming a container redeploy reverses data changes. See Stack operations.
Publisher verification over time
A verified checkmark reflects reviewed publisher identity and maintenance evidence, with validity up to one year. Identity changes, expiry, revocation, or suspension can remove it. Pending public profile changes remain separate from the approved profile.
Verification does not establish an official relationship with the upstream application or a security guarantee. Read the specific release, maintenance notes, and advisory regardless of publisher badge.
Report a problem
Use Report a problem on the dashboard template page for deployment failures, outdated configuration, security concerns, impersonation, or licensing issues. Include the release version, steps to reproduce, observed failure, and redacted recovery details. Reports do not automatically change release availability; staff review the issue.
Exclude passwords, access tokens, private database URLs, customer data, and unredacted logs. Contact the listed publisher support path for application-specific maintenance, or info@infralane.cloud for platform access and registry help.