eworm routeros-scripts: running a script library on devices with 16MB of flash
a collection of scripts for MikroTik RouterOS
At a glance
- What is it?
- A collection of RouterOS scripts distributed by repository over HTTPS, with per device roles, generated variants, checksum manifests and a deliberate compatibility policy around RouterOS versions. Useful for MikroTik shops tired of retyping configuration, provided you can accept a script that touches a router's whole configuration.
- Who is it for?
- Adopt these scripts if you manage MikroTik devices that share one configuration model, since a role based system with an overlay and a checksum manifest removes a large amount of per device typing. Do not adopt them on a device with 16MB of storage or an ARM CPU without checking size first, and do not adopt them on RouterOS v6 from the main branch, which is v7 only.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly RouterOS Script, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The repository ships configuration, not a package manager
RouterOS has its own scripting language and its own update mechanism, and this repository leans into that. There is no package to install on your workstation and push out. There is a set of .rsc files that are downloaded onto the router and added to its configuration on the fly.
The description is deliberately modest: a collection of scripts for MikroTik RouterOS to manage devices or extend their functionality. The README says to use at your own risk and points at both a licence and warranty section and a disclaimer on external links. On a device that carries your uplink, that warning is not boilerplate.
What the collection covers is visible in the file names at the repository root: backup-cloud.rsc, backup-email.rsc and backup-partition.rsc, check-health.rsc, check-routeros-update.rsc, check-lte-firmware-upgrade.rsc, check-perpetual-license.rsc, check-certificates.rsc, certificate-renew-issued.rsc, dhcp-lease-comment.rsc, dhcp-to-dns.rsc, fw-addr-lists.rsc, gps-track.rsc, capsman-download-packages, capsman-rolling-upgrade, daily-psk, collect-wireless-mac and accesslist-duplicates, each existing in several role variants.
Three of these deserve a note. check-perpetual-license.rsc and certificate-renew-issued.rsc are the kind of chore scripts that stop being noticed once they work, which is usually after something has expired once. fw-addr-lists.rsc and the fw-addr-lists.d/ directory suggest the firewall lists are generated from data rather than maintained by hand.
The project has no GitHub releases, so there is nothing to pin a version to. You take the current main branch or a named branch.
One template becomes three scripts, one per device role
The repository root contains files with three extensions that are not variants in the usual sense. There are.template.rsc files, and from each of them the build produces a.capsman.rsc, a.local.rsc and a.wifi.rsc file. Examples include capsman-rolling-upgrade.template.rsc with its three siblings, daily-psk.template.rsc, collect-wireless-mac.template.rsc and accesslist-duplicates.template.rsc.
The Makefile shows exactly how this happens. The rule for a.capsman.rsc target runs contrib/template-capsman.sh on the matching.template.rsc, the.local.rsc target runs contrib/template-local.sh, and the.wifi.rsc target runs contrib/template-wifi.sh. Nothing about the generation is clever; it is three shell scripts doing text substitution.
Two other Makefile targets matter for understanding the distribution. checksums produces checksums.json from every.rsc file by running contrib/checksums.sh, and the all target runs checksums, docs and rsc in that order. commitinfo regenerates global-functions.rsc through contrib/commitinfo.sh, which stamps version and date information into the global function file using the DATE and VERSION variables computed from git.
So the repository is both a distribution endpoint and a build project, and the generated files are checked in.
Establishing certificate trust is the first real command
The update script performs server certificate verification, which means trust has to exist before anything downloads. There are two documented paths.
The builtin route trusts the certificate authorities RouterOS already ships with. The command enables the fetch target for the builtin trust store:
/certificate/settings/set builtin-trust-store=fetch;The README warns not to drop other targets while doing this, and adds that setting builtin-trust-store to default instead is a reasonable alternative since it includes all values that may be required.
If you download the scripts from somewhere other than the built in source, such as github.com, the certificate chain has to be installed separately. The fetch is:
/tool/fetch "https://rsc.eworm.de/main/certs/Root-YE.pem" dst-path="root-ye.pem";Then it is imported:
/certificate/import file-name="root-ye.pem" passphrase="";The README notes that one command is deliberately not shown because it contains a sensitive property, the passphrase.
Verification is by subject key identifier rather than by name, which is the right instinct:
/certificate/set name="Root-YE" [ find where common-name="Root YE" ];
/certificate/print proplist=name,common-name,skid where skid="A3C8265A8EA14CD03563FC9B23C83AAE56F34F56";Exactly one certificate, Root-YE, should be printed. The README also says to always make sure there are no certificates installed that you do not know or want, which is a good habit on any device that fetches things.
One caveat stated in the README: the fetch command does not itself verify the server certificate, so the safer route is to download the file from the CA's site with a workstation browser and transfer it to the device. The certificate in question is the Let's Encrypt Root YE chain.
device-mode is the prerequisite nobody reads first
Before any script runs, the device has to permit the features the scripts use. The README describes the device-mode mechanism as a way to lock down a device for security reasons, giving fine-grained control over which features are available.
The minimum is that scheduler and fetch must be enabled, and specific scripts may require additional features. That is a small sentence with a large consequence. A hardened profile that disables scheduler or fetch can prevent scripts from operating as documented.
The hardware constraint sits beside it. RouterOS packages grow with each release, and the README calls out devices with 16MB storage and below as the problem case, with ARM CPUs specifically affected. It also warns that a huge configuration plus many scripts carries extra risk.
The two warnings together describe the failure mode to plan around: on a small device, a library of scripts can exhaust storage or destabilise the configuration, and there is no partial adoption story here, because global-config, global-config-overlay and global-functions are the base every other script assumes.
For an experienced operator there is a shortcut. The README says that if you know how things work you can copy and paste the initial commands from INITIAL-COMMANDS.md, that those also support fixing an existing but broken installation, and that you must remember to edit and rerun global-config-overlay. First time users are pointed at the long way instead.
Version policy is stated as a compatibility promise
The scripts require a recent RouterOS, and the repository badge shows 7.22 as the minimum version at the time of writing. The README lays out the supported channels: stable, the latest version considered suitable for daily use including new features, and long-term, described as rock solid and usually one minor version behind.
The stated policy is that new functionality and breaking changes in RouterOS are adopted fairly quickly, but pushed for general availability only once a version supporting them has been on the long-term channel for a reasonable time. In seldom cases, and for good reasons, a specific script may require an even newer RouterOS so only stable is supported temporarily. Each page carries a badge showing the minimum version required for that script.
The branch structure follows from that. The README states that the main branch is RouterOS v7 only, and that anyone still on v6 should switch to the routeros-v6 branch. BRANCHES.md exists at the repository root, which is where the details of that arrangement live.
The last push was on 2026-10-11 and the repository is not archived. There are no GitHub releases, so the practical version control is the branch you point your update script at, and the licence is GPL-3.0 with COPYING.md at the root. README.d/ holds the images embedded in the documentation, and contrib/ holds the generation and documentation scripts, which is a good place to look if you want to understand what a script does before running it.
What breaks, and who should not run this
The honest limitations are in the README and they are consistent.
First, the scripts are intended to manage RouterOS devices and can change global configuration. A mistake in global-config-overlay propagates to every script that depends on it. That is why the README repeats the instruction to edit and rerun global-config-overlay, and why the DEBUG.md and CERTIFICATES.md documents sit at the root as separate concerns from the main README.
Second, storage. Devices at or below 16MB of storage, particularly with ARM CPUs, may not fit a large configuration plus this script set. On such a device the correct answer is to take a subset, which means diverging from the distribution and owning the updates yourself.
Third, the external links. The scripts fetch from a server the project controls, and the README includes a disclaimer on external links that you should read before pointing a router at it. If your policy forbids fetching from an external host, this collection is not usable as distributed.
Fourth, the trust decision. Using builtin-trust-store=fetch means your router will trust certificate authorities for fetching. Importing a single chain narrows that. Both are security posture choices with different costs, and the README gives you both because neither is right for everyone.
None of this makes the collection bad. It makes it an operational dependency, which is a different category from a script you run once.
Editorial conclusion
Adopt these scripts if you manage MikroTik devices that share one configuration model, since a role based system with an overlay and a checksum manifest removes a large amount of per device typing. Do not adopt them on a device with 16MB of storage or an ARM CPU without checking size first, and do not adopt them on RouterOS v6 from the main branch, which is v7 only. Before running anything, set builtin-trust-store or import the certificate chain and verify it by subject key identifier, read global-config-overlay before rerunning it, and confirm the device clock is correct because certificate validity is checked against local time.
Frequently asked questions
Which RouterOS version do the eworm routeros-scripts need?
The badge at the top of the page shows 7.22 as the minimum version required. Each individual script page carries its own badge, because some scripts temporarily need only the stable channel.
How do I make RouterOS trust the certificate for the update script?
Either set /certificate/settings/set builtin-trust-store=fetch to trust the builtin certificate authorities, or fetch Root-YE.pem from rsc.eworm.de and import it with /certificate/import. Then verify it by subject key identifier as the README describes.
Do these scripts work on RouterOS v6?
Not from the main branch, which the README states is RouterOS v7 only. Anyone running RouterOS v6 is directed to the routeros-v6 branch.
What must be enabled on the device before running the scripts?
At minimum the scheduler and fetch features in device-mode, and specific scripts may need additional features. The README describes device-mode as the mechanism that controls which features are available.
Are small MikroTik devices supported?
With caution. RouterOS packages grow with each release, and the README calls out devices with 16MB storage and below, with ARM CPUs especially affected, plus the extra risk of a huge configuration combined with many scripts.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/eworm-de-routeros-scripts)Was this useful?