Kubernetes at the Edge with GitOps: How ayedo transformed a distributed IoT fleet from SSH deployments to controlled rollouts

Edge Computing is not just hype for IoT, Industry 4.0, and Smart Grid scenarios; it’s operational reality. Data is generated not in the data center, but out in the field: at measurement points, in transformer stations, at gateways in municipal networks, or in industrial plants. To reliably bring this data into a central data hub, software must be operated at hundreds of locations—often with unstable connectivity, limited maintenance windows, and high demands on availability and integrity.

This is where Kubernetes shows its strength: not just because of scalability, but because it enforces a declarative operational model that can also be applied to distributed edge workers. Combined with ArgoCD as a GitOps interface, it creates a fleet operation that feels like the cloud—but works at the edge.

In this post, we illustrate through an anonymized customer project how ayedo supported a European provider of IoT and IIoT solutions in transitioning over 400 Edge Points of Presence (PoPs) from manual SSH/SFTP deployments to a Kubernetes-based edge platform—reproducible, version-secure, and auditable. The customer remains anonymous. The approach is transferable.

Initial Situation: 400 PoPs, growing software—and deployments like ten years ago

The customer develops IoT and IIoT solutions for Smart City, Smart Grid, and Smart Metering scenarios. The edge locations capture measurements, perform preprocessing, and transmit data to central systems. The PoPs are widely distributed and often only connected via 5G or microwave links—exactly where “quick access” is not feasible.

Operationally, the setup had grown over the years. Software was distributed manually, updates were applied via SSH, artifacts were rolled out via SFTP, and configurations were adjusted at individual locations. This is manageable for a handful of systems. With several hundred PoPs, it becomes a bottleneck.

Manual deployments are not only slow. They inevitably create inconsistencies. One location receives an update later than the next. A configuration file is “briefly” adjusted but never reverted to a standard. A fix is made directly on the system because it needs to be quick. Over time, configuration drift occurs—and drift is particularly costly at the edge because every deviation makes debugging and rollouts unpredictable.

The team first noticed the consequences in planning. Maintenance windows became more difficult because it was unclear which PoPs were truly up to date and what dependencies had accumulated over the years. New features reached the fleet with delays because each rollout meant operational effort. Security updates became a logistical challenge—and in critical environments, this is not just an inconvenience but a risk.

At the same time, the engineering team grew. This brought new requirements that are hardly solvable in “SSH realities”: segmentation of access rights, conditional access, clear responsibilities, knowledge transfer without heroics. Initial attempts to reduce complexity with Nomad or Docker Swarm did not bring the hoped-for breakthrough—because the core problem was not “orchestrator missing” but “operational model not standardized.”

The Core of the Problem: Edge needs declarative state—not imperative tinkering

Manual deployments follow an imperative pattern: “do this, do that.” This pattern breaks at the edge for two reasons.

The first reason is connectivity. PoPs are not permanently stable in terms of reachability. A deployment that breaks off in the middle of a transfer leaves an undefined state. This increases drift and creates an operational tailspin.

The second reason is scaling. Even if every deployment were perfect: if a team has to touch hundreds of locations with each rollout, it’s not the platform that scales, but only the workload. This inevitably leads to delayed updates—and thus both innovation and security suffer.

The solution is not “more scripts,” but a system that describes the desired state and continuously enforces it. This is where Kubernetes—properly implemented—is a very good foundation. And this is where GitOps with ArgoCD unfolds its value: not as a tool, but as a control principle.

ayedo’s Approach: Edge fleet as a GitOps system—with Kubernetes distribution and central platform backbone

We fully migrated the edge infrastructure to the ayedo Kubernetes Distribution and organized the fleet so that each PoP operates as an independent Kubernetes node—centrally orchestrated and managed via ArgoCD.

This is the crucial change in perspective: The PoP is not a “server” where things are copied. The PoP is part of a fleet that derives its state from Git. Deployments happen declaratively, reproducibly, and version-securely. If a location is temporarily offline, chaos does not ensue—the PoP reconciles automatically as soon as it is reachable again.

To prevent this approach from becoming a “GitOps silo,” we also equipped the operational model with central platform components that are not optional in the edge context: identity, observability, artifact security, and secrets.

ArgoCD as Management Interface: Rollouts become controllable and auditable

