The importance of keeping software maintained (migrating from VPS to Cloudflare)

Over the weekend I spent some time migrating some of my websites from a VPS to Cloudflare Workers and Pages. While I got the majority of things up and running in no time, it wasn’t all sunshine and rainbows. Let’s have a look at some of the problems that complicated the move.

I was using Cloudflare already

Important to note, that my move to Cloudflare didn’t come out of the blue. I’ve been using their rather generous free tooling for years now. Specifically for my website dedicated to escape games, their DNS services have been rather useful (apex domain as CNAME is glorious and every provider should have support for it). I’ve also been using a worker to handle prerendering for better SEO as well. So I’m familiar with their offering and know my way around the dashboard and documentation.

For this migration, I was planning to move the actual hosting of a few websites towards Cloudflare as well. As they are all static websites, I didn’t need any fancy server setup — so my choice landed on using Cloudflare Pages to manage the actual file serving. Besides that, I had an API proxy to manage the data from Storyblok, which I use as a CMS. Here is a quick drawing to explain the old setup, and the setup I had in mind:

Static File Hosting migration

Diving directly into what was giving me problems, and is the reason I’m writing this blog in the first place. You didn’t expect that, did you? Static file hosting is super easy after all — you upload some files to a magic place and they become available. While that is true, I did run into a lot more issues than you might expect.

First things first, Cloudflare Pages is super easy. My code is hosted on Github, so all I had to do was walk through the Pages wizard and configure it to build my website (written in Vue) and subsequently deploy it from the dist folder. Easy as cake. I executed these exact steps for another website of mine (iamatthijs.nl) and it worked straight out of the box.

The problem with my escapegaming.io codebase is that it wasn’t updated in a while. The last change I made was about 2 years ago, and I don’t need to tell you that technology doesn’t stand still. In this case, the results were rather dramatic. My website wouldn’t build anymore. Node versions have changed, and packages have seen a thousand and one CVE reports that have since (hopefully) been resolved with minor updates. It meant I needed to dive into my code, into my packages and the default node version used.

Package updates

If you’ve ever built a website with a popular frontend framework, you’ll know they use a massive amount of node modules that are all intertwined. So step one was a simple one: try and update packages to see if that magically resolves my problems (npm update). Okay. Different error message. Suddenly some of the exports I was using weren’t available anymore. But… npm update doesn’t do any major package changes… Ah well, no time to contemplate the ecosystem. Off I went fixing some imports, and sure enough, I can now run my website locally on my laptop again! Progress! Let’s try a production build, and see if it also works now.

Down the Node rabbit hole

As you might have expected from the paragraph title, no, production builds didn’t work yet at this point. I got a rather interesting error message, complaining about ‘digital envelope routines’. Any clue what they are? I certainly didn’t, so off I went Googling for a solution as you do in this situation.

This is when things got interesting. I came across a rather popular question on StackOverflow, describing the exact issue I was facing: https://stackoverflow.com/questions/69692842/error-message-error0308010cdigital-envelope-routinesunsupported. Great, so I just do whatever is in the answers and we should be good to go. Well… that’s where you’re wrong. Or rather, I didn’t want to, at first. See, the problem with my error is that this is caused by a bunch of security issues that have since been resolved — and properly solving the error basically means ensuring the security issues are resolved.

What the by far most popular answer to this question said, however, was a bit mind-boggling. It said to use a workaround, that would allow you to bypass the error message and run your app with security issues. So rather than solving the security issues, just accept that your website is open to security threats. I certainly wouldn’t want that for my website. Now, in this case, my website is rather underused and small, but imagine doing this for your website where user details might be involved. Let alone payment or banking statements!

I admit defeat

Not a great paragraph title to begin with as it spoils the ending a bit. Yes, I did admit defeat. After a bit of struggling, I admit to doing exactly what the most popular answer suggested: use a workaround to still use the insecure context. As I mentioned before, my website is small and proves no real significant purpose or exposes anything important — so I accepted my fate.

But why then, when I just made such a big deal out of using this insecure workaround? Well, to use the more secure setup, I had to make a massive amount of updates to my website. What I needed to do here, was update the majority of the node modules that I used to a version that weren’t insecure (generally achieved with npm audit fix — —force ).

If you know web development a bit, updating the majority of packages to a newer version is rather cumbersome. Especially if you haven’t done so for a year or more. The available functions, way of working, imports and exports might have changed so much — that you’re basically rewriting the website from scratch. As was exactly the case for me. And that’s something I didn’t want to invest the time in at this stage.

Had I updated my code more frequently in small increments over the past year or two, I wouldn’t have been in this situation to begin with. My website would have been up to date with the latest packages, taking advantage of the security updates, but also performance updates, for example. I should have maintained my website’s code.

Moral of the story

When I had finally admitted defeat and pushed the workaround to the git repo, it was back to smooth and easy sailing. The Cloudflare Pages deployment went off without a hitch, and things were up and running in literal minutes. Of course, the Pages setup was only a small portion of the migration, but it was by far the most time-consuming. If I had updated my code a bit more frequently, I wouldn’t have spent so much time trying to find a solution for my website not building. Let alone the fact that my actions have now made my website vulnerable to security threats.

Cloudflare is great, and setting workers and pages up can be done in literal minutes. But don’t forget to maintain your code. It has a lot of benefits. You’ll spend a lot less time overall when you do need to make changes (like I did for this migration). But, most importantly, your website or application will maintain a high level of security, preventing others from potentially abusing vulnerabilities.