When I’m helping customers troubleshoot Rancher issues I spin up and tear down local Rancher environments constantly.

Most of the time, everything runs locally with no need for public access (and if I need to access it remotely I do so with Tailscale). But some tests, like provisioning clusters in a cloud k8s offering (EKS, AKS, GKE) or using Rancher’s built-in EC2 cluster provisioning require my Rancher server to be publicly reachable.

What I didn’t want was a Rancher instance that’s permanently exposed to the internet or a requirement to open ports on my pfSense router every time I need to run a test. I wanted something I could turn on for a few hours, run my cloud-provisioning tests, and then shut back down as soon as I’m done.

That’s what led me to Cloudflare Tunnel (cloudflared). I already make use of NGINX Load Balancer in Docker for my Rancher environment load balancing, so I can securely expose my local Rancher environment to the internet on demand, no firewall changes, no static public IP, and no long-term exposure.

In this guide, I’ll walk through how I set it up and how you can do the same.

Prerequisites

The prerequisites here are:

1. A Cloudflare domain name
2. A local NGINX LB running in Docker
3. A Rancher environment (3 nodes, in my case)

If you don't have these set up that's okay, I think it'll still be worth your time.

Architecture

Let's briefly discuss the architecture.

The Cloudflare tunnel is what we'll set up in the next section. It's job is to securely route traffic from the Cloudflare network (i.e. the internet) to wherever you determine.

Cloudflared is the client, which can be installed on macOS, Windows, Linux, or Docker. In our case, as you can see above, we'll be installing the client on the same Docker host providing our load balancing.

NGINX Load Balancer is what handles the traffic from my local network and balances those connections to my Rancher cluster.

Rancher is what I'm using for all my kubernetes management. It runs on an RKE2 cluster in my lab.

Make a Cloudflare Tunnel

Assuming you already have a domain name through Cloudflare, setting up a tunnel is simple. Go to:

Zero Trust -> Networks -> Tunnels

Then click "Create a Tunnel". Chose "Cloudflared" as the type.

Give your tunnel a good name, and on the next page click "Docker".

Cloudflare will generate a "docker run" command for you at the bottom of the page, copy that, we'll need to edit it before we run it.

Click "Next".

On the next page you'll configure the application that's going to be exposed with this tunnel. Copy the settings below while also adding in your own domain and subdomain.

Note: this will create a CNAME record to point this subdomain to the tunnel.

Click "Complete Setup".

NGINX Load Balancer

Here's my LB config you can use. My certs are in ~/user/certs and I have my 3 Rancher node IPs listed in the "rancher_backend" section.

worker_processes 1;

events {
    worker_connections 1024;
}

