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

Dispel

8d•$150,000 - $159,000•Remote

About The Position

Dispel builds secure, private network infrastructure for critical industries. A large share 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

5+ years of professional engineering experience with a demonstrated track record of shipping software that runs on infrastructure you do not operate.
You have owned a release and update mechanism for deployed systems — edge, appliance, embedded, or on-premises enterprise — and dealt with the consequences when one went wrong in the field.
Deep Linux systems fluency: systemd, the boot and init path, filesystem and partition layout, kernel and package lifecycle, and how a distribution actually gets assembled.
Strong packaging and distribution experience — Debian/apt packaging, OCI images, image-based or A/B update schemes, or equivalent — including artifact signing and repository operation.
Proficiency in at least one systems-capable language (Go, Rust, Python, or C) and comfort reading code across the layers you package.
Comfortable using coding agents (e.g., GitHub Copilot, Claude Code) as part of your daily workflow
Proficiency with Infrastructure as code, with primary focus using Ansible and Terraform.
Container runtime and orchestration experience, with real opinions about what is appropriate on a single constrained node versus in a datacenter.
Infrastructure-as-code and CI/CD experience (Terraform, GitHub Actions, or similar), including building pipelines that produce release artifacts rather than just deploying them.
Solid network fundamentals — routing, DNS, firewalls, VPN concepts — enough to package and operate networking software without breaking its data path.
Demonstrated ability to work with cross-team stakeholders to define requirements and deliver results with minimal oversight.
A willingness to accept failure and feedback, learn and try again.
A passion for learning new disciplines and gaining a deep understanding of how others on the team do their work.
An ability to communicate clearly and succinctly both in-person and over team chat.

Nice To Haves

Experience shipping into OT, ICS, or industrial environments, and familiarity with the change-control and segmentation realities of those networks.
Experience with air-gapped or intermittently connected deployments, including offline mirrors and sneakernet update paths.
Background in security-focused products where reliability and regulatory compliance matter — IEC 62443, NERC CIP, FIPS-validated cryptography, or FedRAMP-adjacent work.
Supply-chain security depth: SLSA, in-toto, Sigstore, SBOM generation and consumption, reproducible builds.
Lightweight Kubernetes distributions or single-node orchestration at the edge (K3s, MicroShift, Talos), and honest experience with their operational costs.
Image-based Linux and atomic update systems: OSTree, Mender, RAUC, SWUpdate, or similar.
On-premises virtualization, hardware bring-up, or hardware qualification experience.
Telemetry pipeline experience at the edge — agent-based collection, buffering, and forwarding into customer SIEMs.
Experience building or operating commercial VPN, ZTNA, or secure remote access products.

Responsibilities

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.
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.
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 access to it.
Own the integrity of the on-premises supply chain: signing keys, trust roots, artifact provenance, and the assumption that any of it may be audited by a customer or regulator.
Build the test substrate this work requires — appliance-in-a-loop testing, upgrade and downgrade paths exercised in CI, hardware and near-hardware validation before a release reaches a customer.
Ensure on-premises systems meet performance, scalability, and security requirements, particularly where packaging and runtime choices touch the network data path.
Participate in incident response and root cause analysis, especially for field failures where the evidence is thin and the appliance is remote.
Participate in an on-call rotation to support system reliability, including responding to incidents and performing after-hours troubleshooting as needed.
Partner with the field, support, and customer-facing engineering teams — they encounter your work first, and their friction is your backlog.
Work with security and compliance to make on-premises releases evidence-producing by default, so customer and regulatory reviews draw on artifacts you already generate.
Give product and engineering leadership a straight read on what the edge can and cannot support, early enough to change a plan.
Write the runbooks, upgrade notes, and architecture documentation that other engineers and field teams operate from.
Informally mentor IC1 and IC2 engineers on your team — through code review, pairing, and sharing technical context.
Participate in evaluation portions of interview loops to help Dispel hire well.