Remote power: waking a computer you are not at

The file is on the desktop machine at home and you are not. Or the render finished and the computer has been sitting at 60 watts for eleven hours since. Or someone needs a document from a machine that is switched off, and switching it on requires a person in the room.

Remote power is the ability to wake, sleep or shut down a machine you are not sitting at, and it is a different problem from remote access — though the two get discussed as one. Waking, sleeping and shutting down a machine is a network-level operation that works whether or not anyone is logged in; seeing its screen or its files is an application-level one that needs the machine already running. Getting the distinction right is what makes the setup work.

What is remote power, and how does it differ from remote access?

Only the first row works on a machine that is off, and it works because the network adapter stays partly powered and listens for a specific packet. Everything else needs the machine awake, which is exactly why waking is the piece people set up last and need first.

Wake-on-LAN is not remote access. It is the switch that makes remote access possible, and without it every other tool fails at the moment you actually need one.

How do you get wake-on-LAN working?

It fails for a small number of reasons, always the same ones, and in this order.

1. Enable it in firmware. The setting lives in BIOS or UEFI, usually named Wake on LAN, Power on by PCI-E, or similar. Off by default on most machines.
2. Enable it in the operating system. The network adapter's properties have a separate permission for waking the machine, and both layers must agree.
3. Use a wired connection if you can. Waking over Wi-Fi is possible on some hardware and unreliable on much of it. Ethernet is the difference between "sometimes" and "always".
4. Note the MAC address, not the IP. The packet is addressed to the hardware, because a sleeping machine has no active IP address.
5. Send from the same network. The packet is a broadcast, and broadcasts do not cross the internet unaided.

Point five is where most attempts stop, and it has three answers: run the sending app on a device already at home, use a router that supports sending the packet on your behalf, or connect back to your home network through a VPN first. An app such as Wakivo handles the sending side from a phone, which covers the common case of being on the same network — arriving home and waking the desktop before you reach it — and pairs with a VPN for the away case.

Shutting down and sleeping, which is the harder half

The remote power story is asymmetric: waking needs no software on the target, while sleeping and shutting down do, because the machine has to be told by something running on it.

Three approaches:

A small agent. A helper application on the machine that listens for a command. Simple, and it is what most consumer wake-and-shutdown apps use.

SSH or remote management. Built into macOS and Linux, available on Windows. A single command sleeps or powers off the machine, and it is scriptable.

Scheduled sleep. No remote control at all — the machine simply sleeps at a set time or after a period of inactivity. Boring, effective, and it solves the eleven-hours-at-60-watts problem without any infrastructure.

The third option is genuinely the right answer more often than people expect. If the goal is not wasting power rather than controlling the machine, a sleep schedule needs nothing set up and never fails.

Reaching it from outside the house

Once the machine is awake, four routes, in descending order of how much I would trust them.

• A VPN back to your network. You appear to be at home, and everything works as it does locally — including the wake packet. Most modern routers can host one, and this is the cleanest arrangement by a distance.
• A remote desktop service with its own relay. Convenient, no networking to configure, and it means a third party sits in the path. Fine for most people, with the understanding that you are trusting that company.
• SSH with key authentication. For anyone comfortable with a terminal, this is efficient and secure — provided passwords are disabled and only keys are accepted.
• Port forwarding to a remote desktop port. Exposing remote desktop directly to the internet is how machines get compromised. Avoid this even briefly; automated scanning finds an open port within hours.

That last one is worth stating plainly because it is still the most common advice in older guides, and it has not been reasonable for years.

Do you actually need remote control?

Most people who think they need full remote control need one of three narrower things.

A file. Sync the folder, or run a file server. No remote desktop required, and a synced folder solves it before you think to ask.

A long job's result. Have the job upload its output when it finishes. You never need to see the machine at all.

The machine to stop drawing power. A sleep schedule.

Full remote desktop is genuinely necessary when you need to interact with an application that only runs on that machine — a licensed tool, a specific environment, something with hardware attached. That is a real case, and it is narrower than the number of people who set up remote desktop suggests.

Keeping it from becoming a liability

A machine with remote power and remote access enabled is an asset with a security posture, so four rules.

Nothing exposed directly to the internet unless it is designed for that. Put access behind a VPN.

Key authentication rather than passwords, wherever the option exists.

Keep the machine updated. A remotely reachable machine that is rarely used is exactly the machine nobody patches.

Know what wake-on-LAN can and cannot do. It can wake the machine from anyone on your network — the packet carries no authentication of any kind. On a home network that is fine; on a shared or office network it is worth knowing, because "anyone here can turn this on" is the actual security model.

More developer tools in developer tools, comparisons in comparisons, and general software in software. The Wake-on-LAN mechanism is documented if you want the packet format itself.

The short version

Waking a machine and controlling one are separate problems. Wake-on-LAN works on a powered-off machine because the network adapter listens for a packet addressed to its MAC; everything else — screen, files, commands — needs the machine already running and software installed on it.

Enable wake-on-LAN in both firmware and the operating system, prefer Ethernet, and send the packet from inside your network or through a VPN. Then ask whether you need remote control at all: a synced folder, a job that uploads its own output, or a sleep schedule solves most of what people set up remote desktop for.