Connecting An Existing Firebase Hosting Project To A New Site

As a follow-up to my last post on GitHub Pages, I mentioned that I moved one of my websites to Firebase. Firebase is a platform from Google for creating web and mobile applications. As a PaaS offering, there are a lot of different parts to the service, but as a platform for web applications hosting is naturally one of them. The free Spark plan offers 10 GB of storage, 360 MB of data transfer per day (which works out to 10 GB of bandwidth per month), and support for custom domains and SSL. That’s more than enough for me to host a simple, single page website that’s only made up of static HTML, CSS, and a single image. If anyone is curious, my site is using just 1.8 MB of storage and 15 MB of bandwidth. Note that bandwidth used divided by storage used will not be indicative of total hits due to caching, compression, etc.

I’ve used Firebase before, so I already had my Google account linked up to Firebase, and I even had a project still technically “live” there, though the domain had long since been shifted somewhere else. To be honest, it had been so long since I used Firebase that I almost forgot about it until I just happened to start receiving some well-timed emails from the service informing me that I needed to re-verify ownership of the domain I was using for my defunct project. I had no interest in re-verifying anything, but I did want to start hosting something new there.

The first step for hosting new content was to log in to the Firebase Console. Since I had already used the service, this gave me tiles of my existing projects; in my scenario, I just had a single project for my hosting. I clicked on that tile, and I was taken to a Project Overview screen. This gives me a high-level look at my project. To get to the hosting-specific functionality, though, I just had to click the Hosting option under the Develop menu to the left.

On the hosting dashboard, the first item listed contains all of the domains associated with the project. Clicking the 3 dots … next to a domain allowed me to delete it; I removed the two entries (apex domain and www) for the domain I used previously. Then I clicked the button for Add a custom domain. I followed the instructions on the screen to add a custom domain; I won’t document the steps here since they’re directly covered through the Firebase custom domain documentation.

With everything configured on the Firebase side, I next needed to crack into the Firebase CLI to link up my local project. I opted to install the standalone CLI, though you can still get it through npm if you prefer to roll that way. The first thing I had to do was link the CLI to my Firebase account. This is different based on whether you’re going to be using the CLI from a system with a GUI or if you’re doing it from a headless system you’re accessing via SSH. I was using it from a headless system where I cannot pop a browser to follow the normal authentication process; as a result I ran:

firebase login --no-localhost

If you’re running this from a system with a GUI, I believe you just omit the --no-localhost parameter. In the headless setup, though, this gives a Firebase URL to navigate to on another system. I copied it out of my terminal and pasted it into the browser in my laptop. This gives me an authentication code for the CLI. I copied that from my browser, pasted it into my terminal, and that linked the CLI to my account in the Firebase platform.

Since I was just moving my content from my old VPS to Firebase, I didn’t have to worry about actually creating a website; I already had one that was backed up in a tarball. I simply had to expand my tarball on the same system where I was using the Firebase CLI. I did this by creating a new directory for the project, expanding my tarball that had all of my site’s content, and then copying that content to the project directory:

mkdir ~/laifu
tar -zxvf ~/temp/laifu.tar.gz
cp -r ~/temp/html ~/laifu

Note: If you look closely at the commands above, you’ll see that after I expand the tarball I’m recursively copying not the entire directory but the html folder from it. This is due to the fact that my tarball is of the entire /var/www/laifu.moe/ directory that Nginx was previously hosting on my VPS, and the html directory is what contains the content of the site. If your backup is storing the content directly (e.g. it’s not in a subfolder) that’s fine. However, you’ll want to make a new folder inside of your project directory that you copy the content to because you do not want the content of the site to be in the root of the Firebase project’s directory. For example, your mkdir command would look something like: ~/myproject/html

One I had the files situated accordingly, I needed to tell Firebase that my directory was a Firebase project. Similar to using git, I do this by navigating to my project directory and running:

firebase init

This gets the ball rolling by asking some questions interactively through the CLI. One question will ask what service the project should be connected to; be sure to pick “Hosting.” After that there should be a prompt for which existing hosting project you’d like to use. The existing project should be listed as an option to be selected. If it’s not there, you can cancel out of the process and ensure everything worked correctly with your authentication by running the following and verifying that you see the project. If it’s missing, you may need to redo the authentication (e.g. maybe you were in the wrong Google account when pasting into your browser.)

