Secure remote access to a homelab server from a laptop

How to Secure Remote Access to a Homelab: Choose the Right Access Method

Sophie CarterSophie Carter

Managing a homelab from home is easy. Remote access is where things get more complicated.

Maybe you need a project file from one PC, want to restart a Docker container, check Home Assistant, or reach several private services while you are away. Those jobs call for different setups.

The safest choice is usually the one that gives you no more access than you need. A VPN makes sense for several private resources. A tunnel may be enough for one Web app. If all you need is one computer, remote desktop software such as AskLink can keep the scope much smaller.

This guide will help you choose the right approach and secure it properly.

First, Decide What You Actually Need to Access

Before choosing a tool, narrow down what needs to be reachable.

Three things usually determine the answer:

1. What are you trying to reach: one computer, one app, a server shell, or several private services?

2. Who needs access: only you, or other people too?

3. What will you connect from: a laptop, phone, or just a Web browser?

The last question matters because some methods require a client app, while others can work through a browser.

Use this as a quick guide:

What you need to reachUsually the best fit
Several devices or private services inside your home networkVPN or mesh VPN
One self-hosted Web appAuthenticated tunnel or reverse proxy with access controls
One homelab computerRemote desktop
A server command lineSSH, ideally behind a VPN/tunnel or strict access controls

What Are the Main Ways to Access a Homelab Remotely?

Homelab access decision tree comparing VPN, reverse proxy, remote desktop, and SSH

VPN or Mesh VPN for Network-Level Access

Need your NAS, a Proxmox dashboard, Home Assistant, and several other private services while you are away? That is where a VPN usually makes sense.

WireGuard is a common traditional option, while services such as Tailscale build a mesh VPN between your devices. Once connected, the remote device can reach the private resources you have allowed it to reach.

But a VPN can also be more access than the task requires. If all you really want is Photoshop running on one workstation, remote desktop may be the simpler fit.

VPN access does not have to mean full LAN access either. Rules can limit a user or device to specific machines, services, or ports.

Tailscale, for example, recommends using least-privilege access policies so users and devices only receive the access they need.

Tunnel or Reverse Proxy for a Self-Hosted Web App

A single Web app does not usually justify access to the whole home network.

For something like Jellyfin, Immich, or Home Assistant, an authenticated tunnel or reverse proxy can give users a direct route to that service.

This matters even more when other people need access. If your family only needs Jellyfin, giving every device VPN access to the rest of your homelab is probably more access than they need.

An app-level route can also be more convenient when someone is connecting from a browser or a device where installing a VPN client would be awkward.

Some tunnel services avoid a public inbound listener on the homelab side. Cloudflare Tunnel, for example, creates outbound connections from the origin.

The tunnel itself is only part of the setup. The app still needs authentication and sensible access rules. HTTPS encrypts the connection; it does not decide who is allowed to sign in.

Remote Desktop for One Homelab Computer

Sometimes the whole job is simply getting back to one PC.

Remote desktop lets you use that machine's screen, apps, and files from somewhere else.

Maybe the workstation already has Photoshop or Blender, your project files, local development tools, and the browser sessions you use to manage Proxmox or Home Assistant. In that case, it may be easier to work on the computer that is already set up than recreate the same environment on your travel laptop.

Unlike a VPN, remote desktop does not place that laptop inside your home network by default. You are controlling the workstation itself.

For a homelab where that one machine is all you need, the narrower scope can be an advantage.

SSH for Server Administration

If all you need is to restart a Docker container, check a log, or edit a config file on a Linux server, SSH is usually more direct than opening a full graphical desktop.

Use key-based authentication and appropriate firewall rules, or keep SSH behind a VPN or tunnel rather than exposing it more broadly than necessary.

SSH and remote desktop solve different jobs: one gives you a shell, while the other gives you the graphical environment of the computer itself.

How to Secure Remote Access to Your Homelab

Choosing the access method is only half of the setup. The accounts, devices, permissions, and services around it also need protection.

NIST's remote access guidance similarly recommends protecting both remote access technologies and the devices used to connect to them.

Laptop displaying a network connection diagram for remote access

Minimize Exposure and Access

Keep services local unless you have a clear reason to access them remotely. It is especially important for router admin pages, hypervisor dashboards, databases, and other management interfaces.

If RDP, SSH, VNC, or an admin panel is public, anyone on the internet can access and probe that service. CISA's Internet Exposure Reduction Guidance recommends identifying internet-facing assets and removing or restricting unnecessary exposure.

The same principle applies after someone signs in. Give each user or device only the access it needs. A VPN user who needs one NAS, for example, does not necessarily need access to the entire LAN.

In a larger homelab, firewall rules or network segmentation can keep a public-facing service from reaching everything else.

Protect Accounts and Keep Systems Updated

