Running European Servers From the Other Side of the World

The servers are in Italy. I am in Australia. Between the two there are roughly 16,000 kilometres and a nine-hour time difference, which means that for most of the Italian working day I am asleep.

This is not a problem I am trying to solve. It is a design constraint, and like most constraints it forced decisions that turned out to be better than the ones I would have made sitting in the same room as the hardware.

What follows is what actually breaks at this distance, what surprisingly does not, and the one category of tool where the distance stops being an abstraction.

The latency, measured

Twelve ICMP samples from my desk to the VPS, taken while writing this:

minimum   362 ms
average   363 ms
maximum   367 ms

The average matters less than the spread. Five milliseconds of jitter across twelve samples is a remarkably stable path — and stability is what determines whether a remote session is usable. A connection averaging 150 ms that spikes to 800 ms is far more painful to work on than a flat 363 ms, because your hands learn a rhythm and the rhythm holds.

What the distance does not break

This is the part people get wrong, and it is worth stating plainly: latency does not damage almost anything that matters.

A site served from Arezzo to a visitor in Milan knows nothing about where the administrator happens to be standing. The visitor’s experience is determined by the distance between the server and them, not between the server and me. My 363 ms is invisible to every reader of every site on that machine.

SSH at 363 ms is entirely workable. There is a perceptible delay between keystroke and echo, and you stop using interactive editors for anything long, but running commands, reading logs and editing configuration files are all fine. Scripted work — anything you have written down and simply execute — is completely unaffected, because the round trip happens once rather than once per character.

File transfer is unaffected too. Throughput is a function of bandwidth, not distance; the connection takes a moment longer to get up to speed and then behaves normally.

What the distance does break

Everything interactive and graphical. That is the whole list, and it is enough to reshape how you work.

Web administration panels are the worst offenders, because they were designed by people sitting near their servers. An interface that makes a round trip for every click costs you a third of a second per gesture, and a task with forty clicks in it becomes a task you avoid. Raw remote desktop protocols are similar: technically they connect, practically you spend the session waiting for the mouse pointer to catch up with your intention.

The realistic response is not to find a faster connection. It is to stop needing the interactive path.

The real consequence: automate or do not exist

This is not a preference for tidy engineering. It is time-zone arithmetic. Anything that requires my presence during Italian business hours simply does not happen.

So everything that can run without me does: publishing, backups, certificate renewal, monitoring, alerts. I act on exceptions, not on the routine. When something needs a human decision, it waits for my morning — and the system is built so that waiting is safe.

Monitoring changes value at this distance. An alert that reaches you before the site falls over is worth roughly double when the alternative is discovering the outage nine hours later. If you are working out where a small server actually breaks under load, why WordPress returns 502 Bad Gateway when traffic rises covers the failure you are most likely to sleep through.

How the machines are actually reached

Servers: SSH. It absorbs the distance well and it is where ninety per cent of the work happens. Everything repetitive lives in a script rather than in my hands.

Windows machines: a proper remote desktop tool. This is the one place where the distance cannot be engineered away, because the work genuinely is interactive and graphical. Raw RDP over a 363 ms path is technically alive and practically unusable — and this is the category where paying for software that compresses aggressively and tolerates latency stops being an indulgence.

I use RemotePC for that, and have done for years — not only for servers. From Australia I have rebooted family machines sitting frozen in Italy, which is a small thing until you consider that the alternative was asking somebody to drive over and press a button. From home I can look in on what the office servers are doing, and from the office at what is running at home. That is the entire job at this distance: reaching a screen that is somewhere else, on a connection bad enough to make most tools useless.

Two things decided it, and neither is exciting. Price: when I compared, it came in at roughly a quarter of TeamViewer and below AnyDesk’s unattended tier — and unattended is the tier that matters here, because there is nobody at the other end to accept a session. And the agent stays running, which is the only reason a remote reboot is possible at all.

The limit of that is worth stating, because it is the kind of thing vendors leave out: if the machine has genuinely crashed, it has crashed. An agent living inside the operating system cannot help you once the operating system is gone. That is what out-of-band console access is for, and it is one of the few real advantages a rented server has over a computer in somebody’s living room.

It appears on this page because I pay for it. This guide exists because the situation it describes is mine, and recommending a tool I did not use would defeat the point of writing it. That link is a referral: it discounts your first year and pays me a commission. It costs you nothing extra, and the guide would say the same thing without it.

What not to do: long administrative operations through a heavy web panel. Not because it fails, but because the friction quietly makes you postpone maintenance, and postponed maintenance is how small problems become incidents.

The part nobody plans for: being the only technical person

At this distance the real risk is not latency. It is that you are the single point of failure.

Ask what happens if you are ill for a week, or in the air for twenty-four hours, or simply unreachable when a certificate expires. The honest answer for most one-person setups is: nothing good, and nobody else knows where anything is.

Which reframes automation entirely. “Set and forget” is not laziness — it is operational continuity. Every task that runs without you is a task that survives your absence. And every access credential that exists only in your head is a liability, not a security measure. Written procedures, shared access for the things somebody else may one day need to reach, and a monitoring system that shouts loudly enough to wake someone other than you.

The same logic applies to knowing your own numbers before you need them. How much RAM you actually need for multiple WordPress sites on one VPS is easier to work out on a calm afternoon than at three in the morning from the wrong hemisphere.

Would I recommend it

No — not as a choice. If you can be near the people and the infrastructure you are responsible for, be near them.

But if you find yourself in this position, it is entirely workable, and it has one genuine advantage: the distance removes the option of fixing things by hand. You cannot lean on being available, so you are forced to build systems that hold without you. That is a better way to build than the one I would have chosen with the servers in the next room.