Tailscale'd로 홈랩빙

Tailscale’d Into Homelabbing Written at 2026-03-26Having my own homelab was something I wanted to try for a long time. However, I just couldn’t get started. Mostly because I kept overthinking it. How will I handle dynamic IPs? Do I need something like a local DNS on my router for that? Even if I solve things inside the home, how am I supposed to access it remotely? Do I need port forwarding at the NAT layer? And what about TLS certificates, how do I even manage those without using a public certificate authority? Of course, I know there are answers to all of these questions. And each one, on its own, is probably manageable. But I was discouraged by the possibility of Lingchi, small things slowly adding up until the maintenance burden is no longer low. I knew that I could have used a VPS. Hosting everything there would have solved all these problems I mentioned. But I chose not to, for three main reasons: (1) A VPS still lives on someone else’s computer. So, nothing fundamentally prevents a VPS company from accessing your machine. (2) My old home computer is cheaper than renting an equivalent compute and storage. And lastly, but maybe most importantly, (3) I would feel much more satisfied homelabbing on hardware I physically control. So, how did I start homelabbing then? What changed? Well, my friend Halil introduced me to Tailscale. He showed me how it kind of solves all the problems I talked about. I do not want to explain how it works in detail here; I think it would be more appropriate to examine that in a separate blog post. But shortly, Tailscale lets you create a private peer-to-peer network between your devices, with a lot of conveniences that make it very easy to manage. For example, it allows me to access my machines remotely without exposing them to the public internet. Makes SSH access trivial. Handles HTTPS certificates so local services can be accessed securely, and gives fine-grained control over which devices can communicate with each other. Since most of my concerns were eliminated by Tailscale, there was basically no reason not to try it. So I started a small homelab experiment and used my old Lenovo computer as the server. The next step was to decide which apps I wanted to try and what features I should be looking for. Prioritizing Local-First Software Now, since things like electricity or internet outages are real possibilities, I think it is reasonable to expect that there will be times when the server is not available. Especially when I am away from it. In those cases, I would still want to be able to use the programs, with everything syncing back once the server is available again. I simply do not want to be blocked from using something when I need it. So it became kind of a hard requirement for me that the most important apps I use also have local-first clients. Luckily, all of the important apps I set up so far had local-first clients. For example, my Vaultwarden setup uses the Bitwarden client, where the vault is stored locally for up to 90 days, and the server is mainly there for syncing across devices. With Immich, the client is still usable even if it cannot reach the server at that moment. You can view files on your device, and everything shows up again once the server is available. And for note-taking, I use Obsidian, which is already offline-first by design. Syncing is handled through Nextcloud whenever an internet connection is available. The Architecture The initial architecture I followed for this homelab setup is fairly simple. I have a homelab directory under my $HOME directory. Right now, it looks something like this: $ tree -a -L 2 . ├── caddy -> /etc/caddy/ ├── immich │ ├── docker-compose.yml │ ├── .env │ ├── library │ └── postgres ├── nextcloud │ ├── db_data │ ├── docker-compose.yml │ ├── .env │ └── nextcloud_data └── vaultwarden ├── data └── docker-compose.yml I use Caddy as a reverse proxy in front of all my services, and the caddy folder here is a symlink to its configuration in /etc/caddy . I prefer keeping everything related to my homelab in one place, and any change I make here is automatically reflected there, and vice versa. The nice thing about Caddy is that it integrates well with Tailscale. Basically, it automatically fetches and renews certificates for *.ts.net services through the local daemon, which you would otherwise have to manage manually. Each of the remaining folders is used to bootstrap its service with Docker and store its data. They contain a docker-compose.yml and a .env file, and the volumes are mounted directly into these folders, so it is always clear where the data lives, especially for backups. Overall, I tried to keep things simple: the caddy folder is for configuration, and every service gets its own directory with its compose file, environment variables, and local volumes. Applications Tried Now that I have covered the overall setup I followed for starting my self-hosting journey, I think it is a good time to talk about the apps I tried