Jamstack

The Drupal site we were running on AWS was reaching its LTS end-of-life this December, so we addressed this by migrating servers.

Due to server constraints, the system requirements could not be met, limiting upgrade options. We were running Drupal 10.6.12, which reaches LTS end-of-life in December 2026. We needed to migrate to a server compatible with Drupal 11.x or later and update to Drupal 11.x to address the LTS end-of-life.

Initially, we considered migrating the Drupal installation on the server, but instead decided to stop server-based operation, run Drupal on a MacBook Pro, convert to static files, and publish the website using a CDN — a style known as “Jamstack.”

This article summarizes the background and process of our transition to Jamstack.

This is a technical article covering Drupal, AWS, and Jamstack — topics not directly related to Hooked-on. However, the migration work and Jamstackification ended up taking over a month, bringing Hooked-on updates to a halt, so this article summarizes what happened.

The sister site “Interset” that we migrated this time is built with Drupal, and we leverage Drupal’s strength in intuitive internal navigation to give articles a reverse-lookup quality. Going forward, we’d like to develop it so visitors can use both this site and Interset as complementary interfaces based on their preferences.

• Our AWS-hosted sister site that was migrated this time [ Interest ]
• Article about the Jamstackification [ Drupal with Jamstack ]

Lightsail + Bitnami + Drupal

We were running a Drupal site using a package that installed Drupal — optimized by Bitnami — on AWS Lightsail, a VPS service. This is what’s called a “blueprint”: a VPS plan that bundles an OS with a CMS. (It’s similar to selecting Drupal from the OS/app image plans on Xserver VPS.)

Since Bitnami handles the server configuration optimization needed to run Drupal, this plan lets you start using Drupal from the very day your server contract begins. It’s a plan AWS prepared for those who want to try Drupal for the first time, as well as individuals and organizations looking to build small-to-medium websites with Drupal.

While it made using Drupal very easy — which is why I used it — there was one problem that needed to be addressed. That problem is this: because Bitnami handles the server configuration optimization, Bitnami is responsible for updating PHP, the database, Apache, and so on. This operational policy is excellent and user-friendly in design, but it also means users cannot touch these components themselves. “User-initiated updates to PHP, the database, Apache, etc.” fall outside the scope of plan support.

When performing a Drupal major update, if the system requirements change, you need to update PHP and the database to match Drupal’s new requirements. Bitnami’s design philosophy is not to update the system requirements or Drupal within the existing Lightsail + Bitnami package plan, but rather to migrate to a new plan where Bitnami has already installed the latest major version of Drupal with the updated system requirements.

This design philosophy is a sensible approach — launching a new system without taking down the existing one, then switching over when ready. It takes full advantage of the benefits of modern cloud and virtual servers.

In practice, migrating an existing site to a new server is quite a hassle — less the actual work itself, more the research into data migration preparation, verification methods, and running test simulations of the migration process — so I kept putting it off.

As of June 2026, my environment is as follows.

Existing Lightsail + Bitnami Environment

• PHP up to 8.2.x — Drupal 11.x requires 8.3.x or higher, recommends 8.4.x or higher
• MariaDB up to version 11.x — DB meets Drupal 11.x system requirements
• Meets system requirements up to Drupal 10.x — does not support Drupal 11.x due to PHP version

Running on Drupal 10.6.12, the latest version of Drupal 10.

The current server does not meet the PHP requirements for Drupal 11.x, so either PHP needs to be updated or a migration to a compatible package is required. As mentioned earlier, the current Lightsail + Bitnami package cannot be upgraded to Drupal 11.x due to PHP constraints. The solution is to migrate to the latest available Lightsail + Bitnami package — the “Drupal 11.3.9 plan.”

End of Blueprint

At this point, a new problem arose with the Lightsail + Bitnami package. The relationship between Lightsail and Bitnami has been dissolved. Bitnami had been handling server infrastructure maintenance and security, but as of May 19, 2026, Bitnami’s maintenance ended, and users are now responsible for their own server infrastructure maintenance and security.

