Longtail Forge Update: When a Safe Upgrade Has to Stop
Longtail Forge Update · October 3–16, 2026
In the last Longtail Forge update, I wrote about finally getting the TypeScript compiler to stop complaining. That was a real milestone. Then came the part where the finished code had to leave GitHub and actually run on a server.
That part didn’t go nearly as smoothly.
Two releases got stopped for two different reasons. The first ran into a disagreement about the SQLite version inside the application. The second couldn’t even be unpacked by Docker on the preview host. Neither problem was a missing button or an inconvenient error message. These are the sorts of problems that can turn a routine upgrade into a very long afternoon if the deployment process is willing to guess.
The good news is more specific than saying the releases were tested. The bad upgrades stopped before changing the running preview. The repairs also exposed a few places where backup checks, recovery, and packaged maintenance tools needed to be more deliberate. That’s what this update is about.
The short version
- The October 5 release,
0.33.33, was published but correctly refused by the preview’s deployment helper because its SQLite dependency didn’t match the helper’s approved version. - A follow-up release fixed that compatibility check without sacrificing the ability to roll back to the previous working release. It also repaired missing maintenance files and strengthened early backup checks.
- That follow-up still couldn’t deploy: Docker couldn’t unpack an image layer on the preview host. The existing application stayed untouched.
- Release
0.33.33.51, published October 14, repackages the same runtime without the incompatible layer markers, with new checks designed to catch the problem before release. - The public demo was upgraded under supervision and its resets were verified. That is not the same thing as declaring the separate private preview upgraded, or saying the next product modules are finished.
The first refusal was about trusting the database
When 0.33.33 was published on October 5, the release process had the usual test results, packaged files, and checksums. But the Compose deployment helper on the preview server looked at the release metadata and said no.
The disagreement was between two versions of better-sqlite3, the Node.js library that lets Longtail Forge talk to its SQLite database. The helper was approved for version 13.0.1. The new application shipped 13.0.3, with a newer SQLite library underneath it. The software might have started. That’s not the same thing as having proved the combination was safe for this deployment.
So the helper refused the upgrade before it pulled an image. No switching versions, no database migration, no attempt to work around a check just because the build was green. That is the behavior I want from a safety boundary, even though it makes for a lousy release day.
The October 6 repair, version 0.33.33.50, made that rule more useful. Instead of approving exactly one database-library combination forever, the helper now recognizes the reviewed combinations for both the new release and the previous known-good one. It also runs the selected image and checks what SQLite version it actually uses, rather than simply trusting what a file claims.
The previous version matters because an upgrade isn’t really maintainable if you can move forward but can’t move back. And this change did not mean accepting every newer SQLite version that happens to appear. Unknown combinations are still refused until they’re reviewed.
Reliable automation
Automation is wonderful until it quietly stops working three Tuesdays ago. Raymond Tec builds integrations with logging, monitoring, and failure handling in mind so the boring work stays automated without becoming mysterious.
Then Docker refused to unpack the image
Version 0.33.33.50 fixed that first problem, updated some vulnerable dependencies, and tightened the runtime container. But when the preview host tried to pull the new image, Docker couldn’t unpack one of its layers. The deployment stopped there. Again, the running preview stayed on the earlier release.
This one needs a little Docker explanation. A container image is built in layers. When a later layer removes a file from an earlier one, the image uses a special deletion marker called a whiteout. That’s normal image machinery, and it works on plenty of systems. On the preview host’s Docker storage, removing the old package-manager directory through those markers failed.
The package managers had been removed deliberately from the final runtime image. That’s a sensible way to reduce what an attacker could use if an application were compromised. The problem wasn’t the security goal. It was the way the image expressed the deletion.
The October 14 release, 0.33.33.51, keeps that runtime, including the absence of npm and the other JavaScript package managers, but packages the filesystem as one complete layer. There’s no later layer telling Docker to erase a directory from an earlier one.
That isn’t just a clever workaround that someone tried once and declared fixed. The new image was compared against the previous intended runtime, file by file and configuration field by configuration field. A probe was pulled and started with disposable data on the affected preview host, then removed without replacing the running application. The published image also passed its own native qualification.
A new release check now rejects images containing those whiteout markers, including at publication after the image is pulled back from the registry. That rule may reject a legitimate future image until the checker is deliberately updated. I’d rather have that inconvenience than discover another storage mismatch in the middle of a live deployment.
A failed backup should not become an outage
There was more to the October 6 repair than getting one driver version past a gate. The deployment helper’s recovery rules changed in a way that matters to anyone who has ever had an upgrade stop halfway through.
Before starting, it now checks for the recorded rollback target and the backups needed to return to it. It also requires the Secure Notes recovery-key backup. If those prerequisites are missing, it refuses the request early instead of beginning a maintenance operation it can’t safely finish.
Here’s a concrete example. Suppose the application has entered maintenance mode, but the new pre-upgrade backup can’t be created or inspected. At that point no application data has been changed. The helper can now restart the existing release, verify its identity and health, and reopen it unchanged. The attempted upgrade still counts as failed. That’s an important distinction. Getting the old application back is recovery, not proof that the new release worked.
That protection has boundaries. A failure after data has changed can require a different restore or operator intervention, and unresolved recovery remains behind the maintenance curtain. It would be irresponsible to describe this as a promise that every failed deployment repairs itself.
The same review caught a less dramatic but very real problem with the public demo. Some of its packaged reset and activation scripts imported helper files that weren’t included in the release artifact. They worked in the development tree, but not in the image people would actually run. The missing files are included now, and the release checks reject packaged imports that point to files the package doesn’t carry.
That is not a new demo feature. It’s the difference between having a reset procedure written down and having a reset procedure the shipped software can execute.
Backups & recovery
Backups are comforting right up until you need one. Raymond Tec helps small businesses build practical backup and recovery plans — including the decidedly unglamorous part where we make sure the thing can actually be restored.
Security improvements, with the footnotes left in
While the release path was being repaired, the runtime also moved to Node.js 24.21.0, added three pinned Debian security updates, and updated the compression and proxy-addr dependencies. A development-only source-map dependency was patched too. The final image runs without npm, npx, corepack, or yarn.
Some of those changes address identified vulnerabilities. They don’t prove the container is free of security risk, and a clean JavaScript dependency audit doesn’t say much about every library in an operating system image.
The published 0.33.33.51 qualification still reported Debian vulnerability findings without available published fixes. It also recorded the exact packages in the image and their provenance so the next review has something better than a vague claim that security was ‘handled.’ That evidence matters, but it’s not a substitute for updating the system when fixes become available.
There are also known limitations in the deployment procedure, including an operator-supervised private-preview upgrade. Those aren’t footnotes to hide after the announcement. They’re part of deciding whether a release belongs on somebody else’s server.
Technical discovery & auditing
The public page doesn’t tell you much about the machinery behind it. Raymond Tec audits inherited and long-running projects to uncover the plugins, integrations, data, dependencies, and old decisions that determine what the next change will really involve.
So, what will anybody actually notice?
If you’re looking for a new project screen, this isn’t that update. The October work was mainly about getting the work already built into a release that can be installed and maintained without taking chances with existing data.
There is one visible operating result: on October 14, the public demo host was upgraded under supervision to 0.33.33.51. Its existing data was preserved through the upgrade, and both an attended reset and the next scheduled reset ran on the new image. That is meaningful evidence for the demo. It isn’t evidence that every environment has been upgraded, and it isn’t a promise that resets can never fail.
For somebody self-hosting Longtail Forge, the benefit is less glamorous but probably more important. The deployment now checks the runtime it is about to use, refuses missing recovery prerequisites earlier, preserves the known-good application in specific pre-change failure cases, and checks that the image it publishes can actually be unpacked the way it expects.
A failure should be clear, contained, and recoverable wherever the evidence supports that. It shouldn’t force an administrator to improvise.
Where things stand now
Version 0.33.33.51 was published October 14 and the public demo upgrade is recorded as successful. The source material confirms an isolated compatibility probe on the private preview host, but not a completed replacement of that separate running preview, so I’m not claiming one. Preview invitations still require their own readiness decision.
The next planned product work, including the public-demo privacy and feedback follow-on and the larger Support Tickets module, hasn’t magically arrived because the release machinery was repaired. Longtail Forge is still a private technical preview. This period made the path toward the next update safer. It didn’t skip the steps in between.
If you want the version-by-version details, the Longtail Forge Changelog has them. The Roadmap shows what I’m working toward, and you can subscribe to future Longtail Forge updates without having to follow every release check along the way.
