Self-Hosting an RMM in 2026: ET Ducky's Local-First Tier
ET Ducky now offers a Local-First tier: the full stack (API server, database, and web dashboard) runs on your own infrastructure as Docker images, with unlimited agents for a flat published price ($650 per month, or $6,630 per year). It is the same product as the cloud tier, not a reduced edition. This post covers how the deployment is put together, what the license and identity design actually do, exactly which bytes leave your network, and where this sits against the on-prem RMM options that still exist in 2026.
The self-hosted RMM landscape, stated accurately
Self-hosted RMM is not a new idea; it is mostly an abandoned one. Kaseya VSA still supports on-premises installation, on both the legacy VSA 9 line and current VSA 10, and ConnectWise Automate self-hosted servers are still supported and patched, though new sales are steered toward cloud hosting. Both are quote-only, per-endpoint products. On the open-source side, Tactical RMM is self-hosted by design (source-available, with paid sponsorship tiers for signed agents). The cloud-first platforms (NinjaOne, Atera, Datto RMM, Syncro, Level, Action1) offer no self-hosted option at all.
What has not existed is a current-generation RMM whose vendor ships the same product for your hardware and theirs, at a published flat price, with no per-endpoint meter. That is the slot Local-First fills: full product parity with the cloud tier, from kernel-event capture and AI live sessions to behavioral detection, patch rings, and remote desktop, with the server under your control and an agent count that is deliberately unmetered.
Same binary, different composition
The local image is not a fork. It is the cloud API compiled with a deployment mode flag. At startup in local mode, a controller feature provider removes the cloud-only controllers (Stripe billing, Clerk webhooks, workspace and subdomain management: 17 of 91), and the tenant-resolution middleware pins the instance to the single organization named in your license file. The multi-tenant isolation layer, EF query filters plus PostgreSQL row-level security, stays exactly as it runs in the cloud, enforced against your one org. Single-tenant deployments run the same fail-closed code paths the shared cloud does, so there is no separately-audited "on-prem edition" security model to reason about.
The bundle is a docker-compose.yml with four services in enforced order: db (TimescaleDB on PostgreSQL 17), a one-shot backup that takes a pg_dump before anything else runs, a one-shot migrate that applies the schema chain and must exit 0, and the api, which also serves the dashboard. A failed migration never leaves you without a fresh pre-migration backup, and the API deliberately does not start behind a failed migration.
A license file, not a kill switch
Entitlement is a JSON license file with a detached Ed25519 signature, issued by the cloud when the subscription activates and mounted read-only into the container. The verifying public key is embedded in the API binary, so validation needs nothing external. The instance renews the license automatically against etducky.com while the subscription is active.
The interesting design decision is what happens when renewal fails: the vendor went unreachable, the card lapsed, the subscription was cancelled. The instance runs through a 30-day grace window with a dashboard banner, and past that it degrades to collection-only: agents keep enrolling and telemetry keeps landing in your database, the dashboard goes read-only, and automations, alerts, AI, and exports switch off. Nothing is deleted, nothing shuts down, and your data, which was always in your PostgreSQL, stays queryable. A self-hosted product whose failure mode is "your monitoring history evaporates" is a hostage arrangement, and we declined to build one.
Identity: Clerk stays, and this is not an air-gap product
Login is still Clerk, the same identity provider the cloud uses. Local instances validate Clerk JWTs against cached signing keys, and org membership is synced from the cloud on a 15-minute poll. A member removed from the org loses access to the local instance within one poll interval, and a Clerk or network blip is tolerated on cached data for up to 24 hours before the instance fails closed rather than open.
Stated plainly: outbound internet is required for login. This is a local-data product, not an air-gapped one. If your requirement is a fully disconnected enclave, Local-First v1 is not that, and we would rather say so here than in a support ticket.
What leaves your network
The egress surface is short enough to list completely, and the bundle README does:
| Destination | Purpose |
|---|---|
| Clerk | Login and JWT signing keys |
| etducky.com | License renewal, org membership sync, threat-intel relay (IOC blocklist, aggregated server-side so your instance never talks to feed providers directly) |
| registry.etducky.com | Image pulls for upgrades |
| Your SMTP relay | Alert and invite email |
| api.anthropic.com / api.openai.com | Only if you configure your own AI keys |
Agent telemetry (kernel events, health metrics, inventory, session recordings) never touches ET Ducky's infrastructure. The one disclosed exception: AI features default to bring-your-own-key, where queries go directly from your server to your AI provider, but there is an optional metered query subscription that routes AI calls through the ET Ducky gateway instead; if you choose it, query content transits our infrastructure, and the settings UI says so before you turn it on. Configure neither and AI features are simply disabled.
Even the security-incident pipeline respects the boundary. The same sweep that runs in the cloud (blocked shell commands, suspicious file transfers, mass enrollment, behavioral detections) runs locally, but the incident report (an xlsx of the evidence) is written to your storage volume, the review ticket is filed in your own workspace, and the notification email goes through your SMTP. No vendor-side copy exists.
Updates: signed images from a private registry
Distribution is a private registry with per-organization, read-only, revocable pull credentials. Images are tagged semver plus stable and signed with cosign; the README documents verifying the signature before first start. Upgrading is docker compose pull && docker compose up -d, which re-runs the backup → migrate → api sequence, so every schema change is preceded by an automatic dump into ./backups/. The migration chain is forward-only and skip-tolerant; jumping N → N+3 is a supported, tested path, because nobody self-hosting a server upgrades on the vendor's weekly cadence. Pin a tag if you want to control exactly when upgrades happen.
Agents enroll against your hostname with the normal registration-token flow: the install command rendered in the token dialog carries /API_ENDPOINT="https://<your-host>" on Windows and --api-endpoint on the Linux install.sh, so nothing about an agent install assumes the cloud. Agent auto-update is served from a downloads/ directory on your instance: drop the current signed installers in and agents update on their next check; leave it empty and your fleet stays pinned. Your endpoints never phone the vendor for updates.
Why unlimited agents is the point
Per-endpoint pricing exists because the vendor's costs scale with your fleet: their infrastructure stores your telemetry. Under Local-First that cost transfer disappears; the kernel-event stream lands on your disks and the queries run on your CPU, so metering agents would be charging you rent on your own hardware. The flat price covers the license, updates, and business-hours support; there is deliberately no agent-count ceiling, and the axis that scales with organization size is the optional support contract, not the license.
The math against the per-endpoint incumbents is straightforward. At $3 per endpoint per month, 1,000 endpoints is $36,000 a year, every year; Local-First is $6,630 plus a server you probably already know how to run (the baseline is 4 vCPU, 8 GB RAM, and 100 GB of disk on Linux x64 or Windows Server 2022+ with Docker). Against ET Ducky's own cloud tier, the crossover sits around 170 agents (one Professional subscriber, no retention add-on): below that the cloud's per-agent pricing is cheaper; above it the flat price wins and keeps winning.
Limitations, stated before you find them
- Not air-gapped. Login requires outbound internet to Clerk; license renewal requires reaching etducky.com. A fully offline variant is a possible future direction, not a current offer.
- Subscription purchase stays on the cloud website. Stripe does not ship to customers; billing UI on the local dashboard deep-links to etducky.com.
- Docker images, not source. This is self-hosted, not open source.
- Windows and Linux agents; no macOS. Same coverage as the cloud tier.
- New deployments first. Migrating an existing cloud org's history down to a local instance is not supported in v1.
Setup, sizing, backup and restore, and the full egress reference live on the Self-Hosted Deployment documentation page. Pricing, including how Local-First compares to the per-endpoint platforms at your fleet size, is on the pricing page and in the RMM pricing comparison.
Run ET Ducky on your own infrastructure
Flat price, unlimited agents, your data on your disks. Published pricing, no sales call required.
View Pricing