Engineering inside Launchpad /
The data model, constraints and recovery decisions behind Launchpad.
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.
Interface and interaction architecture
The public preview has local release states and a review checklist. The private full-stack app uses Cytoscape to connect real artifacts, approvals and local deployments by their recorded digests.
Source, execution and artifact identities
A release references an immutable repository revision, test command, build command and artifact path. The local runner performs actual Docker commands and returns bounded evidence plus the produced bytes. The package includes the artifact rather than a placeholder export. A digest provides a stable way to compare those bytes across package and deployment.
Approval is separate from execution
Tests and build must produce acceptable results before the owner can approve the release. The approval request supplies the saved record version and content digest. A stale review is rejected. Running checks again invalidates prior approval, so a previous decision cannot silently authorize different evidence or a newly produced artifact.
Frozen deployment snapshots
Promotion saves the approved artifact into a deployment snapshot and updates the local environment using its expected version. The previous snapshot remains independent of the mutable release record. The rollback path restores saved bytes, including when the earlier release has been rerun and its current approval cleared. Repeated commands use persisted operation identities.
A restricted local preview
The environment view renders its artifact in a titled iframe with sandbox allow-scripts and a restrictive response policy. Browser QA confirmed that parent document access raises SecurityError. This boundary lets a small HTML result be inspected locally without granting same-origin access. It is not a deployment connector, general application host or substitute for reviewing executable content.
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.
Independent by construction
Launchpad has its own application source, build configuration, local server, database, object store and session cookie. The fifteen applications reuse copies of a common foundation, but their operational data and credentials are independent. A shared dependency cache on this Mac saves disk space; each product includes a lockfile and a command to install its own dependencies.
Mutations validate the workspace and current record version. Approval binds the reviewed content digest; an idempotency key prevents an identical retry from becoming a second action. These controls are implemented in the server, alongside the product-specific rules described above.
A similar problem in your business?
Bring a real workflow, representative inputs and the result that needs to be reliable.
Shape a project brief