<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Self-Hosting on /var/log/janio</title><link>https://devops.sarmento.org/en/categories/self-hosting/</link><description>Recent content in Self-Hosting on /var/log/janio</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 11 Apr 2026 11:31:22 +0000</lastBuildDate><atom:link href="https://devops.sarmento.org/en/categories/self-hosting/index.xml" rel="self" type="application/rss+xml"/><item><title>Tailscale in the Homelab — Remote Access Without Opening Ports</title><link>https://devops.sarmento.org/en/posts/tailscale-in-the-homelab-remote-access-without-opening-ports/</link><pubDate>Sun, 29 Mar 2026 21:58:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/tailscale-in-the-homelab-remote-access-without-opening-ports/</guid><description>&lt;p&gt;Anyone who runs a homelab — or even a single Raspberry Pi hosting services — eventually hits the same obstacle: how do you access those devices from outside the local network? The classic answer involves opening ports on the router, setting up port forwarding, dealing with dynamic IPs via DDNS, and hoping no bot discovers that SSH port exposed to the internet. It works, but the attack surface grows with every open port, and the maintenance becomes a silent headache that only shows up when something breaks.&lt;/p&gt;</description></item><item><title>Exposing homelab services to the internet with Cloudflare Tunnel</title><link>https://devops.sarmento.org/en/posts/exposing-homelab-services-to-the-internet-with-cloudflare-tunnel/</link><pubDate>Fri, 27 Mar 2026 18:24:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/exposing-homelab-services-to-the-internet-with-cloudflare-tunnel/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/ssh-behind-nat-ssh-jcom-solves-it/"&gt;previous post&lt;/a&gt;, I showed how SSH-J.com solves a specific problem: accessing a machine behind NAT via SSH, without opening ports on the router and without relying on a public IP. The reverse tunnel works well for interactive sessions and file transfers, and SSH-J.com as a jump host makes everything trivial to configure. For SSH, it remains the simplest solution I know.&lt;/p&gt;
&lt;p&gt;But SSH is just one piece of the puzzle. Anyone who maintains a homelab — even if it&amp;rsquo;s just a mini PC under the desk or a Raspberry Pi in the corner of the room — inevitably ends up running web services: an RSS reader, a monitoring dashboard, a Gitea, a Jellyfin, an &lt;a href="https://devops.sarmento.org/en/posts/immich-your-photos-your-server-your-rules/"&gt;Immich&lt;/a&gt;. These services listen on local HTTP ports and work perfectly as long as you&amp;rsquo;re on the same network. The problem appears when you want to access them from outside — from the office, from your phone on the bus, from anywhere that isn&amp;rsquo;t your local network.&lt;/p&gt;</description></item><item><title>Immich: Your Photos, Your Server, Your Rules</title><link>https://devops.sarmento.org/en/posts/immich-your-photos-your-server-your-rules/</link><pubDate>Wed, 25 Mar 2026 07:18:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/immich-your-photos-your-server-your-rules/</guid><description>&lt;p&gt;There comes a moment when everyone stops and thinks about where their photos are. It usually happens when Google sends that friendly email letting you know your free storage is full — and that for just a few dollars a month you can keep storing your memories on their servers. It is a gentle nudge toward a monthly subscription that, added up over years, costs more than a multi-terabyte external hard drive. But the monetary price is only the most obvious part of the equation. There is a more subtle cost to leaving all your photos, videos, and personal memories in the hands of a company that profits from data — and it is worth talking about that cost before discussing any tool.&lt;/p&gt;</description></item></channel></rss>