firebase project:list

After selecting the project, the CLI will ask what to use as the “public directory.” This is essentially asking what directory inside of the project directory contains the web content to be hosted. In my case I picked html since that’s what I named the folder.

Be wary of the next couple of prompts, which will trigger regardless of whether or not there’s something in your public directory matching them. When prompted about your 404.html page, opt not to overwrite it unless you really hate your existing one. When prompted about index.html, definitely don’t overwrite it or you’ll lose the first page of your site.

Once that’s all done, you should get a message:

“Firebase initialization complete!”

This means that the directory has been initialized successfully as a Firebase project, but the local content still hasn’t been pushed to the cloud. So the last step is to run the following:

firebase deploy

This will give a “Deploy complete!” message along with a Firebase-specific URL in the format of:

https://project-name-GUID.web.app

Copying this URL and pasting it into a browser should allow you to verify that the content you expect is now being hosted, even if you’re currently waiting for DNS TTLs to expire before you can navigate to the custom DNS. The Hosting Dashboard of the Firebase console will also show the update in the “Release History” section.

GitHub Pages Hosting

As I had mentioned in my post about Dropbox Passwords, I’m looking to cut down on the number of services that I pay for each month. One of the areas I’ve decided to cut down on are my domains; I’m letting a few domains that I never ended up finding much of a use for expire rather than having them automatically renew. Some have been renewing like this for years just because I didn’t want to lose them for some reason despite never having any real use for them. With a decrease in my domains comes a decrease in websites, to the point where I started to wonder if I could get away with ditching my VPS. I had been using the same VPS for over 2 years, and it served me well. In a world with so many hosting options, though, it seemed overkill just to run 2 static websites, each of which were only a single page.

One of my sites I placed on Firebase. I’m not a fan of using Google products, but I’ve used Firebase previously (moving my website to an existing, stale Firebase project will be the topic of another post), and the free Spark plan gives me more than enough for a simple site with 1 GB of storage and 10 GB of egress traffic each month.

I wanted to check out some different options for jfabhd.com, though. After recently reading one of Kev Quirk’s blog posts, I thought I would give Netlify a shot. Their free Starter plan seems great for a simple hobby site and includes CI (continuous integration) from a git repository. I signed up for an account but quickly disliked the fact that leveraging my own domain meant I needed to move my nameservers for it to Netlify. While this isn’t horrible, I really prefer to keep managing my DNS in a single place as opposed to scattering nameservers around to wherever my content is hosted. Currently all of my personal domains have DNS hosted in the same place, and I’d like to keep it that way. As a result, I shelved the idea of Netlify and looked to GitHub Pages instead.

I actually used GitHub Pages before, way back in the day when they were brand new and I set up my first Jekyll-based blog. It wasn’t bad by any stretch, but a lot of it was clunky. I remembered having to manually add some text files to the repository to configure my custom domain and to host content out of a folder that was named differently than what was expected. Likewise, there were no SSL options, so I ended up putting my GitHub Pages site behind CloudFlare in order to secure it. I figured this would be a good opportunity to see what, if anything, had changed. If I hated it, I wouldn’t be out anything and could continue to look at other options.

The initial setup is still the same as I remember: just create a public repository with a name of:

github-account.github.io

I did this through the GitHub website in less than a minute. Next up I ran git clone in order to initialize the repository on my local laptop in the same directory where I keep all of my other GitHub repos. With my local environment ready, I just copied the handful of files that I had backed up from my VPS into the root directory for the repository; if I don’t take any other action, GitHub will host content from the root of the repo. Since this is a static, single page site, I don’t need to worry about compiling it with static site generators like Jekyll or Hugo. I was able to commit the change for adding the files, navigate to https://jfaby-noc.github.io, and see my site.

With the content out of the way, I wanted to set up my custom domain. The GitHub side of the work can now be done through the Settings menu of the repository; it basically replaces the manual work that I previously had to do by adding files to my repository:

The top allows me to change the branch and directory to host content from; in my case I could just leave the defaults. The Custom domain sections allows me to type in my domain of choice. This just adds a file named CNAME to my repo containing the domain information. Then I just had to follow the directions for setting up a custom domain in my DNS host’s settings.

