Then there's my old MacBook. It's been sitting in a drawer for about six months now, and the screen has been dead for about ten months. It'll cost me a fortune to get it replaced. I could literally purchase a new laptop with that much money. Every once in a while, I hook it up to my monitor to remind myself it still works. Last week, I saw it lying there, and it finally clicked. I could just start here.

People are out there buying used Mac Minis specifically to build home servers, and a MacBook is basically just a Mac Mini with a battery.

While wiping it clean, my first instinct was to install Linux. But trust me, it's way easier to stick with macOS.

There are a dozen ways out there to prevent your MacBook from sleeping when you close the lid. I plan to keep it running 24x7, so I skipped all third-party apps and went with the nuclear option.

sudo pmset -a disablesleep 1

Here, it asks the power management settings to disable the system's ability to sleep, irrespective of your other settings.

IP addresses are dynamic by default, but you need a static one to keep your server reachable. You can assign a static IP address by going to System Settings > Network. Choose your connection, go to the TCP/IP tab in Details, change the Configure IPv4 option to Using DHCP with manual addresses, and assign your desired IP address there.

Well, this turned out to be surprisingly easier than I thought. Just go to Settings > General > Sharing and enable Remote Login. Viola, you can now SSH into your MacBook with a password.

ssh omega@<ip address>

SSH keys are more secure than a password. So I switched to that instead. I store mine on 1Password, so I generated one there. You can generate a key pair yourself with this command:

ssh-keygen -t ed25519 -f ~/.ssh/omega

Now, copy the public key into your server using the command:

ssh-copy-id -f -i ~/.ssh/omega.pub omega@<ip address>

Now, disable password-based login entirely. Edit the /etc/ssh/sshd_config with the following setting.

PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM no
KbdInteractiveAuthentication no

This essentially locks out everyone except those with the key. This section is already getting a bit long, so I won't explain what each line does. Please do look it up yourself if you are curious.

By this stage, I already had Docker up and running. My plan was to containerize everything on this machine. But then I hit the Jellyfin documentation and saw this banner right at the top:

Warning for Docker on MacOS

Basically, it was asking me to just install Jellyfin like any other standard macOS app. I complied. At this point, I felt more like a Soydev than a hackerman. The only remaining step was to copy my media into the Jellyfin-recommended folder structure.

And just like that, I had my entire library accessible on every device in my home network.

Jellyfin Web and Moonfin mobile app

The media shown in the screenshots is Caminandes: Llamigos, an open-source short film produced by the Blender Foundation. It is licensed under Creative Commons Attribution 4.0. You can find more of their work at peach.blender.org.

Like any responsible person, I started by installing Tailscale. With a few clicks, I was streaming media on devices outside my network.

However, I'm also planning to move my Ente photos to this server, and Tailscale's private-mesh nature makes it impossible to share album links publicly. So, I scrapped this option.

Cloudflare tunnel would have been the path of least resistance for exposing my server to the web for free. Sadly, streaming videos is strictly against their TOS, and I'm not trying to get my account banned.

Then there's the Tailscale funnel. It's a solid free option. It is meant for temporary sharing of local development servers. Reddit users from the Jellyfin community complained about bandwidth issues from time to time. I didn't want to abuse a free service either. I dropped this option, too.

Probably, the most robust solution is to run a reverse proxy on the server and only allow HTTPS traffic through port 443. As I explained earlier, IP addresses are dynamic by default. Just like your local network, your public IP address changes whenever the IP feels like it. Purchasing a static IP is definitely one option, but the popular workaround is using Duck DNS.

Duck DNS acts as your beacon. You run a client on your server that periodically pings the Duck DNS servers with an HTTP request, "Hey, my current IP is <ip addresss>". To make this work, you have to forward ports 80 and 443 on your router. I went to the login, only to realize the technician had changed the default router password, likely anticipating that I'd try to mess with it. Now, that was another dead end.

This is when I read about creating your own tunnel. I still have my free 1GB EC2 instance on AWS. I could just tunnel my traffic and set up a reverse proxy there. And that's exactly what I did.

