DEV Community: Michael Oteng

Testing Microsoft Publisher Conversion on Linux: What Worked, What Broke, and Why Fidelity Matters

Michael Oteng — Sun, 01 Nov 2026 20:48:42 +0000

Microsoft Publisher's retirement creates a practical problem for anyone maintaining older publications: what happens when you have .pub files but no longer have access to the application that created them?

Microsoft has recommended converting existing publications into other formats. PDF is an obvious choice when the objective is to preserve a document for viewing or distribution. But converting a file and preserving its original layout are not necessarily the same thing.

I wanted to investigate that distinction while implementing Publisher conversion support for a web-based document utility platform.

Rather than relying on documentation stating that a particular format was supported, I tested actual Publisher documents through several conversion routes.

The investigation included:

LibreOffice 24.2 and 26.8 on Linux.
Font compatibility testing.
Scribus and its scripted import interface.
Direct libmspub utilities.
Editable OpenDocument Drawing (ODG) output.
Direct DOCX export.
PDF-to-PNG rendering using Poppler.

Some conversions worked. Some failed immediately. Others generated perfectly valid output files that were visually unsuitable for their intended purpose.

Those differences became the most useful part of the investigation.

1. The problem: what does a successful conversion actually mean?

Microsoft Publisher was widely used for brochures, newsletters, flyers, invitations and other page-layout documents.

Those documents can contain more than ordinary paragraphs. A publication may rely on independently positioned text boxes, layered images, unusual fonts, linked text containers and carefully arranged shapes.

Converting that material into another format introduces several different questions.

File conversion: Can the application read the source and generate an output file?

Visual fidelity: Does the converted publication still resemble the original?

Practical editability: Can someone open the result and meaningfully modify its contents?

I decided to evaluate these separately.

A command that exits successfully is evidence that a processing operation completed. It is not, by itself, evidence that the resulting document is visually correct.

Likewise, a publication that looks reasonable as a PDF may not provide a useful way to update its original text, images or design.

2. The testing environment

My initial conversion work was performed on an Ubuntu 24.04 server running LibreOffice 24.2.7.2.

I subsequently built an isolated test environment using Docker Desktop on Windows, with LibreOffice 26.8.2.2 running inside a Linux container.

The relevant software included:

Component	Version or environment
Linux server	Ubuntu 24.04
Original LibreOffice	24.2.7.2
New LibreOffice	26.8.2.2
Docker test environment	Docker Desktop 4.97.0
Docker Engine	29.9.2
libmspub tools	0.1.4
Scribus	1.6.1
PDF rendering	Poppler `pdftoppm`

I used separate LibreOffice user profiles for the conversion tests to avoid interfering with an existing application profile.

The test documents were three Publisher fixtures identified during the investigation as Apache POI samples:

Document	Pages	Characteristics
`Sample.pub`	2	Relatively simple sample
`SampleBrochure.pub`	2	Art gallery brochure with text boxes, images and decorative objects
`SampleNewsletter.pub`	4	Text-heavy newsletter with multiple columns, headings and article sections

These were useful because the files were not equally complex.

The simple publication provided a basic compatibility test. The brochure and newsletter exposed problems with text positioning, overlapping content and page composition.

This was a small exploratory test set, not a comprehensive compatibility benchmark across every Publisher version.

3. Baseline: converting Publisher to PDF

The original Ubuntu installation reported:

/usr/bin/libreoffice --version

LibreOffice 24.2.7.2 420(Build:2)

Publisher documents were imported as LibreOffice Draw documents and exported using the draw_pdf_Export filter.

The application-side command construction used Symfony Process, including an isolated user profile:

$process = new Process([
    config('services.libreoffice.path', '/usr/bin/libreoffice'),
    '-env:UserInstallation=file://' . $profileDirectory,
    '--headless',
    '--nologo',
    '--nodefault',
    '--nofirststartwizard',
    '--convert-to',
    'pdf:draw_pdf_Export',
    '--outdir',
    $outputDirectory,
    $input,
]);

The results were mixed.

The simple Publisher sample converted with an acceptable appearance.

The brochure also converted, retaining two pages, text, images and much of its overall structure. However, the layout was visibly damaged.

Text wrapped differently inside its containers. Some headings were incorrectly sized or positioned. Images and decorative elements overlapped text in places where the original publication had a more deliberate arrangement.

The newsletter was worse.

Although it produced a four-page PDF, several article sections had overlapping paragraphs. Content from different text regions appeared intermingled, and the intended multi-column layout was no longer reliably readable.

The PDF conversion worked technically, but the complex documents were not preserved faithfully.

This was the first important result.

A valid PDF can still be a poor migration outcome.

[Figure 1: Original Publisher brochure and converted PDF, showing text-box and image positioning differences.]

[Figure 2: Converted newsletter, showing overlapping article content and displaced text.]

4. Could missing fonts explain the layout damage?

Font substitution was one of the first possibilities I investigated.

The original Linux environment did not have several Microsoft fonts installed.

This matters because the dimensions of a text box do not necessarily change when its original font is unavailable. If the replacement font has different character widths, line heights or spacing, the text may wrap differently.

A paragraph that originally fitted inside a fixed container may need an additional line after substitution.

I installed the Microsoft core fonts using the Ubuntu ttf-mscorefonts-installer package and verified font matching for fonts including Arial, Times New Roman, Trebuchet MS and Comic Sans MS.

I then repeated the brochure conversion.

There was a slight improvement, but the main layout defects remained.

The text-box positioning and more substantial content overlaps were not resolved.

This did not establish that fonts were irrelevant. They clearly affect document layout.

It established something narrower: missing fonts were not sufficient to explain the conversion problems observed in this brochure.

The investigation therefore needed to move beyond font substitution.

5. Would a newer LibreOffice version improve the result?

The next experiment was to test LibreOffice 26.8.2.2 independently of the production installation.

I downloaded the official Linux Debian archive and built a Docker image containing the newer version.

The container reported:

docker run --rm swiftvecto-pub-lo268 --version

LibreOffice 26.8.2.2 9dea406ab7695df6325b11b0e19fdca8db4b7276

I then converted the brochure and newsletter:

docker run --rm `
  --mount "type=bind,source=$((Get-Location).Path),target=/work" `
  swiftvecto-pub-lo268 `
  -env:UserInstallation=file:///tmp/lo-pub-profile `
  --headless `
  --convert-to pdf:draw_pdf_Export `
  --outdir /work/output `
  /work/SampleBrochure.pub `
  /work/SampleNewsletter.pub

The command output showed two successful exports:

convert /work/SampleBrochure.pub as a Draw document -> /work/output/SampleBrochure.pdf using filter : draw_pdf_Export
convert /work/SampleNewsletter.pub as a Draw document -> /work/output/SampleNewsletter.pdf using filter : draw_pdf_Export

I verified the generated files:

Get-ChildItem .\output\*.pdf |
Select-Object Name, Length

Name                 Length
----                 ------
SampleBrochure.pdf   226390
SampleNewsletter.pdf 367071

The files existed, contained multiple pages and were not empty.

However, visual inspection was disappointing.

The brochure still contained incorrect text wrapping, displaced headings and overlapping objects. The newsletter continued to show serious paragraph collisions and unreadable areas.

I could not identify a meaningful visual improvement for these documents.

There is an important qualification here: the Docker environment and original production environment did not initially have exactly the same font installations.

This was therefore not a perfectly controlled renderer benchmark.

It was sufficient, however, to establish that moving to LibreOffice 26.8 did not resolve the most significant visual defects in the documents I tested.

A newer application version did not automatically mean a better conversion.

6. Testing another importer: Scribus

I also investigated Scribus 1.6.1.

Because this was a Linux server without a normal graphical desktop session, I used Xvfb to provide a virtual display for scripted processing.

The conversion attempt used Scribus's Python interface to open a Publisher document and export a PDF.

It did not work as expected.

The importer reported:

ERROR: Parsing failed!

The workflow subsequently produced a PDF of approximately 1,244 bytes.

On inspection, that file contained one essentially empty page rather than the expected two-page brochure.

This was an important failed test.

A generated PDF is not necessarily proof that a source document was successfully imported. Some workflows can reach an export stage even though the earlier import operation did not produce useful content.

I treated the Scribus result as a failure rather than a successful conversion.

It also highlighted why automated document-processing systems should validate more than process exit codes and output filenames.

7. Testing libmspub directly

LibreOffice's Publisher import capability uses the open-source libmspub library, so I wanted to see whether accessing the library's utilities directly could provide a useful alternative output.

I launched a temporary Ubuntu 24.04 container and installed the available tools:

apt-get update
apt-get install -y libmspub-tools

The installed version was 0.1.4.

Attempt 1: PUB to SVG

The pub2xhtml utility describes itself as a Publisher-to-SVG converter.

I tested the brochure:

pub2xhtml \
  /work/SampleBrochure.pub \
  /work/libmspub-output/SampleBrochure.svg

The result was:

ERROR: SVG Generation failed!

I then attempted the simple sample:

pub2xhtml \
  /work/Sample.pub \
  /work/libmspub-output/Sample.svg

That returned a different error:

ERROR: Unsupported file format!

Neither test produced a usable SVG document. The generated files were empty.

These errors should not be conflated. The utility reported an unsupported format for one input and an SVG-generation failure for the other.

I did not establish the precise internal cause of either failure.