Note: It’s a little wonky from the directions, but to make GitHub redirect everything appropriately when using both an apex domain and a subdomain, you follow both sections of the instructions verbatim. For example, I wanted the domain to be jfabhd.com, but I also wanted www.jfabhd.com to still redirect to the site. I configured the apex domain via the instructions above, creating 4 A records pointing to different IP addresses. Then I configured a CNAME record for www.jfabhd.com pointing not to jfabhd.com, but instead to jfaby-noc.github.io. If you do it this way, GitHub will work it all out under the hood.

Immediately after setting up my DNS records, the option for Enforce HTTPS was not available, telling me that the site was not configured properly. I rightly assumed this just meant DNS needed time to propagate. I checked back 15 minutes later (which is the TTL of my DNS records), and it presented me with a new message that the certificate wasn’t finished being created yet. I once again rightly assumed that they were spinning up these certificates through Let’s Encrypt, so I browsed Hacker News for a few minutes until refreshing my repository’s settings showed that the option to force HTTPS was now available. I simply checked the box, waited a few minutes, and then verified that going explicitly to http://jfabhd.com would redirect me successfully to https://jfabhd.com. If this doesn’t work for you, chances are that you just didn’t give it enough time. While the tooltip in the GibHub UI says it can take up to 24 hours, it took about 5 minutes for my site.

The last thing to check was that the CI was working so that changes to the repo would be reflected on the site. A few things had changed since I took the backup of my site, meaning there were some needed tweaks with which I could test. For one I restarted this blog and I deleted my Twitter account since Twitter is a cesspool (that might be a good topic for another post…), so I wanted to swap the Twitter link on my site with one for this blog. I first did a git pull to get local copies of things like the CNAME file that had been made in the cloud, and then I quickly updated my HTML to share a link with the Font Awesome RSS feed icon as the content. After committing and pushing the change, I refreshed the site to confirm it had also been updated.

On the whole, there’s really nothing for me to complain about with GitHub Pages. It’s free, I can use the same GitHub account I’m already in every day, I can use a custom domain without moving my DNS, and I get a Let’s Encrypt certificate out of the box. Obviously, though, my use case for it is very simple, and your mileage may vary. With options like this, though, I feel even better about my idea to stop running my own VPS just to host a couple of small, low-traffic websites.

Self-Hosting A Static Website

Earlier this week a friend reached out to me regarding a website. He had just finished developing his very first iOS game and was ready to submit it to Apple for approval. One of Apple’s myriad requirements, though, is a website containing the author’s privacy policy. My friend had no website and no idea how to make one, so he asked me if I could help. It seems wild to me that someone could have the chops to make an iOS app in Objective-C or Swift but not be able to make a website, but each of us has a different skill set.

We first took some early steps gathering requirements. What did he want for the site? Literally just the privacy policy. Where did he want to host it? Wherever was the cheapest. Did he have a domain name already? Yes! This was fairly straightforward; he literally just wanted the very basics. After a bit of discussion I convinced him to write up a quick “about me” type of page so that we could have more than just the privacy policy. From there I could get to work.

Hosting

The first thing I did was have him head over to Vultr and spin up their cheapest instance. I think this is running him $5 USD per month. I had him pick Ubuntu as the server operating system given that it’s the one I’m most familiar with. My friend has some familiarity with Linux but not a lot of practical knowledge; when I asked him to shoot me some SSH credentials with sudo access he literally sent me the root account from Vultr. Ick.

Configuring The Host

Accounts

My first goal was to configure the host. I started that off by creating user accounts for each of us:

adduser username
usermod -aG sudo username

After switching users and verifying my new account worked, I disabled root’s ability to log in:

sudo passwd -l root

Ports

Next I wanted to change the default SSH port since having 22 open means a million places from across the planet are going to throw garbage traffic at your server. I did this by modifying the SSH config at /etc/ssh/sshd_config, finding the line with #Port 22, uncommenting it, and changing the port to a high number of my friend’s choice. Then I restarted SSH:

sudo systemctl restart ssh

Firewall

I wanted to enable the firewall as well, so I opened up with the new SSH port and 80 and 443 for our eventual website:

sudo ufw allow sshPortNumber/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Webserver