I created another SSH key pair, this time to let my home server SSH into the EC2. A simple command opened the tunnel:

ssh -f -N -R 8096:localhost:8096 admin@<ip address>

I configured a reverse proxy using Caddy to point to that port. Since Jellyfin runs on port 8096 by default, Caddy just picks up the traffic from the tunnel and serves it over HTTPS. And just like that, I got it working with zero issues.

There are plenty of third-party clients on both iOS and Android, but my Samsung TV runs on Tizen OS. The official Jellyfin client isn't available on the App Store. The workaround was to enable developer mode and push a signed build to the TV over the local network.

I spent hours trial-and-erroring different methods before finally getting a build to stick. Once I figured it out, I wanted to install a even better-looking Jellyfin client called Moonfin.

I ended up forking a Tizen installer that worked for me, and built a moonfin-tizen-installer. I've published it as a Docker image that handles everything from downloading the latest Moonfin release, signing it, and installing it on your Samsung TV with a single command. Convenient.

docker run --rm --platform linux/amd64 abhayvashokan/moonfin-installer <samsung tv ip>

I've really grown to love the Jellyfin community. There's so much room to hack around; plenty of cool integrations, plugins, and custom CSS. I have spent way too many hours customizing the UI to my liking.

The features are actually impressive. Syncplay stands out; you could start a watch party with your friends, and everyone stays in sync. One thing that's missing, and what the community keeps asking for is a native chat feature. I'm planning to implement that myself, as a plugin ofc.

It's also wild how Jellyfin just handles the heavy lifting. It automatically pulls the movie details, reviews, subtitles, and even cast and crew images. It even transcodes media on the fly for devices that don't support a particular format. I've enabled hardware acceleration to use my MacBook's GPU via VideoToolbox to reduce load on my CPU. How cool is that?

Now that I finally have a functional server at home, I'll be using it as a playground for a bunch of other experiments.

I grew up watching Superman. I loved Superman. Yes, the same Superman who wears a cringy blue costume with bright red underwear. Christopher Reeve's Superman. I was mesmerized by watching him fly, fight bad guys, and save the world. I also loved that clumsy Clark Kent, too. I giggled at whoever made fun of him, knowing that he could literally fly circles around them.

There was this magic in this character that I just couldn't let go of. The naive 4-year-old me wanted to be Superman when I grew up. Some dream, huh! Eventually, reality set in. I realized I couldn't fly on my own, so I went for the next best thing: becoming a pilot, specifically a fighter pilot. That's partly because my dad was in the Air Force, and I grew up watching jets tear through the sky over Bangalore. Ha, that didn't work out either, did it?

As I got older, life got in the way. Superman movies went quiet for a while, and suddenly, everyone wanted to be Batman. I hadn't seen a single Batman movie till I was sixteen. I mean, who cares about a guy in a bat costume who can't even fly?

That's when I watched The Dark Knight for the first time. Then I watched it again, and again, and then again. I was obsessed. I had to go back and binge-watch the whole trilogy. I was mindblown to see the depth in each character; it's not just a good guy-bad guy superhero movie anymore. There were way too many sharp dialogues and scenes that just hit the right nerve.

I'm not a comic book guy. I've only read five in my life, and two were Superman. But lying in bed last night, I realized I still can't shake the feeling away. As much as I love Batman, Superman is still the one I look up to. He's that pure symbol of hope that brings the four-year-old me right back to the edge of the bed, ready to jump.

Superman '78

Fast-forward to May, and I pretty much had no choice but to export everything from Google Photos. Gmail had started whining that it might stop sending emails soon. I'm not about to pay Google ₹100+ per month just to hang on to my photos. I have an ick for subscription plans. In fact, I don't even have a YouTube premium subscription.

Ente was an easy choice for me. It runs as a lightweight Go binary with minimal resources. The lightweight server can be run on a Raspberry PI. Due to its client-side encryption, all heavy lifting including face recognition and semantic search is done on your own device. It's wild that they pulled off on-device machine learning with limited processing power and still got it working across different platforms. They've written a great breakdown of how they pulled it off.

