Miguel Bracamontes

I just migrated my website from Codeberg to NearlyFreeSpeech (NFSN). There's a lot to take in, but it feels awesome to finally have it up and running. With NFSN, you've got way more control, make your own decisions, and the pricing is fair and affordable for small basic blogs like mine. Plus, Codeberg is more geared towards cooperative development and FOSS. My hosting needs are different because I'm running a personal website with a more opinionated vibe.

I'd never used FileZilla before, and this seemed like the perfect opportunity to make the switch and start figuring it out. It's a name I've seen around a lot over the years, but I never really understood how to use it. Digging into my NFSN panel, I stumbled upon the SFTP info for connecting and uploading. After a bit of web surfing, I seized the chance. It was the shortest learning curve I've ever had. It was as streamlined as this article, and in just a few minutes, I was in the server, uploading the website files and online.

Even though there was an option to handle everything through the command line, I opted for the GUI. I feel like, given the way I'm building this website (without using generators), I can have more control over each update and any new blog post. I keep a local version control with Git, and I keep pushing the changes to the now private Codeberg repository. However, cloning the repo to the NFSN server and writing a hook for it to checkout to a public branch and publish each push felt a little overkill. I preferred to go with the FileZilla comparison mode, where I can also track changes in files and only push the updated versions with a couple of clicks. It's as easy as the full automation, I feel.

When you go with these kinds of hosting services, there are also some responsibilities that fall on you. Security is the most crucial. NFSN provides the basic (almost obvious) protections based on their infrastructure. However, it's up to you to ensure your site is secure. In my case, since the blog is built with the most basic technologies and vanilla applications, the attack surface is tiny. Creating a well-configured .htaccess file should do the trick. Also, ensuring there's an active TLS certificate and enabling redirection will pretty much wrap up the security tasks.

I make sure that the .htaccess file covers the basic security practices, like minding XSS attacks by setting X-XSS-Protection to "1; mode=block"; preventing clickjacking by always appending X-Frame-Options sameorigin and preventing MIME sniffing by setting X-Content-Type-Options nosniff. Plus, I get to play a little with the URL aesthetics and that's cool.

I recognize this is not the biggest operation, but again, being a self-learning tool, its results are more than satisfactory, and overall, this has been a rewarding experience. It's been a blast to do, and eventually, it'll be a happiness machine with countless opportunities to learn and grow. It just takes a bit of hands-on tinkering.