Sitemap
Alwin Sunil

Alwin Sunil

Fullstack Developer, CS Student at Kalvium. Around 2-3 hours a day, I work on my project CodeHost. Track my progress in my journal.

Day 31: CodeHost

2 min readSep 24, 2024

Today, I started by looking at a few ways how I deploy the request-handler service for the project and the few options are to use serverless compute like lambda or Cloudflare workers. Still, as each site can have multiple files loaded on request this can hit a huge number of request usage and may cost a lot at scale, even ignoring this I wrote a simpler version of the handler with Cloudflare db and key store. Still, in the free tier, it only supports a compute time of 10ms per request, which is just unusable.

So I went with the basic option to run it on a virtual machine, for deployment I chose t2.micro from AWS and it's running an NGINX server that receives all the HTTP and HTTPS requests and forwards to the node process running. As manually doing this is inconvenient and takes time, I went to use docker-compose to run two services ie request-handler and nginx service with volumes and a bridge network attached.

Get Alwin Sunil’s stories in your inbox

Join Medium for free to get updates from this writer.

This made deploying new changes and running the service in the VM much easier. The VM is running Amzon Linux with docker and docker-compose installed. I ssh’ed into the system and cloned the project, moved to the directory of their quest handler added the env’s using export manually for the time being and runner the command docker-compose up, this starts both the service and attached process to the terminal. For HTTPS, I have configured to use the certificates generated using certbot. For that, before running the docker-compose I created the certificate using certbot manually through the shell, and now it's not auto-renewing, I will be updating it. And added the fills to docker as a volume so the NGINX service will have access to it. After the certification, I ran docker-compose start at the request-handler which runs the process in detached mode(in the background) thus, service is available even after closing the remote terminal connection to the server.

Finally added inbound secret rules to allow HTTP and HTTPS requests at 80 and 443 ports respectively and pointed the domain *.codehost.alwinsunil.in to the public IP address of the EC2 machine. Thus deploying the service to the public.

Also removed the rate limiter from express logic and configured NGINX to rate limit the request after 50 requests per minute from the same IP.

That’s all for today, thank you for catching up.

--

--

Alwin Sunil
Alwin Sunil

Written by Alwin Sunil

Fullstack Developer, CS Student at Kalvium. Around 2-3 hours a day, I work on my project CodeHost. Track my progress in my journal.