Attempt 2: raw diagnostic output

The package also provided pub2raw, a utility intended for testing libmspub.

After checking its argument syntax, I ran:

pub2raw /work/SampleBrochure.pub > /work/libmspub-output/SampleBrochure.raw 2> /work/libmspub-output/pub2raw-error.log

Both generated files were zero bytes.

There was no useful diagnostic content and no error text.

I had not captured the utility's exit code, so I could not determine from this evidence whether parsing had completed successfully but produced no output, or failed silently.

The direct library experiments did not provide a viable alternative conversion route.

That was useful information, but not a reason to conclude that the library could never be improved or that its behaviour was identical for every Publisher file.

8. A different outcome: converting Publisher to editable ODG

At this point, I changed the question.

Instead of asking only whether a Publisher document could be reproduced faithfully as a PDF, I wanted to know whether its underlying content could be recovered in a form that remained editable.

I tested conversion to OpenDocument Drawing (.odg).

Using the LibreOffice 26.8 Docker environment:

docker run --rm `
  --mount "type=bind,source=$((Get-Location).Path),target=/work" `
  swiftvecto-pub-lo268 `
  -env:UserInstallation=file:///tmp/lo-pub-odg-profile `
  --headless `
  --convert-to odg:draw8 `
  --outdir /work/odg-output `
  /work/SampleBrochure.pub `
  /work/SampleNewsletter.pub

The results were promising:

convert /work/SampleBrochure.pub as a Draw document -> /work/odg-output/SampleBrochure.odg using filter : draw8
convert /work/SampleNewsletter.pub as a Draw document -> /work/odg-output/SampleNewsletter.odg using filter : draw8

The generated files were:

Name                 Length
----                 ------
SampleBrochure.odg   102569
SampleNewsletter.odg 190794

I opened the ODG documents in LibreOffice Draw to test whether they contained meaningful editable content.

The important result was that individual text fields and objects in the brochure remained editable. They were not simply flattened into a single image of each page.

Text could be changed within the converted document, and recovered page elements could be worked with independently.

I also observed no noticeable difference in practical ODG editability between the LibreOffice 24.2 and 26.8 versions tested.

That observation does not establish that their internal output structures were identical. It means I found no meaningful editability improvement attributable to the newer version.

The overall result was still significant.

Although the original layout could require correction, ODG offered a practical way to recover and continue editing the publication's contents.

For certain migration scenarios, that may be more valuable than a PDF that merely looks similar to the original.

[Figure 3: Converted brochure opened in LibreOffice Draw, with an individual text object selected for editing.]

9. What about converting directly to DOCX?

The next question was whether the Publisher documents could be converted into Microsoft Word's DOCX format.

I attempted a direct export using the Office Open XML Text filter:

docker run --rm `
  --mount "type=bind,source=$((Get-Location).Path),target=/work" `
  swiftvecto-pub-lo268 `
  -env:UserInstallation=file:///tmp/lo-pub-docx-profile `
  --headless `
  --convert-to docx:"Office Open XML Text" `
  --outdir /work/docx-output `
  /work/SampleBrochure.pub `
  /work/SampleNewsletter.pub

LibreOffice recognised each input as a Draw document, but the export failed.

The brochure produced:

convert /work/SampleBrochure.pub as a Draw document -> /work/docx-output/SampleBrochure.docx using filter : Office Open XML Text
Error: Please verify input parameters... (SfxBaseModel::impl_store <file:///work/docx-output/SampleBrochure.docx> failed: 0xc10(Error Area:Io Class:Write Code:16))

The newsletter produced the same class of error.

This was not evidence that DOCX was an impossible destination under all circumstances.

It showed that the direct Draw-to-DOCX export route I attempted was not supported successfully by that workflow.

Publisher and Word also organise document content differently. Publisher's positioned page-layout objects do not necessarily map cleanly to a Word document's structure.

A different approach might involve extracting text and images, reconstructing a DOCX document and accepting that some layout information would be lost.

I did not implement that approach during this investigation.

Rather than claim a working converter from a failed export, I left DOCX conversion for separate research.

10. Converting the resulting PDF into images

One of the more straightforward experiments involved rendering converted Publisher pages as PNG images.

The aim was not to improve layout fidelity. It was to determine whether a successfully generated PDF could be used as an intermediate format for producing individual page images.

I used Poppler's pdftoppm utility inside the test container:

docker run --rm `
  --entrypoint /bin/bash `
  --mount "type=bind,source=$((Get-Location).Path),target=/work" `
  swiftvecto-pub-lo268 `
  -c 'pdftoppm -f 1 -l 2 -r 150 -png /work/output/SampleBrochure.pdf /work/image-output/brochure'

The command completed without reporting an error.

The resulting files were:

brochure-1.png     262755 bytes
brochure-2.png     706529 bytes

Both pages of the brochure had been rendered at 150 DPI.

This established a useful two-stage pipeline:

Publisher (.pub)
       |
       v
Converted PDF
       |
       v
Poppler renderer
       |
       v
Individual PNG page images

The same concept was subsequently used in a web-based PUB-to-Images utility.

However, it is important to understand what this pipeline does not achieve.

If the intermediate PDF already contains overlapping paragraphs or incorrectly positioned images, the PNG output will reproduce those errors.

Rasterisation preserves the appearance of the intermediate representation. It cannot reconstruct the layout of the original Publisher document.

11. Results across the conversion routes

The following table summarises the tests rather than claiming general compatibility for every Publisher document.

Route	Technical result	Practical conclusion
Simple PUB to PDF	Successful	Basic publications can convert acceptably
Complex PUB to PDF, LibreOffice 24.2	Successful export, poor fidelity	Generated PDF not necessarily suitable for final distribution
Complex PUB to PDF, LibreOffice 26.8	Successful export, poor fidelity	Upgrade did not resolve observed layout defects
PUB to PDF through Scribus script	Failed	Import failure made the generated PDF unusable
PUB to SVG using `pub2xhtml`	Failed	No usable SVG output
PUB to raw diagnostics using `pub2raw`	Empty output	Inconclusive diagnostic result
PUB to ODG	Successful	Recovered editable document content
Direct PUB to DOCX	Failed	Requested export filter did not produce usable DOCX
Converted PDF to PNG	Successful	Page images generated, inheriting the PDF's appearance

The most important distinction was not simply successful versus failed conversion.

It was whether the output met the intended requirement.

For viewing, I needed readable pages with acceptable layout preservation.

For editing, I needed independently accessible text, images and other document elements.

For archiving, I needed confidence that important content had not been lost or displaced.

The same output format did not satisfy every requirement.

12. What I would recommend for legacy Publisher documents

Microsoft's official retirement guidance recommends preserving existing Publisher documents by converting them into other formats, including PDF. It also identifies Word and PowerPoint as alternatives for several common Publisher use cases.

That is Microsoft's documented guidance.

My testing addresses a narrower question: what can happen when alternative Linux-based tools are used to import existing PUB files?

Based on these results, I would approach a Publisher migration according to the actual requirement.

If Microsoft Publisher is still available through a functioning perpetual installation, exporting directly from the original application is a sensible option to evaluate first, particularly when visual fidelity matters. I did not benchmark direct Publisher exports in this investigation.

For organisations working without Publisher, alternative conversion tools can provide access to the contents, but the output should be reviewed, especially for newsletters, brochures and other complex publications.

If the objective is continued editing rather than static distribution, an editable drawing format such as ODG may be useful. The recovered content can still require layout adjustments, but at least the publication can remain workable.

For image output, rendering an intermediate PDF is technically straightforward, provided the PDF is already acceptable.

For DOCX, I would not promise reliable conversion on the basis of a supported filename or export filter alone. The actual document structure and selected conversion path matter.

For large archives, I would also recommend retaining the original PUB files alongside any converted outputs.

Conversion should not be treated as a reason to discard the only existing source document.

13. Limitations of this investigation

The testing was deliberately practical rather than exhaustive.

It used three named Publisher fixtures, not a representative sample of all Publisher versions or real-world publication designs.

The LibreOffice comparison was not initially performed under identical font environments.

I did not perform automated pixel-difference analysis or assign numerical fidelity scores.

I also did not inspect the internal source code of libmspub deeply enough to identify a specific parsing defect.

The ODG editability assessment was based on opening and interacting with the converted documents, rather than a complete automated audit of every object.

These limitations matter because they define what the results can and cannot establish.

I can say that the tested complex Publisher files converted poorly to PDF under the tested LibreOffice versions.

I cannot say that every Publisher document will convert poorly, or that no other conversion tool could produce a better result.

I can say that the ODG files retained meaningful editability in my tests.

I cannot say that ODG is a perfect replacement for Microsoft Publisher or that every publication feature survives intact.

Conclusion

The investigation changed how I think about legacy document conversion.

Initially, the question seemed straightforward: could I open a Publisher file on Linux and generate another format?

The answer was often yes.

But a successful export did not necessarily produce a document that was suitable for printing, sharing or further editing.

The simple Publisher sample converted acceptably. The more complex brochure and newsletter exposed serious layout-fidelity problems that were not resolved simply by installing additional fonts or switching from LibreOffice 24.2 to 26.8.

Scribus and direct libmspub utilities did not produce a useful alternative through the approaches tested.

Direct DOCX export failed.

ODG, however, demonstrated that recovering editable content could still be worthwhile, even when the original appearance was not preserved perfectly.

And PDF-to-PNG rendering showed how a successful intermediate conversion could support additional output formats, while also carrying forward any existing defects.

For a legacy document migration, generating an output file is only the beginning of validation. The useful question is whether that output preserves what the organisation actually needs: appearance, information, editability, or some combination of the three.

That distinction matters more than whether a converter reports success.

References

The conversion commands and results documented above come from the practical tests performed during this investigation. Microsoft retirement information is based on Microsoft's published support documentation.

A Backup Isn't a Recovery Plan: Building a Docker-Based MySQL Restore Verifier

Michael Oteng — Mon, 26 Oct 2026 22:02:54 +0000

There is a significant difference between having a database backup and knowing that the database can be recovered.

A backup command can finish successfully. An archive can exist in the expected directory. Its checksum can match after transferring it to another machine.

Those are useful checks, but none of them proves that the database can actually be restored.

I recently had to address this distinction while decommissioning a Laravel-based SaaS platform. The infrastructure was being retired, but I wanted to preserve the option of recovering the application and its data in the future.

That meant treating the recovery process as something to test before deleting the original infrastructure, rather than something to investigate if the backups were ever needed.

The experience eventually led me to build and publish a small open-source project: Recoverable SaaS Decommission.

The problem with backup verification

Database backups are often considered successful once the backup file has been created.

For example:

mysqldump ... > database.sql

Or, with compression:

mysqldump ... | gzip > database.sql.gz

The resulting file may be present, nonempty and correctly transferred to another machine.

But several questions remain unanswered.

Will the SQL import into a compatible database engine?
Does the restored database contain the expected tables?
Are important records accessible?
Can relationships between records be verified?
Is the restore procedure independent of the original hosting environment?

File integrity and database recoverability are related, but they are not the same thing.

A SHA-256 comparison can establish that two files contain identical bytes. It cannot establish that those bytes represent a complete or usable database backup.

That distinction becomes particularly important during infrastructure decommissioning.

Once the original database server has been deleted, discovering that the backup is unusable becomes a much more serious problem.

The original decommissioning exercise

The application involved Laravel, PHP, Nginx, Ubuntu and a managed MySQL database hosted on DigitalOcean.

It also used a multi-tenant architecture.

The decommissioning process involved preserving several categories of assets:

A database export.
Application files and configuration.
Persistent application storage.
Server configuration needed to understand the original deployment.
Recovery credentials and encryption material, stored separately from the public project.

The archives were encrypted, transferred away from the original server and checked using SHA-256 digests.

The database backup then underwent an independent restore test using Docker on a Windows machine with Ubuntu WSL.

That exercise involved importing the database into a separate MySQL environment, inspecting the restored structure and querying representative records.

The database restoration succeeded.

Importantly, this was a database recovery test, not a full clean-room reconstruction of the SaaS application. I did not use that result to claim that every component of the original application stack had been independently recovered.

With the necessary recovery evidence and archives in place, the original infrastructure could then be retired.

Turning the process into a reusable tool

After completing the decommissioning, I wanted a reusable way to verify future database backups without manually repeating the Docker setup, import and cleanup procedure.

I deliberately kept the first implementation small.

Rather than building a complete disaster-recovery framework, I focused on one specific question:

Can this MySQL backup be imported into a disposable database, and do the supplied verification checks pass?

The resulting Bash verifier is available in the repository:

mysql/verify-restore.sh

It uses Docker to create a temporary MySQL environment, restore the supplied SQL backup, perform verification and remove the container afterwards.

How the verifier works

The workflow is straightforward:

SQL backup
    |
    v
Validate input
    |
    v
Start isolated MySQL container
    |
    v
Wait for authenticated readiness
    |
    v
Import SQL backup
    |
    v
Check restored table count
    |
    v
Run optional SQL assertions
    |
    v
Report PASS / FAIL
    |
    v
Remove temporary container

The tool supports ordinary .sql backups and gzip-compressed .sql.gz files.

For isolation, the container is started without published ports and with Docker networking disabled:

docker run -d \
    --name "$CONTAINER" \
    --network none \
    ...

The temporary MySQL password is generated using OpenSSL and supplied through a restricted file mounted into the container.

The verifier also uses an exit trap to remove the container and its associated temporary resources when execution ends.

A key design decision was not to connect to the production database at all.

The verifier works entirely with a supplied backup file.

Running a restore test

The repository contains a synthetic SQL fixture and a corresponding set of verification queries.

This means the example can be tested without production data.

On Linux, with Bash and Docker available:

bash mysql/verify-restore.sh \
  fixtures/sample-schema.sql \
  mysql/verification-queries.sql

On Windows, I tested the Bash verifier using Ubuntu WSL with Docker Desktop:

wsl -d Ubuntu -- bash mysql/verify-restore.sh fixtures/sample-schema.sql mysql/verification-queries.sql

The fixture contains fictional organisations, users and activity records.

The verifier imports the database and executes the provided assertions.

A successful run produces output similar to:

[PASS] MySQL authenticated and ready.
[PASS] SQL import completed.
[PASS] Restored base tables: 3
[PASS] Custom verification assertions passed.

RESTORE VERIFICATION: PASS
MySQL image: mysql:8.0
Restored base tables: 3
Custom assertions: PASS

[INFO] Removed disposable MySQL container.

The same process can be used with gzip-compressed SQL backups.

When adapting this to another application, the important part is supplying verification queries that reflect that application's actual schema and recovery requirements.

Why an import alone is insufficient

An SQL import can finish without an error while still leaving important questions unanswered.

For example, a database may contain the expected tables but lack records that should have been included in the backup.

Or a backup may be internally consistent but represent an older recovery point than intended.

For that reason, the verifier supports application-specific SQL assertions.

These queries can check expected tables, record counts, relationships or other recovery invariants.

The current verifier expects the assertion file to produce exactly one scalar value:

SELECT 1;

A result of 1 indicates that the supplied assertions passed.

Any other result is treated as a failure.

Of course, SELECT 1 alone proves nothing meaningful about the restored data. It is simply the interface contract. Real verification queries should encode useful expectations.

The repository includes an example assertion file using synthetic data.

There is also an important limitation: an assertion is only as strong as the evidence behind it.

Without a trusted source baseline, the tool cannot prove that every record from the original database has been recovered.

Testing failure conditions

I didn't want a tool that only demonstrated a successful restoration.

The failure paths mattered just as much.

For the initial release, I tested five scenarios:

Scenario	Observed result
Valid `.sql` backup	Restoration and assertions passed
Valid `.sql.gz` backup	Restoration and assertions passed
Missing backup file	Input rejected
Deliberately failing SQL assertion	Verification rejected
Malformed SQL backup	MySQL import failed and the verifier reported failure

The failed-import and failed-assertion scenarios also demonstrated that the disposable container was removed afterwards.

These tests are useful evidence for the core workflow, but they are not a comprehensive security audit or a claim of compatibility with every MySQL dump format.

Security considerations

A disposable database is not an excuse to ignore security.

The current implementation follows several basic principles:

It does not require access to a production database.
MySQL is not exposed through published network ports.
Docker networking is disabled for the restore container.
Temporary credentials are generated rather than hardcoded.
The script attempts to remove only the container it created.
SQL errors and failed assertions cause verification to fail.

However, SQL backups and assertion files should still be treated as trusted inputs.

The verifier executes SQL with administrative privileges inside the temporary database. It is not intended to safely process arbitrary malicious SQL or MySQL client commands.

There are also operational limitations. Database imports and Docker image downloads are not individually time-limited, and the initial release uses the mysql:8.0 image tag rather than an immutable digest.

These are considerations to understand before using the tool in a more demanding operational environment.

What the tool does not verify

It is important not to overstate what a database restore test proves.

For a Laravel SaaS application, complete recovery may also require:

Application source code and Composer dependencies.
Environment variables and encryption keys.
Uploaded files and persistent storage.
Web server and PHP configuration.
Queue workers and scheduled tasks.
DNS, TLS certificates and external services.
Tenant-specific configuration and application-level testing.

A successful database import cannot establish that all of those components are recoverable.

The verifier answers a narrower question: whether the supplied MySQL backup can be restored and whether the selected checks pass.

That is still a useful piece of recovery evidence.

Why I published the project

The work started as an operational requirement: retire an application without losing the ability to recover its preserved data.

The resulting verification procedure was useful enough to make reusable.

I have published the first release, v0.1.0, under the MIT License, with synthetic fixtures and documentation so others can examine and adapt the approach without needing access to the original system.

The repository is available here:

Recoverable SaaS Decommission on GitHub

The initial version is intentionally limited to MySQL restore verification. It is not a finished, general-purpose disaster-recovery platform.

For me, the main lesson from the exercise is that creating a backup and demonstrating recovery should be treated as separate operational activities.

Both matter, but only one involves actually attempting the restore.

Don't test whether you can create a backup. Test whether you can restore from it.

Decommissioning a Laravel SaaS Without Losing the Ability to Restore It

Michael Oteng — Mon, 26 Oct 2026 07:19:09 +0000

Recently, I decommissioned the infrastructure behind Scholent, a multi-tenant Laravel SaaS application I built.

Deleting the infrastructure itself was easy.

The more important question was:

If I needed Scholent again six months or two years from now, could I actually recover it?

I didn't want the answer to be:

I have a backup somewhere.

I wanted evidence that the critical recovery material was intact and, particularly for the database, actually restorable.

So I treated this less as a server deletion exercise and more as a small disaster-recovery exercise.

The process eventually looked like this:

Inventory
   ↓
Archive
   ↓
Encrypt
   ↓
Transfer off-server
   ↓
Verify integrity
   ↓
Restore independently
   ↓
Inspect recovered data
   ↓
Document reconstruction
   ↓
Decommission infrastructure

The distinction between having a backup and having tested recovery material became the most important part of the exercise.

Note: Commands in this article have been sanitised where necessary. Credentials, encryption secrets, application keys and other sensitive infrastructure information are deliberately excluded or represented using placeholders.

What was being decommissioned?

Scholent wasn't simply a Laravel directory sitting on a VPS.

The production environment included:

Ubuntu 22.04
Laravel 12
PHP 8.3
MySQL 8
Nginx
Redis
Supervisor
Let's Encrypt
Stancl-based multi-tenancy
DigitalOcean compute
DigitalOcean Managed MySQL

The deployed Laravel application lived under:

/var/www/school-platform

There were also existing infrastructure snapshots.

This matters because preserving a Git repository alone would not necessarily preserve enough information to reconstruct the application.

A working Laravel SaaS can depend on considerably more:

Application source
        +
Composer dependencies
        +
Database
        +
Environment configuration
        +
APP_KEY / encryption material
        +
Web server configuration
        +
Queue workers
        +
Redis
        +
Scheduled jobs
        +
DNS
        +
TLS
        +
Tenant configuration
        +
External services

So the first job was not creating a .zip file.

It was determining what constituted the system.

1. Inventory the environment before touching anything

Before removing infrastructure, I documented the environment and the components required to reconstruct it.

For a PHP application, even something as basic as recording versions matters.

Typical checks include:

php -v

mysql --version

and for Laravel:

php artisan --version

Along with the obvious questions:

Which PHP version?
Which MySQL version?
Which Laravel version?
Where is Redis?
How are queues processed?
How is Nginx configured?
How is TLS handled?
How does tenancy work?
Which scheduled jobs exist?
Which external services does the application depend on?

This information is easy to obtain while the server exists.

It becomes considerably less convenient after the server has been deleted.

2. Create independent recovery artefacts

I separated the recovery material into broad categories rather than treating the existing server as the archive.

That included:

Application
Database
Server configuration
Recovery documentation

The application and relevant configuration were archived independently.

A simplified example of the approach is:

tar -czf application.tar.gz /var/www/school-platform

with relevant server configuration archived separately.

The actual application archive was approximately 16 MB, while the server-configuration archive was approximately 121 KB.

Those numbers aren't particularly important by themselves.

What mattered was that the recovery set contained the material I expected it to contain.

The database was handled separately because I wanted to test it independently later.

3. Encrypt sensitive recovery material

Application archives and database exports can contain information that should not simply be copied into general storage unprotected.

Depending on the application, this may include:

environment configuration
database connection information
API credentials
application encryption material
user data
internal infrastructure information

I encrypted the sensitive archives using AES-256-CBC with PBKDF2-based key derivation and a deliberately high iteration count.

The general form was:

openssl enc \
  -aes-256-cbc \
  -salt \
  -pbkdf2 \
  -iter <iteration-count> \
  -in <archive> \
  -out <archive>.enc

The real password and sensitive parameters obviously do not belong in a public article.

The same applies to Laravel's APP_KEY.

For some Laravel applications, losing the original APP_KEY can mean losing the ability to decrypt data that was encrypted using it.

So preserving recovery secrets matters.

But preserving them inside an unprotected archive rather defeats the point.

4. Get the recovery material off the infrastructure

This is an obvious rule, but an important one:

A backup that exists only on the infrastructure you are about to destroy is not an acceptable long-term backup.

Once the archives were prepared, I copied them away from the DigitalOcean infrastructure.

I retained independent copies outside the server environment, including local storage and Google Drive.

At this point, however, I still only knew that I had files.

I didn't yet know that those files would recover anything.

5. Verify the transferred files

After transferring the archives, I calculated SHA-256 hashes.

On Linux, that can be done with:

sha256sum <archive>

The same archive can then be hashed again after transfer.

Conceptually:

Server archive SHA-256
        ↓
        == ?
        ↑
Downloaded archive SHA-256

The hashes matched.

That established that the transferred files were byte-for-byte identical to the files produced on the server.

Useful?

Absolutely.

Proof that the application could be recovered?

No.

A checksum answers:

Has this file changed?

It doesn't answer:

Is this file actually useful?

That required a restore test.

6. Test the database backup independently

This was the most important technical test in the process.

I didn't want to verify the database backup by importing it into the original production database.

That would still leave too much dependency on the existing environment.

Instead, I created a disposable MySQL environment using Docker.

The idea was straightforward:

Production database
        │
        │ export
        ▼
Encrypted database archive
        │
        │ copy elsewhere
        ▼
Independent machine
        │
        │ decrypt / decompress
        ▼
Disposable MySQL container
        │
        │ import
        ▼
Inspect recovered database

If the archive failed here, I still had the live infrastructure available to investigate and create another backup.

That's exactly when I wanted failure to occur.

Before deletion.

7. Start a clean MySQL container

I used Docker to provide an isolated MySQL 8 environment.

A simplified version of the command is:

docker run \
  --name scholent-restore-test \
  -e MYSQL_ROOT_PASSWORD='<temporary-test-password>' \
  -e MYSQL_DATABASE=scholent_restore \
  -d \
  mysql:8.0

The restore environment was running:

MySQL 8.0.46

Using a disposable container had several advantages.

It didn't require installing another permanent MySQL instance.

It kept the restore isolated from anything important.

And when the verification was finished, the entire test environment could simply be removed.

Before restoring anything, the container could be checked with:

docker ps

and the MySQL instance interrogated independently.

The important point was that this database server had no dependency on the original Scholent database infrastructure.

8. Restore the backup, not the production database

The encrypted database archive then had to survive the reverse process.

Conceptually:

Encrypted archive
      ↓
Decrypt
      ↓
Decompress
      ↓
MySQL import

The exact recovery pipeline depends on how the original database archive was packaged.

The important thing was that I was feeding the archived database into the disposable MySQL environment rather than querying the original production database.

A conventional import into the container would look like:

docker exec -i scholent-restore-test \
  mysql \
  -uroot \
  -p'<temporary-test-password>' \
  scholent_restore < scholent.sql

In my case, the archived database was decrypted and decompressed as part of the recovery process before being imported.

That exercised several parts of the recovery chain at once:

Can I access the encrypted archive?
            ↓
Can it be decrypted?
            ↓
Can the database payload be recovered?
            ↓
Will MySQL accept it?
            ↓
Does the restored database contain what I expect?

The import completed successfully.

But I deliberately didn't stop there.

9. "Import succeeded" isn't enough either

A database import returning without an obvious error is encouraging.

It isn't the same as checking the restored database.

So I queried the restored environment.

For example:

docker exec -it scholent-restore-test \
  mysql -uroot -p

Then:

USE scholent_restore;
SHOW TABLES;

The restored Scholent database contained:

82 tables

That was the first useful structural verification.

The schema had actually been reconstructed inside the independent MySQL environment.

But I wanted to go one level further.

10. Check representative application data

Rather than attempting to manually inspect all 82 tables, I selected representative areas of the application.

Queries equivalent to the following were used:

SELECT COUNT(*) FROM tenants;
SELECT COUNT(*) FROM students;
SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM assessments;
SELECT COUNT(*) FROM behaviour_records;

The restored database returned representative counts including:

tenants               4
students              69
users                 29
assessments           11
behaviour_records      4

This was much more useful than simply knowing that mysqldump had produced a file.

At this point I knew that:

✓ The archive existed
✓ The transferred archive matched the original
✓ The protected database material could be recovered
✓ MySQL could import it independently
✓ The database schema had been reconstructed
✓ 82 tables were present
✓ Representative application data was present

That's a substantially stronger recovery position.

11. What exactly had I proved?

It's important not to overstate the result.

I had not rebuilt the complete Scholent production environment from zero and run a full end-to-end application acceptance test.

That would have been a different exercise.

What I had independently tested was the critical database recovery path.

The distinction matters.

I had evidence for:

Archive
   ↓
Transfer
   ↓
Integrity verification
   ↓
Decryption
   ↓
Database recovery
   ↓
Independent MySQL import
   ↓
Schema verification
   ↓
Representative data verification

The reconstruction of the broader Laravel stack was documented in the recovery runbook rather than fully executed during this decommissioning exercise.

I think that distinction is important whenever we talk about disaster recovery.

"Backup tested" can mean many different things.

It is better to state precisely what was actually tested.

12. Create the recovery runbook

Once I knew the critical data could be recovered, I documented how the wider system would be reconstructed.

The runbook covered the major dependencies around:

Ubuntu
PHP
Laravel
MySQL
Nginx
Redis
Supervisor
SSL
DNS
Tenant routing
Application configuration
Encryption material
Post-restore verification

The purpose wasn't to create documentation that could rebuild everything automatically.

It was to reduce ambiguity.

Future me shouldn't have to ask:

How did I configure the workers again?

or:

Was Redis actually required?

or:

How were tenant domains routed?

or, considerably worse:

Where is the encryption key for this data?

A good recovery archive should contain both the material and enough knowledge to make sense of that material.

13. Snapshots are useful, but I didn't want them to be the archive

The DigitalOcean environment also had existing snapshots.

It would have been easy to leave them there and consider the system archived.

I chose not to make that the long-term recovery strategy.

Snapshots are useful operational tools, but for long-term archival I preferred independent recovery artefacts.

That gave me:

Application archive
Database archive
Configuration archive
Recovery documentation

rather than:

"Hopefully that old provider snapshot still gives me everything."

The independent approach is also more portable.

If I eventually rebuild Scholent somewhere else, the recovery strategy isn't inherently tied to the original compute instance.

14. Only then did I destroy the infrastructure

At this point, I had moved through several different verification stages.

Application and configuration

✓ Archived
✓ Encrypted where required
✓ Copied off-server
✓ Integrity checked

Database

✓ Exported
✓ Protected
✓ Copied independently
✓ Decrypted successfully
✓ Restored into disposable MySQL
✓ 82 tables recovered
✓ Representative records verified

Recovery knowledge

✓ Infrastructure documented
✓ Reconstruction procedure documented
✓ Critical configuration requirements identified

Only after those checks did I proceed with removing the paid DigitalOcean infrastructure.

That included the relevant:

Droplet
Managed MySQL instance
Infrastructure snapshots

Obsolete DNS records were also removed.

The domain and email did not need to disappear simply because the compute infrastructure was being retired, so they were retained.

That's another distinction I think is useful:

Decommissioning infrastructure doesn't necessarily mean destroying the application identity or intellectual property associated with it.

My objective was to stop paying for infrastructure I wasn't currently using without turning that cost-saving decision into irreversible data loss.

15. Clean up the disposable recovery environment too

One advantage of using Docker for this kind of verification is that the recovery environment itself doesn't need to become another permanent piece of infrastructure.

Once verification was complete, the test container could be removed:

docker stop scholent-restore-test
docker rm scholent-restore-test

If a dedicated Docker volume had been created for the exercise, that could also be removed once it was no longer required.

The restore environment had served its purpose:

prove that the archived database could reconstruct usable data independently of production.

Then it could disappear too.

The different levels of backup confidence

This exercise made me think about backup verification as a progression.

Level 1: The backup command completed

I probably have a backup.

Level 2: The file exists

I definitely have a file.

Level 3: The checksum matches after transfer

I know the file I downloaded is the same file I created.

Level 4: The encrypted archive can be recovered

I can still access the protected contents.

Level 5: The database imports successfully elsewhere

The backup can reconstruct a database independently.

Level 6: Schema and representative data are verified

The reconstructed database resembles the application data I intended to preserve.

Level 7: Full application recovery is tested

The complete service can be reconstructed and validated.

For this decommissioning exercise, I independently tested through the database-recovery and data-verification stages.

I documented the remaining application reconstruction requirements rather than claiming a complete end-to-end disaster-recovery test that I hadn't performed.

A practical Laravel SaaS decommissioning checklist

If I were retiring another Laravel application tomorrow, my high-level checklist would look something like this.

Understand what exists

[ ] Application/version inventory
[ ] PHP version
[ ] Database/version
[ ] Redis/cache dependencies
[ ] Queue configuration
[ ] Scheduled jobs
[ ] Web server configuration
[ ] SSL configuration
[ ] DNS requirements
[ ] External services
[ ] Tenant-specific architecture

Preserve it

[ ] Application/source
[ ] Database export
[ ] Relevant environment configuration
[ ] APP_KEY and other required secrets
[ ] Nginx/server configuration
[ ] Queue/worker configuration
[ ] Relevant storage
[ ] Recovery documentation

Protect it

[ ] Encrypt sensitive recovery material
[ ] Store recovery credentials separately
[ ] Copy archives away from production

Verify it

[ ] Generate checksums
[ ] Verify transferred copies
[ ] Decrypt the archive
[ ] Restore the database independently
[ ] Inspect schema
[ ] Query representative records

Document it

[ ] Write recovery sequence
[ ] Record software versions
[ ] Record infrastructure dependencies
[ ] Document DNS/TLS requirements
[ ] Document tenancy
[ ] Record post-restoration verification

Only then

[ ] Remove compute
[ ] Remove managed databases
[ ] Remove unnecessary snapshots
[ ] Remove obsolete DNS
[ ] Verify billing/resources
[ ] Retain domains/services that still have a purpose

What I'd change next time

The biggest improvement I'd make is to treat the recovery runbook as a living part of the application rather than something created primarily when the application is being retired.

The same applies to restore testing.

Backups are easy to automate.

Restore tests are easier to postpone.

But the restore is the part that actually tells you whether the backup strategy works.

I'd also consider automating more of the verification process for a system that remained operational long-term.

For example, a controlled process could periodically:

Create backup
      ↓
Verify checksum
      ↓
Create disposable database
      ↓
Restore
      ↓
Run verification queries
      ↓
Report result
      ↓
Destroy test environment

Docker makes that kind of disposable recovery testing considerably easier.

Final thought

Deleting the Scholent infrastructure took very little time.

Getting to the point where I was comfortable deleting it took considerably longer.

And that's how I think it should be.

The process ultimately became:

Inventory
   ↓
Archive
   ↓
Encrypt
   ↓
Transfer
   ↓
Hash
   ↓
Restore
   ↓
Inspect
   ↓
Document
   ↓
Decommission

The most important lesson wasn't really about DigitalOcean, Docker, MySQL or Laravel.

It was this:

Don't test whether you can create a backup. Test whether you can restore from it.

A backup file tells me that I saved something.

Seeing 82 tables and the expected application data inside a clean MySQL container tells me considerably more.

Patching Critical PHP Vulnerabilities on Ubuntu 24.04: A Production Laravel Walkthrough

Michael Oteng — Thu, 22 Oct 2026 11:14:10 +0000

On 21 October 2026, two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, prompted a review of the production infrastructure behind SwiftVecto, a web-based platform offering browser utilities and file-processing tools.

The following morning, I carried out security maintenance on the Ubuntu server hosting the application.

What initially appeared to be a straightforward PHP upgrade turned into a useful reminder about distribution-maintained packages, security backports, backups, and the difference between a successful package installation and a healthy production application.

This article documents the actual maintenance process, including the commands used, the results obtained, and the checks performed before returning the server to normal operation.

For security reasons, application-specific directory paths, database names and service identifiers have been replaced with generic examples.

1. Understanding the vulnerability and the available fix

The two PHP vulnerabilities were addressed through security updates released by the PHP project and Linux distribution maintainers.

The important question was not simply whether the server was running the latest upstream PHP release.

It was whether the installed packages contained the security fixes required to address the vulnerabilities.

This distinction matters because Ubuntu, like other Linux distributions, can backport security fixes into existing package versions.

For Ubuntu 24.04 LTS, security notice USN-8948-1 identified the corrected PHP 8.3 package revision as:

8.3.6-0ubuntu0.24.04.13

That was the version I needed to verify against the production environment.

Rather than replacing Ubuntu's PHP installation with packages from an alternative repository, the preferred approach was to use the distribution's maintained security packages.

2. Establishing the production environment

The environment consisted of:

Component	Configuration
Hosting	DigitalOcean Droplet
Operating system	Ubuntu 24.04.4 LTS
Application framework	Laravel
Web server	Nginx
PHP runtime	PHP 8.3-FPM
Database	MySQL
Background processing	Supervisor-managed Laravel queue worker

I started by checking the operating system and PHP version:

cat /etc/os-release
php -v

The PHP command reported:

PHP 8.3.6 (cli)

At first glance, that looked concerning.

The upstream PHP project had released newer versions containing the security fixes, while the server was still reporting PHP 8.3.6.

However, the upstream version number alone was not sufficient to determine whether the Ubuntu installation was patched.

There were two reasons.

First, php -v reports the command-line runtime, which is not necessarily the runtime serving web requests.

Second, Ubuntu may retain the same upstream PHP version while incorporating backported security fixes.

The next step was to inspect the actual installed packages.

3. Checking the installed PHP package revisions

I queried the PHP packages using:

dpkg-query -W \
  -f='${Package} ${Version}\n' \
  'php8.3*' 2>/dev/null

The relevant installed packages were at:

8.3.6-0ubuntu0.24.04.12

This included:

php8.3-cli
php8.3-fpm
php8.3-common
php8.3-opcache

Ubuntu's security notice identified .13 as the corrected revision.

The server was running .12.

That established that the relevant security update had not yet been installed.

Why the package revision matters

Consider these two versions:

8.3.6-0ubuntu0.24.04.12
8.3.6-0ubuntu0.24.04.13

Both contain the upstream version number 8.3.6.

However, they are different Ubuntu package revisions.

The final revision incorporates distribution-specific changes, which can include security backports.

For administrators maintaining Ubuntu systems, this is why checking only php -v can be misleading.

The exact package revision must be compared against the vendor's security advisory.

4. Refreshing the package indexes

I checked the versions available through APT:

apt-cache policy php8.3-cli php8.3-fpm

Initially, the installed and candidate versions were identical:

Installed: 8.3.6-0ubuntu0.24.04.12
Candidate: 8.3.6-0ubuntu0.24.04.12

The patched revision was not yet visible in the local package indexes.

I refreshed the indexes:

sudo apt update

Running the policy check again showed:

Installed: 8.3.6-0ubuntu0.24.04.12
Candidate: 8.3.6-0ubuntu0.24.04.13

The patched version was now available through the configured Ubuntu repositories.

There was no need to introduce a third-party repository or migrate to another PHP release branch.

This kept the maintenance focused on the relevant security update.

5. Simulating the upgrade before changing production

Before installing anything, I ran an APT simulation:

sudo apt-get -s install --only-upgrade \
  php8.3-cli \
  php8.3-fpm \
  php8.3-common \
  php8.3-opcache

APT reported:

14 upgraded, 0 newly installed,
0 to remove and 69 not upgraded.

The proposed changes included the four explicitly requested packages and their related PHP extensions.

These included components used for MySQL connectivity, XML processing, ZIP handling, image processing and other application functionality.

All 14 packages were scheduled to move from revision .12 to .13.

The simulation provided two useful assurances:

The update could be resolved without installing additional packages or removing existing ones.
The proposed changes were limited to the expected PHP packages and extensions.

The 69 other packages were outside the scope of this targeted PHP update and would require separate review.

For production maintenance, I prefer to understand exactly what the package manager intends to change before approving an installation.

6. Creating backups before applying the patches

Before proceeding, I created a DigitalOcean Droplet snapshot.

That provided a server-level recovery option if the maintenance introduced an unexpected infrastructure problem.

However, I also wanted a separate logical database backup.

The application uses MySQL on the same server, so relying exclusively on a Droplet snapshot would not have been my preferred approach.

I first verified the database service:

systemctl is-active mysql

The result was:

active

I then created a restricted backup directory.

The path below is illustrative rather than the actual production location:

sudo install -d -m 700 /root/app-backups

A compressed logical database backup can be created using:

set -o pipefail

BACKUP="/root/app-backups/database-$(date +%Y%m%d-%H%M%S).sql.gz"

mysqldump \
  --single-transaction \
  --quick \
  --no-tablespaces \
  --routines \
  --triggers \
  --events \
  app_database | gzip > "$BACKUP"

Here, app_database is a placeholder for the actual database name.

The --single-transaction option is useful for producing a consistent logical backup of InnoDB tables without locking them for the entire dump, provided concurrent schema changes are avoided.

The pipefail setting ensures that a failure in mysqldump is not concealed by a successful exit from gzip.

After creating the backup, I checked the compressed file:

gzip -t "$BACKUP"

I also inspected the end of the SQL dump:

zcat "$BACKUP" | tail -n 8

The actual backup contained the MySQL completion marker:

-- Dump completed on 2026-10-22  4:28:45

The compressed backup was approximately 866 KB.

Restricting access to database backups is also important:

chmod 600 "$BACKUP"

The backup passed the compression integrity check, and the completion marker was present.

These checks do not replace a proper restoration test, but they provide useful evidence that the backup completed successfully.

With the Droplet snapshot and database backup available, the update could proceed with a more reasonable recovery position.

7. Applying the PHP security update

I ran the targeted installation:

sudo apt-get install --only-upgrade \
  php8.3-cli \
  php8.3-fpm \
  php8.3-common \
  php8.3-opcache

APT upgraded the expected 14 PHP packages.

These included:

PHP CLI and PHP-FPM
PHP common components and OPcache
MySQL and SQLite extensions
cURL, GD and internationalisation extensions
Multibyte string, XML and ZIP extensions
Other installed PHP 8.3 components

The installation completed successfully, and PHP-FPM restarted during the update.

I then checked the installed package revisions:

dpkg-query -W \
  -f='${Package} ${Version}\n' \
  php8.3-cli \
  php8.3-fpm \
  php8.3-common \
  php8.3-opcache

All four packages reported:

8.3.6-0ubuntu0.24.04.13

This matched the corrected revision identified in Ubuntu's security notice.

The PHP vulnerabilities had been addressed through Ubuntu's security-maintained packages without changing the application's PHP major or minor version.

8. Verifying PHP-FPM and background processing

Installing the packages was only part of the maintenance.

The next step was to verify that the services required by the application were still functioning.

I checked PHP-FPM:

systemctl status php8.3-fpm --no-pager

The service reported:

Active: active (running)

I reviewed its recent journal entries:

journalctl -u php8.3-fpm \
  --since "15 minutes ago" \
  --no-pager -n 40

The inspected output showed normal service restarts during the package installation, with no startup errors.

The application also uses Laravel queues for background processing.

These workers are managed by Supervisor, so I checked their status:

sudo supervisorctl status

The production worker was running.

This is an important check for Laravel applications.

A website may respond successfully to HTTP requests while queued jobs remain unprocessed because a background worker has stopped.

Checking the homepage alone would not establish that the application was functioning as expected.

9. Checking the website and application logs

I tested the public HTTPS endpoint:

curl -sS -o /dev/null \
  -w 'HTTP status: %{http_code}\n' \
  https://swiftvecto.com/

The response was:

HTTP status: 200

That confirmed the homepage was responding successfully.

I also reviewed the Laravel application logs for evidence of new errors following the update.

For readers adapting this procedure, the application log can be inspected using a command such as:

tail -n 50 /var/www/example-app/storage/logs/laravel.log

The path above is an example and should be replaced with the relevant application directory.

When reviewing logs after maintenance, I find it useful to distinguish between historical errors and errors that began during or after the change window.

An existing error should not automatically be attributed to the latest update simply because it appears in the log.

In this case, the inspected log contained no newly recorded production errors attributable to the PHP maintenance.

That was reassuring, but it was not a substitute for testing individual application features.

An HTTP 200 response verifies that a particular endpoint responded successfully. It does not prove that every controller, database operation, queued job or file-processing function works correctly.

Infrastructure verification and application regression testing are separate responsibilities.

10. Identifying a pending kernel update

During the maintenance, Ubuntu also reported that the running kernel was older than the installed kernel.

The running kernel was:

6.8.0-134-generic

The newer installed kernel was:

6.8.0-147-generic

This was separate from the PHP vulnerability remediation.

However, because the server was already undergoing controlled maintenance, I decided to complete the pending kernel activation.

Before rebooting, I checked that the essential services were configured to start automatically:

systemctl is-enabled \
  nginx php8.3-fpm mysql supervisor

All four returned:

enabled

I checked their current running states:

systemctl is-active \
  nginx php8.3-fpm mysql supervisor

All four were active.

I also verified the installed kernel package:

dpkg-query -W \
  -f='${Package} ${Status} ${Version}\n' \
  linux-image-6.8.0-147-generic

The result confirmed:

linux-image-6.8.0-147-generic install ok installed 6.8.0-147.147

Finally, I checked for failed systemd units:

systemctl --failed --no-pager

The result was:

0 loaded units listed.

With the pre-reboot checks completed, I initiated a controlled reboot:

sudo systemctl reboot

11. Post-reboot verification

Once the server became available again, I reconnected and verified the active kernel:

uname -r

The output was:

6.8.0-147-generic

I checked the essential services:

systemctl is-active \
  nginx php8.3-fpm mysql supervisor

All four returned:

active

The Supervisor-managed Laravel queue worker had restarted successfully.

I repeated the public website check:

curl -sS -o /dev/null \
  -w 'HTTP status: %{http_code}\n' \
  https://swiftvecto.com/

The response remained:

HTTP status: 200

Finally:

systemctl --failed --no-pager

Again returned:

0 loaded units listed.

The new kernel was active, the essential services had recovered, and the public application remained accessible.

12. What this maintenance exercise reinforced

There are several lessons worth taking from this process.

The upstream version number is not the whole story

PHP 8.3.6 may appear outdated when compared with a newer upstream release.

On Ubuntu, however, security fixes can be backported into distribution-maintained packages.

The correct approach is to compare the exact installed package revision against the relevant Ubuntu security notice.

Simulate package changes before applying them

APT's simulation mode provides an opportunity to inspect dependency changes, package removals and the overall upgrade scope.

It is a simple step that can prevent avoidable surprises.

Maintain more than one recovery option

A Droplet snapshot and a logical MySQL backup serve different purposes.

Having both available before modifying production infrastructure improves recovery options if something goes wrong.

Neither should be considered fully validated without an appropriate restoration test.

Check background services as well as HTTP responses

Laravel applications may depend on queue workers, scheduled tasks and other processes that are not exercised by a homepage request.

Checking Nginx and PHP-FPM is necessary, but it may not be sufficient.

Keep security maintenance focused

A critical security update is not the ideal time to introduce unrelated application changes.

The PHP update was handled as a targeted maintenance operation, with unrelated work left for separate review.

A successful update is not a complete regression test

A successful package installation, active services, healthy queue workers and an HTTP 200 response are all useful indicators.

They do not prove that every application feature is functioning correctly.

That distinction should remain clear when documenting production maintenance.

Conclusion

The PHP security update on SwiftVecto's production infrastructure was completed successfully.

The server moved from Ubuntu's PHP package revision:

8.3.6-0ubuntu0.24.04.12

To:

8.3.6-0ubuntu0.24.04.13

This addressed the vulnerabilities identified in Ubuntu's security notice.

Fourteen PHP packages were upgraded, PHP-FPM restarted successfully, and the Laravel queue worker remained operational.

A pending kernel update was also activated through a controlled reboot.

Following the reboot, Nginx, PHP-FPM, MySQL and Supervisor were all active, the website returned HTTP 200, and systemd reported no failed services.

The maintenance did not constitute a complete application regression test or a penetration test, but it provided clear evidence that the required PHP security packages had been installed and that the essential production infrastructure was functioning afterwards.

For me, the main takeaway is that security patching is not simply about installing a newer software version. It is about establishing what is affected, verifying the vendor's fix, preparing a recovery path, controlling the change, and checking the system afterwards.

References

Wi-Fi or VPN sign-in failing after a Windows update? What to check

Michael Oteng — Fri, 16 Oct 2026 08:24:23 +0000

When a user says their Wi-Fi or VPN stopped working after an update, there are quite a few things to check. Drivers, connection profiles, credentials and the network itself can all come into it.

One more thing worth checking after the October 2026 Windows updates is how the connection handles automatic sign-in.

This walkthrough is based on Microsoft’s published guidance. It is a troubleshooting reference, rather than a report of an incident I have personally reproduced.

What changed?

Microsoft’s 13 October 2026 update changes the default handling of NTLMv1-derived single sign-on credentials from auditing to blocking.

The documented scope covers Windows 11 24H2, 25H2, 26H2 and Windows Server 2025 where Credential Guard is disabled and BlockNtlmv1SSO is unset.

Connections using MS-CHAPv2, including certain Wi-Fi, wired network and VPN configurations, can be affected.

A useful clue is that automatic sign-in may fail while manually entering credentials still works.

That gives you a direction to investigate. It does not, on its own, confirm the cause.

Start with the affected computer

Before changing anything, record:

The Windows version and OS build from winver.
The installed update from Windows Update history.
When the failure started.
Whether it affects Wi-Fi, wired access, VPN, or more than one.
Whether manual sign-in behaves differently.

I would also compare an affected device with a working one, where possible. Keep the comparison specific: the same connection, similar configuration and the same test.

Check whether Credential Guard is running

Open System Information by running:

msinfo32

Under System Summary, look for Virtualization-based security Services Running and check whether Credential Guard appears.

You can also query it from an elevated PowerShell session:

$deviceGuard = Get-CimInstance `
    -Namespace 'root\Microsoft\Windows\DeviceGuard' `
    -ClassName Win32_DeviceGuard `
    -ErrorAction Stop

[pscustomobject]@{
    CredentialGuardRunning = (
        $deviceGuard.SecurityServicesRunning -contains 1
    )
}

True means the returned running-services list includes Credential Guard.

If the query fails, treat the result as unknown. A failed query does not prove that the feature is disabled.

Microsoft documents these verification methods in its Credential Guard configuration guide.

Check the authentication method

Review the deployed Wi-Fi, wired or VPN profile with whoever manages it. Look specifically for MS-CHAPv2, including PEAP-MSCHAPv2 and EAP-MSCHAPv2.

Record the actual configuration rather than assuming every device receives the same settings.

Look for matching events

In Event Viewer, open:

Applications and Services Logs → Microsoft → Windows → NTLM → Operational

Microsoft identifies:

4024: an audited attempt.
4025: a blocked attempt.

This read-only PowerShell query retrieves those events from the last seven days:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 4024, 4025
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction Stop |
    Select-Object TimeCreated, Id, Message |
    Format-List

Compare the timestamps and event details with the failed connection attempt. An unrelated event elsewhere in the week is not enough to explain the user's problem.

If no matching events are returned, keep investigating. If access is denied or the log cannot be read, resolve that before interpreting the result.

What about a temporary fix?

Microsoft documents an audit-mode exception, but it reduces protection and should be scoped and temporary. Follow KB5066470 for the settings and current guidance.

Before making an exception, record the affected devices, the reason, who owns the remediation and when it will be reviewed.

Add sign-in to the update test

For a pilot deployment, I would include:

Automatic network sign-in after a restart.
VPN connection and reconnection.
Access to the internal resources users actually need.
A check for new authentication errors.

It is easy to focus on whether an update installed successfully. For the person using the computer, the more useful test is whether they can still connect and get on with their work.

What Building a Browser-Based PDF Editor Taught Us About PDF Coordinates, State and Export

Michael Oteng — Fri, 09 Oct 2026 20:40:08 +0000

Building a PDF editor looks deceptively simple at first.

Render a PDF in the browser, place some controls around it, let the user add text or images, and then save the result.

That sounds reasonable until the first object has to survive zooming, page resizing and export.

While developing the Edit PDF tool for SwiftVecto, we found that the visible editing interface was only a small part of the problem.

The harder work was underneath it.

How do you make sure an object placed at a particular position in the browser appears at exactly the same position in the exported PDF?

How do you represent edits without constantly rewriting the original document?

What happens when pages have different dimensions?

What does "redact" actually mean?

And when should an operation happen in the browser rather than on the server?

These turned out to be some of the most interesting engineering problems in the project.

1. The screen is not the PDF

One of the first problems is coordinate systems.

Browser interfaces normally work from the top-left:

0,0 ─────────────→ X
 │
 │
 ↓
 Y

PDF coordinate systems traditionally work from the bottom-left:

 Y
 ↑
 │
 │
0,0 ─────────────→ X

Already, an object's Y position cannot simply be copied from the browser into the PDF.

But that is only the beginning.

Now introduce:

zoom
page rotation
crop boxes
media boxes
different page dimensions
device pixel ratios
responsive editor layouts

A text object that appears at (300, 420) on the screen does not necessarily belong at (300, 420) in the PDF.

This becomes especially obvious when zooming.

Suppose the user positions an object while viewing a page at 80% zoom. If its stored coordinates are based on screen pixels, changing the zoom can effectively change the document.

That is the wrong model.

Zoom should change the view, not the underlying document state.

A much safer architecture is to treat coordinate conversion as its own subsystem:

PDF coordinates
      ↕
Editor coordinates
      ↕
Screen coordinates

Features then use the same transformation layer rather than implementing their own coordinate calculations.

That becomes increasingly important as the editor grows.

2. Don't rewrite the PDF after every edit

Another important decision was how to represent the document while it is being edited.

The tempting approach is:

User adds text
      ↓
Modify PDF

User adds image
      ↓
Modify PDF again

User moves object
      ↓
Modify PDF again

That quickly becomes difficult to manage.

Instead, we found it much more useful to think of the editor as maintaining its own document state.

Conceptually:

Original PDF
     │
     ├── Original pages
     │
     └── Editor state
           ├── Page operations
           ├── Text objects
           ├── Images
           ├── Drawings
           ├── Annotations
           ├── Links
           ├── Forms
           └── Redactions

An editor object can then have a structure along these lines:

{
    id: 'obj_82',
    type: 'text',
    pageId: 'page_1',

    bounds: {
        x: 140,
        y: 215,
        width: 180,
        height: 32
    },

    content: 'SwiftVecto',

    style: {
        fontFamily: 'Helvetica',
        fontSize: 16,
        bold: false,
        italic: false,
        color: '#111827',
        opacity: 1
    }
}

The important part is not the exact schema.

It is the separation between the source document and the editing state.

That separation makes features such as moving objects, undo/redo, deleting objects and changing properties considerably easier to reason about.

3. Stable page identity matters

Page management introduces another interesting problem.

Imagine a five-page document.

The user adds something to page 3.

Then they move page 3 to the beginning of the document.

Is the object attached to page 3, or to the page that is now page 1?

If objects are associated only with page numbers, reordering becomes dangerous.

A better model gives each page a stable internal identity.

For example:

{
    id: 'page_a81f',
    sourcePage: 3,
    rotation: 0,
    deleted: false,
    objects: []
}

The visible page number can change.

The page identity does not.

That distinction makes page reordering much easier to manage because objects belong to a page entity rather than to a temporary position in an array.

4. Added content and existing content are different problems

Adding new text to a PDF and editing text that already exists in the PDF may look like the same operation to a user.

Technically, they are very different.

Adding new text can often be represented as a new editor object:

Page
 + text object

Existing PDF text may instead be represented internally as positioned glyphs, text runs, font references and drawing instructions.

There may not be anything resembling the editable paragraph you would find in a word processor.

This is one reason PDF editing becomes significantly more complicated once an editor moves beyond adding objects and starts modifying the document's existing content.

The UI may make both operations look similar.

The document model underneath them is not.

5. Redaction is not a black rectangle

This was one of the most important distinctions in the editor.

Visually covering information is not necessarily redacting it.

If sensitive text remains inside the PDF and a black rectangle is simply drawn over it, the underlying information may still exist.

Depending on how the PDF is constructed, it might still be extractable, searchable or recoverable.

A real redaction workflow therefore needs to treat redaction differently from ordinary drawing.

Conceptually:

Select sensitive region
        ↓
Identify affected content
        ↓
Remove or irreversibly alter that content
        ↓
Apply the visible redaction appearance
        ↓
Generate and validate the resulting PDF

That is fundamentally different from:

Draw black rectangle

The two may look identical on screen.

From a document-security perspective, they are not remotely equivalent.

6. OCR is another separate layer

OCR creates a similar distinction.

A scanned PDF may contain pages that are effectively just images.

A human can read the text.

The PDF cannot necessarily search or select it.

OCR can identify characters in those images, but an editor then has to decide what to do with that information.

Possible outcomes include:

extracted text
searchable text layers
selectable text
positioning data
confidence information

So "run OCR" is not really a single UI operation.

It is a document-processing pipeline.

That affects where the feature belongs architecturally.

7. Not everything belongs in the browser

We wanted the editor to feel immediate, so interactive operations naturally belong close to the user.

Things such as:

rendering
selection
dragging
resizing
drawing
annotations
signatures
page thumbnails
reordering
zoom
undo and redo

are well suited to browser-side interaction.

But some operations have different requirements.

For example:

OCR
true redaction
document sanitisation
complex content removal
PDF repair or normalisation
final output validation

may require heavier or more controlled processing.

For SwiftVecto, this led to a hybrid model.

The browser owns the interactive editing experience.

The processing layer handles operations where heavier processing or output correctness becomes more important.

This also means privacy claims need to be precise.

It would be misleading to say that every PDF operation always happens locally if some features legitimately require server-side processing.

8. Export is where everything has to agree

An editor can look perfect in the browser and still produce a bad PDF.

Export is where all the architectural decisions finally meet.

Conceptually, our pipeline looks more like:

Original PDF
      +
Editor state
      ↓
Apply page operations
      ↓
Apply content changes
      ↓
Apply annotations
      ↓
Apply images, text and signatures
      ↓
Apply forms
      ↓
Apply redactions
      ↓
Validate output
      ↓
Final PDF

If the coordinate model is wrong, export exposes it.

If page identity is wrong, export exposes it.

If zoom has leaked into document coordinates, export exposes it.

If reordered pages have lost their objects, export exposes it.

This is why treating export as an afterthought is risky.

The editor and export pipeline need to share the same understanding of the document.

The biggest lesson

The biggest lesson from building the editor has been that a PDF editor is not primarily a toolbar.

The toolbar is simply the visible interface to a much larger document system.

Behind buttons such as:

Text
Image
Sign
Draw
Shapes
Annotate
Link
Forms
Redact
Crop
OCR
Pages

are several different engineering problems involving document state, coordinate transformation, page identity, rendering, processing and export.

Once those concerns are separated properly, adding features becomes much more manageable.

Without those boundaries, every new feature risks becoming another special case.

We wrote a more detailed breakdown of the architecture and the problems we encountered in the original SwiftVecto guide:

https://swiftvecto.com/guides/building-a-browser-based-pdf-editor

The browser-based editor discussed here is also available to try on SwiftVecto:

https://swiftvecto.com/tool/edit-pdf

Formatting Laravel Blade Templates: Why It Is Harder Than Formatting HTML

Michael Oteng — Sat, 12 Sep 2026 14:34:11 +0000

Laravel Blade templates can look deceptively simple.

At first glance, a .blade.php file is mostly HTML. That can make formatting one seem like the same problem as formatting an ordinary HTML document.

It isn't.

A Blade template can combine HTML with conditional directives, loops, components, slots, PHP expressions and Laravel-specific syntax, sometimes within the same few lines.

Consider a deliberately badly formatted example:

<div class="user-card">
@if($user)
@if($user->active)
<h2>{{ $user->name }}</h2>
<p>{{ $user->email }}</p>
@if($user->isAdmin())
<span class="badge">Administrator</span>
@elseif($user->isEditor())
<span class="badge">Editor</span>
@else
<span class="badge">User</span>
@endif
@else
<p>This account is inactive.</p>
@endif
@else
<p>No user is available.</p>
@endif
</div>

The HTML itself is not particularly complicated. The difficulty comes from understanding the structure created by the Blade directives around it.

A formatter needs to recognise that @if, @elseif, @else and @endif are related control structures. It needs to understand how the HTML is nested inside those structures while also preserving Blade expressions such as {{ $user->name }}.

Simply treating the file as HTML is therefore not enough.

What a Blade-aware formatter needs to understand

Formatting HTML is largely concerned with the hierarchy of elements.

For example:

<div>
    <section>
        <p>Hello</p>
    </section>
</div>

The opening and closing tags provide most of the information needed to understand the structure.

Blade introduces another structural layer.

@if ($user)
    <div>
        @foreach ($user->notifications as $notification)
            <p>{{ $notification->message }}</p>
        @endforeach
    </div>
@endif

There are now at least three things a formatter needs to reason about:

The HTML structure.
The Blade directive structure.
The expressions embedded within the template.

Real templates can become considerably more complicated when components, slots, conditional attributes, sections and other Blade features are introduced.

<x-layout>
    <x-slot:title>
        {{ $pageTitle }}
    </x-slot:title>

    @if ($user->isAdmin())
        <x-admin.dashboard :user="$user" />
    @else
        <x-user.dashboard :user="$user" />
    @endif
</x-layout>

A formatter that only understands HTML does not have a complete picture of that document.

What should our badly formatted example become?

Running the original example through a Blade-aware formatter produces a much clearer structure:

<div class="user-card">
    @if ($user)
        @if ($user->active)
            <h2>{{ $user->name }}</h2>
            <p>{{ $user->email }}</p>
            @if ($user->isAdmin())
                <span class="badge">Administrator</span>
            @elseif ($user->isEditor())
                <span class="badge">Editor</span>
            @else
                <span class="badge">User</span>
            @endif
        @else
            <p>This account is inactive.</p>
        @endif
    @else
        <p>No user is available.</p>
    @endif
</div>

Nothing particularly exciting happened to the application logic.

That's the point.

Formatting isn't supposed to redesign the template. It makes its existing structure easier for a human to see.

The relationship between the outer user check, the account status check and the role check is now immediately apparent.

There is also a smaller change that is easy to overlook:

@if($user)

became:

@if ($user)

Consistent spacing and indentation might seem cosmetic, but across a large collection of views they reduce unnecessary variation and make templates easier to scan.

Formatting is not linting

This distinction is important.

A formatter can make code consistent without determining whether that code represents a good implementation.

For example, this can be beautifully formatted:

@if ($conditionOne)
    @if ($conditionTwo)
        @if ($conditionThree)
            @if ($conditionFour)
                ...
            @endif
        @endif
    @endif
@endif

But formatting does not answer whether four levels of nested conditions belong in the template.

Perhaps some of that logic should move elsewhere. Perhaps a Blade component would make the view clearer. Perhaps the underlying design needs reconsideration.

Similarly, a formatter cannot necessarily tell you that:

a route name does not exist;
a variable was never passed to the view;
a component is missing;
an included view does not exist;
the business logic is incorrect.

Formatting improves presentation. It should not be confused with validation, static analysis, testing or application design.

Blade formatting options

There are several ways to approach Blade formatting.

Editor extensions can format templates as part of the development workflow. Blade-aware Prettier tooling can provide automated formatting, and dedicated Blade formatter projects are available for developers who want formatting integrated into their local environment.

Laravel Pint also supports Blade formatting.

Blade formatting is not enabled by default in Pint, but it can be invoked with the --blade option or configured using the Pint/laravel_blade rule.

For a Laravel project where Pint is already part of the development workflow, that can be a natural place to enforce formatting consistently.

There are also situations where you may not want to configure anything locally.

Perhaps you have been sent a Blade fragment.

Perhaps you are reviewing an example outside the original project.

Perhaps you are working on a machine without the project's development environment.

Or perhaps you simply want to paste a template somewhere, format it and copy the result.

That is where a browser-based formatter can be useful.

Building a browser-based Blade formatter

While developing SwiftVecto, I wanted the Laravel Blade Formatter to work without requiring the user to upload a Blade file or configure a Laravel project.

The formatter therefore operates directly in the browser using Blade-aware formatting tooling.

The basic workflow is intentionally simple:

Blade source
     ↓
Blade-aware formatter
     ↓
Formatted template
     ↓
Copy result

The tool also analyses the source separately to provide information such as directive counts, echo expressions, components, slots, loops, conditionals, sections and approximate directive nesting depth.

Those statistics aren't part of formatting itself. They are simply another way of getting a quick picture of the structure of a template.

The important architectural distinction is that normal interactive formatting is performed in the browser rather than sending the Blade source to the server for processing.

Creating reusable formatting fixtures

While testing formatting behaviour, another useful idea emerged.

Instead of keeping test examples buried inside development notes, why not make them reusable?

I created a public SwiftVecto repository for Blade formatting examples and fixtures.

A simple fixture structure can contain:

fixtures/
├── unformatted/
│   └── conditionals.blade.php
└── expected/
    └── conditionals.blade.php

The unformatted version provides a reproducible input.

The expected version provides a reference result.

That makes it easier to experiment with different formatting workflows and, as the fixture collection grows, test more interesting Blade structures.

The expected output should not necessarily be treated as the one canonical way every Blade template must look. Formatter versions, configuration and formatting rules can legitimately produce different results.

The important part is having reproducible examples.

Try the example yourself

The example used in this article is available as part of the public Blade formatting fixtures:

View the Blade formatting examples on GitHub

You can also paste the unformatted example directly into the browser-based formatter:

Try the SwiftVecto Laravel Blade Formatter

No Laravel project is required to experiment with it.

Final thoughts

Formatting will not make a Blade template well designed.

It will not fix application logic, replace testing or tell you whether a view has become too complicated.

What it can do is remove unnecessary visual inconsistency and make the structure that already exists considerably easier to reason about.

And with Blade, that structure involves more than HTML.

As the public fixture collection grows, I plan to add examples covering components, slots, loops, layouts, forms, convenience directives and some of the more awkward structures that can appear in real Blade templates.

If you have an interesting Blade formatting edge case, I'd be interested to see it.