Senior Systems Engineer II - Edge Platform & Packaging (On-Prem)

Dispel builds secure, private network infrastructure for critical industries. A large of our product does not run in our cloud — it runs on appliances inside customer plants, substations, water districts, and manufacturing floors, on networks we do not control, behind change-control windows we do not set, sometimes reachable only through a narrow tunnel and sometimes not reachable at all. Every one of those appliances has to be installable by a field technician, patchable without a truck roll, and diagnosable after the fact. As a Senior Systems Engineer II, you own how Dispel's on-premises software gets built, packaged, shipped, updated, and observed. That covers our Site Control appliance and the Wicket fleet: the OS baseline, the container and package layers, the release artifacts, the signing and provenance chain, the update mechanism, and the local telemetry and edge-processing capability that lets an appliance keep doing useful work when its uplink is degraded or gone. This is a systems role, not a build-tooling role. You will make consequential calls about the runtime substrate on the edge, how state and configuration are reconciled, how an appliance recovers from a failed update, and how much processing belongs at the edge versus in the cloud. You scope that work into well-defined milestones, estimate it, and follow through — and you write it so other engineers can reason about it and extend it with confidence. Engineering at Dispel is a collaborative effort and those that show up trying to get things done and help others will receive support from the team. Dispel has high aspirations and we are growing quickly. Requirements Execution (Primary Focus) Packaging and Release Engineering - Own the build and packaging pipeline for on-premises deliverables — OS images, packages, container images, and the release bundles field and customer teams actually install. - Make on-premises builds reproducible and verifiable: pinned inputs, deterministic outputs, signed artifacts, and an SBOM per release that survives a customer security review. - Design a versioning and compatibility model that tells anyone, at a glance, which appliance versions interoperate with which cloud-side and orchestration components. - Collapse bespoke, per-project packaging into a small number of supported paths, and make the supported paths good enough that nobody wants to fork them. - Turn appliance provisioning from a documented procedure into an automated, idempotent one. Updatability - Own the update mechanism end to end: delivery, staging, application, verification, and rollback — for appliances on constrained links, in maintenance windows, or fully air-gapped. - Design for failure as the normal case. An interrupted or bad update must leave the appliance in a known-good state and recoverable without a site visit. - Build fleet-level release control: staged rollouts, cohorts and canaries, version and drift visibility across the fleet, and a mechanism to hold or reverse a rollout in progress. - Shrink the interval between a CVE being published and the fleet being patched, and make that interval measurable rather than anecdotal. - Keep the update path working across the OS baseline and its kernel lifecycle, not just the application layer on top of it. Edge Processing - Extend the appliance runtime so workloads can execute locally — telemetry collection and pre-processing, buffering and store-and-forward, local decisioning — and reconcile cleanly when connectivity returns. - Define what belongs at the edge versus in the cloud, and hold that line with evidence about bandwidth, latency, and customer data-residency constraints rather than preference. - Own resource discipline on the appliance: hardware is fixed, workloads grow, and the network functions on that box must never be starved by anything you add beside them. - Design the local observability story so that a support engineer can reconstruct what an appliance was doing without shell acces