A secure network path does not help much if the account behind it is easy to take over. Use a unique password for each service and enable MFA where the product supports it. Avoid shared credentials, especially when several people use the homelab.

The same goes for software. Your router, operating system, VPN or tunnel client, remote desktop tool, and exposed applications all become part of the remote-access path. Keep them patched, and remove services you stopped using instead of leaving them running indefinitely.

Review and Revoke Access

Old access tends to accumulate. A laptop you replaced months ago may still be authorized, or an SSH key may belong to a device you no longer use.

Check your authorized devices, accounts, SSH keys, and permissions occasionally. Remove anything that is no longer needed, and look through available connection or login records when something does not look familiar.

How to Securely Access One Homelab Computer Remotely

Use Remote Desktop Instead of Exposing RDP Directly

Windows RDP can provide remote access, but exposing its login service directly to the internet increases the public attack surface.

CISA recommends avoiding direct internet exposure of RDP where possible and using controls such as MFA when remote access is required.

A remote desktop service can give you another path to that computer without publishing its RDP login page directly.

This does not mean remote desktop is always safer than a VPN or SSH setup. It simply fits a different task: controlling one computer instead of accessing the whole network.

Use AskLink for Device-Level Homelab Access

For a homelab PC or workstation, AskLink keeps the connection focused on that device. The Controller does not automatically gain general access to the rest of the home network.

After installing AskLink on the homelab computer, you can connect from another supported device and use the environment that is already set up there.

That may include project files stored on the PC, desktop software that is already installed, or the browser sessions and local tools you normally use to manage the homelab. You do not need to recreate the same setup on the device you are traveling with. Unattended access is also available for computers that need to remain reachable while nobody is home.

There is an extra verification step when a new Controller is authorized from an untrusted device. If you sign in with a password, AskLink requires identity verification before that device can receive Controller permissions. Verification can be completed by QR code, phone, or email code.

Authorized Controllers can also be reviewed and removed later.

That makes AskLink a good fit for device-level homelab access. For full private-network access, a Web app, or command-line server administration, VPNs, tunnels, and SSH still solve different problems.

Common Homelab Remote Access Security Mistakes

Some of the riskiest homelab setups are not obviously broken. They connect successfully, but leave more exposed than the owner realizes.

- Exposing management services directly to the internet. RDP, SSH, VNC, router admin pages, and hypervisor dashboards need strong protection if they are publicly reachable.

- Assuming HTTPS means an app is secure. HTTPS protects data in transit, but the app still needs proper authentication and access control.

- Giving remote users more access than they need. A VPN user who only needs one service does not necessarily need access to the whole LAN.

- Leaving old devices or credentials active. Unused Controller devices, SSH keys, VPN permissions, and accounts can become forgotten access paths.

- Assuming no open ports means no risk. A mesh VPN, outbound tunnel, or remote desktop service may work without traditional inbound port forwarding, but the account and authorized devices still become access paths. A stolen account or compromised laptop can matter even when a port scan shows nothing open.

How to Check Whether Your Homelab Remote Access Is Actually Secure

A setup isn't finished just because the connection works. Check what is actually reachable from outside your home network.

1. Test from another network. Turn off home Wi-Fi and connect through cellular data or another network.

2. Check what is reachable. Confirm that the computer, app, or service you intended to expose works, while private resources that should stay local do not.

3. Make sure revocation works. Remove a test device, Controller authorization, SSH key, or VPN permission and confirm that access stops.

4. Review recent activity. Check available login or connection records for devices or access you do not recognize.

If possible, also test that your backups can actually be restored.

Which Remote Access Setup Should You Choose?

There is no single best homelab remote access setup.

Use a VPN when you need several private resources, a tunnel for a specific Web app, SSH for command-line administration, and remote desktop when the computer itself is what you need to use.

For that last case, AskLink provides a device-level option without automatically giving the Controller general access to the rest of your LAN. Whichever route you choose, keep access limited and make sure you can revoke it when you no longer need it.

FAQ

It depends on what you need to reach. Avoid giving yourself network-wide access when one computer or one app is enough. Whichever method you use, protect the account, limit permissions, keep the software updated, and make sure lost or old devices can be revoked.

Yes. Mesh VPNs, outbound tunnels, and some remote desktop services can provide remote access without traditional inbound port forwarding. But no open inbound ports does not mean no security risk. Accounts, remote devices, and applications still need protection.

No. Remote desktop gives you control of a specific computer. Network-level access allows your remote device to communicate with other resources inside the private network. This is why AskLink remote desktop can be a better fit when you only need one homelab computer.

Revoke its access as soon as possible. Remove its VPN permission, controlling authorization, SSH key, or other credentials. If a password or key may have been exposed, replace it and review recent login or connection records for unexpected activity.