> ## Content Index
> Fetch the complete content index at: https://adhdhomelab.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How Tailscale Solved My Homelab's Network Problems
- URL: https://adhdhomelab.com/tailscale-homelab-guide/
- Published: 2026-02-12T15:49:39.000Z
- Updated: 2026-08-31T00:36:28.000Z
- Description: My homelab technically worked - until reality showed up. Tailscale solved remote access, DNS hell, and subnet routing without port forwarding or certificate anxiety. Here are the 7 features that finally made my network calm.
- Author: AJ Tatum
- Tags: Networking, Tailscale, VPN, Mesh VPN, Homelab, Docker

**Updated August 2026:** This article has been refreshed to reflect how I'm using Tailscale in my homelab today, including updated Docker guidance with TSDProxy, newer approaches to exposing services securely, and a few lessons learned after living with this setup for a while. The core idea hasn't changed: Tailscale is still one of the easiest ways I've found to make a homelab feel simpler, safer, and significantly less annoying to maintain.

For years, my homelab technically worked.

That's the most dangerous sentence in home networking.

It worked as long as my public IP didn't change, certificates didn't expire, ports stayed exactly the way I remembered them, and nothing went wrong while I wasn't home. In other words, it worked until reality showed up.

Tailscale didn't just make my network more secure - it made it calmer.

Here are the seven specific ways it finally solved the problems that kept turning my homelab into a background anxiety generator.

---