I next needed a web server; Nginx has been my go-to choice for a long time. Rather than re-hashing all of the steps, I’ll just recommend following the excellent documentation from DigitalOcean which nicely covers the Nginx configuration. That takes you to the point where you are hosting a website. Then you just need content on it.

Certificate

I’m an advocate of using HTTPS for everything, and with free certificates from Let’s Encrypt there’s no reason not to. Given that we have shell access, using certbot is the way to go. There’s also excellent documentation on that process on Ubuntu with Nginx. I highly recommend selecting the option to redirect any HTTP traffic to HTTPS.

Website

Now for the website itself. I’m not really much of a web developer, and I dislike making anything frontend; I don’t exactly have the best design sense. So I once again opted to leverage Hugo to take care of that for me. I’ve written about the specifics of using Hugo in detail. Since we really just wanted a generic landing page with my friend’s socials and then links to the About and Privacy Policy pages, I ended up going with the Hermit theme. It has a nice, simple look. My friend’s favorite color is mint green, so the default background also works nicely with that when I changed the accent color. The theme nicely includes an exampleSite so that I can steal their config.toml file and also their “About” page to make things even easier for myself.

Backups

One of the nice things about Hugo is that, since everything is a simple text file, it’s very easy to compress your entire site and save a backup. Then if something terrible happens to your server, it’s extremely easy to get the site back up and running on a different machine. In this case, I made tarballs for both the finished, compiled site and the Hugo directory storing the configuration and Markdown.

tar -zvcf ~/temp/html_output.tar.gz /var/www/mySite.com/
tar -zvcf ~/temp/hugo_directory.tar.gz /var/www/mySite.com/

With the tarballs created, I used an SFTP client to copy them off the server for safe keeping.

Wrap Up

In total it took me about an hour and a half to get everything up and running. Having gone through this process many times for websites of my own, I’ve got a decent bit of experience with the process, but this shows it still doesn’t necessarily take a super long time to get a decent website up and running. The big benefits are:

The site is cheap to run. Even the smallest instance at any VPS provider will be able to handle multiple sites with ease unless they start getting really popular, so if my friend wants to create any other sites in the future he won’t need additional hosting.
Backups are stupid simple. My friend isn’t beholden to a hosting provider or trying to work within the confines of something more expensive like WordPress or Squarespace.

The downsides are present, though, so you have to be cool with them:

Setup takes more technical chops than clicking through a Squarespace template editor. While the documentation for everything in this post is extremely good, if working out a terminal freaks you out then this likely isn’t for you.
Content is authored in Markdown. This likely doesn’t matter for my friend at the moment since he’s not really posting anything new to the site, but it would be something to keep in mind if he decided to start a blog. In that scenario, I usually just SSH to the server and author my content in Vim. You could also author the Markdown elsewhere and copy it to the server, or use SFTP to open the Markdown file on the server from an editor on your local machine. It’s definitely not as simple as a WYIWYG editor in your browser, though.
Maintenance is something that will need to be done at least periodically. The server will need to be patched. That’s easy enough to do with a simple sudo apt update && sudo apt upgrade and then reboot when necessary, but it’s just another step to keep in mind. Likewise, bouncing the server means that the website will be down, even if it’s typically only for a moment or two.

Being kind of pretentious, technical snob I personally find it easier to author my comment in Markdown on Vim instead of using a WYSIWYG editor in a GUI, but your mileage will vary based on your own prefrences.

Switching To Squarespace

If you happened to see this site around the time when the first post went up, you might notice that:

The site looks very different now.
A lot of what’s in that first post no longer seems to be true.

For example, this is not the Rusty theme for Hugo. Those technically savvy would also notice that the site no longer has the same DNS record value as laifu.moe where things were originally hosted. That’s because the site is no longer running on my own web server and is not created using Hugo. There were a few reasons for this. The main was just that I’m really bad at web design. The Rusty theme in Hugo is pretty light on imagery, which I’m cool with. Once we decided to actually make Unusually Pink into a thing and do a podcast, though, we had our amazing logos made by the uber-talented JPFDesigns. Integrating those into the Rusty theme for Hugo was a bit more than I was up for; CSS is legitimately the final boss of my life, and my life is (apparently) an NES Contra game; I couldn’t do it.

