Every screen on this page is Lens doing the work on real servers — a test fleet of nineteen boxes across Rocky, Alma, Debian and Ubuntu. Nothing is a mockup, and the one failure you will see was put there on purpose to show what Lens does with it.
Name the set. Drag three servers from the tree onto the members table — each is read as it lands: a shell opened with its saved login, what it runs, whether MongoDB is there. Give each member its role. Review the filing and press Apply. One job on every box at once: keyfile, bind, port, checked restarts, every wire proved from the box it starts at, then the set initiated from the primary. Two minutes later it is live and syncing a gigabyte.
Encryption between members is a must, so it is one button. Lens is the set's certificate authority — the keys never leave your computer — and it walks the mode up on every member, allow to prefer to require, with no downtime. Renewal needs no restart. Apps are untouched; only the members' own stream is bound.
A member of a set never gets Update or Restart on the map — an upgrade restarts mongod, and restarting a member out of order is a failover nobody planned. The set's own page walks it safely: secondaries first, each rebooted and reconnected before the next, the primary stepped down last. The apps on a replica-set connection string never notice.
The canvas draws every member and every wire between them on the engine's port, in both directions, and proves each one from the box it starts at — reach measured on the source, listen and allow read on the destination. Red is broken, with the reason on the wire. The same reading goes on paper: a report of the set as every member sees it, the firewall of every member as one table, the versions, the wires proved — drawn on screen and, for the person without Lens, one PDF.
Operations per second by kind, connections, the cache, what is queued, the lag of every member — sampled every two seconds while you look, with a trace that keeps sampling after you leave. The Explorer is Compass without leaving the console: a filter in mongosh's own syntax, documents edited as text, a pipeline, the schema sampled, the planner asked. And the set's own verbs on its page: step down, rolling restart, rolling upgrade, the oplog resized on every member, compact walked member by member.
A sharded cluster is replica sets stacked. The builder is drop boxes — config servers, shards, the app boxes that get a router — and one job puts it together. This is the whole conversion, including the part that went wrong.
Drop a server that has no MongoDB and Lens says so and offers the install at the cluster's version. A box whose login came in with a key asks for its sudo password once, on its own row. Nothing is written until every box has answered.
The servers picked, the summary confirmed, the build starts on every box at once. One box was broken on purpose. The job does not pretend: it names the box, says what it found, and Repair runs the fixes it knows — then the build finishes and every wire is proved again.
Two more shards and two more config servers dropped in; Apply puts them in place and the sets already there are left as they run. Then a collection sharded on a key, with per-shard bars and the balancer's verdict. Then the Linux updates of the whole cluster walked from a router — config set, shards rolling, routers one at a time — while the apps keep writing.
A shard holds one slice of every sharded collection, so a dump of one piece is meaningless alone. Lens pauses the balancer through a router, dumps the config set and every shard with the oplog at the same moment — each on a secondary of its own — into one folder with a manifest beside every piece, and puts the balancer back the moment it ends. On a schedule, the same thing goes to a repository: here, Cloudflare R2. The log of every box, or of every box in one role, is one window.
Then the test that matters: the database dropped, brought back from R2 through a router, its collections sharded again on the keys the manifest kept, every shard's slice loaded from the box that holds it. Restored under a different name, too. And "shard as before" replicates the original's sharding onto the copy, with the collections you leave out left out.
With the cluster built, Themis reads it through the probes and says what she would change — each recommendation a row with Run, Show me and No. She never changes anything on her own; the exact script is a click away.
Replication, sharding, TLS, cluster backups: every Lens server gets all of it. What is licensed is the server, not the feature.