Ente's founder, Vishnu, a Malayali, was creeped out by seeing how much information Google could infer from photos. So, he left Google to build something different: a reliable, privacy-focused alternative to Google Photos - Ente. In Malayalam, "ente" means "mine," so "Ente photos" literally translates to "My photos."

I created my second AWS account. Well, only God and I know what happened to my first one. Since I don't own a credit card, my options were limited. I don't plan to use AWS beyond the free tier either. I've seen enough AWS memes to know I'm probably going to mess something up… again. Well, that's future me's problem now.

After a bit of digging around, I decided to go with Cloudflare R2 instead of AWS S3 or EBS for storing my photos. R2 offers a pretty generous 10GB of free storage and charges only about ₹1.20 per month for each additional GB. Plus you get millions of free read and write operations every month. Thanks to Ente's client-side caching, my usage stays well below the limits, like, over 100x lower. They do not charge anything for egress either, which is wild. Here's how I did it.

I am running a Debian on my EC2 instance, so I just followed the installation steps in the official docs to get this part up.

The Ente team has built a quick start script to setup and run the Ente server with a single command.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ente-io/ente/main/server/quickstart.sh)"

This curl command sets everything up. It creates a my-ente directory with the necessary configuration files, pulls and runs all the containers, and gets things up and running. To test it out, you can forward port 3000 from your EC2 instance and access your web server at http://<elastic-ip>:3000.

Ente Auth, by design, requires a secure connection (HTTPS) for its communication. It does not support HTTP connections. So, to get things running, you'll need a custom domain.

I've deployed my Ente server at https://ente.abhay.app. To do something similar, start by adding an A record for your domain and point it to your EC2 instance's elastic IP. You'll also need to set up a reverse proxy. I used Caddy for this. It has a lightweight web server with a clean, easy-to-read config file. It fetches and renews TLS certificates by default.

Firstly, install Caddy on your instance:

sudo apt install caddy

This will create a Caddyfile at /etc/caddy. Update your Caddyfile in this format:

{
    email ente@abhay.app
}
 
ente.abhay.app {
    reverse_proxy {
      to http://localhost:3000
    }
}
 
ente-api.abhay.app {
    reverse_proxy {
      to http://localhost:8080
    }
}

Now, execute the caddy reload command and you are done. You have your Ente server running on your custom domain.

I have used Cloudflare R2 for my setup. You can use any S3-compatible storage provider. By default, Ente's compose file is shipped with MinIO, which itself is a solid starting point.

To use R2, create a bucket through the Cloudflare dashboard, and then set the following CORS policy:

[
  {
    "AllowedOrigins": ["*"],
    "AllowedMethods": ["GET", "HEAD", "POST", "PUT", "DELETE"],
    "AllowedHeaders": ["*"],
    "ExposeHeaders": ["Etag"],
    "MaxAgeSeconds": 3000
  }
]

You don't need to make the bucket public. Instead, we'll use an API token for secure access. Just head over to the Manage API Tokens section in the Cloudflare dashboard and generate an access key and secret. We'll plug these into the Ente configuration in the next step.

I really loved Ente's reasoning for naming their server museum: "We named our server museum because, for us and our customers, personal photos are worth more than any other piece of art". I made a few tweaks to the generated configs to make sure everything works with my configuration. Here's what my final config looks like. By default, all encryption keys are generated as random hashes.

# museum.yaml
 
key:
  encryption: <your-encryption-key>
  hash: <your-encryption-hash>
 
jwt:
  secret: <your-jwt-secret>
 
db:
  host: postgres
  port: 5432
  name: <your-db-name>
  user: <your-pg-user>
  password: <your-pg-password>
 
s3:
  are_local_buckets: true
  b2-eu-cen:
    endpoint: <your-bucket-endpoint>
    bucket: <your-bucket-name>
    key: <your-access-key>
    secret: <your-access-secret>
    region: auto

# compose.yaml
 