The other reason was just that it allows for much better reliability. The site isn’t beholden to my ability to not mess up my web server. Not that it’s particularly likely for me to do something to brick it (I’ve been using Linux and Nginx for my web servers for ages now), but it’s possible. I was also responsible for backups, which I’d prefer to take off of my own hands if possible.

The last reason was that the site really needed to be divided from one main section (e.g. the blog I originally planned just to do something with the domain) to two sections: a blog and a list of podcast episodes. While I was able to just dump a /podcast directory into my static folder for Hugo, it meant that posting podcast episodes and summaries was now an entirely manual process rather than something assisted by a CMS-esque system like Hugo.

Swapping to Squarespace allowed me to let someone far smarter than me figure out all of that within a theme; all I had to do was upload some images (Squarespace is awesome at scaling images for me, even when it needed to make one tiny for the favicon) and then swap around a few of the colors in the theme to get something unusually pink. I was also able to simply add two blogs to the site; one is a normal blog and the other will have posts for each podcast episode. In this way, both sections of the site are managed by a CMS rather than being done manually. Doing it manually may not seem like too big of a deal at first, but once you start to get too many posts for a single page, creating and manually updating the pagination after each new post would be enough to drive someone insane.

As for choosing Squarespace, it’s the one I’ve heard the most about through various avenues on the Internet. Their pricing was reasonable, and I figured it seemed like a safe bet since I know a few other people who have experience with them. The other recommendation I got was Wix, which I admittedly had never heard of previously. Looking at the pricing for Wix compared to the pricing for Squarespace, though, I think it’s clear that Squarespace is a better deal. The Wix $11 USD per month package is pretty lackluster, especially when you look at 2 GB of bandwidth and 3 GB of storage. To get something more comparable to Squarespace’s $12 per month package that includes unlimited bandwidth and storage, you’d need the $14 per month plan from Wix… and that still doesn’t give you unlimited storage.

Expect the site to still go through a few minor changes as we continue to tweak the layout, colors, and everything else. Feel free to drop any feedback to our Twitter profile!

It’s all about being Unusually Pink.

This domain was a completely random purchase. Earlier today while taking a break from work (which was sorely needed… I had 3 weeks off over the holidays, and coming back today was not easy), I decided to hop on Mastodon for the first time in quite a while. A friend of mine who was previously on the same instance as me had apparently swapped to a different instance during the month or so that I was gone. I just happened to get lucky enough that another individual I follow happened to boost a toot from him; this friend was using the same avatar on his new instance that he used on the previous instance, so I immediately knew it was him. In seeing what instance he was on, I was a bit surprised. It had a .pink TLD. I had no idea .$COLORS was a thing now.

I hopped over to my registrar of choice (Namecheap) and saw that I could snag a domain for just $2.88 USD. It was a no-brainer. This was especially true because another friend of mine has a saying about the color pink. She doesn’t normally enjoy pink things, but she likes things which are (to quote her) “unusually pink.” A pink heart? Boring. A pink Razer keyboard and mouse combo? Unusually pink and therefore extremely cool. (If you happen to be curious, I own both that keyboard and mouse. They match wonderfully with the pink LEDs in my gaming desktop. Bonus points to me if I’m using them to play Overwatch while wearing my pink Mercy t-shirt.) Hopefully she wasn’t too mad that I snagged this domain. If you’re reading this, I’m sorry. But I did offer up a sub-domain of her choice should she want one!

At any rate, I made the purchase but had no idea what to do with it. After rolling a few things around in my mind, I decided that I would just make a blog on it. I used to blog a lot back in my college days, and I managed to garner enough readership that a few companies would occasionally send me free anime and video games if I promised to write a review on my blog. I lost my luster for writing a few years back, but maybe this will motivate me to do it more frequently. I already had the hosting space available on my VPS currently running laifu.moe, which doesn’t need all of the resources on the server by a longshot. Plus, I found this sick theme! It’s Rusty from the Hugo Themes gallery. It also gave me an excuse to learn how to use site blocks in Nginx as I’ve used Nginx for years but never with multiple sites on the same server. Spoiler alert: it’s super easy to do.

Hopefully I’ll put up more posts in the near future! They’ll be… unusually pink.