I Turned an Idle Office PC Into My Own Cloud Server — So I Can Sleep While Agents Work

There's a machine sitting in our office. Intel Ultra 7, 32GB RAM, a good GPU. On most days it does almost nothing.

I wanted to stop opening my laptop at midnight.

So I turned that idle box into a remote dev server I can reach from anywhere in the world — my phone included. Now I dispatch agents before bed, go to sleep, and wake up to finished work. This is the full story: what I built, why I built it, and the security mistake that almost ruined it.

The Itch

I run a lot of agents. Claude Code sessions, background tasks, things that take time. The pattern was always the same — an idea would hit at night, and I'd drag my laptop back open to kick off a run.

That's a bad way to live.

What I actually wanted was simple. A machine that's always on. Always reachable. Powerful enough to do real work. I could rent a cloud server for it. But we already had the hardware sitting right there in the office, awake almost 24/7, connected to WiFi, doing nothing.

The only catch — I couldn't install another OS on it. It had to stay Windows. And it had to be safe for my teammates to use too.

So the goal became: turn this Windows box into something that behaves like a cloud server, reachable from anywhere, shared by the team, with everyone's data kept separate.

The Three Pieces

The whole thing comes down to three layers. None of them are complicated once you see them together.

Tailscale — so I can reach the machine from anywhere without touching the office router or opening any ports. It builds a private network between my devices and the office machine. The office machine gets a fixed IP on that network, and that IP works from my home, my phone, a coffee shop, anywhere.

OpenSSH Server on Windows — so I can actually log in. SSH runs as a background Windows service. Once it's on, it stays on, even after a reboot. I never have to touch the machine physically again.

Separate user accounts — so each teammate gets their own sandboxed space on the same machine. This is the part I got wrong the first time. More on that soon.

That's it. Tailscale to reach it, SSH to log in, user accounts to keep everyone separate.

Getting In From Anywhere

Tailscale was the easy win. Install it on the office machine, sign in, and it hands you an IP that looks like 100.x.x.x. Install it on my laptop and phone with the same network, and suddenly all three devices can see each other like they're on the same WiFi — even when they're thousands of miles apart.

No router config. No port forwarding. No begging IT to open something. That alone felt like magic the first time it connected.

For SSH, three commands on the Windows machine turn it on for good:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'

That last line is the important one. It tells Windows to start SSH automatically on every boot. After this, the machine reboots, the WiFi drops and comes back, the monitor goes to sleep — and SSH is still there waiting.

Then from my phone, using a terminal app, I just connect to the Tailscale IP. A full Windows shell, in my pocket, running on a machine in the office. I genuinely sat there grinning the first time it worked.

One Thing That Almost Stopped Me

Before any of this works, the machine needs virtualization turned on in the BIOS — and on our machine it was off.

Worse, I couldn't even get into the BIOS. The boot was too fast to catch the key.

The trick that saved me: you can tell Windows to reboot straight into BIOS, no key-spamming required.

shutdown /r /fw /t 0

That command restarts the machine and drops you directly into the firmware settings. From there it was a hunt through menus to find the virtualization toggle — but at least I was in.

Small thing. But it's the kind of wall that stops people for an hour. Now you know.

The Mistake That Could Have Burned Me

Here's the part I almost left out of this post. I'm keeping it in because it's the most useful thing I learned.

I created an account for each teammate. Good. But I made every account an administrator. Felt convenient at the time — everyone can install what they need, no friction.

Then I set up my GitHub keys and credentials inside my own account and got back to work.

Later I logged in as a teammate's account to test something. Out of curiosity, I tried to read my own private SSH key from inside their session.

It worked.

The teammate account could open my private key and print it on screen. Plain text. The secret that authenticates me to GitHub, readable by anyone else on the machine.

That's not a small bug. That's the whole point of separation, gone.

The reason was simple, and it's a Windows fact worth burning into memory: any administrator can read any other user's files. By making everyone an admin, I'd handed every teammate a master key to everyone else's data.

How I Fixed It

Two moves.

First, I stopped making teammates admins. There's exactly one admin account on the machine now — the one I use to manage it. Everyone else is a standard user.

Second, I locked each person's home folder so only the owner and the machine admin can open it. On Windows, that's done with icacls:

icacls "C:\Users\teammate" /inheritance:r /grant:r "teammate:(OI)(CI)F" "Administrators:(OI)(CI)F" "SYSTEM:(OI)(CI)F"

In plain words: strip away the inherited "everyone can peek" permissions, then grant full access to just three parties — the folder's owner, the machine admins, and Windows itself. Nobody else gets in.

Then I tested it properly. From a teammate's session, I tried to read my private key again.

Access is denied

That's the sound of a sandbox working.

The setup I have now is exactly what it should have been from the start:

The admin account can see everything — it's the master key for managing the machine.
Each user can only see their own files.
No teammate can read another teammate's data.

And because the key had already been exposed once, I treated it as burned and rotated it — deleted the old one, generated a fresh one, updated GitHub. An exposed secret is exposed forever. You don't get to un-see it.

The Rule I Follow Now

So I never repeat the mistake, adding a new teammate is now two steps, not one:

Create their account as a standard user — not an admin.
Lock their folder with icacls after their first login.

Standard user plus locked folder equals automatic sandbox. That's the whole secret. The convenience of "just make everyone admin" is a trap, and it costs you the one thing the setup was supposed to give you.

The Part That Made It All Worth It

Once the machine was reachable and safe, I installed Claude Code on it.

And this is where it stopped being a server and started being the setup I'd always wanted.

The moment Claude Code was running, it took over the rest of the work itself. Setting up my projects. Wiring up the tools I use. Configuring the things I'd normally do by hand, one annoying step at a time. I gave it the goal and it handled the steps. My setup went from messy to clean without me babysitting it.

That's the real shift. Before, the machine was a place I had to log into and operate. Now it's a place I hand work to.

I run my agents there — Claude Code and others — point them at a task, and close my laptop. The work happens on a machine that never sleeps, that I'm not staring at. When I wake up, a good chunk of it is done.

I can check on any of it from my phone, from anywhere, because it's a real server now. Not a laptop I have to carry. Not a cloud bill I have to watch. Just a quiet box in the office doing my work while I sleep.

How You Can Do This Too

You probably have a machine like this somewhere. An old desktop. A spare laptop. A workstation that's powered on far more than it's used.

The recipe is short:

Tailscale to reach it from anywhere, with zero router config.
OpenSSH set to start automatically so it's always waiting for you.
One admin account, everyone else standard, every folder locked so sharing it never means leaking data.
Then put an agent on it and let the machine do the work you used to stay up for.

You don't need to rent anything. You don't need a second OS. You just need to stop letting good hardware sit idle.

Key Takeaway

The point was never "save money on a server." The point was getting my time back.

The machine being always-on means I can dispatch work and walk away. The sandboxing means I can share it without fear. The agent on top means I'm not the one doing the repetitive parts anymore.

And the lesson I'd hand to anyone trying this: convenience and security pull in opposite directions, and the convenient default — making everyone an admin — is exactly the one that breaks. Lock it down early. Test it like an attacker would. Then enjoy the setup.

I wanted a machine that works while I sleep.

Now I have one.

— Omkar Chebale