DEV Community: Michael Villaverde

How I made my Home Server accessible outside my home

Michael Villaverde — Thu, 01 May 2025 14:16:37 +0000

"Every developer should try to self host at least once" - anonymous

I recall seeing a similar sentiment pop up on Reddit months ago, and it genuinely sparked a feeling of FOMO – a worry that I was missing out on something important. Despite working in this industry for a considerable time, I haven’t yet explored setting up my own home server.

Currently, I rely on services like Google Drive, Dropbox, and iCloud for file backups, which are convenient, but I recognize that we’re essentially entrusting our data to these companies and I'm now considering the potential benefits of taking control of my data by exploring home server options.

Then the journey begins...

I bought a barebone Mini PC since I have spare laptop RAM and NVME SSD lying around my house. I then downloaded Ubuntu Server and use Balena Etcher to flash the ISO image into my flash drive.

The setup begins by connecting a monitor, keyboard and ethernet cable for internet access in the PC and installing the operating system. There are many tutorials online on how to perform this tasks but I am pretty sure you already know how to do these things. After installation and logging in, I ran the following command:

sudo ufw allow ssh

This command will help you remotely access your machine so that you can remove the keyboard and the monitor connected into it (In my case, I am using those things for my work laptop 😂). You can also enable http and https in order to access your server in your preferred browser of choice.

I chose Casa OS to run my home server dashboard and applications. It is a community based open source software that is also very beginner friendly, which is ideal for users like me. In order to install it, just run the following command:

curl -fsSL https://get.casaos.io | sudo bash

Casa OS by default runs on port 80, but you can always change the port using the following command:

sudo bash -c "$(wget -qLO - https://raw.githubusercontent.com/bigbeartechworld/big-bear-scripts/master/change-casaos-web-ui-port/run.sh)"

After installing Casa OS, access your dashboard in your preferred browser using the link pattern <home server ip>:<casa os port>. You must setup an administrator account first and then login to view your dashboard. Your dashboard might have fewer apps than mine which now looks like this.

I have the following apps installed currently:

Transmission: A torrent client.
Immich: Similar to Google Photos, backups my photos and videos.
AdGuard Home: A personal DNS that I used to block unnecessary ads.
Jellyfin: Similar to Netflix, but the media content are at your control 😉.
Vaultwarden: A password manager.
Open WebUI: I use it for user interface of my running Ollama models.

As of the moment, the following applications will suffice for my personal use case. Having this kind of machine helps me become more in control of my data.

Here comes the challenge...

Even though my setup runs smoothly and within expectations, I still cannot access it outside my home network. Yeah, I touch some grass also 🤣. I need to access my home server outside of my home network but without the risk of exposing my data into public web.

Here then comes VPN (Virtual Private Network) which is basically establishes a protected network connection when using public networks. I already have relevant experiences with this one as some of my previous projects involves private repositories that can only be accessed by connecting into the client's VPN. There are many solutions for this specific use case like WireGuard, but in this particular blog, I chose Tailscale.

Tailscale has a very generous free tier, which contains the following:

Up to 3 users
Up to 100 devices
Access to nearly all Tailscale features

You can start your Tailscale account here.

In order to use Tailscale in your home server. You need to install it first by running the following command in your terminal:

curl -fsSL https://tailscale.com/install.sh | sh

After installing Tailscale, your device must be visible now in your Tailscale machine dashboard. They also have comprehensive documentation for other functionalities and guides.

I installed their mobile application in my device, activated the VPN and I was able to view the IP designated to my home server.

But Michael, I don't want to input IP address when accessing my home server every time!

I gotchu fam! Here's where DNS (Domain Name System) comes into action. DNS acts like a phonebook of the internet which translates human readable domain names like facebook.com into their appropriate IP addresses like the ones Tailscale VPN assigned to our corresponding machines.

You can always buy some domain names online like in Google Domains, Namecheap and GoDaddy. In this particular scenario, I will be using Duck DNS which is a free dynamic public DNS.

First, you must obtain your API key from Duck DNS by signing in. In my case, I use X to sign in and get my own API key. Then, register a subdomain you want to have and add the corresponding IP designated by Tailscale for your home server. Finally, your Duck DNS dashboard should look like this:

This single record will suffice as we will be using a reverse proxy to map each of our application. For the reverse proxy solution, we will be using Caddy, particularly xcaddy.

To install xcaddy, log into your home server and run the following commands:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/xcaddy/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-xcaddy-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/xcaddy/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-xcaddy.list
sudo apt update
sudo apt install xcaddy

After installing xcaddy, run the following command to install Caddy with Duck DNS module included:

xcaddy build --with github.com/caddy-dns/duckdns

The executable caddy file will be added in your current working directory and for the next steps, we will be setting up Caddy to run as a service. This Caddy documentation will help you to make it happen.

After setting the Caddy as a service, it's time for editing the Caddyfile. This file will hold your domain name/s to home server application/s mapping. Here's my configuration:

# This configuration holds your API key configuration and enables you to use wildcard (*) for your Duck DNS domain
(duckdns) {
    tls {
        dns duckdns <YOUR API KEY HERE> {
            override_domain <YOUR SUBDOMAIN HERE>.duckdns.org
        }
    }
}

