Back to Blog

Self-Hosting an RMM in 2026: ET Ducky's Local-First Tier

Christopher 8 min read
self-hostedlocal-firstrmmdeployment

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:

DestinationPurpose
ClerkLogin and JWT signing keys
etducky.comLicense renewal, org membership sync, threat-intel relay (IOC blocklist, aggregated server-side so your instance never talks to feed providers directly)
registry.etducky.comImage pulls for upgrades
Your SMTP relayAlert and invite email
api.anthropic.com / api.openai.comOnly 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

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