![](https://adhdhomelab.com/content/images/2026/08/tailscale.webp)

## First, What Tailscale Actually Is (Briefly)

Tailscale is a WireGuard-based mesh VPN, but what matters is how it behaves:

- Devices authenticate as you, not as IP addresses
- Traffic is encrypted end-to-end
- Devices connect directly when possible
- No inbound ports are required
- Access is controlled by identity and intent

There's no VPN server you babysit. No port-forwarding rituals. No "important box" waiting to ruin your weekend.

Your devices just know how to find each other.

---

## 1\. Exit Nodes: One Internet, Everywhere

**The problem:** Every network behaves differently. Debugging from "the wrong place" lies to you.

**What Tailscale fixed:** Exit nodes let me route all my traffic through a trusted network - usually my home - no matter where I am.

**Real-world example:** You're at a hotel troubleshooting why your Home Assistant automations aren't firing. On hotel Wi-Fi, you can't reach your local network, geo-restrictions block your streaming services, and DNS behaves unpredictably. Enable your home exit node, and suddenly everything works exactly like you're sitting on your couch. Same network context, same DNS, same access - every time.

That means:

- Hotel Wi-Fi behaves like my home network
- Geo-restricted services stay consistent
- Troubleshooting happens from the same context every time

This alone removed an entire category of "works at home but not elsewhere" confusion.

Right now, I have two exit nodes available to me:

**OPNsense** \- Advertises routes across all my VLANs, allowing me to communicate with devices across the network:

```bash
sudo tailscale up --accept-dns=false \
  --advertise-routes=192.168.175.0/24,192.168.185.0/24,192.168.195.0/24,192.168.155.0/24,192.168.145.0/24 \
  --advertise-exit-node \
  --advertise-tags=tag:router
```

**AdGuard Home** \- Uses itself as a DNS server, providing network-wide ad blocking wherever I am:

```bash
sudo tailscale up --accept-dns=false --advertise-exit-node
```

I typically use the AdGuard Home exit node on my phone and tablet for ad-free browsing anywhere.

> **🧠 ADHD Brain Note:** If the environment keeps changing, your conclusions will always be wrong.

## Sign up for ADHD Homelab

Every week (or so - we're not robots), I share practical setups, automations, and the occasional 3 AM discovery from the ADHD Homelab & Smart Home.

Subscribe 

Email sent! Check your inbox to complete your signup. 

No spam. Unsubscribe anytime.

---

## 2\. Subnet Routing: One Device, Full Network Access

**The problem:** Not everything can run Tailscale. Printers, IoT devices, switches, and appliances don't care about your VPN strategy.

**What Tailscale fixed:** Subnet routing lets one Tailscale-enabled device represent an entire LAN or VLAN.

**Real-world example:** Your Zigbee coordinator and smart switches live on a 192.168.155.0/24 IoT VLAN. None of them can run Tailscale. But your OPNsense router can. Configure it as a subnet router advertising that VLAN, and now you can access your Home Assistant dashboard remotely - which in turn controls all those IoT devices - without flattening your network security.

This allows me to:

- Access local-only services remotely
- Keep VLAN segmentation intact
- Avoid flattening my network just for convenience

One device speaks for many. Clean. Explicit. Reversible.

---

## 3\. MagicDNS: I Stopped Remembering IP Addresses

**The problem:** IP addresses change. My memory does not keep up.

**What Tailscale fixed:** MagicDNS gives every device a stable, human-readable hostname:

- `nas.tailnet.ts.net`
- `proxmox.tailnet.ts.net`
- `homeassistant.tailnet.ts.net`

**Real-world example:** Your Proxmox server used to be at 192.168.185.10\. Then you reorganized VLANs and it became 192.168.195.10\. With MagicDNS, you just SSH to `proxmox` or browse to `https://proxmox.tailnet.ts.net:8006` every time. The IP address underneath can change - you never notice.

No split DNS. No `/etc/hosts` archaeology. No guessing whether it was .42 or .24.

> **🧠 ADHD Brain Note:** If you're memorizing IPs, the system already failed.

---

## 4\. Tailscale DNS: Split Tunneling That Actually Makes Sense

**The problem:** You want local devices to resolve your internal domain names, but you don't want to use your ISP's questionable DNS for everything else.

**What Tailscale fixed:** Tailscale DNS supports split DNS configurations, letting you route specific domains to specific nameservers while using different resolvers for everything else.

**Real-world example:** All your homelab services use the `marvel.lan` domain. Your Proxmox host is `ironman.marvel.lan`, your NAS is `thor.marvel.lan`, and Home Assistant is `jarvis.marvel.lan`. These names only exist on your local network at 192.168.185.1 (your primary DNS server).

With Tailscale DNS configured for split tunneling:

- Queries for `*.marvel.lan` → Routed to 192.168.185.1 (and your other VLAN DNS servers)
- Everything else → Routed to Quad9 (9.9.9.9) for privacy and security

You can configure this in the Tailscale admin console under DNS settings:

**Nameservers:**

- Global nameservers: `9.9.9.9` (Quad9)
- Restricted nameservers:
  - `192.168.185.1` for `marvel.lan`
  - `192.168.155.1` for `iot.lan` (if you have an IoT-specific domain)

**Alternative DNS services you can use:**

- **NextDNS** \- Privacy-focused with customizable filtering
- **Mullvad DNS** \- Privacy-first, no logging
- **Cloudflare** (1.1.1.1) - Fast and reliable
- **Quad9** (9.9.9.9) - Security and privacy focused

Now when you're on your phone at a coffee shop and visit `https://jarvis.marvel.lan`, Tailscale knows to ask your home DNS server. But when you visit `google.com`, it uses Quad9 - keeping your browsing private and fast.

This means:

- Local names work everywhere without configuration
- Public DNS queries don't leak to your homelab
- You can use privacy-respecting resolvers without breaking local services
- Different VLANs can have different DNS servers, all working simultaneously

> **🧠 ADHD Brain Note:** The best DNS configuration is the one you set up once and never think about again.

---

## 5\. Tailscale SSH: Access Based on Identity, Not Keys

**The problem:** SSH keys multiply. Ports get opened "temporarily." Cleanup never happens.

**What Tailscale fixed:** Tailscale SSH ties access to identity and ACLs, not keys or IP addresses.

**Real-world example:** You're helping a friend debug their Proxmox setup. Traditionally, you'd open port 22 to the internet (risky), or have them copy your SSH key (tedious), or walk them through creating a Tailscale account and adding you (friction). With Tailscale SSH, you grant their Tailscale identity temporary access via an ACL. They connect. You help. You revoke access. No keys exchanged, no ports exposed, no cleanup forgotten.

That means:

- No exposed port 22
- No SSH key sprawl
- Instant access revocation
- Clear, centralized rules

I don't SSH to a server anymore - I SSH as myself.

That mental shift removed a lot of quiet stress.

**Locking it down with UFW:** Even better, you can ensure SSH is only accessible through Tailscale by restricting it to the `tailscale0` interface:

```bash
# Allow SSH only through Tailscale interface
sudo ufw allow in on tailscale0 to any port 22

# Deny SSH from all other interfaces
sudo ufw deny 22

# Enable UFW if not already enabled
sudo ufw enable
```

Now SSH only works through your Tailscale network - even if someone discovers your public IP, port 22 is completely unreachable from the internet.

> **🧠 ADHD Brain Note:** Security that requires memory is not secure. Security that requires systems is survivable.

---

## 6\. Tailscale Serve: Private Services Without Public Exposure

**The problem:** I want remote access to services - but I don't want them on the public internet.

**What Tailscale fixed:** Tailscale Serve lets me expose services inside my tailnet, securely, without opening ports or managing certificates.

**Real-world example:** You run Navidrome for your personal music library. You want to stream music on your phone during your commute. With traditional setups, you'd expose it publicly (inviting bots and attacks), configure Let's Encrypt certificates (ongoing maintenance), and hope your dynamic DNS stays updated. With Tailscale Serve, you run one command, and Navidrome is available at `https://navidrome.tailnet.ts.net` \- but only to devices on your tailnet.

I can access my music library from anywhere:

- Over HTTPS
- On a private address
- Without worrying about bots or password guessing

The service exists. It's reachable. But only by devices I explicitly trust.

---

## 7\. Tailscale Funnel: Public When I Mean It

**The problem:** Sometimes you do need public access - but only temporarily.

**What Tailscale fixed:** Funnel allows explicit, controlled public exposure of a service through Tailscale's infrastructure.

**Real-world example:** You built a webhook receiver for GitHub Actions that triggers deploys to your homelab. You need it publicly accessible, but only while you're actively using it. Enable Funnel, GitHub can reach your service, complete the deploy, disable Funnel. No firewall rules to remember, no ports permanently exposed, no certificate renewal anxiety.

That means:

- No inbound firewall rules
- TLS handled automatically
- Easy to enable and disable

Perfect for demos, webhooks, or short-lived access - without committing architectural sins.

---

## Bonus: Cloud Servers That Actually Feel Local

Because Tailscale is a mesh, my servers on Vultr or DigitalOcean behave like they're on my home network.

**Real-world example:** You run Uptime Kuma on a VPS to monitor your homelab from outside your network. Traditionally, you'd expose your services publicly just so your monitoring can reach them. With Tailscale, your VPS joins your tailnet, reaches everything privately, and reports status - all without a single inbound port on your home network.

That means:

- Private communication between cloud and home
- No public service exposure
- No site-to-site VPN complexity
- One consistent network model

Cloud and home stop being "two worlds." They're just nodes.

---

![Tailscale for Homelabs](https://adhdhomelab.com/content/images/2026/08/Tailscale-Homelab-1.svg)

Tailscale for Homelabs

## Tailscale Is Free (For Almost Everyone Reading This)

This deserves to be explicit: **For most homelab users, Tailscale is free.**

The free plan includes:

- Up to 3 users
- Up to 100 devices
- MagicDNS
- ACLs
- Subnet routers
- Exit nodes

If you're running a homelab, a phone, a laptop, and maybe a VPS - you're not paying anything.

Paid plans exist for teams and enterprises, not curiosity-driven tinkerers.

---

## Can I Self-Host Tailscale?

**Short answer:** Yes, with [Headscale](https://github.com/juanfont/headscale?ref=adhdhomelab.com).

**What is Headscale?** It's an open-source, self-hosted implementation of the Tailscale control server. You run Headscale on your own infrastructure, and your Tailscale clients connect to it instead of Tailscale's official servers.

**Why you might want it:**

- Complete control over your coordination server
- No dependency on Tailscale's infrastructure
- Data sovereignty - everything stays in your environment
- Learning opportunity if you want to understand the internals
- No user/device limits (though Tailscale's free tier is already generous)

**Why you might not:**

- Tailscale's free tier already covers most homelabs (3 users, 100 devices)
- You become responsible for availability and updates
- Missing some Tailscale features (Funnel, some ACL capabilities)
- More complexity - another service to maintain
- Tailscale's control plane doesn't see your traffic anyway (end-to-end encryption)

**The honest take:** Headscale is excellent if you're philosophically committed to self-hosting or have specific compliance requirements. But for most homelab users, Tailscale's free tier removes the practical need while letting you focus on building instead of maintaining coordination infrastructure.

Tailscale's control plane only handles coordination and authentication - your actual traffic is encrypted end-to-end and never touches their servers. So the privacy gain from self-hosting is smaller than you might think.

That said, if self-hosting everything is part of your homelab's purpose (and joy), Headscale works well and has an active community.

> **🧠 ADHD Brain Note:** The best infrastructure is the kind you don't have to think about. Choose accordingly.

---

## Installing Tailscale: It Runs Everywhere

Tailscale runs on:

- Linux (all major distros)
- Windows
- macOS
- Android / iOS
- FreeBSD / OpenBSD
- Synology / QNAP / TrueNAS
- Proxmox
- Docker containers
- VPSes

If it has an OS and opinions, it probably runs Tailscale.

### Linux: The One-Liner Install

On most Linux systems:

bash

```bash
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
```

Authenticate once in a browser. The device appears in your tailnet. You're done.

> **🧠 ADHD Brain Note:** If setup exceeds your attention span, it wasn't meant to be infrastructure.

### Proxmox VE + LXCs: There's a Helper Script

If you're using Proxmox (you are), there's a [Proxmox VE Helper Script](https://tteck.github.io/Proxmox/?ref=adhdhomelab.com) that installs Tailscale cleanly inside LXCs.

This avoids:

- Weird networking edge cases
- Half-working installs
- Losing momentum

It makes lightweight Tailscale-enabled utility containers trivial.

Now `imgproxy` is accessible at `https://imgproxy.tailnet.ts.net` within your tailnet - no exposed ports, no reverse proxy configuration.

---

## Sign up for ADHD Homelab

Every week (or so - we're not robots), I share practical setups, automations, and the occasional 3 AM discovery from the ADHD Homelab & Smart Home.

Subscribe 

Email sent! Check your inbox to complete your signup. 

No spam. Unsubscribe anytime.

## Docker + Tailscale: TSDProxy Makes This Ridiculously Easy

Here's another common homelab problem:

You have a Docker host running a pile of services. You want those services available through Tailscale with proper MagicDNS hostnames and HTTPS, but you don't necessarily want to install Tailscale inside every container or maintain a separate Tailscale sidecar for every application.

That's where [**TSDProxy** ](https://github.com/almeidapaulopt/tsdproxy?ref=adhdhomelab.com)comes in.

TSDProxy watches Docker for specific labels and automatically creates Tailscale endpoints for the containers you choose.

Think of it like a Tailscale-aware receptionist for Docker:

```
https://browserless.your-tailnet.ts.net
                    ↓
                TSDProxy
                    ↓
           Browserless :3000
```

One TSDProxy instance can handle multiple Docker applications, and enabling another service can be as simple as adding three labels to its Compose file.

That means:

- One TSDProxy container manages multiple applications
- Each service gets its own Tailscale hostname
- HTTPS is handled on the Tailscale side
- Applications can continue using plain HTTP internally
- You don't need a Tailscale sidecar attached to every container
- New services can be added without manually configuring `tailscale serve`

In other words, less YAML duplication and fewer tiny networking gremlins hiding behind every Compose stack.

> **🧠 ADHD Brain Note:** If adding secure remote access to a container requires cloning the same networking configuration 14 times, eventually container number 15 is just staying inaccessible forever.

### Step 1: Create the TSDProxy directories

I keep TSDProxy's configuration and persistent data under `/opt/data/tsdproxy`:

```
mkdir -p /opt/data/tsdproxy/config
mkdir -p /opt/data/tsdproxy/data
```

The resulting layout looks like this:

```
/opt/data/tsdproxy/
├── config/
│   ├── tsdproxy.yaml
│   └── authkey
└── data/
```

### Step 2: Create a Tailscale auth key

In the Tailscale admin console, create an auth key for TSDProxy by going to "Trust credentials."

For a persistent TSDProxy installation, a reusable and pre-authorized key is convenient because TSDProxy may need to recreate or manage nodes without making you authenticate everything manually.

Do not put the key directly inside your `docker-compose.yml`.

Instead, create:

```
nano /opt/data/tsdproxy/config/authkey
```

Put only the auth key in the file:

```
tskey-auth-xxxxxxxxxxxxxxxxxxxxxxxx
```

Then restrict access:

```
chmod 600 /opt/data/tsdproxy/config/authkey
```

Yes, technically putting secrets directly into Compose works.

So does writing your password on a Post-it attached to the monitor. We are attempting standards here.

### Step 3: Create the TSDProxy configuration

Create:

```
nano /opt/data/tsdproxy/config/tsdproxy.yaml
```

My configuration looks like this:

```yaml
  GNU nano 8.4                                               /opt/data/tsdproxy/config/tsdproxy.yaml                                                         
defaultProxyProvider: default

docker:
  local:
    host: unix:///var/run/docker.sock
    targetHostname: host.docker.internal
    defaultProxyProvider: default

tailscale:
  providers:
    default:
      authKey: ""
      authKeyFile: "/config/authkey"
      controlUrl: https://controlplane.tailscale.com

  dataDir: /data/

http:
  hostname: 0.0.0.0
  port: 8080

log:
  level: info
  json: false

proxyAccessLog: true

adminAllowLocalhost: true
```

There are two particularly important pieces here.

First:

```
host: unix:///var/run/docker.sock
```

This allows TSDProxy to watch Docker and discover containers with the appropriate labels.

Second:

```
targetHostname: host.docker.internal
```

This lets TSDProxy reach services through ports published on the Docker host.

That's particularly useful if you're using something like Dockge, where applications may live in completely separate Docker Compose stacks and networks.

### Step 4: Run TSDProxy

Here's the Compose configuration:

```
services:
  tsdproxy:
    image: almeidapaulopt/tsdproxy:2.3.4
    container_name: tsdproxy
    restart: unless-stopped

    ports:
      - "8080:8080"

    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/data/tsdproxy/data:/data
      - /opt/data/tsdproxy/config:/config:ro

    extra_hosts:
      - "host.docker.internal:host-gateway"

    labels:
      tsdproxy.enable: "true"
      tsdproxy.name: "tsdproxy"
      tsdproxy.port.1: "443/https:8080/http"

    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "3"
```

Then start it:

```
docker compose pull
docker compose up -d
```

You can watch the logs with:

```
docker logs -f tsdproxy
```

Or perform the classic "is this thing actually alive?" check:

```
docker compose ps
docker logs --tail 100 tsdproxy
```

TSDProxy is actually exposing itself through Tailscale in this example, so once everything is registered, its dashboard should be available at something like:

```
https://tsdproxy.your-tailnet.ts.net
```

I initially expose port `8080` directly so I can reach the dashboard during setup.

Once Tailscale access is working, you can remove:

```
ports:
  - "8080:8080"
```

That keeps the dashboard from being directly available on the LAN.

Also note that:

```
adminAllowLocalhost: true
```

is convenient during setup, but you should not casually expose that administrative interface to networks you don't trust.

> **🧠 ADHD Brain Note:** Temporary troubleshooting ports have a supernatural ability to become permanent infrastructure. Remove them while you still remember why they exist.

### Step 5: Add a Docker service

This is the part that makes TSDProxy worth the setup.

Let's say you have Browserless running on port `3000`.

Add:

```
labels:
  tsdproxy.enable: "true"
  tsdproxy.name: "browserless"
  tsdproxy.port.1: "443/https:3000/http"
```

That's it.

TSDProxy sees the labels and creates the corresponding Tailscale endpoint.

The label:

```
tsdproxy.port.1: "443/https:3000/http"
```

basically means:

```
Tailscale side            Docker side

443 / HTTPS       →       3000 / HTTP
```

So Browserless becomes available at:

```
https://browserless.your-tailnet.ts.net
```

without Browserless itself having to handle a certificate.

### Understanding TSDProxy's port labels

TSDProxy v2 uses this format:

```
tsdproxy.port.<index>: "<proxy-port>/<proxy-protocol>:<container-port>/<container-protocol>"
```

The index starts at `1`.

For example:

```
tsdproxy.port.1: "443/https:3000/http"
```

means:

```
HTTPS :443 → HTTP :3000
```

You'll sometimes find older examples online using:

```
tsdproxy.container_port
```

That's older TSDProxy v1 syntax. For new configurations, use the `tsdproxy.port.<index>` format instead.

### What about HTTPS applications?

If the backend application already uses HTTPS, specify HTTPS on the target side too:

```
labels:
  tsdproxy.enable: "true"
  tsdproxy.name: "myapp"
  tsdproxy.port.1: "443/https:8443/https"
```

If the application uses a self-signed certificate, TSDProxy can skip backend certificate validation:

```
labels:
  tsdproxy.enable: "true"
  tsdproxy.name: "myapp"
  tsdproxy.port.1: "443/https:8443/https, no_tlsvalidate"
```

Only use `no_tlsvalidate` when you actually need it. Disabling certificate validation because certificates are being annoying is how security slowly turns into decorative theater.

### Do I still need Docker ports?

In my configuration, yes.

Because TSDProxy uses:

```
targetHostname: host.docker.internal
```

it reaches containers through their published Docker host ports.

So Browserless still includes:

```
ports:
  - "3000:3000"
```

This approach works especially well when applications are maintained as separate Dockge stacks because TSDProxy doesn't need to join every application's private Docker network.

There are other networking arrangements if TSDProxy shares Docker networks with the target applications, but published host ports are straightforward, predictable, and significantly easier to troubleshoot at 11:47 p.m. when you've forgotten why you created six Docker networks.

### Adding another application

Once TSDProxy itself is running, exposing additional applications becomes almost boring.

For example, Atuin listening on port `8888`:

```
labels:
  tsdproxy.enable: "true"
  tsdproxy.name: "atuin"
  tsdproxy.port.1: "443/https:8888/http"
```

Now it becomes:

```
https://atuin.your-tailnet.ts.net
```

No additional Tailscale container.

No new certificate configuration.

No new `tailscale serve` command to remember.

Just labels.

### Why I Prefer TSDProxy for Docker

You can absolutely run the official Tailscale container as a sidecar for individual services, and there are situations where that architecture makes sense.

But for a Docker host running a bunch of independent applications, I prefer TSDProxy because it centralizes the repetitive parts.

Without it:

```
App
├── application container
└── Tailscale sidecar

App
├── application container
└── Tailscale sidecar

App
├── application container
└── Tailscale sidecar
```

With TSDProxy:

```
                 TSDProxy
               /    |    \
              /     |     \
        Browserless Atuin  Another App
```

Each application declares what it needs through labels, and TSDProxy handles the Tailscale plumbing.

That's exactly the kind of infrastructure I like: explicit enough that I understand what it's doing, but automated enough that I don't have to remember twelve slightly different versions of the same configuration.

> **🧠 ADHD Brain Note:** The goal isn't to eliminate configuration. It's to configure the pattern once and make future-you type as little as possible.

## Why This Works So Well for ADHD Homelabs

TSDProxy is a good example of why Tailscale has worked so well across my homelab. The individual features are useful, but the bigger win is what they remove: repetitive configuration, things I have to remember, and infrastructure that needs constant babysitting.

That's the pattern throughout my entire Tailscale setup.

Exit nodes remove the need to think about where I'm connecting from. MagicDNS removes IP addresses from my mental inventory. Subnet routing makes devices reachable without redesigning the network. Serve and TSDProxy make private services available without turning every container into its own networking project.

The technology fades into the background.

And for an ADHD brain, that's kind of the point.

Tailscale succeeds because setup is fast, mistakes are reversible, access is predictable, and I don't have to keep the entire network topology loaded in working memory just to use my own stuff.

I can add one device, expose one service, see value immediately, and stop.

No mandatory weekend-long infrastructure migration. No "while I'm here, I might as well rebuild DNS" side quest.

Unless I want one. Obviously.

---

## Final Thought

Tailscale didn't make my homelab more impressive. It made it quieter.

Less remembering. Less guessing. Less fear of touching things that "technically work."

For a homelab - and especially an ADHD brain - that's not a small win.

That's the whole point.

---

## How Are You Using Tailscale?

I'd love to hear how you're using Tailscale in your homelab - or what's holding you back from trying it.

**Drop a comment below:**

- What's your favorite Tailscale feature?
- Are you using it in a creative way I didn't mention?
- Have questions about getting started?
- Stuck on a specific setup challenge?

The best homelab discoveries come from the community. Let's learn from each other.

---

**Thanks for reading,**  
AJ Tatum

👉 [linkedin.com/in/ajtatum](https://linkedin.com/in/ajtatum?ref=adhdhomelab.com)  
📅 [tidycal.com/ajtatum](http://tidycal.com/ajtatum?ref=adhdhomelab.com)

---