Release engineering / Usage guideSEPTEMBER 2026

How to use Launchpad /

A practical path through Launchpad, from the first input to a saved, reviewable result.

A dark release-control interface combines the release queue, staged path, changed-file story and decision checklist. Its public simulation makes review dependencies visible without implying a deployment occurred.

Before you begin

Explore the public interface with example records first. Its preview interactions stay in the current view; use the workspace link to open the account-backed product described below.

Create an account in Launchpad and work in its own private workspace. Accounts and records from another Lumia product are separate. Developers and delivery leads who need a small, inspectable release and recovery workflow for dependency-free Node builds producing a single local artifact.

Follow the workflow below to understand the application. Contact Lumia for a guided walkthrough; account access is private. An exported file reflects the record at the time of export.

01

Prepare the source and release

Import an authorized folder, inspect its revision and choose the build script. Enter the output path under dist/ and meaningful recovery instructions. The demonstrated path uses node --test followed by node build.mjs and emits dist/index.html. Each release stays associated with its selected immutable source snapshot.

02

Run and inspect actual checks

Start tests and build from the release view. The action becomes unavailable while the executor is working, and the interface displays persisted command results afterward. Read the regression output and build evidence; a successful click or a queued job is not a finished build. Correct source issues in a new snapshot when needed.

03

Approve and package the artifact

After passing checks, the owner reviews the release and approves the current evidence and exact artifact digest. Download the ZIP to retain the built file, release evidence and recovery instructions. If checks run again, review the new evidence and approval state before reusing the release. Approval is tied to the reviewed record.

04

Promote and restore locally

Compare the proposed and current artifact digests in the promotion dialog. Confirm to serve the approved HTML in the local isolated frame. After a second promotion, the rollback dialog identifies the prior digest and revision. Restore it and check both visible content and history. This action changes only this product's local preview target.

Operating the product

Start with the public interface to explore the design using example records. These interactions stay in the current view. Open the private workspace from the interface to use the existing account, storage and product workflows.

Run the application and its product-specific local executor with Docker available. A production build of the UI alone does not execute a release job.

Keep source, artifacts, release records, deployment snapshots and the runner journal within the backup and restore scope. Verify restoration before relying on it operationally.

After a restart or interrupted request, read the current release and target digest before retrying. Reuse the intended operation identity rather than creating unrelated duplicate actions.

Treat promotion and rollback confirmations as a review of exact bytes. External delivery needs its own credentials, permission model, environment checks and acceptance tests.

APPLY THE THINKING

A similar problem in your business?

Bring a real workflow, representative inputs and the result that needs to be reliable.

Shape a project brief