There is a specific kind of frustration that comes with managing a fleet of edge devices when something small needs to happen across all of them. Not a deployment. Not a version update. You just want to run scripts across edge devices. Maybe Docker’s logging system has filled up the disk again, something it does quietly and without apology. Maybe you need to check network connectivity across fifty remote nodes. Maybe a data gap appeared because a tower went offline during load shedding, and you need to push that missing data back to the cloud before the engineers notice the gap in their dashboards.
In all of these situations, you know exactly what you need to do. The problem is doing it at scale without breaking anything in the process.
If you rely on tools built primarily for container management, running scripts across edge devices means packaging your script into a temporary container, deploying that container as a one-time-run job to every device, waiting for it to finish, and cleaning up after it. What should be a five-minute task becomes a multi-hour process. And if you are SSHing into devices individually, you are not solving the problem, you are just exhausting yourself doing it one node at a time.
Daployi approaches this differently, through a feature in its templating system that most people do not fully appreciate until they have needed it.
Using Template Sections to Run Scripts Across Edge Devices
When you build a template in Daployi, you are not just writing a Docker Compose file. A template can contain several independent sections: your Compose stack, your environment variables, your scripts, and tunnel configuration. Each of these sections can be switched on or off independently.
This means you can create a template that only activates the Scripts section. When you execute that template, whether against one device, a group of devices, or your entire fleet, Daployi only processes what is switched on. Your containers remain unmodified. Your variables stay exactly as they are. Nothing else is touched. The platform targets the script, executes it, and reports back.
This is a more fundamental capability than it might first appear.
The Operational Difference
Consider how most deployments actually work in a Docker environment. Variables are baked in at container startup. If you need to change one, you are typically recreating the container, which means a full redeployment, a heavier, riskier process than the change itself warrants. Over time, teams start treating all changes as full redeployments, because that is what their tooling forces them to do.
Daployi’s template sections break this assumption. When you need to change a configuration value across your fleet, you create a Variables-only template, set the new values, and execute it. Only the variables are modified. The change goes in cleanly.
When you need to run a maintenance script, you create a Scripts-only template. The logic is defined once, the script executes across the targeted devices, and your services are not at unnecessary risk.
What you end up with is a library of purpose-built templates: one for provisioning new devices end-to-end, one for maintenance tasks, one for configuration updates, one for data recovery operations. Each template does exactly one type of thing, by design, which means the risk of an unintended side effect is dramatically lower than it normally would be.
How to Run Scripts Across Edge Devices: More Control Than You Might Expect
Not all scripts serve the same purpose, and Daployi reflects that by letting you define not just what a script does, but when and how it triggers. There are four run modes, and choosing the right one for a given task is part of what makes the system practical at scale.
Run Once
“Run Once” executes a script exactly one time, regardless of what happens to the device afterward. Even if the agent is removed and reinstalled, or the device is rebooted, the script will not run again, because the execution state is stored outside the agent itself. This is the right mode for setup tasks: creating directory structures, seeding initial configuration, or anything that should only ever happen once on a fresh device.
Run at Startup
“Run at Startup” triggers every time the device restarts. A common use case is checking that hardware aliases are still correctly mapped. On devices with USB serial adapters, for example, the mount point can shift if the adapter is unplugged and reconnected. A startup script can silently verify and correct that alias every time the device boots, so the service always finds what it expects.
Run at Interval
“Run at Interval” executes on a repeating schedule. This is well suited to health checks and routine maintenance: verifying DNS resolution and restarting the service if it has stopped resolving, monitoring disk usage, or clearing temporary files on a cadence. Rather than waiting for something to break and then responding, interval scripts let you build self-correcting behaviour directly into the fleet.
Manual
“Manual” scripts are defined and deployed to devices, but only execute when someone explicitly triggers them. This mode is for tasks that need human judgement before they run. Consider tasks like fetching a specific data window, clearing logs, or any operation that could be destructive if triggered at the wrong moment. The script is ready and waiting; the decision of when to run it stays with the operator.
What makes this four-mode system genuinely useful at fleet scale is that all of these run types live inside the same template structure. A single Scripts-only template can carry multiple scripts, each with its own run mode, deployed across thousands of devices in one operation.
A Real-World Scenario: The Docker Log Accumulation Problem
To make this concrete, take a problem that comes up repeatedly in forums and issue trackers wherever Docker runs on resource-constrained devices: log accumulation. Docker’s default logging driver stores container logs as JSON files on the host filesystem without any size limits, which means they grow continuously until something breaks. On a powerful server with a terabyte of storage, this is an inconvenience you notice eventually. On an edge device with a small SSD or an SD card, the kind of hardware that lives inside a cabinet at a remote site, it is a slow-motion disaster.
An ops team managing a fleet of thirty remote devices wakes up to alerts: containers failing to write logs, services refusing to start, deployments timing out. The root cause, when they dig in, is the same across most of the affected machines. The disk is full, and Docker’s logging system put it there.
Before having the right tooling, fixing this meant SSHing into each affected device one at a time, running the cleanup command manually, verifying the disk had freed up, and moving on to the next one. Thirty devices. Thirty sessions. And the deeper problem, that it will inevitably happen again, still has no answer, because there is no easy way to push a scheduled cleanup job across the whole fleet without building something custom.
With Daployi, a DevOps engineer writes a log cleanup script once, inside a template that only has the Scripts and Variables sections active. The script truncates the Docker log files, checks remaining disk space, and reports back. It is parameterised with a threshold variable so the team can control which devices it targets based on how critical the situation is. They log into Daployi, select the affected devices, and click execute.
The script runs across all thirty devices in a single operation. Disk space is recovered. Services resume. And because the template is saved, the team can go one step further: set the same script to run at an interval, like once a week, or automatically, turning a reactive firefight into a routine, self-managing process that nobody has to think about again. That is the difference between a Manual script for the emergency recovery, and an Interval script for the ongoing prevention. Both can live in the same template system, or even in the same template.
Crucially, nothing else changed on those devices. The running containers were untouched. The existing configuration was not reset or overridden. The only thing that happened was the thing that needed to happen.
The Benefit for Wider Team Access
There is a second advantage to this approach that is easy to underestimate: it makes certain operations accessible to people who are not developers.
When operational logic lives inside a targeted, parameterised template, the complexity of that logic stays with the engineer who built it. The person executing the template only sees the inputs they need to provide such as a date range, an IP address, or a device identifier. They do not need to understand the underlying script. They do not need shell access. They do not need to know what commands are running or in what order.
This matters in practice because not everyone managing an edge fleet at the operations level is a developer. Field engineers, electricians, and on-site technicians often need to run maintenance tasks on devices they manage. If doing so requires modifying a bash script or SSHing into a Linux system, it simply will not happen, or worse, it will happen incorrectly. If doing so means logging into a web platform, selecting a group of devices, filling in two fields, and clicking a button, it is something a much wider group of people can do safely and consistently.
How This Compares to the Alternatives
Portainer does not provide a native, template-driven system for orchestrating scripts across device fleets. While features like Edge Jobs allow commands to be executed on multiple nodes, these are job-based and lack the structured, reusable, and variable-driven orchestration needed for consistent cross-node operations. As a result, more complex workflows often require per-node execution patterns or packaging logic into container deployments.
Tools like Mesh Central or raw SSH workflows have no equivalent concept at all. They offer terminal access to individual machines, which is useful for troubleshooting but not for fleet-wide operations. There is no templating, no variable injection, no run-mode scheduling, and no audit trail of who ran what and when.
The ability to run scripts across edge devices as a first-class, targeted operation, without full redeployment, without significant service disruption, and with parameterised inputs, is not something most teams are accustomed to having. Once they do have it, it changes how they think about maintenance and operational tooling at scale.
Conclusion
The ability to run scripts across edge devices without triggering a full deployment is one of those features that is hard to articulate until you have needed it. Daployi’s template section model, where a template can target only scripts, only variables, or any combination of sections, gives teams a way to make changes in a much more controlled and surgical way than most tools allow.
The four script run modes extend that control further, letting teams encode not just what should happen on a device, but when and under what conditions. Setup logic runs once. Health checks run automatically on a schedule. Recovery operations stay available as manual triggers for when they are needed. All of it lives inside the same reusable template, deployable across a fleet of any size.
It reduces the risk of unintended side effects. It lowers the barrier to execution for non-developers. Importantly, it shifts the maintenance of a large fleet from a high-effort, error-prone manual process into something repeatable, auditable, and operationally sane.