ArgoCD became the interface between development and operations. Every change to workloads is a commit. Every deployment is traceable. Every deviation between desired state and reality becomes visible.

Especially at the edge, this drift detection is key. While in a manual setup drift often only becomes apparent when something breaks, in the GitOps model it becomes a signal: The PoP deviates—and the controller brings it back to the defined state.

This not only brings technical consistency. It creates predictability. Rollouts can run in waves, step by step, with clear criteria. And if a version causes problems, a rollback is not an emergency SSH, but a controlled return to the last known state.

Identity and Access: Keycloak as a foundation for team scaling

As the fleet grows, so does the number of people needing access—and thus the necessity to control, segment, and document access.

We introduced Keycloak as an identity provider, including single sign-on and role-based access control. In the edge context, this is more than convenience. It is a security and governance building block: Who is allowed to deploy? Who can only observe? Who has access to secrets? Who can access production environments?

Through central identities, the operational model also becomes organizationally robust. Knowledge and responsibility can be distributed without “who has the SSH key” becoming a hidden power center.

Observability: VictoriaMetrics, VictoriaLogs, and Grafana for fleet operation

In distributed PoPs, monitoring “running or not running” is never enough. Central visibility into states, trends, and anomalies is needed. This concerns not only technical metrics but also the behavior of workloads under changing network conditions and real field load.

We integrated an observability stack consisting of VictoriaMetrics, VictoriaLogs, and Grafana. This makes fleet operation manageable: identifying PoPs that deviate, seeing latency and error trends, securing rollouts with telemetry, and identifying problems early.

An additional lever was created by the stack not only aggregating “ops signals” but also business data. Energy values and measurement data from the field are directly fed into this pipeline and visualized. This is a pragmatic first step towards “Edge-to-Cloud Data Intelligence”: technical transparency and business evaluation grow together, and data becomes more quickly connectable for BI and further processing.

Artifact Security: Harbor with SBOM scans as a standard process

Edge environments have a unique security reality: many locations, many updates, often physical proximity to potential attack surfaces. If it is not ensured that only verified artifacts are rolled out, one remains permanently vulnerable.

We introduced Harbor as a container registry, including integrated security scans and SBOM generation. The effect is twofold. First, the security of deployed artifacts becomes measurable and controllable. Second, traceability is created: Which components run where, which vulnerabilities were known, which versions were rolled out when?

Especially when edge projects grow into regulated industries, this type of supply chain transparency is a real door opener—because compliance is no longer “project work” but part of the delivery process.

Secrets Management: Vault for keys, tokens, and rotation capability

In practice, many edge setups fail not on Kubernetes, but on secrets. API keys, certificates, tokens, and credentials are often distributed locally, manually renewed, or hidden in configurations. With 400 PoPs, this becomes a permanent risk.

With HashiCorp Vault, secrets management was centralized and integrated into the GitOps/delivery process. This reduces the attack surface and makes key management operational: secrets are no longer “somewhere,” but controlled, auditable, and rotatable. This enables an operation that is both faster and more secure—instead of having to choose between the two.

The Biggest Lever: Cloud-native delivery processes instead of edge special paths

The central change was not a single tool, but the shift to cloud-native development and operational processes. This has an impact on both sides.

On the engineering side, it means: changes go through standardized pipelines, are versioned, reviewed, reproducible. On the operations side, it means: rollouts are plannable, drift becomes visible, incidents are contained faster, and updates are no longer “an event” but routine.

This combination of speed and predictability is the point at which edge operation becomes economically viable. Not because less is operated—but because operation is defined as a platform standard.

Result: Multiple daily deployments, higher security, auditable processes

After the transition, deployments for the entire edge fleet now occur multiple times daily—in a controlled, continuously monitored GitOps process. Deployment times have drastically decreased, updates are rolled out consistently and reach locations regardless of whether they are perfectly reachable or not.

Through SBOM and security scans in Harbor, the security of the artifacts has significantly increased. Errors and anomalies are detected early through the observability stack and immediately translated into incident processes. This makes operation not only reactive but proactive: problems become forecastable and actionable before they escalate.

The built-in audit functions of the platform also enable the customer to serve projects with higher compliance requirements without the engineering team having to build their own special processes. And by integrating business data into the observability pipeline, an additional value is created: measurement data from the field is not only transported but immediately visible and analyzable—a building block for new data-driven services.

Why this approach works: Edge is