I'm a network engineer and I got tired of two things: finding out a config changed only after something broke, and maintaining a dedicated Oxidized/rConfig server just to back up a handful of routers across client sites.
So I built ConfigStash — a small SaaS that does one thing: keeps versioned, encrypted backups of your device configs and tells you when they change.
How it works:
You install a lightweight open-source agent (Python, MIT-licensed) on any Linux box inside the network: pip install configstash-agent
The agent SSHes into your devices on a schedule (every 6h by default) and runs /export on RouterOS
Configs are pushed over outbound HTTPS only — no inbound ports, no firewall changes, and device credentials never leave your network (the cloud side never sees them)
Every version is stored encrypted (AES-256, per-organization keys); you get side-by-side diffs and an email the moment a config changes
Status: public beta, free while in beta (10 devices). Solo project, launched this week — so I'm here for honest feedback, not sales. Agent Github source: configstash-agent — audit it, it's ~1000 lines of readable Python.
What I'd love to hear from you: which device types should I add next, what would make you trust (or never trust) a cloud service with config backups, and anything broken you find. Thanks!
What do those who help you get?
Royalties on sales?
Or have you taken this forum for users who, in addition to working free for MikroTik,
also serve as free beta testers for anyone who passes by?
I've been doing all this for years_for_free_ with two lines of "cron" and two lines of code inside the devices. As @savage also wrote, why reinvent the wheel?
savage — RANCID (and Oxidized, its modern successor) are great, and if you already run them, ConfigStash won't give you much. The difference isn't the concept — it's not having to host, patch and babysit the collector, the git repo and the notification pipeline yourself. Some people enjoy running that; plenty of MSP folks don't.
rextended — you're right, /export + fetch in a scheduler covers the basic case, and I did exactly that for years. What I kept rebuilding on top of it was: version history that survives the router itself dying, readable diffs, "email me when someone touched the firewall", and one place for all clients' devices instead of N ftp folders. If two cron lines cover your needs — honestly, keep them, this isn't for you. On "unpaid beta testers": fair point. That's why the beta is free with no card required, the agent is MIT-licensed on GitHub so there's no lock-in on the collection side, and early users keep their raised limits when pricing lands.
infabo — mikr.app looks like a solid tool, but it's a different shape: self-hosted, MikroTik-only, perpetual license — you run the server. ConfigStash is the opposite trade: hosted, nothing to run except a small agent, multi-vendor (RouterOS + UniFi today). Both trades are legitimate, they're just for different people. And yes, running a SaaS is more work than a cron line — that's kind of the point: I do that work so users don't have to.
Genuine question back, since you've all clearly done this at scale: what would a hosted service need to do — encryption model, config export, a self-host option? — before you'd trust it with device configs? That's the part I'm actually here to learn.
Credentials should never ever "leave" the agent. The agent should only upload the encrypted config, while the private key keeps locally and secret and unknown to the saas. I hope it works this way.
I didn't understand this one...
I actually have a backup and history of every device from when it was installed up a day before it "died"...
Having it for just a "second" before doesn't make much difference, last working config still working config...
More than obvious, the devices whose configuration I change are backed up before and after the change is made...
So I know what the configuration was like when the last change was made,
net of any automatic nightly backups...
Great discussion — let me address all of this, because you’ve collectively hit the two real design questions.
savage — point (1) is a misunderstanding I clearly need to fix on the landing page, so thanks: you don’t give me access to anything. The agent runs on a machine inside your network, device credentials sit in a local config file next to it and never leave, and nothing becomes publicly accessible — the only traffic is the agent making outbound HTTPS calls. infabo described it correctly in his reply: credentials never leave the agent, that’s already how it works today. If my service were fully compromised, the attacker would get stored configs — not a path into your network, not your device logins.
Point (2) — you’re right, and I won’t pretend otherwise. Encryption at rest (per-org keys, envelope model) protects against a stolen disk or a leaked database, not against me as the operator.
infabo / rextended — you two just had exactly the debate I have with myself. infabo’s model (agent encrypts with a key only the customer holds, server stores ciphertext only) is the right answer for security-sensitive orgs, and rextended’s objection is the exact cost of it: the server can no longer render diffs or detect changes. The way to square it: the agent can compare configs locally (it already sees plaintext) and the diff can render client-side, with the server storing only ciphertext blobs and metadata. More moving parts, but doable — that’s the E2E mode I’d build if this survives beta.
rextended — on “history that survives the router”: if you already keep disciplined off-device backups from day one, you’ve built yourself what I’m selling, and my product genuinely has nothing for you. The two cases it covers are (a) people who don’t have that discipline across every client site, and (b) changes you didn’t make yourself — a colleague, an installer, or someone who shouldn’t be in there. “Backup before/after my changes” works when you’re the one making the change; the alert is for when you weren’t.
Quick follow-up for savage and infabo — your feedback from this thread shipped today in agent v0.2.0:
The agent now masks secrets before upload: pre-shared keys, passwords, SNMP communities etc. are replaced with REDACTED on your side of the wire. (RouterOS /export already omits them; EdgeOS show configuration doesn't — that was the gap.)
Public IPs never reach my servers either — globally routable addresses are replaced with stable pseudonyms derived from a salt that exists only on your machine, so diffs and change alerts still work, but I couldn't tell you your WAN address if I wanted to.
Both are on by default and can be turned off in the agent config if you want verbatim backups.
It's all in the open-source agent, so you don't have to take my word for any of it: configstash-agent
Full E2E (customer-held key, ciphertext-only storage) is still the end goal for security-sensitive orgs, but this closes the biggest gap today. Keep the hard questions coming — this thread has already made the product better.
. valid point.