Running OCI Workloads on nova8OS

nova8OS is a purpose-built edge operating system with a single application delivery mechanism: OCI-compliant container images. There is no package manager on the host, no application installation path outside the container runtime, and no supported way to run uncontainerized binaries in production. If your workload runs as an OCI container, it runs on nova8OS. If it does not, it cannot.

This constraint is deliberate. By limiting the application surface to OCI containers, the platform eliminates entire classes of host-level configuration drift, dependency conflict, and ad hoc software installation that erode security and predictability at fleet scale. The host exists to boot, establish identity, and run containers, nothing more.

The practical implication for application teams is straightforward: package your application as a container image that conforms to the OCI Image Specification, and it will run on nova8OS. No host-level setup, no prerequisite packages, no installation scripts.

The Open Container Initiative defines two specifications that matter for application teams: the OCI Image Specification (how container images are built, stored, and distributed) and the OCI Runtime Specification (how container processes are created and executed). Compliance with these specifications is the contract between your workload and the nova8OS platform.

In practice, any container image built with standard OCI-compliant tooling will produce a compliant image. The specification ensures portability: an image built on a developer workstation, validated in CI, and pushed to any OCI-compliant registry can be pulled and executed on nova8OS without modification.

Teams should avoid build practices that produce non-standard images or rely on runtime-specific extensions that fall outside the OCI specifications. The platform enforces the standard contract and does not support vendor-specific image formats or proprietary runtime extensions.

• Use standard OCI-compliant build tools to produce specification-conformant images.
• Push images to any OCI-compliant registry. The platform pulls standard OCI artifacts.
• Avoid proprietary image formats or runtime extensions that fall outside the OCI specifications.
• Validate images with OCI tooling before deployment to catch compliance issues early.

nova8OS provides the Linux kernel, the OCI container runtime, device identity and enrollment services, and fleet management integration. It does not provide a package manager, development tools, application-level libraries, language runtimes, or any software that belongs inside your container image.

The host filesystem is immutable. Workloads cannot write to host paths, install packages on the host, modify host configuration files, or assume that any host-level state persists across reboots. Persistent storage for application data is provided through explicitly configured volume mounts, not through host filesystem access.

This model requires a shift in thinking for teams accustomed to installing dependencies on the host. On nova8OS, everything your application needs must be inside the container image or provided through a mounted volume. There is no fallback to host-level package installation.

• The host provides: kernel, OCI runtime, device identity, fleet management, and network connectivity.
• The host does not provide: package managers, compilers, language runtimes, application libraries, or writable host paths.
• Persistent application data uses explicit volume mounts, not host filesystem writes.
• Host configuration is managed by the platform. Workloads cannot modify it.

The most important design principle for nova8OS workloads is self-containment. Your container image must carry every dependency your application needs: runtime libraries, language interpreters, configuration files, certificates, and static assets. Nothing is inherited from the host beyond what the OCI runtime specification guarantees.

Multi-stage builds are the standard practice for producing minimal, self-contained images. The build stage installs compilers, development headers, and build tools; the final stage copies only the compiled artifacts and runtime dependencies into a clean base image. This produces smaller images with fewer components, which reduces both pull time over constrained edge links and the in-container attack surface.

Base image selection matters. Choose minimal base images (Alpine, distroless, or scratch-based) that include only what your application requires. Every unnecessary binary or library in the base image is a component that must be tracked for vulnerabilities and updated across the fleet.

• Use multi-stage builds to separate build-time dependencies from runtime artifacts.
• Choose minimal base images (distroless or Alpine) to reduce image size and attack surface.
• Include all runtime configuration in the image or inject it via environment variables and mounted config files.
• Pin base image versions and dependency versions for reproducible builds.

nova8OS enforces image admission policy at the runtime level. Only container images that meet the platform's signing and verification requirements are permitted to run. This means application teams must sign their container images as part of the CI/CD pipeline, using the signing keys and processes established by their organization's release governance.

Image signing follows the cosign/sigstore model: the image is signed after build, the signature is stored alongside the image in the OCI registry, and the platform verifies the signature before allowing the container to execute. Unsigned or incorrectly signed images are rejected at admission time. They will not run.

Teams should integrate image signing into their automated build pipeline so that every image pushed to the registry is signed without manual intervention. The signing step should be non-bypassable: if the build succeeds but signing fails, the image should not be published.