My experience getting up and running with Homebase
I finally got round to exploring Homebase yesterday (jump straight to setup steps). My original intention was to get the SB-PH site on Dat + HTTPS à la this blog post by Tara Vancil. As far as I can tell though, without multi-writer support in Dat this setup would effectively lock Sam out of being able to quickly deploy changes. We’re interested in making that site a little bit more of a collaborative sandbox, so making deployment harder than it is currently is not the right step to take there.
So though I definitely want to get the SB-PH site on Dat eventually, we’re putting that on hold for now and I’m pivoting towards my site. In this blog’s earliest incarnation it was on Tumblr, and for a long while now has been a pretty standard WordPress site. The big task in moving to Dat, besides figuring out Homebase, is converting my site from WordPress to a static site via Jekyll/Hugo/Eleventy/GatsbyJS or something similar. It’s taking a while, I didn’t realise quite how much content has accumulated (1000+ tags?!) and there are a few WordPress-y features that I definitely want to build in (“more” tags, descriptions for tags+categories, proper pagination, etc.). More on that in a separate note.
So yesterday I put that aside and focused on getting Homebase up and running on a DigitalOcean droplet. Overall, setting up Homebase wasn’t too bad. The most involved part of the process was setting up the server. I kind of like tinkering with server stuff, so that’s cool. I 100% agree with the caveat at the top of the Homebase README, you should consider Homebase only if you’re comfortable with and interested in server administration. I would add that your interest should be *ongoing*. Servers take maintenance (related, see note on serverless setups). It’s your responsibility if a process stops running, or the software is out of date, or the Let’s Encrypt certificate doesn’t renew, etc. Hashbase looks like a great alternative for those that want the final result but don’t want to deal with the server configuration/maintenance.
The rest of this note is an outline of the steps I took to get Homebase working. Where good documentation exists elsewhere, I have linked to that instead of elaborating.
I used a DigitalOcean droplet as suggested in TV’s blog post. This works well for my needs because A) I’m too much of a newbie to set up something on a Raspberry Pi or something similar, and B) DigitalOcean’s documentation is *fantastic*. Note that a lot of DigitalOcean’s tutorials are suitable for non-DigitalOcean server setup as well.
Create DigitalOcean account. It looks like if you sign up during Hacktoberfest, you get $100 free credit valid for 60 days. If you sign up via this link then I might get some sweet referral $$$.
Create ssh keys if you haven’t done so already. Be sure to store your passphrase somewhere safe. As in, if you don’t already have a password manager, get one! See DO tutorial on setting up SSH keys
Create an appropriate droplet. I selected their Ubuntu distribution image with 1GB memory in their London datacenter region. I selected the latest Long Term Support (LTS) version of Ubuntu, which for me was 18.04. As part of the droplet setup, I added my SSH key from the step above (see related DO tutorial).
Note that Ubuntu recommends 2GB of system memory for this version, but I decided to go with 1GB anyways. ¯\_(ツ)_/¯ Time will tell if I end up regretting that, but should be able to upgrade later if need be. Note also that I decided not to use DigitalOcean’s NodeJS one-click-app because we’re better off installing NodeJS via NVM later in this setup process to avoid permissions issues (see permissions-related docs on NPM) when we install NPM packages such as Homebase and pm2.
Edit 30.10.18 — Was chatting about this with a friend this past Saturday at Mozfest. If I were to put a site on this setup and it went viral (a girl can dream?), the server would probably fall over due to the lack of system memory. Worth keeping in mind.
Point a domain name to your droplet’s public IP. You can do this by adjusting the relevant DNS records with your existing domain registrar, or you can set up the DNS records in DigitalOcean and point your nameservers at DigitalOcean (see DO tutorial on working with DNS).
Connect via SSH and complete the initial server setup tasks (see DO docs on initial server setup for Ubuntu). This includes creating a non-root superuser with external access and setting up a basic firewall.
Configure your firewall to allow all incoming HTTP (port 80), HTTPS (port 443), and Dat (port 3282). If using UFW:
sudo ufw allow proto tcp from any to any port 80,443,3282
Install NVM using cURL, and then use NVM to install NodeJS (see the README in the NVM repo).
Install additional build dependencies required by
homebase. Note that this is mentioned in the Troubleshooting section of the
homebase docs, but I found it to be a required step.
sudo apt-get install libtool m4 automake libcap2-bin build-essential
Install Homebase and pm2 (see install instructions in Homebase readme).
Add your config file at
~/.homebase.yml by running
nano or your preferred editor.
nano, you’ll be prompted with a blank editor. Use the example config files in the Homebase docs to create your own config, then type
x to exit. You’ll be prompted to save the file.
Give NodeJS the rights to use ports 80 and 443. As with step #8, this is mentioned in the Troubleshooting section of the
homebase docs, but I found it to be a required step.
sudo setcap cap_net_bind_service=+ep `readlink -f \`which node\``
Start the daemon and visit your site at
pm2 start homebase
pm2’s logging and debugging functionality is a super useful place to start if you don’t see your site at this point.
Tara Vancil’s How I publish taravancil.com was the jumping-off point for this exercise with Homebase. It is a very useful post!
Paul Frazee recently published a post titled Why bother with P2P when you still need to guarantee uptime?. The “it’s cheaper” argument is particularly compelling. Alongside his points, I would add that a server for guaranteed uptime may not be critical if/when Dat gains enough traction. Even if that never happens, and people just getting started on Dat have to use some sort of service such as DigitalOcean+Homebase or Hashbase if they want guaranteed uptime, IMO that’s ok! Should we not be more jazzed about creating alternatives rather than completely eradicating these services?
Aral Balkan wrote a short, useful post this past summer titled Multi-writer Dat could power the next Web. I’m struggling to find much info on where multi-writer Dat is at, so might use that as a jumping off point.
Edit 26.10.18 at 19:19 – Just happened to be listening to Episode 3 of DatCast, it sounds like Hashbase might be good for managing Dat sites with multiple users, so maybe a solution for the SB-PH site? I don’t think they’re supporting full URLs yet though, just Hashbase subdomains. Supporting proper DNS definitely sounds a little scary for a bootstrapped startup, that is a lot of pressure. Also, they elaborated a little on the complexities surrounding multi-writer support on Dat. That is major in and of itself, but to try to implement a layman-friendly multi-writer UI within Beaker… That sounds like a bear. So though multi-writer support might come soon-ish to Dat, it might take a while longer with Beaker. Totally fair enough! [That podcast episode is from months ago though, so the status of Hashbase/multi-writer has probably evolved, need to dig deeper.]