services:
  museum:
    image: ghcr.io/ente-io/server
    ports:
      - 8080:8080 # API
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - ./museum.yaml:/museum.yaml:ro
      - ./data:/data:ro
 
  web:
    image: ghcr.io/ente-io/web
    ports:
      - 3000:3000
    environment:
      ENTE_API_ORIGIN: https://ente-api.abhay.app
 
  postgres:
    image: postgres:15
    environment:
      POSTGRES_USER: <your-pg-user>
      POSTGRES_PASSWORD: <your-pg-password>
      POSTGRES_DB: <your-db-name>
    healthcheck:
      test: pg_isready -q -d <your-db-name> -U <your-pg-user>
      start_period: 40s
      start_interval: 1s
    volumes:
      - postgres-data:/var/lib/postgresql/data
 
volumes:
  postgres-data:

To enable public sharing of your albums, you'll need to run two instances of the web app. One serves as your regular app, and the other runs the same code but on a different origin. Then, you simply configure the main app to use this second instance to handle public links.

# Rest of the museum.yaml file
 
apps:
  public-albums: https://albums.abhay.app

# Rest of compose.yaml file.
 
web:
  image: ghcr.io/ente-io/web
  ports:
    - 3000:3000
  environment:
    ENTE_API_ORIGIN: https://ente-api.abhay.app
    ENTE_ALBUMS_ORIGIN: https://albums.abhay.app
 
albums:
  image: ghcr.io/ente-io/web
  ports:
    - 3002:3002
  environment:
    ENTE_API_ORIGIN: https://ente-api.abhay.app
    ENTE_ALBUMS_ORIGIN: https://albums.abhay.app
# Rest of compose.yaml file.

// Rest of the Caddyfile
 
albums.abhay.app {
    reverse_proxy {
      to http://localhost:3002
    }
}

All your uploaded photos are encrypted by default, which is great for privacy. But it also means the data in your bucket is useless without your server. So, having proper backups is essential. Losing your server shouldn't mean losing all your photos.

You'll want to back up all the secrets used by your museum server. For PostgreSQL, you'll need to back up the entire data volume. To handle this, I set up a separate Docker container that periodically backs up my database to R2.

# Rest of the compose.yaml file
 
backup:
  image: eeshugerman/postgres-backup-s3:15
  environment:
    SCHEDULE: "@daily"
    BACKUP_KEEP_DAYS: 30
    S3_REGION: auto
    S3_ENDPOINT: <your-bucket-endpoint>
    S3_ACCESS_KEY_ID: <your-access-key>
    S3_SECRET_ACCESS_KEY: <your-access-secret>
    S3_BUCKET: <your-bucket-name>
    S3_PREFIX: backups
    POSTGRES_HOST: postgres
    POSTGRES_DATABASE: <your-db-name>
    POSTGRES_USER: <your-pg-user>
    POSTGRES_PASSWORD: <your-pg-password>

Ideally, you should also enable replication in Ente - this gives you primary and secondary hot storage, along with cold storage. It's actually pretty easy to set up. That said, I'm skipping it for now since Cloudflare R2 boasts a whopping 99.999999999% (yep, eleven nines!) annual durability. Realistically, the only way I'd lose data at this point is me accidentally doing something dumb, which, let's be honest, is always the biggest risk anyway.

I also updated my museum server to block new registrations and set up the Ente CLI. Once everything was ready, I exported all my Google Photos with Takeout. Over the past couple of years, I had backed up photos in all sorts of weird places. I lost quite a bit of metadata in the process. To fix that, I wrote a bash script using exiftool to restore the correct timestamps and locations. Those are really the only two pieces of metadata I care about.

It's been two weeks since I migrated everything, and I've been really happy with how it's all working. My photos and their thumbnails take up just over 11GB, and I'm expecting my monthly bill to be under ₹3. Not bad at all.

Sometimes, Mom used to wake up at 3 AM in the morning so that Dad could take his breakfast with him for his early morning shift. I would get up at 6 AM and still be the last one awake. We had a window right beside our bed. The sunlight would have started to seep into the room, yet the view outside remained a blank canvas. No, it's not just because of the dew that has condensed on the glass, it was due to the thick, chilly fog that greeted us every morning.