http {
    server {
        listen 80;
        return 301 https://$host$request_uri;
    }

    upstream rancher_backend {
        least_conn;
        server <server_IP_1>:443;
        server <server_IP_2>:443;
        server <server_IP_3>:443;
    }

    server {
        listen 443 ssl;

        ssl_certificate /etc/nginx/certs/cert.pem;
        ssl_certificate_key /etc/nginx/certs/key.pem;

        location / {
            # Block WebSockets
            if ($http_upgrade ~* "websocket") {
                return 403;
            }

            proxy_pass https://rancher_backend;
            proxy_ssl_server_name on;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

Here's how I run NGINX passing in ~/user/certs for it to consume my certs and serve them up.

docker run -d --name rancher-lb \
    -p 80:80 -p 443:443 \
    -v /etc/nginx.conf:/etc/nginx/nginx.conf:ro \
    -v /home/user/certs:/etc/nginx/certs:ro \
    --restart unless-stopped \
    nginx

Run Cloudflared

Now, take the token from the generated Docker command and paste it in the below command that you'll run on your Docker host.

docker run -d \
  --name cloudflared \
  --add-host=host.docker.internal:host-gateway \
  cloudflare/cloudflared:latest tunnel \
  --no-autoupdate run \
  --token xxxxxxxxxxxxxxxxxxxxxxxxx

This simply:

• pulls/runs the cloudflared container
• passes in the token to authenticate with Cloudflare
• add the host.docker.internal DNS entry to the container so that it can reach the host machine

If you're following closely you'll notice that the Cloudflare tunnel points to port 443 on the host machine so that it'll function just like it would if you were on the local network hitting the IP address of the load balancer host.

Once you run the command above^ if your tunnel is up, it should show as healthy in the Tunnels page on Cloudflare.

You should now have a publicly accessible Rancher URL, ready to be used with any cloud provider. Whenever you'd like to turn it off, just stop the cloudflared Docker container and your Rancher instance won't be publicly accessible.

I've found myself in a bit of a pickle. I want to upgrade my TrueNAS server from Core to Scale, but I'm currently using the Plex jail install on Core that isn't compatible with Scale.

So I've decided to write up this short tutorial about how I did move my Plex install from the "jail" kind of install over to the "app" install while retaining all my settings/config.

If all this sounds interesting to you, follow along.

Pre Upgrade Steps

First things first, make a new dataset in TrueNAS. This will be the home of our Plex config. In my case it's /mnt/PlexData/plex_config/

Stop the Plex jail so there are not additional changes to your config (your users will be fine).

Copy the contents from the current Plex config to the new dataset that our Plex container will eventually reference . For me, this is at:

/mnt/<dataset>/iocage/jails/<jailname>/root/Plex Media Server

The below command will copy the current contents of the Plex config jail to the new dataset using rsync.

rsync -a --progress --info=stats2 "/mnt/<dataset>/iocage/jails/<jailname>/root/Plex Media Server" /mnt/PlexData/plex_config/

Once that completes, we need to make sure permissions are correct on the new config dataset. Plex will need permissions to be UID/GID 1000:1000 so it can read/write to this new dataset. Below is the command to do so.

chown -R 1000:1000 /mnt/PlexData/plex_config/

You're basically ready to upgrade now. But before you do, be sure to take backup of your TrueNAS config.

I'm not going to give steps on how to do the upgrade because the official TrueNAS doc is great. For me it'll be Dragonfish-24.04.2.5 for now to match my backup server.

However you do it, I'll see you on TrueNAS Scale.

Plex Setup

With your TrueNAS server migrated to Scale it might be a good idea to confirm everything looks okay in your settings and that the migration didn't break anything. This isn't a tutorial on that so I'm going to keep moving.

Start by going to Apps on the left hand bar and search for "Plex". Once you find it, install it. You'll need to choose the correct pool to install the app to.

You'll then be presented with the setup of your new Plex app.

If you're migrating from a previous Plex install, don't forget to get your claim code and enter that in the config using https://www.plex.tv/claim.

Now, this next part took a little bit of learning on my end, so hopefully I can help you out. The goal here is to point Plex to both the storage dataset (i.e. movies, tv shows, etc.) and config dataset we created earlier. Below is my setup for reference, but really it's important to make sure that Plex is able to find:

media -> "Storage Configuration"
config -> "Plex Configuration Storage"

I used this reddit post to make sure my permissions were correct on both datasets. The first two photos are the important ones here, as they give you a template to use for the datasets. Very important to have the below options set on the dataset as Read/Write/Execute.

User - apps
Group - apps

Also, something I had to figure out the hard way was that my previous Plex install inside a jail didn't have the correct folder structure for what Plex was looking for in this installation. If you're coming from a jail install, it may be the same for you. Check this page for reference.

See, it's looking for Library/Application Support in the new setup but my jail didn't have this. The link above shows that the "FreeNAS 11.3 or newer" location is:

${JAIL_ROOT}/Plex Media Server/

So what I ended up doing was creating said structure within my plex_config dataset and moving the Plex Media Server directory under it. So it ended up like:

/plex_config/Library/Application Support/Plex Media Server

Once I did that, Plex recognized my previous configuration files.

Lastly, because this tripped me up too. This new install mounts the media to the /data directory. This is not where I had the actual Plex application pointing within the app itself, because previously the media was mounted at a /mnt location. So I had to go to

Settings -> Manage - Libraries -> library_name -> Edit Library -> Add Folders

and change the library location to the new media mount starting with /data. You'll need to do this for each library.

Final thoughts

You're done! Hopefully you have a running your Plex server on TrueNAS Scale.

proceed with caution - we're getting cheeky here, folks

If you haven't read my previous post on monitoring internal resources using Tailscale on an external VPS, I recommend you read it first. This post will be an iteration of that project.

Monitor Your Homelab from the Cloud: Uptime Kuma on a VPS using Linode + Tailscale + pfsense

I’ll show you how I configure a VPS to safely monitor my homelab.

Road to HomelabDustin Groh

My Uptime Kuma notifications coming from a Linode VPS have been working great and I don't need to change it up... but there's always room to simplify my homelab. Up until this project I had two Kuma instances (public and internal) and multiple VPS' with different providers. To clean that up, I'm getting rid of the Linode VPS entirely, although it's been awesome.

$free.99

To do this for free* you'll need to already have purchased Pushover... which I'm hoping you've done in the first version of the project.

Oh, also you will need a domain from Cloudflare.

... so it's not completely free, okay? I admit it, leave me alone.

Getting started

I hope you try to avoid opening any ports on your firewall if you don't need to. My rule has been I don't host public things on my home network. However, we'll be using Cloudflare Tunnels today, which technically will be allowing public traffic to an internally hosted service - but no ports will be opened. It's sort of magic, and they explain it better than me so check it out.

Fair warning, once I got this set up with my new domain on Cloudflare I got HAMMERED with spam calls about logo designs, website designs, etc. Just be aware.

I'll be using a few different platforms to make this work today.

First, the main component that allows this to work, like we said, is Cloudflare Tunnels. This will allow us to expose our internal Uptime Kuma instance publicly without opening any ports on our firewall. Check out the docs below.

Next, Uptimedoctor. The idea here is a service to monitor a public website and notify you if it's down. Uptimedoctor does that (for 5 websites) for free.

Log In to Your Account - Uptime Doctor

Log in to the monitoring control panel.

Partners Contact Language Login

Last is Pushover, which I mentioned in the first iteration of this project. It's a service that lets you set up push notifications to many different devices in many different ways.

Pushover: Simple Notifications for Android, iPhone, iPad, and Desktop

Pushover makes it easy to get real-time notifications on your Android, iPhone, iPad, and Desktop (Android Wear and Apple Watch, too!)

TL;DR

1. Use a Cloudflare Tunnel to expose your Uptime Kuma instance on a public domain without opening any ports on your firewall.
2. Use Uptimedoctor to notify you if that website goes down.
3. Use Pushover to receive push notifications about the status of the Uptime Kuma wesbite.

Let's do it

So, with the assumption you're already running Uptime Kuma, let's get started. Make sure you have a domain in Cloudflare ready to use. I'm the kind of person who isn't going to rehash something if there's already good documentation for it. So using the docs below, set up a Cloudflare Tunnel for Uptime Kuma.

Reverse Proxy with Cloudflare Tunnel

A fancy self-hosted monitoring tool. Contribute to louislam/uptime-kuma development by creating an account on GitHub.

GitHublouislam

At this point you should be able to navigate to your Uptime Kuma instance from the public internet, which is cool. Next we need a way to be notified if that website goes down for some reason, which is where Uptimedoctor comes in.

Get an account with Uptimedoctor and set up your monitor to be pointed at the domain you got from Cloudflare.

You'll also need to login to Pushover and grab the email address they've set up for you to input into Uptimedoctor. Essentially any emails that come to that email address generate a Push notification on your device of choice, simple. When you log into Pushover you'll see a section titled "Your E-Mail Aliases", and that will be the email address you'll input to Uptimedoctor.

Once complete it should look something like this, where at minimum you'll be receiving an email to your Pushover email address if Uptimedoctor sees this site go down.

Test the magic

Now, it's probably worthwhile to test it out.

Go on back to Uptime Kuma > Settings > Reverse Proxy you'll see a big red "stop cloudflared" button. Doing so will make your tunnel go down. After a few minutes there should be pretty substantial impact to what we just set up. In the Cloudflare Tunnel portal you should see your tunnel as "down" as well.

And finally, we should get a Push notification from Pushover.

Excellent! Now, back in Uptime Kuma click "Start cloudflared".

Once you receive the UP notification - you're good to go.

Hope this works well for you, enjoy.

I've seen an increase in people asking about container VPNs, and at one point I had the same questions. Hopefully this blog post can help answer those questions and get you up and running with a VPN for your containers.

In my situation I have a few containers that I want connecting to a VPN, but not all of them. So, I can't just put a VPN client on my Docker host machine and call it done. What's the best method to route select containers to a VPN while keeping others off it?

Well, I don't know if it's the best, but Gluetun is perfect for just that.

What is Gluetun?

GitHub - qdm12/gluetun: VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in.

VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in. - qdm12/gluetun

GitHubqdm12

If you haven't heard of Gluetun before, let me explain.

It's simply a container that you configure to use your VPN provider. Once the Gluetun container is connected to your VPN service you can then connect other containers to it and those containers will be utilizing a VPN connection.

Anyways, let's get started. If you'd like to follow along, it's important to note I'll be using Portainer to do my container configs, but you can do this all through the CLI if you want. I use Private Internet Access as my VPN, so that's what I'll be showing in my examples. Check this link to see all of the supported VPN options.

gluetun/internal/provider at master · qdm12/gluetun

VPN client in a thin Docker container for multiple VPN providers, written in Go, and using OpenVPN or Wireguard, DNS over TLS, with a few proxy servers built-in. - qdm12/gluetun

GitHubqdm12

First, let's get Gluetun deployed with some PIA options.

Deploying Gluetun

On the documentation page there is a very simple docker-compose file to get started with. In general for these self-hosted services it's a good idea to understand what they're doing before you just haul off and run the command. We'll need to input a few details like our PIA username and pw, the region we'd like to connect to, etc. Below is a template you could use, make sure to fill your details in before you use the file.

version: "3"
services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add:
      - NET_ADMIN
    volumes:
      - /yourpath:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=private internet access
      - OPENVPN_USER=PIA_USER
      - OPENVPN_PASSWORD=PIA_PW
      - SERVER_REGIONS=PIA_REGION

Using this file, we're going to create a stack in Portainer like so:

Deploy the stack.

Test if the VPN is up

"But how will I know if the Gluetun container is actually using the VPN?"

Well, good question. Let's test that. Exec into a container that is not Gluetun and run this, if you have curl, curl ifconfig.me. Below is an example output (your not getting my public IP, nerds)

If you don't have curl, this also works. wget http://ipecho.net/plain -O - -q ; echo and here's an example.

After that, exec into your Gluetun container and use this command to grab the public IP that the container is using for it's connection to the internet. Note: this should be different than the IP you just saw.

As you can see my Gluetun IP address is different than the container above, which confirms it's using the VPN we set up earlier.

Connect containers to Gluetun

We have Gluetun up and running, but let's connect a service to it.

In Portainer pick a container and scroll to the bottom where it shows the networking options. Unless you've edited things in the past, it will likely say "bridge" under "Connected networks". Click "Leave network".

If there are published ports for your container, you'll need to remove those before continuing.

Then, at the top select "Duplicate/Edit" and scroll to the bottom of the page to look for the "Advanced container settings".

Select the network tab, and change the Network from "bridge" to "container". Then, under "Container", select the Gluetun container.

Now select "Deploy the container". Once the container deploys it's time to confirm the IP of the container and we should see it using the VPN through Glutetun!

If you enjoyed this or it helped you, consider subscribing or buying me a coffee. Even if not, you're still welcome to come on by anytime.

Do you get notified if your services go down (which they never do...) and come back up? Have you ever wanted those notifications to look like this?

Well, today we'll make that happen.

Previously I had set up an instance of Uptime Kuma on a Linode in order to monitor my homelab "from the cloud" (check the link below if you'd like to read about it). This blog will be an extension of the blog above because now I'd like to set up Push notifications about my lab, to my phone, from the cloud. We'll be using Pushover to handle sending my phone (or any device, in your case) said notification.

Monitor Your Homelab from the Cloud: Uptime Kuma on a VPS using Linode + Tailscale + pfsense

I’ll show you how I configure a VPS to safely monitor my homelab.

Road to HomelabDustin Groh

Consider signing up

Before we get into it, if you're interested in getting emails when I post something new, click sign up below. It's free and I don't run ads.

What is Pushover?

Pushover: Simple Notifications for Android, iPhone, iPad, and Desktop

Pushover makes it easy to get real-time notifications on your Android, iPhone, iPad, and Desktop (Android Wear and Apple Watch, too!)

Pushover is a service that allows you to receive simple notifications on your iPhone/iPad/Android/Desktop.

Although it's not free, there is a 30 day trial. To purchase it there's a $5 one time purchase per platform (I'm a big fan of platforms that are one time purchases). That means if you want to receive notifications on your phone and desktop, you'll be out $10. Very reasonable.

Anyway, you'll obviously need a Pushover account and then you'll need to download the app on what ever platform you want to receive notifications on. For me, that's my iPhone. Login to your new Pushover account on the app you downloaded.

When you login on any of the Pushover apps you'll be asked to register the device you're on. I gave mine the name "iphone", but you can call yours whatever you like.

Now login to your Pushover account on a web browser.

On the home page, you'll want to take note of your "User Key" in the top right corner, you'll need this later on.

Click "Create an Application/API Token" at the bottom of the page. On the next page fill in the details of the application you're making and click "Create Application".

You'll be presented with a page that displays the API Token/Key for this application. That value will be copy/pasted into Uptime Kuma, so go ahead and copy it.

Now, let's head over to the Uptime Kuma instance.

Uptime Kuma config

Under "Settings" > "Notifications", click "Setup Notification".

This screen will allow us to configure our notification. Uptime Kuma has tons of ways to get notified about your services, here are a few that standout as good options to me:

• Discord bot
• Slack
• Microsoft Teams
• Email
• SMS
• Push notification

We're obviously going with Push notifications today, but I've used the Discord bot in the past and it worked perfectly. In the popup box I'll select "Pushover" as my Notification Type. Also, give it a friendly name and message title.

You're going to paste in three additional pieces of info from Pushover to make Uptime Kuma communicate with it:

• the Application Token (or API Token/Key), found when you click the name of your Application at the bottom of the homepage.
• your User Key, found on the right side of the homepage.
• the name of a device you'd like these notifications to go to (as a reminder, I gave mine the name "iphone").

So head back over to Pushover, grab that info, and put it in this popup within Uptime Kuma like my screenshot above.

You're welcome to edit some of the other fields like Message Title (i.e. the actual title of the Push notification you'll receive)., TTL, Priority, etc. I've also chosen to select "Default enabled" and "Apply on all existing monitors" at the bottom.

That's it! Click "Test" to confirm your notification works the way you want.

Look at that. You now have Push notifications set up for your homelab.

If you haven't heard, hosting a local static homepage for your homelab is all the rage. Also, you're very uncool if you haven't done one yet.

Obviously that's not true, because I haven't done one yet! So why don't we do one (or six) together?

I'm going to be setting up seven options today (SUI, Flame, Heimdall, Homepage, Homer, Dashy, and Homarr) so we can see how easy/hard they are to get going, how beginner friendly they are, and what their feature sets are.

Before we get into it, it's important to think about what it is you might be looking for. Maybe you want something very simple that's configurable with a GUI and strictly just has links to your most used services. Maybe you want the most complex homepage you can build with API integrations into your services and statistics on your Docker hosts and VMs. Maybe you want something in the middle. Regardless, having a rough idea of what you're looking for will help you weed out the options that won't work for you in this post.

My goal here is to give you a framework, or, a way to think about how I find it useful to setup and configure these apps, in order for you to use them in your own lab. There's no point in you doing exactly what I did if that doesn't work for you! Chances are you're hosting different services than me - but of course you're welcome to copy what I'm doing if that blows your hair back.

Also remember, all of these projects are free - and that in and of itself is amazing. Please go show the developers some love!

Consider signing up

If you're interested in getting emails when I post something new, click sign up below. It's free.

SUI

GitHub - jeroenpardon/sui: a startpage for your server and / or new tab page

a startpage for your server and / or new tab page. Contribute to jeroenpardon/sui development by creating an account on GitHub.

GitHubjeroenpardon

We're starting off simple.

SUI, and it's sister, Flame, are the easiest setup/configuration of the bunch. I'd recommend this one to anyone who doesn't care about integrations or having additional stats of services shown on their startpage (like ping).

For those of you who like to tinker and incorporate as much as possible into these platforms, SUI and Flame will likely be a touch too simple for you.

Install

Like most of the others we'll go through today, it's very easy to get started with Docker Compose. Just make a directory on your Docker host, mine is /home/docker/sui, cd to it, and run the below command.

git clone https://github.com/jeroenpardon/sui

Then, bring up the container.

docker-compose up -d

Then promptly receive an error that the Docker network cannot be found, just a reminder that I'm learning too!

I just ran the command in the error message and fixed it.

Config

And now, SUI is accessible on localhost:4000. We're greeted with a very nice example page with plenty to get started with.

Editing the apps list requires editing the apps.json file inside the repo you cloned. Here's what I came up with if you're interested in a starting point, don't forget to update your URLs.

{
    "apps" : [
        {"name":"pfsense","url":"10.1.1.1","icon":"wall"},
        {"name":"Nginx Proxy Manager","url":"nginx.domain.com","icon":"arrow-decision"},
        {"name":"TrueNAS","url":"Truenas.domain.com","icon":"tape-drive"},
        {"name":"Pi-hole","url":"pihole.domain.com","icon":"do-not-disturb"},
        {"name":"Portainer","url":"portainer.domain.com","icon":"docker"},
        {"name":"Plex","url":"plex.tv","icon":"plex"},
        {"name":"Tautulli","url":"tautulli.domain.com","icon":"chart-box"},
        {"name":"Speedtest Tracker","url":"speedtest.domain.com","icon":"speedometer"}
    ]
}

You can also edit the bookmarks section by editing links.json in the same way, I'm not going to get into that though. Lastly, there is a color theme option in the bottom lefthand corner, which is pretty nifty since dark themes are life.

I do wish you could give the applications a subtitle or description, as it's nice to have alternate text associated with some services. Overall, it's a simple app that works as expected and looks nice doing it. I personally like that it's no frills, and if that's what you're looking for I think SUI could be a great option for you.

Flame

GitHub - pawelmalak/flame: Flame is self-hosted startpage for your server. Easily manage your apps and bookmarks with built-in editors.

Flame is self-hosted startpage for your server. Easily manage your apps and bookmarks with built-in editors. - GitHub - pawelmalak/flame: Flame is self-hosted startpage for your server. Easily mana…

GitHubpawelmalak

Flame was inspired (heavily, in the dev's words) by SUI, so you'll see the look is very similar. The major difference, from what I see, is that Flame is SUI with a GUI. No file editing necessary, it's all done right inside Flame's GUI here, which is very easy to use. Flame easily takes the cake for "easiest configuration". It's the perfect choice for someone who wants a really great looking startpage but doesn't want to have to edit it via yaml or json file.

Install

On your Docker host just run the below command to get started.

docker run -p 5005:5005 -v /path/to/data:/app/data -e PASSWORD=flame_password pawelmalak/flame

Config

After installing, accessing the app from localhost:5005, and logging in (I changed my theme to "Mint" as well) you'll be greeted with this page.

Unlike SUI, Flame starts off empty. Clicking "Applications" brings you to the applications editor, and it's as simple as adding each service you want a link to on your homepage.

You can set all these fields up however you want. One thing I like is the icons option (using MDI like I mentioned above), it feels like a simple way to make this your own. Here's how this application would look using the "television" icon.

Add as many apps as you want in addition to Bookmarks (to idk, maybe your favorite homelab blog?) and you've got a beautiful, simple startpage for your homelab. Since this is similar to SUI I won't bore you with my final dashboard. Side note, this one has a weather widget - check it out.

Heimdall

GitHub - linuxserver/Heimdall: An Application dashboard and launcher

An Application dashboard and launcher. Contribute to linuxserver/Heimdall development by creating an account on GitHub.

GitHublinuxserver

If you've researched the best homepages anytime in the past few years, you'll see that lots of people have been using Heimdall. I've avoided it, partly because of it's popularity but also partly because the look of it isn't really my vibe. I think it's time to find out what all the hype is about.

Install

I'm going to create another directory here/home/docker/heimdall and run the following command to install Heimdall.

sudo docker run --name=heimdall -d -v /home/kodestar/docker/heimdall:/config -e PGID=1000 -e PUID=1000 -p 8080:80 -p 8443:443 linuxserver/heimdall

Going to localhost:8080 will take you to this very ominous photo of a hot air balloon getting lost forever over the ocean.

Config

There's a little button that says "Add an application here", so I'm gunna click that without reading the documentation and let Heimdall sweep me away. Clicking that link brings up this dialog.

Choosing "Application Type" allows you to pick from a gigantic list of services that are pre-built and changes the button to match that service. Here are some examples.

Again, these are templates so you can change the color, icon, text, URL, etc. if you don't like the template. If the app you're adding is classified as an "Enhanced App" it will likely have another section below called "Config" that allows you to integrate your services with Heimdall via username and password or API. Here's a good example with the Speedtest Tracker integration as it's showing the current download speed it's getting.

Probably one of my favorite things is that the services are drag-and-droppable once you add them to the dashboard. Fancy a change? Just click "Reorder and pin items" in the bottom right hand corner and you can move them around without ever having to touch a yaml file.

I changed up my background to something less busy under Settings > Appearance, and here's my final Heimdall dashboard.

I will say, I judged Heimdall too soon. The integrations are pretty extensive and it's really quite delightful to use.

Homepage

GitHub - benphelps/homepage: A highly customizable homepage (or startpage / application dashboard) with Docker and service API integrations.

A highly customizable homepage (or startpage / application dashboard) with Docker and service API integrations. - GitHub - benphelps/homepage: A highly customizable homepage (or startpage / applica…

GitHubbenphelps

From what I see, Homepage gets lots of the attention in the homelab space recently - and for good reason. Clean look, easy to configure via YAML file, and lots of integrations to make your installation shine.

Install

Setting this up is a breeze using Docker Compose...

version: "3.3"
services:
  homepage:
    image: ghcr.io/benphelps/homepage:latest
    container_name: homepage
    ports:
      - 3000:3000
    volumes:
      - /path/to/config:/app/config # Make sure your local config directory exists
      - /var/run/docker.sock:/var/run/docker.sock:ro # (optional) For docker integrations

or Docker Run.

docker run -p 3000:3000 -v /path/to/config:/app/config -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/benphelps/homepage:latest

Config

When you're done, go to localhost:3000 and you're greeted with a fresh Hompage.

Now, the extensibility of this app is what makes it really cool, and if you'd like to see the integrations/configurations they support check it out here:

Services - Homepage

Service Configuration

Homepage

Like this documentation says, we need to configure our services.yml file (located at /path/to/config/) in order to add our services and configure the page how we want.

Homepage is split into four main categories, the first two of them look familiar.

Bookmarks are exactly like you'd expect bookmarks to be, static links.

Services are the actual services you want to link to and can have properties attached to them like a description, icon, Docker integration, or ping.

Adding properties, such as ping or description, is as easy as nesting them under the service they're connected to.

- Network Services:
    - Service A:
        href: http://IPADDRESS/
        ping: http://IPADDRESS

    - Service B:
        href: http://IPADDRESS/
        description: my docker host

You can set up Information Widgets, which are the pieces of info like CPU and Disk space that show up next to the search bar at the top. The few options here are pretty cool - things like the weather, Unifi Controller stats, Kubernetes resources, or a custom logo. Look into these on your own.

You can also set up a Service Widget which is an integration (usually API) designed for that specific service.

The possibilities inside Service Widgets are really quite impressive, most common services have some kind of API integration for you to pull in lots of really helpful info right onto your homepage. I left out a ton of integrations that you can set up, the list is extensive.

Here's my "final" dashboard! I'm a big fan of the look of Homepage.

Here's my complete services.yml file. You can find all the info about setting up corresponding APIs in the link I added below my file.

- Network Services:
    - pfSense:
        icon: mdi-wall-fire
        href: http://IPADDRESS
        description: Firewall
        ping: http://IPADDRESS
    - pihole:
        icon: mdi-pi-hole
        href: http://IPADDRESS
        description: network ad blocking
        ping: http://IPADDRESS
        widget:
            type: pihole
            url: http://IPADDRESS
            key: APIKEY
    - Unifi Controller:
        icon: mdi-wifi
        href: https://IPADDRESS
        description: wifi controller
        ping: https://IPADDRESS
        container: unifi-controller
        widget:
            type: unifi
            url: https://IPADDRESS
            username: username
            password: password

- Media Services:
    - TrueNAS:
        icon: mdi-nas
        href: http://IPADDRESS
        description: NAS
        ping: http://IPADDRESS
        widget:
          type: truenas
          url: http://IPADDRESS
          username:
          password:
          key: APIKEY
    - Plex:
        icon: plex
        href: http://IPADDRESS
        description: media
        ping: https://IPADDRESS
    - Tautili:
        icon: mdi-folder-play
        href: http://IPADDRESS
        description: plex stats
        ping: http://IPADDRESS
        container: tautulli
        widget:
          type: tautulli
          url: http://IPADDRESS
          key: APIKEY

- Applications: 
    - Portainer:
        icon: mdi-docker
        href: http://IPADDRESS
        description: docker controller 
        ping: http://IPADDRESS
        container: portainer
    - Uptime Kuma:
        icon: mdi-bell
        href: http://IPADDRESS
        description: uptime monitoring
        ping: http://IPADDRESS
        container: uptime-kuma
        widget:
          type: uptimekuma
          url: http://IPADDRESS
          slug: SLUG
    - Proxmox:
        icon:  mdi-server
        href: https://IPADDRESS
        description: hypervisor
        ping: https://IPADDRESS
    - Dozzle:
        icon: mdi-database
        href: http://IPADDRESS
        description: docker logs
        ping: http://IPADDRESS

- Information:
    - Speedtest Tracker:
        icon: mdi-speedometer
        href: http://IPADDRESS
        description: speedtest
        ping: http://IPADDRESS
        container: speedtest
        widget:
            type: speedtest
            url: http://IPADDRESS   
    - Tailscale:
        icon: mdi-tailwind
        href: https://tailscale.com
        description: router connection
        ping: https://tailscale.com
        widget:
            type: tailscale
            deviceid: DEVICEID
            key: APIKEY

Service Widgets - Homepage

Service Widget Configuration

Homepage

I couldn't get the Portainer widget working, but I'm guessing it's something on my end. Homepage is a special one. I think the devs did a fantastic job adding integrations to really make Homepage stand out from competitors.

Homer

GitHub - bastienwirtz/homer: A very simple static homepage for your server.

A very simple static homepage for your server. Contribute to bastienwirtz/homer development by creating an account on GitHub.

GitHubbastienwirtz

Homer is a nice option for hosting a server homepage. It's somewhere in the middle of simple and complex to setup, with a simple and kind of cartoon-ish look and feel overall.

Install

Using Docker Compose...

version: "2"
services:
  homer:
    image: b4bz/homer
    #To build from source, comment previous line and uncomment below
    #build: .
    container_name: homer
    volumes:
      - /your/local/assets/:/www/assets
    ports:
      - 8080:8080
    user: 1000:1000 # default
    environment:
      - INIT_ASSETS=1 # default

or Docker run you can get started quickly.

docker run -d \
  -p 8080:8080 \
  -v </your/local/assets/>:/www/assets \
  --restart=always \
  b4bz/homer:latest

Config

Homer will then be accessible from localhost:8080.

Homer is customizable via editing the assets/config.yml file. Here's a snippet of what we'd need to edit to customize our homepage. Similar to Homepage above, you can group services into categories based on their function.

  - name: "Group 1"
    icon: "fas fa-code-branch"
    items:
      - name: "Application 1"
        logo: "assets/tools/sample.png"
        subtitle: "Bookmark example"
        tag: "app"
        keywords: "self hosted reddit"
        url: "https://www.reddit.com/r/selfhosted/"
        target: "_blank" # optional html tag target attribute
        
      - name: "Application 2"
        logo: "assets/tools/sample2.png"
        subtitle: "Another application"
        tag: "app"
        tagstyle: "is-success"
        url: "#"

You'll need to go through and add services (including any custom services), change names, links, etc. in addition to any icons you'd like to use. Here's the final look of my page.

If you want a starting point, here's the "services" section of my configuration file.

services:
  - name: "Network Services"
    icon: "fas fa-code-branch"
    items:
      - name: "pfsense"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/pfsense.png?raw=true"
        subtitle: "firewall"
        tag: "app"
        url: "https://IPADDRESS"
      - name: "Pi-hole"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/pihole.png?raw=true"
        subtitle: "local DNS"
        url: "http://IPADDRESS"
      - name: "NGINX Proxy Manager"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/nginxproxymanager.png?raw=true"
        subtitle: "reverse proxy"
        url: "http://IPADDRESS"
      - name: "Uptime Kuma"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/uptimekuma.png?raw=true"
        subtitle: "system uptime"
        url: "http://IPADDRESS"
      - name: "Speedtest Tracker"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/windows98.png?raw=true"
        subtitle: "internet speedtest"
        url: "http://IPADDRESS"
  - name: "Media Services"
    icon: "fas fa-database"
    items:
      - name: "TrueNAS"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/truenas.png?raw=true"
        subtitle: "NAS"
        url: "https://IPADDRESS"
      - name: "Plex"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/plex.png?raw=true"
        subtitle: "movies and tv"
        url: "https://plex.tv"
      - name: "Tautulli"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/tautulli.png?raw=true"
        subtitle: "plex stats"
        url: "http://IPADDRESS"
  - name: "Applications"
    icon: "fas fa-tablet-screen-button"
    items:
      - name: "Proxmox"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/proxmox.png?raw=true"
        subtitle: "hypervisor"
        tag: "other"
        url: "http://IPADDRESS"
      - name: "Portainer"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/portainer.png?raw=true"
        subtitle: "docker management"
        tag: "other"
        url: "http://IPADDRESS"
      - name: "Unifi Controller"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/unifi.png?raw=true"
        subtitle: "wifi controller"
        tag: "other"
        url: "http://IPADDRESS"
      - name: "Dozzle"
        logo: "https://github.com/NX211/homer-icons/blob/master/png/dozzle.png?raw=true"
        subtitle: "docker logs"
        tag: "other"
        url: "http://IPADDRESS"

Homer also has widgets you can set up, check out their documentation. I like that you can use icons and images next to your services and links to make Homer unique, in addition to picking your own hex colors to change the theme however you want.

Dashy

GitHub - Lissy93/dashy: 🚀 A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!

🚀 A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more! - GitHub - Lissy93/dashy: 🚀 A self-hostable personal dashboard…

GitHubLissy93

Dashy is the most unique option I'll be going over today - the style it's designed with is noticeably different than the rest.

Install

Dashy has a lot of install options, I recommend you read through their deployment page.

dashy/docs/deployment.md at master · Lissy93/dashy

🚀 A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more! - Lissy93/dashy

GitHubLissy93

If you want to go the Docker Compose route like me, here you go,

version: "3.8"
services:
  dashy:
    # To build from source, replace 'image: lissy93/dashy' with 'build: .'
    # build: .
    image: lissy93/dashy
    container_name: Dashy
    # Pass in your config file below, by specifying the path on your host machine
    volumes:
      - /home/docker/dashy/my-config.yml:/app/public/conf.yml
    ports:
      - 4000:80
    # Set any environmental variables
    environment:
      - NODE_ENV=production
    # Specify your user ID and group ID. You can find this by running `id -u` and `id -g`
    #  - UID=1000
    #  - GID=1000
    # Specify restart policy
    restart: unless-stopped
    # Configure healthchecks
    healthcheck:
      test: ['CMD', 'node', '/app/services/healthcheck']
      interval: 1m30s
      timeout: 10s
      retries: 3
      start_period: 40s

Note: I premade a config file just so I knew where it was, you don't have to do this.

Config

Dashy is accessible via localhost:8080.

I'll just say this, Dashy is powerful. I highly recommend you read the configuration guide below to get more infor about the 3 ways to configure Dashy.

dashy/docs/configuring.md at master · Lissy93/dashy

🚀 A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more! - Lissy93/dashy

GitHubLissy93

The three options to configure it are:

1. Directly in the YAML file (5/5 reliability, 3/5 usability)
2. UI JSON Editor (4/5 reliability, 4/5 usability)
3. UI Visual Editor (3/5 reliability, 5/5 usability)

I'm going to be setting mine up directly through the YAML file since that's what I'm most comfortable with, but you're welcome to do it however you see fit. I could spend a lot of time talking about all the cool ways to configure Dashy. There are some really creative general widgets (like weather, sports scores, crypto prices, flight trackers, etc.) and even more if you've got some services self-hosted.

From what I can tell, Dashy becomes really powerful once you use it with Glances.

Glances - An Eye on your system

Glances is a cross-platform curses-based system monitoring tool written in Python.

An Eye on your systemNicolas Hennion, Alessio Sergi, and Glances contributors

This is something I'm not currently hosting, but it's the way to display tons of graphs and visual data about your system. If you're interested in running Dashy and would like to use it to it's full potential, I recommend getting Glances as well.

One of my favorite parts of Dashy is the theme options, knock yourself out.

Here's what I ultimately came up with.

Go birds.

---
# Page meta info, like heading, footer text and nav links
pageInfo:
  title: Road to Homelab Dashboard
  description: look at the money you've wasted

# Optional app settings and configuration
appConfig:
  statusCheck: false
  theme: charry-blossom
  fontAwesomeKey: c94dc2b452
  customCss: '.clock p.time { font-size: 3rem !important; }'
  layout: vertical
  iconSize: small

# Main content - An array of sections, each containing an array of items
sections:
- name: Today
  icon: 
  displayData:
    collapsed: false
    hideForGuests: false
  widgets:
  - type: clock
  - type: weather
    options:
      apiKey: efdbade728b37086877a5e83442004db
      city: Indianapolis
      units: imperial
  - type: sports-scores
    options:
      teamId: 134936
      pastOrFuture: future
      limit: 1

- name: My Network
  icon: mdi-web
  displayData:
    collapsed: false
    hideForGuests: false
  widgets:
  - type: public-ip
  - type: pi-hole-stats
    options:
      hostname: http://IPADDRESS
      apiKey: APIKEY
      useProxy: true

- name: Dev & Cloud
  icon: far fa-code
  items:
  - title: Linode
    icon: favicon
    url: https://linode.com
  - title: DigitalOcean
    icon: favicon
    url: https://cloud.digitalocean.com/
  - title: GitHub
    icon: favicon
    url: https://github.com/
  - title: StackOverflow
    icon: favicon
    url: http://stackoverflow.com/
  - title: CloudFlare
    icon: favicon
    url: https://dash.cloudflare.com/
    statusCheckAcceptCodes: '403'
  - title: Blog
    icon: favicon
    url: https://roadtohomelab.blog
  - title: Documentation
    subItems:
    - title: JavaScript
      url: https://developer.mozilla.org
      icon: si-javascript
      color: '#F7DF1E'
    - title: TypeScript
      url: https://www.typescriptlang.org/docs
      icon: si-typescript
      color: '#3178C6'
    - title: Svelt
      url: https://svelte.dev/docs
      icon: si-svelte
      color: '#FF3E00'
    - title: Go
      url: https://go.dev/doc
      icon: si-go
      color: '#00ADD8'
    - title: Rust
      url: https://doc.rust-lang.org/reference
      icon: si-rust
      color: '#000000'
    - title: Docker
      url: https://docs.docker.com/
      icon: si-docker
      color: '#2496ED'

- name: Network Services
  icon: mdi-network
  items:
  - title: pfsense
    description: firewall
    icon: mdi-wall-fire
    url: http://IPADDRESS
  - title: pi-hole
    description: local DNS
    icon: mdi-pi-hole
    url: http://IPADDRESS
  - title: Speedtest Tracker
    description: internet speedtest
    icon: mdi-speedometer
    url: http://IPADDRESS
  - title: Unifi Controller
    description: wifi controller
    icon: mdi-wifi
    url: http://IPADDRESS

- name: Media
  icon: mdi-folder-multiple-image
  items:
  - title: TrueNas
    description: NAS
    icon: mdi-nas
    url: http://IPADDRESS
  - title: plex
    description: media
    icon: mdi-plex
    url: https://plex.tv
  - title: Tautulli
    description: plex stats
    icon: mdi-folder-play
    url: http://IPADDRESS

- name: Applications
  icon: mdi-application
  items:
  - title: Portainer
    description: docker management
    icon: mdi-docker
    url: http://IPADDRESS
  - title: Uptime Kuma
    description: system monitoring
    icon: mdi-bell
    url: https://IPADDRESS
  - title: Proxmox
    description: hypervisor
    icon: mdi-server
    url: https://IPADDRESS
  - title: Dozzle
    description: docker logs
    icon: mdi-database
    url: https://IPADDRESS

The bells and whistles abound on this one.

Homarr

Home | Homarr Docs

Simplify the management of your server with Homarr - a sleek, modern dashboard that puts all of your apps and services at your fingertips. With Homarr, you can access and control everything in one convenient location. Homarr seamlessly integrates with the apps you’ve added, providing you with valuab…

Homarr

Homarr is a sleek option for those who don't want to mess with yaml. It's mostly drag and drop, with some widget options that really bring it up a level.

Install

You can use Docker run (like me) or Docker compose. If you use the below command, just make sure to update the two -v flags to be the path to your resources.

docker run  \                                                                         --name homarr \
  --restart unless-stopped \
  -p 7575:7575 \
  -v /home/docker/homarr/configs:/app/data/configs \
  -v /home/docker/homarr/icons:/app/public/icons \
  -d ghcr.io/ajnart/homarr:latest

Homarr is accessible via localhost:7575.

Config

After install you're met with this page.

By clicking the little edit button in the top righthand corner you are able to drag the icons around. All I can say is this GUI is slick. First thing to note is the settings menu under the hamburger icon at the top right. Under settings you can:

• enable ping on services
• change the number of columns displayed when the screen is different sizes
• change accessibility options
• change the color scheme and appearance of Homarr

When you're ready to add apps and bookmarks just click the "enter edit mode" button in the top right and then "add a tile". You'll be presented with this popup.

If you start typing the name of your app, for instance, "Plex", Homarr will automatically go grab the icon for you, which is excellent design. Then you fill out the address that the button should take you to (i.e. the IP of your app).

"Behavior" let's you choose if the link opens in a new tab or the same page.

"Network" allows you to customize the status checker feature of Homarr.

"Appearance" let's you to pick or change the icon associated with that link in addition to some other display options.

"Integration" gives you some options to use API keys to further integrate your services into Homarr. There isn't a huge list, but the one's I've played with so look great. Here's an example of a Pi-Hole integration.

One thing that Homarr is missing is that there isn't a way, that I see, to drag or resize your Categories. That means a Category will take up an entire row of space, no matter how many services are in there. This is a little annoying since I really like to play around with the look of my dashboard until it's just right.

Here's what I came up with.

The options for a markdown notebook, iframe, and weather/calendar widgets is fantastic and welcomed. Good stuff Homarr.

Thanks for reading.

Did I miss any?

I could only dive in to some of the configurations for these platforms, if you're interested in more of what they can do I recommend you read the documentation and support the developers.

If you're interested in having your internal DNS point a custom domain to your new homepage, I wrote a blog just for you.

Local DNS for Docker Containers using Pi-hole + Portainer + Nginx Proxy Manager

Like most people running Docker, I gathered quite a few containers running on my very professional Ubuntu server (it’s an 8 year old Lenovo laptop sitting in my garage). Because of this, I started to have a problem. New containers I deploy want to use ports that I already have

Road to HomelabDustin Groh

I really love monitoring my homelab with Uptime Kuma.

But, the worrier in me has started to wonder "what would happen if the server I have Uptime Kuma running on died?" I would have no way of knowing the status of it, or of any of my services!

Can you imagine?

So, I sought out to solve this problem, and this blog will explain how you can do the same. There are a few ways of achieving this, probably other better ones, I understand. But I'll be showing you the one I came up with. My criteria for this project are as follows:

1. Monitor the uptime of my homelab on something that is not my hardware.
2. Spend as little money as possible.
3. Use cool tech.
4. Keep my homelab safe.

To check off #1 and #2, I chose to utilize the cheapest tier of VPS from Linode which is $5/month (I'm not sponsored by Linode - but I'd like to be).

Assumptions

I'm assuming a few things about you, and your homelab if you're following along here. First, that you can generally get around Linux, Docker, and the like. If so, you should be fine because I barely can. Next, that you have pfsense (or some other firewall/router that can run Tailscale and expose routes). Lastly, that you can set up a Linode account, and spare $5 a month.

^that's one coffee.... figure it out

Disclaimer

Set up a Linode account

Okay after all that preamble, let's jump in.

I'm setting up my itty bitty server in Chicago since I'm in the Midwest, and installing Ubuntu on it since that's what I prefer - you can pick any region or Linux distro you want, be aware that could impact the effectiveness of these instructions.

Once the box has been created, I recommend you create an SSH key to add a layer of security and remove the annoyance of authenticating every time you SSH in. Once complete, we're ready to start installing stuff.

I've redacted some info, but you'll be presented with this page once it completes provisioning the server. And frankly, this is really cool. The fact that you now have a dashboard for the cloud-hosted VPS that built to your specs in under a minute is wild.

Using the command below and the root password you set up, to connect to your box.

ssh root@ipaddress

Install Tailscale on pfsense

There is a simple process outlined in the below link on how to install Tailscale on pfsense. Take note, for this process you will need to setup Tailscale as an exit node, which turns Tailscale into a Full-Tunnel VPN. You'll also need to make sure to follow the instructions on adding your local subnet as an "advertised route".

I ran into an issue initially because my appliance was out of date, just something to note.

How to Set Up Tailscale on pfSense in 2023 - WunderTech

This tutorial looks at how to set up Tailscale on pfSense! Tailscale is a no-configuration VPN that doesn’t require port forwarding! Quick setup!

WunderTechWunderTech

Once complete, do the following:

1. Ensure your router shows up in your Tailscale account as connected.

2. Under the three dots next to your router -> "Edit Route Settings" you'll need to turn on both options.

If that is all true and good, you're ready to move on.

Install Docker, Tailscale, and Uptime Kuma on Ubuntu

There's frankly lots of work you can do to secure this Linux box to the outside world, I'm not going to get into it in this post - but I highly recommend you do some research on how to lock it down since it will be public facing.

We'll be using Docker Compose, but you can do whatever you want with your life.

Docker

Using this guide on the Docker site, set up the Docker repo. Then, go ahead and install Docker Engine, containerd, and Docker Compose.

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Confirm Docker is indeed working.

sudo docker run hello-world

Tailscale

Great, now we have an Ubuntu server running on a Linode that is running Docker. But, how are we going to get this server to see our home network? As of right now it's just a box floating out there in the void of the Internet, we can change that with Tailscale! The great thing about Tailscale is it's based on Wireguard and requires no port forwarding on your router.

So let's install Tailscale on the Linux box. I'm taking these directions right from the official Tailscale site below.

Setting up Tailscale on Ubuntu 22.04 (jammy)

Packages are available for x86 and ARM CPUs, in both 32-bit and 64-bit variants.

TailscaleTailscale

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list

sudo apt-get update
sudo apt-get install tailscale

sudo tailscale up

This will prompt you with a link, and you'll need to click it and authenticate your new Tailscale node into your account.

Next, do the following command to make sure your Linux box sees your Tailnet.

tailscale status

You should see your pfsense box (and any other devices on your Tailnet), and next to it you should see that it's offering routes + is an exit node.

For example in the photo below, the red is the names of my Tailscale devices, blue is the OS/IP of those machines, and the orange is the public IP of my router.

You could also check the admin console of Tailscale to confirm the VPS is represented there as well.

Well, it's looking pretty good. Next, let's ping something on our local network to see if our Linode box can actually see it.

ping IPADDRESS

If you get a response, like me, that's a good thing.

Uptime Kuma

Let's install Uptime Kuma now. I'm taking these instructions right from the Github page here https://github.com/louislam/uptime-kuma/wiki/🔧-How-to-Install which I'd recommend you read, since there are tons of ways to install this. I'll be doing it the simple way, with via CLI.

curl -Lo kuma_install.sh https://git.kuma.pet/install.sh && sudo bash kuma_install.sh

After running through the simple CLI commands our Uptime Kuma instance is accessible through

IP_OF_VPS:3001

Now, go to your Uptime Kuma instance and try adding a new monitor for a local device. Below I added my TrueNAS server with it's local IP - Uptime Kuma says it's up.

I tried one last thing to really be sure the connection over Tailscale is working right. Once I let the above monitor run for a bit I killed Tailscale on my VPS with the command below:

tailscale down

Instantly Uptime Kuma showed this device as down! Task failed successfully?

The only thing left to do is to set up Uptime Kuma's notifications for when a device goes down. I'll let you run with that on your own.

Probably one of the easiest ways to cut this guide a little bit short would be to just set up this Linode instance of Uptime Kuma we're about to set up to monitor another instance of Uptime Kuma on your local network... that way if your local one goes down you'll be notified. You're totally welcome to do it that way, or you can monitor your whole homelab from the cloud.

Thanks for reading.

If you're anything like me, you love simply structured, beautiful, easy to consume content. This is why I love Markdown (and my fav editor, Typora) and Apple marketing.

This has felt like the main barrier for me starting a blog since I never felt like the heavy-hitters in the blog space, like Wordpress, really had the look I was going for. They were too busy, too unpolished, too complicated. I felt like it took away from the writing.

Then, I found Ghost.

Ghost is about a lot more than just blogging, and it's designed for the current landscape of content writers, creators, and consumers. You can pay them a small fee per month to use a Ghost-hosted (Ghosted, if you will) blog, or you can host it yourself for free.** All of their branding content is very thoughtful, the designs are clean, the editor is world-class, plus they have a really excellent community of creators.

I'm not sponsored by Ghost but I love them, truly. Please for the love of God Ghost, sponsor me, I'm begging you.

**Obviously it's not free, but Ghost doesn't charge you if you self-host. You'll still have to pay one way or another for the resources to run the blog, whether on your hardware or not.

Background

I understand there are plenty of tutorials showing how to do this, but I wanted to detail how I host my blog, in case you're interested.

Now, self-hosting isn't for everyone, and if you read this article and think "nah", no shame. I still recommend Ghost.

Don't be scared, we aren't really self-hosting like the people at r/selfhosted are. We won't be hosting this on our own physical hardware. We're going to be using a DigitalOcean droplet to house our shiny blog. Also, I'm assuming that if you're reading this you're at least interested in the world of tech, servers, and blinking lights. If you have an interest + any experience at all, I think you can make it through this.

Ghost has a simple tutorial if you'd like to just install Ghost on Ubuntu yourself, to play with (or run it in production) https://ghost.org/docs/install/ubuntu/. But, there are inherent risks with hosting a website intended for public consumption on your local setup. That's why we'll be doing this a different way.

Why DigitalOcean?

In previous projects I've use Linode for my VPS, which I really enjoy. But I don't discriminate when it comes to hosting providers. In fact, the reason why I'm using a different provider is bigger than my normal "idk cuz I feel like it". DigitalOcean's apps marketplace has a Ghost one-click option, which makes the setup of this wonderful blog platform very simple.

So first, create a DigitalOcean account if you don't have one already. You'll then be asked to create your first project. Don't over think it, just call it something related to Ghost.

Next, we need to create a droplet. Also known as a VPS (Virtual Private Server). Basically, a little VM that DigitalOcean hosts for us, installs our OS of choice on, and gives us the access to make changes to.

Chose your region, but instead of choosing an OS like usual we're going to go to the Marketplace and choose Ghost. This will install Ubuntu 22.04 and Ghost on your droplet. The DigitalOcean Marketplace is full of one-click apps and services that you can deploy really easily. I picked the $6/month machine. Here's what my deployment page looks like before I create the droplet.

Set a root password or SSH key, change the hostname at the bottom (if you want) and click "create droplet".

Now that it's done, let's access the shell of our droplet to make some changes. You can do this by ssh-ing into the IP provided on the dashboard, or you can click the ellipses on the right -> "access console", which gives you a web console.

Once you're all done with that, head over to the console of your droplet, and you'll eventually be shown this:

Whoops, we didn't set up our domain yet! We'll come back to Ghost in a minute.

Domain Name Set Up

Since this is going to be a blog, you'll need a domain name. You can do this through many different platforms like Name, Namecheap, etc. Go find a domain you want, or use one you already have.

The basics of what we'll be doing is simple, and applies to pretty much any site you'll ever host. You're going to need to:

1. make an A record which directs your domain name, verycoolblog.com, to the IP of the droplet you just created, hosting your very cool blog.
2. make a CNAME record which re-directs traffic pointed at www.verycoolblog.com over to your actual domain name which is verycoolblog.com.

Here's are my DNS records for this blog, which you can match other than the IP of your droplet IP.

DNS takes some time to propagate, so if this doesn't work instantly don't stress it, we can continue the config by accessing Ghost directly via IP.

Back to the console.

Ghost Config

Now, go ahead and click Enter on the console to jump into the config. It'll download and install Ghost, so you'll need to wait a little bit.

You'll then be asked for your "blog URL", which will be the domain we set up earlier. The process will then set up SSL, and ask you for an email to associate with it. Finally, it'll start up Ghost.

If everything goes smoothly you should be able to go to http://domain/ghost in a web browser and get to a Ghost setup page.

If things did not go smoothly, that's okay too. Go to http://dropletIP/ghost to get around the domain thing for now, I've got some troubleshooting steps at the end of this post. We'll get you sorted.

At this stage, you're ready to login and configure your Ghost instance. That wasn't too bad! Have fun playing around with your new blog.

Thanks for reading, if I missed anything please let me know!

Troubleshooting

I ran into an issue that I thought others might run into as well. When Ghost installs via the CLI one of two things can happen here, either:

1. no errors on the CLI
2. something broke and you see something like this:

In my case, this was because I had typed the Ghost URL incorrectly. I fixed this with these commands:

sudo -i -u ghost-mgr

cd var/www/ghost

ghost config url http://domain

Here's a solid blog that gives some troubleshooting steps for getting Ghost started.

How to update the URL of your self-hosted Ghost site

Five quick steps to change your Ghost site’s URL.

Gloat · Start a paid publicationDan Rowden

Like most people running Docker, I gathered quite a few containers running on my very professional Ubuntu server (it's an 8 year old Lenovo laptop sitting in my garage).

Because of this, I started to have a problem.

New containers I deploy want to use ports that I already have allocated on my host machine. This begged the question, how can I run multiple containers on one host that require the use of the same ports?

Well, enter Nginx Proxy Manager (NPM).

It’s a reverse proxy that has a clean UI, is easy to use, and runs in a container. The reverse proxy will help us by being the recipient service of our requests, and will forward them to the right container depending on the subdomain name entered. For example, instead of typing in portainerIP:port to get to your Unifi Controller you could type unifi.domain.com which would forward your request to the Unifi Controller container. Moreover, this means you could run another container on the same Docker host that requires the same port, but because you'll be proxying requests to through NPM it’ll work just the same!

Ways to use NPM

Now, there are other great tutorials out there to use Nginx Proxy Manager to safely get your services exposed to the outside world using port forwarding at your router however, I’m not interested in getting access to these services outside of my home network that right now. So, for my example, I’ll be using pihole for my local DNS.

Pi-hole

This guide assumes you have pihole set up as your DNS server and Docker + Portainer installed already.

A Records

First step is to come up with a list of A records for pihole to know where to send traffic when a subdomain is queried. Since this is exclusively local traffic and we’re not worried about SSL/TLS (if you are, watch this video) you can pick any domain name you want.

For this guide I’ll be using the Unifi Controller container as our example. Here’s an example of the kind of A record we need:

portainer.domain.com → 10.x.x.x

^IP address of Docker host that will run NPM

CNAME Records

Next, we’re going to make list of our services (containers, in this case) that we’d like to point to the A record we just made. Here’s an example:

unifi.domain.com → portainer.domain.com

Cool! Once all your services are all in pihole, we’re good to head over to Docker, install Nginx Proxy Manager, and get logged in. I’m not going to go into detail about the Nginx install process, other people have done a better job of that :

How to setup the Nginx Proxy Manager Docker example

Learn how to setup and install the Nginx Proxy Manager from Docker Hub. This simple tool greatly simplifies the configuration of Nginx reverse proxy servers, asset caching, host redirecting and SSL…

TheServerSide.comCameron McKenzie

Docker + Portainer

Once you have Nginx Proxy Manager installed you’ll need to do a few important steps.

Let’s think about this logically - we made some changes on pihole, but what exactly is the impact of the changes we made?

• Right now you can still access your containers via the host machine IP + port for the container.
• Using a subdomain + domain like unifi.domain.com doesn’t get us to the Unifi Controller container, but if our DNS is working right it should be pointing us to the host machine for the service.

This means not only is Nginx not proxying the requests to those services, but the DNS entries we added aren’t really working. You’re probably wondering “does this guy even know what he’s doing?”

And don’t worry, the answer is kind of.

Container config

How do we make it so that we can only get to those services via Nginx?

First, we need to take note of and remove the port designations on the containers we’re working with (it’s a good idea to save these in case you need to roll back) so that they aren’t accessible directly.

Next, let’s make sure the containers we’re working with are on the same Portainer network as Nginx.

That should be it! Let’s head over to NPM.

Nginx Proxy Manager

In Proxy Hosts, add a Proxy Host. This is where we tell Nginx which container to send traffic to depending on the DNS name entered. In a correctly configured state it should send unifi.domain.com traffic to the Unifi Controller container (duh) and uptimekuma.domain.com traffic to the Uptime Kuma container (duh again).

We want to create a record for unifi.domain.com that forwards the traffic to the port that Unifi Controller requires to get to the webpage, in the case of the Unifi Controller it’s port 3000, like the screenshot below. We also can specify just the container name in the “hostname” section.

That should do it. Now try unifi.domain.com!

Pretty slick. Let me know if you have any questions, issues, or ways to make this better!