In part 1, we went over self-hosting supabase, setting up Svelte, enabling third-party authentication and email sending. In this blog post, I will talk about what I learned about routing, SSL, domain name, local storage, and hosting svelte using GitHub pages.
Routing with Nginx
Currently, there are lots of programs running on various ports of my VPS. Supabase studio on 3000, Svelte on 5173, PostgreSQL running on port 5432, and Kong running on 8000 and 8443 for HTTP and HTTPS respectively. How do I take the users that want to connect to my front end (Svelte) to port 5173, and secure my Supabase studio?
The answer is routing, we can set up a router, or a reverse proxy, to take users that are connecting from HTTP and HTTPS, which is port 80 and port 443, and route them to port 5173, my Svelte front end. To do that, I will use Nginx, because that is the most popular one. In the following, I'm going to summarize what I did to get it working, If you want a more detailed explanation or code examples, I recommend you check out this article from Linode, I find it very helpful.
In Nginx, we create a server to listen to a single port, then we tell it how to redirect based on location. Locations are the URL path after the domain name, the location for example.com is /, and example.com/terms/ is ^terms/(.*)$ . Then in the location, we can ask it to redirect to a certain port, such as proxy_pass http://localhost:5173 , this would redirect the users connecting from this port at this location to this address instead.
An important thing for Nginx is that we have to configure which rules are active. There is a directory called sites-available, and one called sites-enabled. What we have to do it to configure the settings in sites-available, then created a symbolic link to the sites-enabled directory. Then we have to restart the Nginx service to apply changes. An important thing to do is to unlink sites you aren't using, I once forgot to unlink the default rules and was wondering how the default rules were applying for so long.
Getting SSL
After that, we can redirect HTTP traffic, but we need an SSL certificate if we want HTTPS traffic. They provide credibility and encrypt traffic. There are 3 ways to get a certificate:
Purchase it from a trusted certificate authority (CA), the cost can vary from 5 a year, up to who knows how much
Let a proxy like Cloudflare do it for you, users will connect to Cloudflare with the certificate, and then Cloudflare redirects the traffic to your site, and the users see the certificate from Cloudflare. This is free for personal or hobby projects.
Generate your own using a service like Certbot, it generates the certificate for you and you don't have to pay a penny. But the downside is that you will have to configure it yourself.
I went with Certbot since it is free. The website contains very detailed instructions about installing it. After getting it, I need to configure Nginx to use the certificate, redirect HTTPS traffic to my front end, and ask HTTP traffic to upgrade to HTTPS traffic.
Domain name
Then I needed a domain name for my website, you can think of a domain name as basically a link for the website. I went over the three providers that offer free 1-year in Github student pack, namely Namecheap, Name.com and .TECH. I analyzed what service they provide and how much the domain is going to cost after the 1-year free trial. Namecheap has the cheapest domain name after the free trial, so I decided to use it.
Now I have to configure it to redirect traffic from the domain name to the IP address of my VPS. There are different types of records, the ones that you're most likely to use are an A record or a CNAME record. A records allow you to associate a domain name or a subdomain to an IP address, CNAME records allow you to point your domain name or subdomain to a hostname.
I pointed the subdomain I wanted to the IP address of my VPS, then pointed the www version of the domain to the domain without the www part.
Storing data
For the encryption function of the website, I want people to be able to generate an encryption key locally and have it stored locally. So the data they post to the server will be encrypted. This makes it so that even if the website got hacked, the hackers couldn't read the encrypted content.
Users don't want to enter the key every time they visit the website, I need a way to store the encryption key locally. I was thinking to use cookies for this task, but then I found out that cookies get sent back to the web server for every request, which isn't secure at all. So I searched that there is Local Storage in browsers now, and the information there will not be sent to the web server, so I decided to use it.
It is very easy to use, to write something to local storage, you do localStorage.setItem("name", "Chris");, and to read something, you do let myName = localStorage.getItem("name");.
Svelte can be hosted statically
I don't know how I didn't know this, I always thought Svelte has to be hosted on a VPS, maybe because I developed Django apps before and they require a dedicated host. I found this out because I was talking to a friend about how I am buying a VPS to host the website, and he asked me why didn't I use Github pages instead. I said the website needed to be hosted, but he said it doesn't. I looked into it, and turns out he was right! Svelte doesn't have to be hosted dynamically. When we run npm run dev, it runs the developer version, which is dynamically hosted because it reacts to changes. But if we do npm run build, the page is built and the dist directory. Then we can deploy through any static site hosts, including Github pages.
GitHub pages can be used for public repositories for free accounts and private repositories for Pro accounts, which I have from the GitHub student pack. Moreover, GitHub is a big website, so I'm sure loading a front end there is very fast, as they would have good content delivery. Security isn't a big concern either, since only the front end is hosted there, and the important data is secured in the back end. Therefore I will be using GitHub pages to host my site on second thoughts.
Hosting on GitHub Pages
To host on Github pages, if we want to use the user GitHub page (username.github.io), instead of username.github.io/reponame, we need to have the website in the repository with the name username.github.io . Then we can control what to deploy, we can either set up a GitHub workflow, which is GitHub doing something for you automatically, or just deploy from a branch.
To automate this process, there is an npm package called gh-pages. It enables you to deploy your new version of the build, which is inside the dist folder for Svelte projects, to a new branch. Then if you configure your GitHub page to deploy that branch, this would automatically be deployed.
There are some important things to set up. We have to configure the homepage to the GitHub page website in package.json, as well as set up a new run config called deploy, which runs gh-pages -d dist . If we are using a custom domain, we also need to create a CNAME file inside the public/ directory with the content being the custom domain name. Then when we run npm run build then npm run deploy, our GitHub page will be deployed.
Conclusion
In this blog post, I discussed my experience with self-hosting a Supabase Svelte project. I covered setting up routing with Nginx, obtaining an SSL certificate with Certbot, securing a domain name with Namecheap, and hosting the project on GitHub Pages. Overall, I found that self-hosting my project was a valuable learning experience that allowed me to gain a deeper understanding of web hosting and the tools involved.
Top comments (0)