It was working perfectly — then the desktop froze, the connection dropped, and everything you had set up was simply gone. Nothing broke. You met the hardest limit of this method: GitHub terminates every hosted job at 6 hours, without exception and without saving anything.
A GitHub Actions runner is a borrowed build machine, not a rented server. Every limit of the free RDP method flows from that one fact. Some of the limits are written in GitHub's documentation; others you only discover by losing work at the worst moment. This page lists all of them in advance, so none of them can surprise you.
👆 The ending is built into the method. A session that 'suddenly died' almost always just reached one of these three facts.
GitHub's documentation states it plainly: each job in a workflow can run for up to 6 hours of execution time on a GitHub-hosted runner. If a job reaches the limit, it is terminated and fails.
On a private repository, runs draw from your plan's monthly Actions allowance — the Free plan includes 2,000 minutes a month, and Windows minutes are billed at twice the Linux rate, so they drain twice as fast. Standard runners in public repositories are free, which is why RDP repositories are almost always public. That choice has its own price: your workflow file and run logs are visible to the whole internet, so nothing private may ever be written into them.
Before your desktop exists, the runner must be assigned, Windows must boot, and your workflow's steps must run — RDP enabled, password set, tunnel started. On a busy day there can also be a queue. All of it comes out of the same 6 hours. In practice, plan your real working window as roughly five and a half hours, and set your own phone timer when you connect. Being logged out mid-task by your own timer is annoying; being wiped mid-task by GitHub's is worse.
The obvious workaround — restart the workflow every 6 hours to fake a 24-hour server — is exactly the pattern GitHub's monitoring exists to catch. GitHub's terms limit Actions to developing and testing software, state that GitHub may monitor use, and list terminated jobs, restricted Actions, disabled repositories and suspended accounts as the consequences. An occasional test session is one thing; a machine stitched together to run around the clock is the clearest possible signal of misuse. If your need is genuinely always-on, the honest tool for it is a VPS — the decision guide in this series does that maths openly.
The video itself presents this as a temporary, free test machine — watch it to see the method used the way it is meant to be used.
▶️ Watch Full VideoNo. When the job ends, the virtual machine is destroyed completely — desktop, files, installed software and settings. The only way to keep anything is to upload it to your own storage during the session, before the job ends.
No. The 6-hour per-job limit applies to GitHub-hosted runners regardless of plan. Paid plans increase your included minutes and how many jobs can run at once — they do not make a single job longer or permanent.
The usual causes: a workflow step failed and ended the job, someone cancelled the run, the ngrok tunnel died, your private repository ran out of monthly minutes — or GitHub restricted the run. Check the run's log first; it records which one happened.