DEV Community

Cover image for Moving - From DigitalOcean to Cloudflare Pages
Hoai Tong Xuan
Hoai Tong Xuan

Posted on

Moving - From DigitalOcean to Cloudflare Pages

If you're interested, you may know that I use DigitalOcean to host this blog, with a modest configuration of 1GB RAM and 20GB SSD, which is sufficient for the TechStack that I have chosen. I call it sufficient because it still performs well with the current traffic, but deploying with Docker sometimes creates storage issues for the images it generates. Docker is known as the "hard drive killer" when you have many Images, combined with CI/CD setup, it's a "devastating combo". Just think, a 20GB hard drive, without subtracting the operating system, how can continuous deployment be possible? Occasionally, the server reports that the hard drive is full and I have to go in and delete some files.

By chance, I came across Cloudflare Pages which provides a solution for deploying various types of websites, such as Vue, React, Nuxt.js, Next.js... I was curious to see what it had to offer. I spent a whole week researching it. Finally, I decided to try migrating the two interface pages to see if it could be done.

The Process of Moving

According to Cloudflare, Cloudflare Pages is a JAMstack platform for user interface developers and website deployment. Pages focuses on developers as it offers many solutions such as Git integration to support continuous deployment (CI/CD), as well as the deployment speed and performance of the application through it.

Realizing the potential of Cloudflare, I could move the two Front-end pages: the admin control panel (AdminCP) and the blog interface. The AdminCP is built with Vue.js using SPA, while the blog is built with Nuxt.js using SSR. For the SPA, the resource consumption is not much. As far as I can tell, it only takes up a few MB of memory because it is deployed through Nginx. On the other hand, SSR takes up quite a bit of memory, I must say it is the most memory-consuming among the running services. Simply because it is deployed through a Node.js server, and Node.js consumes a lot of memory. Both Vue and Nuxt.js are supported by Pages, so I can easily migrate these two pages. But before migrating, it is necessary to evaluate the required features.

First is the admin panel page, since it is built with Vue and uses SPA, migrating it to Pages isn't too complicated. All that needs to be done is to change the environment variables to receive the configuration during build.

As for the blog interface page, I came up with an idea: instead of using SSR as it is currently, why not try converting it to SSG? This way, I can use a command to generate the website into static HTML files and upload them to any host that supports static pages, not just Cloudflare Pages. Moreover, the speed will be much faster compared to regular SSR because there is no need to query the database and generate HTML code for each visit. Thinking about it, I spent a whole week modifying the Nuxt code to work well with SSG mode.

Finally, earlier this week, I completed the basic process of moving the two interface pages to Pages. Of course, there are still a few bugs that need to be fixed, but currently, it fully meets the reading and search needs of everyone.

Benefits of Moving

I can save some resource costs for the admin panel and blog interface pages. Although it is not much, now I don't have to worry too much about server overload or any errors that may occur, as it can still function normally since Cloudflare has stored all the HTML.

The CI/CD process is shortened and less complicated. Previously, I needed to write many scripts to support this through Gitlab CI and Docker, but now, anytime I push code to Gitlab, it can build automatically.

I have switched DNS to Cloudflare to take advantage of their CDN infrastructure and data caching mechanism. The blog now has an impressive access speed.

Lastly, Web in the EDGE may become a trend in the future. Meaning you don't have to deploy a specific server to run a website, you can just run it through services like Pages. To learn more about this trend, readers can visit The Future of the Web is on the Edge.

What's Left to Do

Although the majority of the migration process went smoothly, there are still some issues that need time to address.

The first is undiscovered or discovered but non-impactful errors. This issue only requires time to fix, or if readers discover any errors, they can leave a comment to inform me and I will fix them.

There are some features that become unnecessary or disabled after migrating to Pages, and they need to be removed to avoid confusion in the future.

Another issue is that there is no way to activate a notification after a successful or failed Page deployment. Hopefully, Cloudflare will soon add a notification feature or, at least, I will run a curl command along with the npm run generate command to send notifications to Telegram.

That's what's currently on the agenda. In the long run, it is to completely eliminate the need for a server and move all services to the cloud. Then I will be able to set up an automated system and not worry too much about infrastructure.

Top comments (0)