Updating PHP on an AWS Lightsail Blueprint WordPress Stack

UPDATE: I can confirm that updating PHP direction only for lightsail blueprint stacks (not bitnami blueprint stacks) is now possible. See Amazon’s guidance related to PHP vulnerabilities of Oct 2026

Specifically to resolve PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 I clicked to ‘Connect using SSH’ then ran sudo apt update` followed by sudo apt upgrade and following confirming the changes and running php -v I now see ‘8.2.35’ which is a patched version of PHP. I then ran `sudo systemctl restart apache2` as shown in the guidance above.

Previously lightsail used Bitnami blueprints for WordPress and other commonly used setups. But in 2025/26 Amazon made their own lightsail blueprints available, and are moving away from Bitnami options.

Bitnami blueprints are being deprecated - info panel from AWS

Note 1: Read this guide in full before you do anything. You’ll want to confirm it matches your situation and your expectations.

Note 2: You can’t simply update PHP on an AWS lightsail WordPress stack. You have to migrate to a new lightsail instance with the newer version of PHP on it. That is what this guide shows you how to do.

Note 3: This guide assumes you already have a static IP on your current Lightsail instance. If you don’t, you could possibly assign one in advance, but otherwise this guide is not for you.

Note 4: I’m planning to add a step or reference for those moving over from Bitnami to Lightsail blueprint. Things like htaccess files needs manual consideration as they’re outside the WordPress structure and are not automatically migrated.

I last ran through this guide myself on 15th October 2026 on this very site, which is about 800MB. It took it from PHP 8.4 to 8.2. Yes, lightsail instances appear to be behind where bitnami instances were, and I’m now seeing plugins that won’t update due to that. WordPress 7.1 was installed on both source and destination instances during the process.

Note that since Bitnami’s tool for SSL certificates is no longer available, the order of things needs to be changed to allow running of the new ‘Set up your WordPress website’ tool which handles domains and SSL certificates. There may be a little more time showing the maintenance page due to this. For me, 7 minutes.

No fluff. Limited details. Just 9 steps and 1 optional one.

Continue reading →

Open image files in Shottr by drag-n-dropping them

I recently moved from Monosnap to Shottr for screenshots on my Mac. Shottr has a whole lot going for it, and it was the right move, but the biggest frustration was how to open images in Shottr quickly.

In Monosnap I almost always dragged the existing image from a browser, or Finder onto the menubar icon. Monosnap would show a little drop zone, you dropped your image file and Monosnap would review it in a new window. Shottr doesn’t yet allow dropping onto the menubar icon.

Also, shottr has a lot of shortcut key options, but none of them are ‘Load from Clipboard’. This is only available via the options list. So my clumbsy workflow was… right click and copy an image, click Shottr menubar icon, move down to ‘More’ then move down and click ‘Load from Clipboard’.

I decided there had to be a better way which allowed drag-and-drop, and after a little whle trying things out I found it.

Continue reading →

Setting Up Partial Digital Inheritance with 1Password

1Password is brilliant for keeping your online life secure, but it does not yet have a simple way to pass on selected information after you die. There is no built in legacy contact feature, and organisers cannot access your private vaults. This leaves a gap for anyone who wants to share only some things with family in the future without giving away their whole account.

After testing different options, I found a straightforward approach that works well. It gives your family the information you want them to have, keeps your private vaults private, and avoids complicated workarounds.

Continue reading →

Elastic Beanstalk crons on multi-instance environments

Wow. What a lot of pain.

Updated 6th October 2025 to reference new token requirement for loading instance meta data

So let me first confirm what won’t work. Whether Apache 1, Apache 2, leader_only or EB_IS_COMMAND_LEADER testing, you cannot consistenty get exactly one (not zero, or 2+) instances to run a cron job over a long period of time.

The issue is the the leader information isn’t safe. It’s only available during deployments, when you usually first set up the cron job. But when an instance replacement happens—for whatever reason—there is no related deployment, the test to check if the new instance is the leader fails, and you end up with no crons.

So for anything you do at the moment of deployment—database migrations, logging, whatever— that you only want to run once, even on multi-instance environments in an Elastic Beanstalk Application, you can use and trust the leader tests available to you.

But for anything you want to run regularly, on a schedule across weeks and months, you cannot trust those options.

After a lot of research, and trial and error there are two options available to you.

Continue reading →

Updating PHP on an AWS Lightsail Bitnami WordPress Stack – Version 2

UPDATE 22.10.2026 – Amazon have also released (complex) steps which may allow you to update the PHP version of a bitnami lightsail wordpress instance in place – https://docs.aws.amazon.com/lightsail/latest/userguide/amazon-lightsail-update-php-security-vulnerabilities.html#php-cve-bitnami-in-place

For quickly updating lightsail blueprint (not bitnami blueprint) lightsail instances see the details at the very top of this article.

AWS are moving away from Bitnami to their own WordPress blueprints. The situation is similar in that you’ll need to migrate to a newly created Lightsail Instance. The instructions are slightly different.

The guide below is specifically for migrating from Bitnami WordPress to Bitnami WordPress. You might want to checkout the lightsail blueprint update version of this.

Note 1: Read the guide in full before you do anything. You’ll want to confirm it matches your situation and expectations.

Note 2: You can’t simply update PHP on an AWS lightsail Bitnami WordPress stack. You have to migrate to a new instance with the latest version of PHP in it. That is what this guide shows you how to do.

Note 3: This guide assumes you have a static IP on your current Lightsail instance. If you don’t, you could possibly assign one in advance, but otherwise this guide isn’t for you.

I last ran through this guide myself on 26th January 2026 on this very site, which is about 750MB. I took it from PHP 8.2 to 8.4. WordPress 6.9 was installed on both source and destination instances during the process. With fast broadband it was down for less than 5 minutes.

I decided to rewrite the previous version of this article. The original has been cloned and copied loads of times, and to be honest it got bloated with updates and comments. I also prefer this new way. It’s fast and avoids issues with SSL certificates.

This guide aims to only take you through the steps I use now when a PHP version update is needed for my AWS Lightsail Bitnami WordPress install.

No fluff. Limited details. Just 7 steps and 3 optional ones.

You follow this guide at your own risk. Back up your site and read the full article through first. The older version of this article is still valid if there isn’t enough information for your needs here.

The main change here is we’re going to use a very simple maintenance plugin which shows a message in the short time required between moving the domain over to the new install and importing the migration file. This does away with the potential complexity of the Lightsail IP address being saved to the database as part of the migration.

Ready?

Continue reading →