Two machines, one identity

Cloning a machine is not an incident. It is a Tuesday. A VM becomes a template, a container gets copied to a second node, a backup lands on new hardware after a dead disk. Machines multiply, and nobody files a ticket about it.

Monitoring, meanwhile, has to answer a question nobody asked out loud: which one is the machine I was watching? Most products answer by accident. You get two hosts flapping over one name, or a graph with a hole in it, or, worst of all, a copy that quietly continues reporting as the original, and you learn about it from a bill or from an alert that fired on the wrong box.

These situations are too routine to be handled by accident. So each one has a designed answer.

A copy of the files is not a copy of the identity

The rule everything else stands on: the agent's identity belongs to the machine it was issued to, not to the files on its disk. Copy every byte, mount the backup, rsync the root somewhere else, and what arrives is not the original's identity. It does not work anywhere else.

This rule exists for an unfriendly reason, and it is written down in our threat model: a stolen disk image or an old backup must not be able to walk in wearing the original's badge. But once that line is drawn, every friendly clone crosses it too. A seal that refuses the wrong machine refuses the admin's template exactly as firmly as the thief's image. So refusing is not enough. What matters is what happens next.

The clone

You clone a monitored machine and boot the copy. The agent inside finds an identity that is not its own. It does not impersonate the original, and it does not die trying: it waits, and it says why in plain words. wakora doctor names the situation in one sentence instead of hinting at it through a generic error. And the normal registration command, wakora --key, does the obvious thing: sets the foreign identity aside and registers the box as what it actually is, a new server.

A refused identity is not an error to be retried. It is information: this body is new, and someone should say so.

The perfect clone

Sometimes the copy is faithful enough to carry everything, and two machines end up alive under one identity at the same time, both convinced they are real. This is the case that justifies the whole design, and it is governed by one rule: **the original must never pay for the existence of its copy.**

The platform notices that one identity is being lived in twice. Within minutes the copy is split off and registered as its own server, clearly marked as a copy, so both machines stand side by side and nothing anyone measured is lost. The original keeps reporting without a gap, and its credentials are refreshed automatically along the way. If the plan has no room for one more host, the copy is turned away with a clear reason instead of silently wrestling the original for its badge. And if that clone was never meant to be monitored at all, the operator refuses it from the console, and the agent on it parks itself and waits for a human decision.

No flapping, no shared graphs, no surprise on the bill. Two machines, two names.

The machine that came back from the dead

The third situation involves no second machine at all. A server is restored from a snapshot taken weeks ago. Same body, same identity, just out of time: while it slept, its credentials moved on without it.

The generic version of this story is an authentication error in a log and an evening with grep. The shipped version: wakora doctor says, in a sentence, that the machine appears to have been restored from an old backup and its credentials have since been retired. The host shows as down, which is honest, because the thing the fleet was watching did stop existing for a while. One wakora --key brings it back under the same identity, history intact, and the incident closes on its own.

Weather, not intrusion

A clone is not an attack. A restored backup is not an attack. But a genuine attack can be assembled from exactly these materials: a copied disk, an old credential, a re-registered body. From the inside they are indistinguishable, and the agent does not try to guess intent. It behaves the same way in all weather: visibly, predictably, with the situation named out loud.

That is also why all three scenarios are written down in our public trust pack, with the behavior spelled out for each: a cloned machine, a restored backup with an old key, a live host re-registered with a team key. Security reviewers should not have to discover any of this by experiment.

The takeaway we keep: binding identity to a machine is the easy half. The hard half is deciding, ahead of time, what every broken case should look like to the person who has to deal with it at 3 a.m. Waiting beats crashing. Naming beats hinting. And a copy that gets its own name beats two machines fighting over one.