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.

Unusually Pink Migration

So Long, Squarespace!

If anyone stumbles across this site who was previously an Unusually Pink reader, then you might notice that the site looks a bit different after a few months of hiatus. In the short, just under 2 year lifespan of the site it has now moved to its 3rd host. Originally it was hosted on a Vultr VPS that I had been hosting a few other things on, back when I originally bought the domain because I loved the name but had no idea what to do with it. Then Brandi, my former co-host, and I decided to start a podcast; it quickly became apparent that my web development skills weren’t exactly up to par with what we wanted to accomplish. As a result, we moved the site over to Squarespace.

Our podcast lived just long enough for the Squarespace hosting to renew before Brandi and I both decided that things had run their course. It was unfortunate that I had just forked over another year’s worth of money to Squarespace for hosting before reaching that decision. With that being said, you might be wondering why on Earth I’d be re-hosting the site somewhere else if I still have time left on the Squarespace subscription; more on that will come a little later on. With this being my first time using Squarespace, though, I thought I would first share some thoughts after running a site there for a year.

The Good

When I initially decided to move the site from my VPS to Squarespace, it was mainly because I knew I needed hosting somewhere, and it seemed like a good chance to mess around with something new. I had run numerous blogs on a free WordPress.com account along with compiling many of my own blogs with Hugo as I tend to discuss frequently. With us wanting to have a presence online that made us look like we knew what we were doing, though, I figured this was a worthwhile opportunity to justify spending the money on hosting with Squarespace.

Squarespace offers, hands down, the nicest management interface I’ve ever seen. Everything is very slick and inviting, without being overly cluttered and complicated. It’s simple to add new pages to your site or even branches to your site. For example, I originally migrated the blog I had been running under the Unusually Pink domain to Squarespace, but I quickly realized that the best way to handle the show notes for each podcast episode would also be basically a blog. It was trivial to literally add another blog to the site; I just had to tell Squarespace what directory I wanted to host that under and which of the two would be the “main” page of the site. The two were then independent of one another.

Squarespace doesn’t offer nearly as many themes as you’ll find with something like WordPress, but all of the Squarespace themes are highly customizable without having to wander into the realm of HTML and CSS. For example, for any theme I can change literally every color by simply using the menus presented to me. On the flip side, the WordPress theme you see right now only offered a handful of elements for color modification. Even worse, this theme offered more options than many of the others I looked at, where changing anything beyond the text color would’ve involved modifying the CSS.

Finally, Squarespace gives you an absurd amount of information about the traffic to your site, all without the need for any type of plugins. You can simply link up Google credentials to integrate with Google Analytics, for example, and see what people are searching for to reach your site, what position you’re in for the search results, the click percentage, how many impressions you get, etc. It also offers a very slick, interactive map if you want to drill down to the specifics of where your hits stem from.

The Bad

The main purpose for the previous site on Squarespace was blogging. Case in point, there were two blogs hosted on it; one for my own random posts and one for the show notes that went along with each podcast episode. Easily the single biggest nail in the Squarespace coffin is that the service is in no way designed for blogging. That might seem contradictory considering I just said that I hosted not one but two blogs on a single site there, but allow me to elaborate.

Adding a blog to Squarespace just means that when you go to edit the site, you have two different streams of posts you can choose from. You pick the blog, say you want to make a new post, and start to edit the content. This is where things immediately get murky. The editor for authoring content in Squarespace is pretty bad. It tries to break the content of each post down into blocks the way the current WordPress editor does, but it does so in an extremely clunky, unintuitive way. Simple things like handling the appearance of media you upload is often not possible, meaning that I had to resize every photo prior to uploading since I knew there would be no good options for scaling this after the fact. Likewise, trying to embed any sort of content was frequently gated behind a paywall; I couldn’t embed the player for each episode into the post with the show notes because they wanted me to pay more for that privilege. I couldn’t embed tweets but had to just link to them. That may not have been a big deal were it not for the fact that the Squarespace plan I was on was already more than double what I’m paying for hosting now.

As another blow to blogging, Squarespace doesn’t provide any real outlet for managing the posts on the site. While in the management interface, for example, going to one of the two blogs I had added would simply show me a lists of posts on the left in chronological order. If the post I needed to modify was at the very bottom of the list because it was old, then I had to just keep scrolling until I got to it, letting the clusters of posts incrementally load the further I scrolled. There weren’t any options to just search for the post I wanted. This may have been a limitation of the theme I selected, but I was equally disappointed that I couldn’t search the blog itself for specific content, either. I frequently author blog posts that I know will help me in the future; they live on a blog as opposed to just in my personal notes because they might also be beneficial to someone else. If I can’t easily get back to that content, though, without mindlessly clicking a “Next” button, that’s a problem. This WordPress blog offers both a search box and sane pagination; neither was an option for my Squarespace deployment. I’d frequently have to search the web for what I wanted to find with the URL of my own site to reach it. That’s a problem.

The last thing I’ll mention is portability. Admittedly, WordPress might be just as bad at this, but it’s extremely difficult to take content from Squarespace and move it somewhere else. This was the big reason why I didn’t want to continue creating content on Squarespace even though I’ve already paid for the hosting there; I knew that I didn’t want to stick with Squarespace once the current hosting expired, but anything new I posted there would just be more work to move to somewhere else later on. Squarespace offers you the ability to export your content, but it’s to an XML file. While this will get the written content for each post and the metadata about it, it will not include any media. I managed to throw together a bit of a workaround that’ll most likely be the topic of my next post, but it was still a large amount of work to move everything from one host to another.

An obvious question at this point would be:

But aren’t you just in the same option regarding portability after moving to WordPress?

The answer is… maybe. As long as I don’t become disenfranchised with the platform as a whole, there are many different WordPress hosting platforms out there. If I want to move from one to another, I can easily export my site or take a backup of it and move the content somewhere else. I had initially tried moving a lot of the content from Squarespace to a Hugo site I already ran, but I very quickly ran into many of the same issues I described with Squarespace regarding management and discoverability; while being lightweight is nice, sometimes having a CMS is beneficial.

Wrap-Up

Despite the vibe you may get, I don’t dislike Squarespace at all. I feel like their business is really tailored to users who want a professional, mostly static website but who don’t have the skills to create that themselves. For a hobbyist like myself with a focus on blogging, the premium you pay for Squarespace gets you essentially nothing. Any WordPress instance is going to be a better blogging platform, and one that is significantly cheaper at that. Similarly, if you need to have firm divisions in your site (e.g. a blog for the sake of shitposting and a blog for podcast show notes), you can’t easily do that within WordPress. While you can create multiple pages, such as the About page here, you can’t set up an entirely separate blog.

At least for the moment, what I did with Squarespace for both a blog and podcast repository wouldn’t be possible with WordPress. For a standalone blog, though, the experience is significantly better on WordPress. It’s important to understand what the goal of your site is and what you need out of your platform. When that goal changes, moving platforms might be the best move. Hopefully my next post on how I migrated my images between Squarespace and WordPress can help with that.