This decision is not limited to Drupal — Lightsail has announced it is discontinuing and will no longer support the “blueprint” plans that packaged various OS and CMS/framework combinations.

While the latest Drupal environment — the Lightsail + Bitnami package “Drupal 11.3.9” — is still available, it too will reach end-of-support in May 2027. Given this situation, the option of migrating to the latest version of the Lightsail + Bitnami package has effectively become unavailable.

As an alternative, there is the approach commonly used for enterprise projects: installing Drupal on AWS EC2 (web server) and RDS (AWS’s dedicated high-performance database). The advantage is that it allows you to fully leverage Drupal’s features and performance, but the downside is that the operational costs and effort are no longer suited for a personal blog, and management becomes considerably more complex.

Another option — one that had been in mind since first starting with Drupal — was to not host Drupal on the web, but instead run it on a MacBook Pro, convert the site to static files (HTML), and publish via CDN using the “Jamstack” approach. This became a realistic plan worth considering.

• Migrate to Lightsail + Bitnami latest package Drupal 11.3.9 — Effectively eliminated
• Migrate to EC2 (web server) and RDS (AWS dedicated high-performance DB) for full Drupal deployment. High-performance infrastructure capable of enterprise-class operation depending on scale — Not suitable for a personal blog, abandoned
• Migration with Jamstack in mind — previously considered once: not hosting Drupal on the web, converting to static files, and publishing via CDN — Selected this option

Since May 19, 2026 has already passed, we need to move quickly with the migration, keeping security concerns in mind.

Jamstack

Among those working in web-related fields — particularly front-end engineers who handle web design and site development — “Jamstack” and “headless” have been trending terms in recent years.

Jamstack is a web architecture method that combines three technical elements: JavaScript, API, and Markup. Unlike traditional approaches such as WordPress, it delivers pre-generated static pages via CDN, achieving high security and ultra-fast loading speeds. — Quoted from Gemini

When people talk about Jamstack or headless, the mainstream approach is to use Next.js or React to fetch CMS data via API and rebuild it for publication. The approach used here — converting Drupal to static files and publishing via CDN — is a minority method.

It is known abroad as “Static Drupal.”

The Jamstack Process

• OrbStack (local server), DDEV (container), Drupal (CMS: website building), and Tome (static file generation) are installed on the MacBook Pro, keeping all website construction self-contained within the MacBook.
• The website is hosted on AWS Lightsail (a deliberate choice over the standard S3). Lightsail only exposes Apache and SSH (sFTP) — configured purely for static file delivery.
• Since there is no need to install or run PHP or a database on Lightsail, this reduces both security risks and server load.
• AWS CloudFront (CDN) is configured. SSL is set up via ACM, and domain management uses Route 53.
• Lightsail is configured with IP restrictions that only allow CloudFront’s IPs. This achieves a setup similar to S3’s internal routing security model — where the origin is not directly accessible from the outside.
• Content is deployed by uploading directly from the Mac to Lightsail via sFTP. This is done using Transmit with simple “GUI copy-paste.” (AWS CLI or Git-based deployment — the mainstream choices — were not selected.)
• sFTP and SSH are protected with key authentication and IP restrictions, so access is limited to my MacBook Pro. All article updates and site management are done on the MacBook Pro, and publishing is done only via sFTP. Compared to the process of “logging into a web-based CMS admin tool,” this significantly reduces security risk.

With the above process, the workflow of building and publishing via Drupal on the web has been transformed into a greatly simplified Jamstack process: build the site with Drupal on a MacBook Pro, convert to HTML, upload via sFTP copy-paste, and publish via CDN.

Benefits of Jamstack

