Baseline
OCI service images
Web services, APIs, workers, and sandbox blueprints use immutable OCI references and digests. Existing registries and images remain useful instead of becoming provider-specific deployment definitions.
Deployments
OCI is the baseline, not the boundary.
GlobalStacks gives service deployments a portable OCI foundation while preserving first-class paths for static bundles, binaries, mobile outputs, installers, archives, and other target-specific artifacts.
First class
Typed file artifacts
Static bundles, executables, mobile archives, installers, browser extensions, packages, firmware, and other declared outputs use Artifact Stores rather than being disguised as container layers.
Target aware
Bespoke delivery
A target can consume the artifact shape it actually supports. Runtime-specific handling stays behind typed capabilities, scoped delivery grants, and explicit release metadata.
Strategic advantage
Adopt the platform without adopting a packaging dead end.
OCI gives GlobalStacks and its adopters a widely supported runtime contract. Typed non-image artifacts keep that common denominator from becoming an artificial limitation.
Keep existing packaging
Bring digest-pinned OCI images and connected registries into the common path before adding target-specific behavior.
Add targets below the product model
Adapt placement and materialization without teaching Products, Environments, Releases, and operators a new deployment vocabulary for every provider.
Avoid container-shaped compromises
Use object-backed artifacts when the output is naturally a bundle, binary, installer, archive, or device image.
Change infrastructure independently
Keep release identity stable while the target adapter changes how an approved artifact reaches Proxmox, bare metal, a managed region, or a specialized runtime.
One release vocabulary
Separate artifact identity from target mechanics.
1. Build
Produce an OCI image or a declared non-image artifact.
2. Identify
Resolve immutable digest, media type, artifact kind, and ownership.
3. Store
Keep images in an OCI registry and file artifacts in a mapped Artifact Store.
4. Release
Bind the exact artifact to a Product environment and deployment record.
5. Materialize
Let the selected runtime or provider adapter perform its typed target operation.
6. Operate
Track health, logs, rollout state, and the artifact identity that is actually running.
A concrete example
OCI into Proxmox, without pretending Proxmox is a container registry.
The validated GlobalStacks deployment path asks Proxmox to import an OCI image through file-based template storage, creates an LXC container with its runtime root filesystem on ZFS, and supplies environment-specific configuration separately. The image remains portable; the adapter owns the Proxmox mechanics.
1 OCI registry + immutable digest
2 Proxmox API import
3 File-backed template archive
4 LXC rootfs on selected storage
5 External runtime configuration
6 Health-checked rollout
Designed for extension
Build against artifact and capability contracts, not one provider's deployment script.
OCI-backed blueprints and typed object-backed artifacts are platform foundations today. Target-specific rollout depth varies by runtime; broader trusted-delivery policy and additional deployment adapters continue to expand on the same model.