I've always been a "do it by myself" person ever since I started programming. I pretty much got trust issues when trying to use any libraries just because I don't know how it actually works under the hood. Too many abstractions, too many documentations to read, and too many weird bugs. Heck, I'd be lucky if they even create a documentation. Sometimes it's just too vague that I refused to pick the library and ended up coding everything all by myself.

Granted, that was my early days. With accumulating experience over how things actually work in industry, sometimes we just need to get things done fast. That requires us to just use any available library that is at least production-ready. We sideloaded all the issues on the third-party libraries, vendors, and components not made by ourselves to the respective maintainers, ending with additional external dependencies. That's why choosing libraries, frameworks, or other tools became an additional burden. An additional burden to properly do research on the tools whether it fits with our product or not. In the end, we just want to deliver our product that lies within our quality control.

Nowadays, the decision doesn't stop on determining which library, framework, or tech stacks we're using. Cloud services, vendors, and things that closely related to infrastructure become an important parameter in our calculation. This complexity is what opens out new possibilities for new [insert component]-as-a-Service product. From the most "primitive" building blocks such as physical or virtual servers that lies in Infrastructure-as-a-Service scope, components that is built on top of an existing infrastructure (Platform-as-a-Service), something that is ready to use (Software-as-a-Service), or many other forms it could be, like Database and Functions.

In this post, I want to talk about my journey in deploying Next.js App from self-hosted environment. From how I configured my infrastructure, the challenges I went through, and my journey in switching between services and vendors.

Self-hosted Environment

So, I started with a pretty simple environment. A VPS (will be referred as Node from here), and a domain. That's it. I used various cloud providers, from DigitalOcean, Vultr, AWS, Hetzner, and all of them are pretty similar: Ubuntu for it's Linux distribution and IPv4 address attached. Later on, I installed nginx server to at least "protect" my Next.js App behind a reverse proxy and additionally add SSL through LetsEncrypt certificates.

Here are my steps

Provision a node. Acquire SSH access through password login or private key login.
Install nginx and pm2
Clone my Next.js App repository.
Configure the necessary data (e.g: environment variables).
Install dependencies, build the app, then run the production build through pm2
Add server block in Nginx configuration that points to Next.js App running locally.
Add DNS record on my domain that points to my node's IP address. I always go with A record.
Use certbot to add SSL. Add HTTP to HTTPS redirection to prevent non-HTTPS request to go through.
Test out if it's reachable from public internet

It's a lot simplified as I omitted several details, but the majority of the steps are as described.

So, what's the problem with this setup? Aside that it's real hard, i mean, REAL hard to automate, it's also requires direct access to the infrastructure for any changes. Not all developers understand, or at least care about how things works in the operations realm. It's also one issue that creates the DevOps role : developers only need to care about delivering deliverables and expect it to be available to others without meddling additional steps in operation sides.

So in order to improve my life, I tried adding more and more components that would let me automate things. One obvious thing is to add CI/CD to the entire process. With the current setting, every time there are changes needed, to redeploy would need the following steps:

Pull changes
Stop currently running Next.js App
Build the app.
Re-run the app.
Testing if needed.

This can be done from the most primitive, not pipelined, way such as creating automation script and run it after changes are pushed to repository. Using CI/CD would benefits us a lot, so if you're using Github, use Github Actions, if you're using Gitlab, use it's CI/CD features, or just a third-party CI/CD services such as CircleCI or Jenkins. You would only need a way to let the CI/CD runner to access your server. It's a little bit unsafe, but it does the job.

Most of the time, it's already great with this setting. Assuming you're only running a hobby project or a small scale website that fits within a single node, you don't need to configure anything more.

The Problem With Self-Hosted

It is as clear as day that "self-hosted" screams "self" which puts more burden to the engineer. The hassle of provisioning nodes, managing network configurations, configuring the automation, or even some additional Next.js problems such as stale cache from previous builds, it all introduces blockers that sometimes are just not necessary.

From the infrastructure side, these are problems that I would always need to face :

OOM (Out of Memory)
Insufficient Disk Space
Expired SSL Certificates
Dynamic IPs

Bear in mind, I tried to reduce my operating cost as much as possible. If possible, free even. But scaling it both horizontally and vertically doesn't benefit much aside from less lag when executing my automation scripts.

And then there is the deliverables. With steps described above, I've stumbled upon these problems :

Failing deployment resulting to downtime
Stale Cache
Almost no APM (Application Performance Monitoring)
No easy way to add observability
Slow Builds

I hate to face these problems. It demoralized myself from further developing the features I planned as I need to constantly switch into DevOps mode just to fix some failed builds or stale cache.

So I tried to see if there is a better solution for an application as small as a blog like this.

Accepting Vercel

It's not that I hate Vercel or anything. The fact that I use Next.js is already a trust I committed as it really able to address some of issues I needed, especially SSR and filesystem-based routing. But if using Vercel means that I need to release some of my "freedom", I really need to have it as cheap as possible. And somehow all the things I needed are provided by Vercel with it's free plan.

And so, I decided to opt in. Steps that I needed to do was:

Create Vercel account.
Import my Next.js App repository
Changing the DNS record to follow Vercel's guide

"That's it... that's IT??!!", was my first reaction. It didn't take more than 5 minutes to done which already covers the entire process I did for the self-hosted environment setup. For any new changes, I don't even need to configure additional pipeline as Vercel already took care of that for me. Now all I need to do was just to focus on development and that's it.

It proved that it managed to deliver a really great developer experience. I didn't need to fret over the Ops part as it's already part of features provided. And additionally, it even came with APM and observability that I needed.

Was it really that smooth? Well...

The way that Next.js structured is based on whether a resource needs to be static or dynamic. Roughly, a web resource accessed would be between static resource (images, media, production builds) that could benefit well from caching, or dynamic resources that needs to always return responses that are up to date which hurts the caching department. Those that could be cached means it doesn't need additional server-side processing. Those that don't, apparently needs workers to be always return actual response. In more detail, there are term such as SSR (Server-Side Rendering), SSG (Static-Site Generation), and ISR (Incremental Static Regeneration). We won't dive into the detail for now, but we would end up with routes/resources that can be served through CDN, or through serverless functions. On Vercel, the functions can even be standard serverless functions or edge functions.

This would add additional things to take care, such as database connection management, revalidation strategy, or even the classic serverless issues like slow cold start. But was it worth it? Definitely. Is it enough for a hobbyist? Absolutely (it's free). Would I go for using Vercel in production? I can't really say anything as I still have no experience with Next.js on Vercel in production scale. But if it's able to increase the development efficiency by a lot, then it really is something that I would opt into.

Afterwords

As my Next.js app is only a standard blog website, I haven't gotten into troubles where I need to maximize concurrency or handle thousands of users. Next.js has evolved so much during the past several years, and coming from someone who started from Next.js 8, it's definitely a feat to see how Next.js evolved. There are even some things that I could improve from learning how React.js works behind the scene.

For now, I glad I made the transition.

Thanks for reading. See ya!

Attribution

Icons by : Flaticon and Ayub Irawan

Log 0x19 - A Journey of Hosting My Hobby Next.js App