# This will be the root mapping of your Duck DNS domain to Casa OS dashboard
<YOUR SUBDOMAIN HERE>.duckdns.org {
    import duckdns
    reverse_proxy localhost:<YOUR CASA OS PORT>
}

# This will map wildcard domains to your home server applications. For this example, I use jellyfin
*.<YOUR SUBDOMAIN HERE>.duckdns.org {
    import duckdns

    @jellyfin host jellyfin.<YOUR SUBDOMAIN HERE>.duckdns.org
    handle @jellyfin {
        reverse_proxy localhost:<YOUR JELLYFIN PORT HERE>
    }
}

Finally, save the Caddyfile and restart the service using the following command:

sudo systemctl restart caddy

You must now be able to access your home server dashboard everywhere using Tailscale VPN and your Duck DNS name from your preferred web browser.

Just in case you're curious about the background image of my Casa OS dashboard, that was made by @artbymerisu. She's a great artist and creates beautiful anime wallpapers.

Deploying FastAPI Application to AWS Fargate using Serverless Container Framework

Michael Villaverde — Sat, 29 Mar 2025 12:21:36 +0000

In this post, I will demonstrate how to deploy a FastAPI application to AWS Fargate using the Serverless Container Framework (SCF).

So, what's the Serverless Container Framework (SCF)?

As stated in their documentation, the Serverless Container Framework provides a unified development and deployment experience for containers on serverless platforms. Think of it the same as their Serverless Framework, but built for containers.

And what about FastAPI?

FastAPI is a fast and modern web framework written in Python. It's often deployed in containers. You could also use Mangum, but we'll cover that another time. For now, we're using SCF to deploy our FastAPI application.

Prerequisites

I'll assume you already have an existing AWS account and a Serverless account, as these are necessary to successfully deploy our application. If you don't have them yet, use the following links to create them:

Done creating your account? That's great! Now, I have a confession to make: my setup is tailored for those using VS Code or Cursor as their IDE. If you prefer other IDEs like PyCharm or NeoVIM, your setup might differ.

So, let's proceed shall we? We'll need to install Dev Containers within VS Code or Cursor. After installation, we can clone the repository from here.

Let's start the journey...

After cloning the repository, open the project in your IDE. Ensure that the settings of "terminal.integrated.inheritEnv" is set to true and make the following environment variables exported in your integrated terminal:

export AWS_ACCESS_KEY_ID=<your access key here>
export AWS_SECRET_ACCESS_KEY=<your secret key here>
export AWS_REGION=<region you want to deploy the application>

After exporting the necessary variables, press Ctrl + Shift + P (for Windows users) or Cmd + Shift + P (for Mac users). This will open the Command Palette. Then, search for "Dev Containers: Reopen in Container". This will set up the project within a containerized environment, complete with AWS CLI, Serverless Framework, and Docker installed.

Project Structure

Here's what the project looks like:

scf-fastapi-example/
├── .devcontainer/
│   └── devcontainer.json
├── app/
│   ├── Dockerfile
│   ├── main.py
│   ├── requirements.txt
│   └── static/
└── serverless.containers.yml        # Contains deployment config

Inside app/main.py you'll find a simple FastAPI application. The app/Dockerfile holds the instructions for building our FastAPI app into a reusable image. By default, SCF looks for the Dockerfile in the root folder of the service you're deploying.

Let's take a look inside the Dockerfile:

FROM python:3.12-slim-bullseye

WORKDIR /app

ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

RUN pip install --upgrade pip
COPY ./requirements.txt .
RUN pip install --no-cache-dir --upgrade -r requirements.txt

COPY . .

CMD ["fastapi", "run", "main.py", "--port", "8080"]

We're running FastAPI on port 8080 by default because the local emulation of the Application Load Balancer within SCF points to port 8080.

The serverless.containers.yml file contains the development and deployment configuration for SCF.

Here's what the serverless.containers.yml file looks like:

name: fastapi-example

deployment:
  type: awsApi@1.0

containers:
  app:
    src: ./app
    routing:
      pathPattern: /*
      pathHealthCheck: /health
    compute:
      type: awsFargateEcs
      awsFargateEcs:
        cpu: 256
        memory: 512

The name attribute defines the namespace for your services when deployed to AWS.

The deployment.type specifies awsApi, which deploys an AWS Application Load Balancer, networking components, and containers.

The containers. will hold the configuration for each service deployed to AWS. For more detailed explanation of each attributes, refer to this documentation.

Running the Application Locally

To run the project, open the integrated terminal and run the following command:

serverless login

Choose login/register and you might encounter similar to this image below:

Click the link and make sure that you are logged in to your Serverless account.

Execute the following command to run the project locally:

serverless dev

After executing the above command, you will now see similar output like this one:

You can access your application in http://localhost:3000/.

Deploying the Application

To deploy the project, run the following command in the terminal:

serverless deploy

Deployment of the application might take some time. After executing the command and SCF performing the deployment processes. The output on your terminal must look like this one:

To remove all the deployed components, run the following command:

serverless remove --force --all

Conclusion

Serverless Container Framework (SCF) offers a streamlined approach to deploying services to AWS, particularly for containerized applications like FastAPI or Django. It simplifies the process by abstracting away much of the underlying infrastructure management, making it easier for developers to get their applications running in the cloud. With SCF, you can focus on building your application and let the framework handle the deployment complexities.