Tag: remote access

  • How to Access Home Assistant Remotely with Tailscale on a NAS (No Port Forwarding Required)

    How to Access Home Assistant Remotely with Tailscale on a NAS (No Port Forwarding Required)

    One of the biggest things I wanted after setting up Home Assistant was reliable remote access.

    At first, I assumed this would be simple. Install Home Assistant, install the mobile app, sign in remotely somehow, and that would be the end of it.

    The deeper I got into self hosting though, the more I realised remote access is one of those areas where things become complicated surprisingly quickly. Every guide seemed to recommend something different, from opening ports on the router to setting up reverse proxies, SSL certificates, Cloudflare tunnels and domain names.

    None of those things are inherently bad, but when you are still building your understanding it becomes difficult to know what is actually necessary and what is just adding complexity.

    There was another factor as well: subscriptions. I completely understand why Home Assistant Cloud exists and for many people it is probably the right solution. But like a lot of people these days, it feels as though everything wants a monthly fee.

    I was not trying to avoid spending money entirely. I just wanted to see if I could achieve reliable and secure remote access using the hardware and software I already had, without exposing Home Assistant directly to the internet while I was still figuring things out.

    That is what led me to Tailscale. It gave me a way to get remote access working without turning it into a much bigger networking project.

    My setup

    For reference, this is the setup I am currently running.

    The NAS itself is a UGREEN NASync DXP2800 running Docker containers for both Home Assistant and Tailscale. If you’re interested in the hardware itself, I covered my experience in my  UGREEN NASync DXP2800 Review After 2 Months.

    There is no port forwarding, no reverse proxy, no public Home Assistant exposure, and no Home Assistant Cloud subscription.

    That probably sounds restrictive at first, especially if you spend enough time reading forums where people are building very advanced setups. But honestly, that was exactly the point.

    Despite working in IT, I did not want this to become a project that required constant maintenance. I wanted something that was secure, made sense, and just worked day to day without needing to be constantly revisited.

    Just because a solution is more advanced does not automatically make it better for your situation. For me, the goal was not to build the most complex setup possible. It was to build one that was secure, reliable, and easy to live with long term.

    That is what pushed me towards Tailscale.

    Why I chose Tailscale

    The biggest reason was simplicity, not because the alternatives were beyond me, but because I was trying to solve a specific problem rather than build a networking project.

    There are plenty of ways to provide remote access to Home Assistant. You can use reverse proxies, SSL certificates, Cloudflare tunnels, domain names, port forwarding and various other combinations depending on how much control you want.

    The problem is that every additional layer becomes something else to configure, secure and maintain.

    For some people that is part of the hobby, and there is nothing wrong with that. For me, the goal was simply to access Home Assistant securely when I was away from home.

    Tailscale felt like a very clean solution to that problem. Instead of exposing Home Assistant publicly and then protecting it afterwards, it creates a private encrypted network between devices you already trust.

    In practice, that meant my phone could communicate directly with my NAS without Home Assistant ever being exposed to the public internet.

    That shift in approach made everything much easier to reason about. I was not publishing a service and securing it, I was extending a private network.

    For a home setup, that balance between simplicity, security and reliability was hard to ignore.

    The benefit I was not expecting

    When I first started looking at remote access, I was focused almost entirely on Home Assistant. The goal was simply to be able to open dashboards and make sure automations worked when I was away from home.

    What I did not really think about at the time was that I was solving a much bigger problem.

    Once Tailscale was working, Home Assistant was only one of the things I could access remotely. I also had other services running on my NAS, including my Recipe App and Home Dashboard. Several of these are applications I discussed in my  Docker Containers I Still Use One Year Later article, and Tailscale effectively gave me secure remote access to all of them at the same time.

    That was the point where it clicked. Tailscale stopped feeling like a Home Assistant tool and started feeling like part of the underlying infrastructure of my home network. The more services I added locally, the more useful it became.

    The Home Assistant benefits were still significant. Presence detection became more reliable, location updates worked more consistently, and geofenced automations behaved the way I expected them to.

    But the bigger takeaway was that I only needed to solve remote access once. Every service I run now, and anything I add in the future, can use the same setup.

    Before you start

    This guide assumes you already have Home Assistant running and accessible on your local network.

    If you are starting from scratch, make sure you can access Home Assistant locally first, for example:

    http://192.168.x.x:8123

    Do not move on until this works reliably. Otherwise you end up troubleshooting multiple things at once.

    Checking Home Assistant locally

    Before adding Tailscale, confirm Home Assistant is actually listening on port 8123.

    sudo ss -tulpn | grep 8123

    You should see Home Assistant (usually as python3) listening on that port. If not, fix that first.

    Installing Tailscale in Docker

    Tailscale running as a Docker container on a UGREEN NAS alongside other self-hosted applications.
    Tailscale running as a Docker container on my UGREEN NAS.

    Install Tailscale as a Docker container on your NAS.

    docker pull tailscale/tailscale:latest
    docker run -d \
    --name=tailscale \
    --hostname=nas \
    --network=host \
    --cap-add=NET_ADMIN \
    --cap-add=NET_RAW \
    -v tailscale-data:/var/lib \
    tailscale/tailscale:latest

    Check the logs to get the authentication link:

    docker logs tailscale

    Open the URL shown, sign in, and approve the device.

    Make sure to click this link right away, as Tailscale login URLs expire after a few minutes. If it has expired, simply restart the container or re-check the logs to generate a new one.

    Note: In this example, Tailscale stores its configuration in a Docker named volume called tailscale-data. If you prefer to keep your container data in a specific folder for easier backups or management, you can replace the named volume with a local path that suits your environment.

    For example:

    -v /path/to/tailscale-data:/var/lib

    The exact location will depend on your operating system, NAS, or Docker setup.

    Verify the connection:

    docker exec -it tailscale tailscale status

    Setting up Tailscale on your phone

    Tailscale mobile app showing connected devices and assigned tailnet IP addresses.
    The Tailscale app lets you confirm your devices are connected and quickly find your NAS Tailscale IP address.

    Installing Tailscale on the NAS is only half of the setup. You also need it running on the device you actually want to connect from, which in my case is my iPhone.

    Download the Tailscale app from the App Store and sign in using the same account you used to authenticate the NAS. Once signed in, your phone will appear in your Tailscale admin console alongside your NAS.

    At that point, your phone is part of the same private network. Your phone is no longer “connecting into” your home network, it is effectively part of it.

    One useful thing is that the Tailscale app shows all connected devices and their assigned IP addresses. That means you can quickly check your NAS Tailscale IP directly from your phone without needing to SSH in.

    This is useful when setting things up or troubleshooting because you can confirm:

    • your NAS is online
    • your phone is connected to the tailnet
    • the correct Tailscale IP is being used

    Finding the Tailscale IP

    Get the Tailscale IP:

    docker exec -it tailscale tailscale ip -4

    You will get something like:

    100.x.x.x

    Use that to access Home Assistant remotely:

    http://100.x.x.x:8123

    This uses HTTP, not HTTPS. Tailscale already encrypts the connection, so forcing HTTPS here will break things.

    Configuring the Home Assistant Companion App

    Home Assistant Companion App server settings showing internal and external URL configuration.
    Directly after “Configuring the Home Assistant Companion App” and before you explain Internal vs External URLs.

    In the Home Assistant Companion App, you need to set the Internal URL and External URL.

    On iPhone, open the app and go to:

    Settings → Companion App → Server Settings

    (If you have multiple servers configured, tap your server first, then open Server Settings.)

    Use your local IP for Internal URL:

    http://192.168.x.x:8123

    Use your Tailscale IP for External URL:

    http://100.x.x.x:8123

    Both should use HTTP. Tailscale already encrypts the connection, so you do not need HTTPS here.

    Once set, back out of the menu and give the app a few seconds to reconnect. If everything is correct, it should connect both on WiFi and over Tailscale without any errors.

    VPN On Demand on iPhone

    One thing I highly recommend enabling is VPN On Demand inside the Tailscale app.

    Enable it for both WiFi and cellular so the connection is automatic. That way you do not need to remember to manually connect before opening Home Assistant.

    This makes the whole setup feel much more seamless day to day and also improves reliability for things like presence detection and geofenced automations because your phone maintains a consistent connection back to Home Assistant.

    The issue that caused the most confusion

    The biggest problem I hit was not Home Assistant. It was Tailscale Serve taking over port 8123.

    sudo ss -tulpn | grep 8123

    If you do not see Home Assistant on that port, something else has taken it.

    Fix it with:

    tailscale serve reset

    Hardware I Use

    Before I wrap up, a quick note: some of the links below are Amazon affiliate links. If you choose to purchase through them, I may earn a small commission at no additional cost to you. I only recommend products I personally use or have hands-on experience with.

    The software in this guide is free, but if you’re curious about the hardware behind my setup, this is what I currently use:

    I’ve been using this setup for Home Assistant, Docker containers, remote access through Tailscale, and various self-hosted projects. If you’re building something similar, these are the components I have the most hands-on experience with.

    Final thoughts

    Tailscale ended up being one of the most useful additions to my setup, not because it was flashy, but because it removed friction.

    Once it was configured, I stopped thinking about remote access entirely. Combined with a stable home network, which I discussed in  What Actually Happens on Your Network (Why WiFi Feels Inconsistent), it became one of those rare pieces of infrastructure that simply fades into the background and does its job.

    There are more advanced ways to achieve the same result, and for some setups they will make sense. But for me, this struck the right balance. It solved the problem I actually had without introducing more moving parts to maintain.

    Looking back, that was the biggest win. Not just remote access, but a simple foundation I can keep building on without having to rethink it every time I add something new.

  • Setting Up the UGREEN NASync DXP2800: Step-by-Step Initial Configuration Guide

    Setting Up the UGREEN NASync DXP2800: Step-by-Step Initial Configuration Guide

    The UGREEN NASync DXP2800 is one of the most accessible NAS options for first-time users, and setting it up is refreshingly simple. In this post, I’ll walk you through the initial setup steps I took — from powering on to creating a storage pool — with commentary on RAID choices and a few tips I picked up along the way.


    What’s Included in the Box

    • UGREEN NASync DXP2800 unit
    • Power adapter
    • Ethernet cable
    • Screws (for 2.5″ drives)

    The NAS has the following ports:

    • 1x 2.5GbE LAN port (back)
    • 2x USB 3.2 Gen1 ports (back)
    • 1x USB-C 3.2 Gen1 port (front)
    • 2x USB 2.0 ports (back)
    • 1x HDMI (currently not in use)
    • Power button and reset button

    Make sure to connect the NAS using the included Ethernet cable for the most stable setup experience.

    Looking to pick up the NAS I used in this guide?

    💡 Need more bays? UGREEN also offers higher-capacity models:

    These are affiliate links — if you decide to buy through them, it supports the blog at no extra cost to you. Thanks for your support!


    Step 1: Power On and Detect the NAS

    Before you start, make sure your NAS is connected via Ethernet for the most reliable connection. It’s also worth checking for any available system updates once you’re in the dashboard — UGREEN recommends updating UGOS Pro early on to avoid compatibility issues, especially if you plan to use SSD caching or Docker later.

    As soon as the NAS is powered on and connected to your network, it appears in the UGREEN NAS app. It can take a few minutes for the device to be detected. However, if it doesn’t show up automatically, you can register it manually by scanning the QR code located on the bottom of the device.

    If it doesn’t appear straight away, you can scan the QR code on the bottom of the NAS to register it manually.

    Step 2: Name Your NAS & Accept Terms

    Once detected, the app prompts you to name your NAS and accept the standard user agreement and privacy terms.

    Give your device a unique name to help distinguish it on the network.

    Step 3: Register Your Email (Recommended)

    While you can skip this, I recommend linking your email for access to UGREENlink and system alerts.

    Registering your email enables remote access and alerts for any system issues.

    Step 4: Enable Remote Access

    I enabled UGREENlink, which gives you remote access to your NAS — useful if you want to monitor or transfer files while away.

    Remote access lets you securely manage your NAS from anywhere.
    UGREENlink remote access lets you securely manage your NAS over the internet. Your NAS name becomes your UGREENlink ID, which you can use from the web or mobile app.

    Step 5: Create Your Storage Pool

    Before you begin, ensure the NAS is powered off when inserting any drives. The DXP2800 uses a tool-less tray system for 3.5″ drives, which makes installation quick and simple. For M.2 SSDs, be cautious as they slot in internally and require careful handling.

    Here’s where you’ll select the drives you installed. I had two 7.2TB HDDs and two 1TB NVMe SSDs.

    You can mix drive types, but it’s best to separate HDDs and SSDs into different pools.

    I opted to configure my HDDs into a single RAID 1 array for redundancy. RAID 1 mirrors the data between the two drives, so if one fails, the other still has all your files. It’s not the most space-efficient, but it offers peace of mind.

    For the SSDs, I chose a Basic (non-RAID) setup for now — mainly because I plan to use them for apps or caching later. I didn’t see much benefit to mirroring them at this stage, especially since I’m not storing critical data there yet.

    RAID 1 for HDDs and a basic SSD pool gives a good mix of reliability and flexibility.

    Step 6: Format and Create Volume

    Once your storage pool is created, the next step is formatting the drives and setting up a volume. This is where you choose between Btrfs and ext4, the two available file systems.

    I chose Btrfs for my HDDs because it supports advanced features like snapshots, built-in data integrity checks, and efficient storage management — all of which are helpful if you’re storing lots of data or want more control over versioning and recovery. It’s especially useful in a home NAS setup where accidental deletion or corruption is a concern.

    For the SSD pool, I went with ext4. While it lacks the bells and whistles of Btrfs, it’s lighter on resources and has a long-standing reputation for reliability and performance. Since I’m planning to use the SSDs for running apps and temporary data, ext4’s speed and lower overhead made more sense.

    Here’s a quick breakdown:

    • Btrfs Pros: Snapshots, checksums, automatic error correction, efficient disk usage
    • Btrfs Cons: Slightly more system overhead, slower write performance than ext4 in some cases
    • ext4 Pros: Fast, low overhead, extremely stable
    • ext4 Cons: No native snapshots, no checksumming or automatic correction
    Btrfs is great for snapshots and folder-level protection. ext4 is a better fit for app containers or temporary storage.

    Before confirming, the system will warn you that all existing data on the drives will be erased.

    Once confirmed, your drives will be formatted and the volume created.

    Step 7: Review System Usage

    After setup, you’ll be shown a breakdown of how your drives are being used. In my case, the system reserved about 15.2GB on one of the SSDs — this includes operating system files and essential services needed to run UGOS Pro.

    This is completely normal, especially on Btrfs volumes where a bit more space is allocated for things like snapshots, metadata, and system overhead. You may also notice:

    • Slightly less available capacity than expected
    • Reserved space depending on your file system and RAID choice

    This screen is a great checkpoint to understand how your storage will behave moving forward:

    • Btrfs can accumulate snapshots and logs, so it’s worth checking the system status occasionally
    • SSDs used for apps (e.g. Docker) may fill quickly if large containers or image caches build up

    You can always check system usage later under the Storage section of the dashboard for a more detailed view.

    Storage overview shows space used by the system, available space, and reserved capacity.

    Final Thoughts

    The DXP2800 offers one of the smoothest NAS setup experiences I’ve used. From unboxing to configuring storage pools, everything was laid out in a way that’s friendly for first-time users. The guided setup process is clear and surprisingly quick.

    I’d recommend enabling two-factor authentication early on to help secure your admin account — it works with any standard authenticator app, and I opted for Microsoft Authenticator since I already use it elsewhere.

    If you’re planning to share the NAS, take advantage of personal folders or set up user-specific access permissions. It’s an easy way to protect privacy and organise data effectively.

    While RAID 1 is a great way to add redundancy, don’t rely on it as your only backup. It’ll help if a drive fails, but it won’t protect you from accidental deletion or file corruption.

    Finally, take note of the reset button behaviour: a short press restarts the system, while holding it down for 10 seconds resets it to factory settings — useful if you ever run into serious issues.

    Next time, I’ll walk through installing Docker and setting up lightweight apps like Pi-hole and Plex to unlock more potential from the NAS.

    Have questions or planning your own setup? Drop them in the comments — always happy to help!