Isomania has moved from a local server to production — isomania.online. This is the moment of the long-awaited release and effectively the birthday of the project.
How an update happens
A new version of the code reaches the server, the process restarts, connections drop, after which clients reconnect to the new build on their own. For a player this is a pause of one second rather than being thrown out of the game.

Separate work went into making a failed start something other than a mystery. If the server cannot come up, it does not stop silently: the process stays alive, serves nothing and reports which stage it stopped at. Instead of a pile of identical errors there is one diagnosable answer.
IP addresses are not stored
The game’s database has no field for a player’s IP address, and that is deliberate. Where an address cannot be avoided, that is when protecting the login from abuse, only its cryptographic fingerprint (HMAC) is kept. It can be used to compare whether this is the same address or a different one, but the address itself cannot be recovered from it.
This policy was accidentally audited by a bug: housekeeping code carried over from another project tried to query the IP address field and did not find it, because no such field exists. The bug was fixed and the field was not added.
The same decision covers the voice chat: audio passes through the server precisely so that players do not see each other’s addresses.
Monitoring through Telegram
Instead of a separate monitoring panel, the game’s events arrive in Telegram: who signed in and by which method, who left, when the process restarted, when someone hit a limit.

A page reload, which is neither an arrival nor a departure, is handled separately. Every press of F5 closes the connection and opens a new one, so a naive implementation would fill the channel with pairs of “left” and “joined” messages that never actually happened. A departure is now reported only when the player has not come back within a minute, and the session length is counted together with that interruption.
Events that can arrive in an avalanche are rate-limited. The suppressed ones do not disappear: they are counted and added as a summary to the next message.
Why a player should know this
A player enters the game with their own email address and their own voice, so they have the right to know how that data is handled. In short, the server keeps exactly as much as the game needs in order to work, and no more.