Shared source
Start from a common Git source and preserve the exact commit and user-friendly version associated with a release. Different deployment types can advance independently while remaining tied back to the same source history.
Software delivery
From shared source to a controlled deployment.
Microwave Pie software delivery capabilities are designed to make self-hosted application implementation easier: manage releases from a shared source, create the right package for a deployment, apply licensing, and keep installation and updates tied to a known release.
Shared delivery model
1Shared application sourceOne source history and release identity.
2Platform releaseBuild for the intended deployment target.
Source package
Compiled package
3Licensed packageIssue the package for a specific implementation.
4Install and updateKeep deployment history connected to the release delivered.
Capabilities
Keep release choices flexible without losing control.
Different environments do not always need the same package format or the same release at the same time. Microwave Pie separates shared application source, reusable releases, packages, licenses, and installed instances so each concern can move deliberately.
Source packages
Deliver the application as source when transparency, direct runtime deployment, or platform-specific Python installation is the better fit. Source packages retain the same release and licensing model as compiled packages.
Compiled packages
Deliver a compiled application package when a more self-contained runtime is preferred. Compilation is a delivery choice, not a separate product lineage, so release provenance remains consistent.
Package & license management
Issue a package with its license and target deployment context already associated. Package lifecycle, license state, downloads, installations, updates, revocation, and closure can be managed together instead of reconstructed later.
Target-specific release choices
Raspberry Pi, GCP, source, and compiled deployment types can remain at different release levels when there is a reason to do so. Missing Git commits can be reviewed by deployment type as well as across the application.
UI-managed updates
Managed applications can automatically surface when an approved update is available without forcing it. An administrator chooses when to prepare and apply the update in the application UI; after restart, the installed release can be confirmed back to the shared delivery service while preserving the Package and License relationship.
Implementation
Package the deployment, not the uncertainty.
A software package can carry the implementation context needed to turn an application release into a working deployment: target platform, package format, installation behavior, release identity, and licensing relationship.
That lets the implementation process begin from a known release instead of asking every environment to recreate build and delivery decisions independently. When a newer release is appropriate, the existing Package and License relationship can remain intact while the selected release advances deliberately.
Application Releases preserve the artifact and Git identity that was actually built.
Availability can be announced automatically, but downloading, preparing, applying, and restarting remain deliberate administrator actions.
Packages, licenses, and installed instances stay connected through installation, update, revocation, and closure.
Blackcap
One application using the model today.
Blackcap can be deployed to supported Raspberry Pi and GCP environments using source or compiled packages while keeping release, package, license, and update behavior aligned.