Yelahanka, as I remember it, was a peaceful suburb with very little traffic. We lived in the Air Force quarters. Mornings were usually a rush with Mum juggling to get my sister and me, who were five and four at that time, ready for school. We were always late since school started at 7:30 AM. She would hold our hands and run the whole 1 km to school. The fog would have started to clear by now revealing a distant hill bathed in a purple hue. To this day, I don't know why it's purple. Mom always bathed us in hot or cold water every morning and still wonder why we have a running nose. Sweater was part of the uniform. When I joined KV, we had a navy blue sweater to match the blue-and-white uniform. I still wore it whenever I was sick for as long as I could remember.

Sister and me at the Air Force school

I was obsessed with fighter aircrafts, and there used to be a whole bunch of them there. Every year, the Air Force held an Air Show, displaying our fighter jets in stunning formations. I'd sneak out of my apartment into the street just to catch these aircrafts making rounds during practice. Back then, I dreamed of being a pilot. I'd tie pillow covers as a cape and jump from the window to the table.

Mom, sister and me at the Air Force station

Phone calls were expensive back then, and I remember Mom making calls home in STD booths. Eventually, we did buy a mobile phone, which felt like a luxury. Every vacation, we traveled back to our hometown by train, with Mom always packing lemon rice for the journey. I used to hate it every time. The joy of seeing those familiar faces always made the long journey home feel worth every mile.

Dad had a scooter—blue, or maybe green? I can't quite recall. The four of us made so many memories on that scooter. I'd stand in the front while we went wherever we needed to go. It still amazes me that it's almost 20 years since we left Bangalore, yet these memories still flash vividly in my mind.

I won't bore you with the details of how I tried building my portfolio with a different framework each time, only to lose motivation halfway through. Long story short, I spent more time creating elaborate Figma designs or starting with building a theme switcher than actually building the site. I kept getting distracted and lost motivation when I didn't see any real progress.

I just needed a personal space where I can share my random shower thoughts and the new ideas that frequently pop into my head. It'll be a mix of many things - sometimes I'll dive into some technical jargon, other times I might us it to vent about whatever's on my mind. Back in college, I was pretty active on Medium, but it feels a bit formal for me now. I want this blog to be a place where I can write freely without worrying about making it perfect.

Honestly, Next.js made the whole process way easier than I expected. I don't need to manually read markdown files, parse them, and turn them into React components during build. Next.js and MDX!! Just create a page.mdx file instead of page.tsx with some minimal configuration; kaboom! your blog is done. I made a little BlogLayout component to handle titles and meta information. Here's how a blog post will look like:

import BlogLayout from "_/blog-layout";
 
export const data = {
  title: "It Only Took a Million Tries, But My Portfolio Is Done!",
  keywords: ["Next.js", "MDX", "Portfolio"],
};
 
<BlogLayout data={data}>
  ## Lorem ipsum dolor
  <img src="" alt="lorem ipsum"></img>
  **Lorem ipsum** dolor sit amet, consectetur adipiscing elit, sed do eiusmod
  tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
  quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
  consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
  cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
  proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</BlogLayout>;

Now, let's talk about the dark theme. I must admit, I'm guilty of always asking if a site has a dark mode. But here? Nope. No theme switcher here. That's right—this site only comes dark. Sometimes you just have to embrace the dark side and make life a little simpler!

I'm pretty pleased with how things turned out. It's simple, it's responsive, and it has reusable UI elements. I even managed to dynamically generate OG images for each blog post. Yep, Next.js makes that possible too! Here's a peek at what it looks like for this blog.

Dynamically rendered OG image

I ran a Lighthouse audit and was delighted to see a near-perfect score. I had to tweak a few minor warnings to hit the perfect score with a confetti for my little victory. Yippee!

100% lighthouse score

So, yeah, there you have it. my portfolio is finally live and I couldn't be happier. Sometimes, simple is just better. Check out the repository at AbhayVAshokan/abhay.app. I'll be posting ramdom stuff here, so stay tuned!