• By running Drupal locally, you are freed from security-related management.
• Since duplicating Drupal locally is easy, you can experiment with designs and settings as much as you like — even if you break something, it has no impact on the live site.
• Even if an update — like the one in Drupal 11.4.0 that actually caused display-breaking errors in some environments — occurs, it’s local and has no impact on the published site.
• The site is published via AWS CDN with an optional WAF, providing delivery speed and security at a world-class level.
• All pages are static HTML. The origin server (Lightsail) functions essentially as a file repository — with no programs or databases installed, and external access restricted to CDN only — freeing you from security and load management.

In addition to the Jamstack benefits of “speed” and “high security,” the increased proportion of local work has also realized “simplified management” and “reduced risk.”

Back to Basics

For this project, we selected modern web publication technologies — CDN for cache-accelerated delivery, WAF managed by major platforms to block the latest threats, and serverless-style architecture where the content server handles requests via internal routing without being exposed publicly. Together these achieve Jamstack-based web publication.

The web publication process built with 2020s technology ended up being essentially the same as the late-1990s homepage publishing process — creating a homepage on a PC, uploading it via FTP to a provider’s homepage space, and going live. It feels like history has come full circle back to its origins.

• 1990s Homepage builder — 2026 Drupal
• 1990s FTP software — 2026 sFTP software
• 1990s Provider’s homepage space — 2026 AWS CDN

After all the twists and turns, it was quite a realization that what we’re doing today isn’t all that different from 30 years ago.

Closing

The Drupal website was launched two years ago out of a desire to learn Drupal and try out AWS. But due to AWS’s infrastructure restructuring, a plan change became necessary, and with the support deadline already passed, work has been proceeding at a rushed pace.

The AWS plan change and the actual implementation took only a few hours, but since this involved a fundamental change to both the publishing method and the infrastructure — something I was doing for the first time — it took far more time in evaluating and selecting the right infrastructure setup than in the actual work itself.

Along with the Jamstackification, I also took the opportunity of the migration to work on design changes and nativization of translations simultaneously, which took unexpectedly long and brought site updates to a complete halt.

In recent times, the spread of AI has accelerated the discovery of security vulnerabilities — which is a good thing — but it has also driven the rapid mass-production of attack tools that exploit them, significantly raising the risks of running a website compared to before. The Jamstackification carried out this time is one option for reducing those risks.

The current environment is

• Xserver Business Standard — WordPress & Drupal
• AWS — Jamstackified HTML

That is the current setup.

Xserver Business Standard is a packaged service with CDN and WAF included as standard, and security measures such as IP restrictions can be configured easily. While performance optimization and security management in operation are left to the user, Xserver takes responsibility for guaranteeing the basic infrastructure performance and security measures.

As a result, running WordPress or Drupal just requires keeping up with basic user-side maintenance such as updates, allowing you to focus on running the site without being distracted by security concerns or performance issues.

AWS’s base environment provides specialized, high-performance instances capable of delivering enterprise-class services. The premise is that experts select the necessary features for a project, carefully evaluate configurations, and build an optimal combination tailored to the purpose.

AWS is responsible for guaranteeing the performance and security of each instance, but since the system is premised on users selecting their own combination and applying their own configurations, overall system security and performance management are left to the user.

The discontinued blueprint plan offered a service similar to Xserver, but now, by independently selecting and operating AWS instances, security and performance are managed at one’s own responsibility.

By choosing the minimal, simple configuration suited to the purpose of publishing a personal blog, management is kept straightforward.

It ended up being more than a month of work, during which article updates came to a complete halt, but I’m hoping to gradually resume. Following the “Xserver migration” for WordPress and Drupal, and now this “AWS migration,” reviewing my own websites has also revealed new areas for improvement.

This website also had a design update in April of this year, but some older articles still have outdated layouts — it’s painstaking work, but I’d like to start making those fixes.

Since resuming article updates, I’ve been publishing one article per week, but this migration experience has become a catalyst for slowing the pace slightly and focusing more thoroughly on polishing the existing site.