Longtail Forge Update · August 8–21, 2026

If you were hoping this Longtail Forge update would be packed with screenshots of twelve shiny new buttons, I have some bad news.

A lot of the work over the last two weeks happened behind the buttons.

That is not quite as much fun to show off, but it matters. Longtail Forge is getting close enough to the point where other people will be using it that “works on my machine” is no longer a useful standard. I need updates to be predictable. I need recovery to be real. I need the different parts of the application to agree on how they talk to each other. And I need the test process to catch mistakes before somebody else gets the privilege.

So this round of Longtail Forge development has mostly been about making the software safer to change without turning every change into an event.

What changed in this Longtail Forge update

• The private preview now has a much more deliberate deployment and rollback process.
• Backups and recovery are being tested instead of merely assumed.
• The different parts of Longtail Forge are getting clearer rules for the information they exchange.
• A large TypeScript cleanup is helping catch bad assumptions while I am still working on them.
• The automated checks are getting faster at finding obvious problems while still running the deeper tests when shared parts of the application change.
• The friends-and-family preview is deployed, but I am still intentionally holding invitations until the remaining readiness checks are complete.

Making updates less exciting is the goal

There is a big difference between getting software onto a server and being comfortable letting another human being depend on it.

The first one is mostly deployment. The second one is deployment, recovery, permissions, testing, backups, and having some idea what you are going to do when the happy path decides not to be happy.

The private preview now has a more controlled update process. Releases can be packaged into known versions, checked to make sure the package arrived intact, backed up before an update starts, placed into maintenance mode during the risky part, and rolled back when necessary.

None of that is supposed to be impressive to the person using Longtail Forge. Ideally, you never think about it.

It is a little like the brakes on your car. Nobody gets out at the grocery store and congratulates the brakes for another successful trip. You notice them when they do not work.

That is the standard I want for updates: boring when they work, recoverable when they do not.

Backups are not useful until you can actually restore them

I have done enough server and website work to be suspicious of the phrase, “Don’t worry, we have backups.”

Great. Have you restored one?

A backup you have never tested is basically a wish with a filename.

The private-preview work now includes more deliberate recovery testing so the first time I need to think through a restore is not while something important is already broken. That matters for the hosted version because I will be responsible for keeping it running, but it matters just as much for self-hosted Longtail Forge.

If somebody installs Longtail Forge on their own server, they should not need a heroic recovery story six months later just because an update went sideways.

---

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.

---

The different parts of Longtail Forge are getting clearer rules

Longtail Forge started as a time tracker. It is very much not just a time tracker anymore.

There are projects, tasks, notes, lists, files, search, reporting, permissions, APIs, Help, the Workbench, and more modules coming behind them. As that grows, it becomes increasingly important that those parts use the same rules instead of each one inventing its own little way of doing things.

Recent framework work has been tightening those rules: how modules register themselves, how they add screens and settings, what permissions they need, how they expose information to other parts of the application, and how they plug into shared things like search and files.

Why should anybody who is not writing the code care?

Because future pieces like Support Tickets, the Knowledge Base, a fuller Calendar, and Creator Studio should feel like parts of one application. They should not feel like four unrelated tools that happen to share a logo and a login page.

That also makes the application easier to change later. The fewer one-off exceptions I build today, the fewer mysterious little landmines I have to remember next year.

TypeScript is catching bad assumptions earlier

There has also been a lot of TypeScript cleanup during this stretch.

If you do not know what TypeScript is, that is fine. The useful explanation is that it checks whether different parts of the program agree about the kind of information they are handing each other.

If one part of the application says, “I am sending you a number,” and another part quietly assumes it is receiving text, TypeScript is there to complain before that disagreement turns into something a user discovers.

One recent cleanup closed 170 of those complaints across a large section of the framework. The number itself is not terribly important. What matters is that the fixes were checked to make sure the application still behaved the same way afterward.

The goal is not to make the compiler stop complaining. I can make lots of problems disappear by simply refusing to look at them. The goal is to make assumptions explicit enough that a mistake is more likely to be found while I am still working on it.

The test process is getting faster without getting shallower

Longtail Forge has accumulated a pretty substantial set of automated checks. That is good. Running every slow test after every tiny change is less good.

The verification process is now better at doing the quick, useful checks first. If a small change breaks TypeScript or a fast unit test, I can find that out immediately instead of waiting for the entire regression suite to finish.

Smaller changes can run more focused checks around the things they actually touched. Changes to shared framework code, the database, the release process, or other high-impact areas still escalate to the broader test suite.

There are also separate checks around database changes, browser rendering, accessibility, version consistency, licensing, and other areas that are boring right up until they are the reason something breaks.

Automated testing does not make Longtail Forge bug-free. If anyone tells you their software cannot have bugs, keep your wallet where you can see it.

What the tests do is reduce the number of mistakes that survive long enough to become somebody else’s problem.

So, what will anybody actually notice?

Probably not a lot from this batch of work, at least not directly.

And I mean that as a good thing.

• Updates to the preview should be safer and easier to undo when something goes wrong.
• Future features should fit into the application more cleanly instead of adding piles of special cases.
• More bad assumptions should be caught during development instead of being discovered by a user.
• Faster feedback should make it easier to keep changes smaller, which usually makes them easier to understand and safer to ship.

This was not a fireworks update. It was the kind where the software gets a little less fragile and future changes get a little less scary.

Where things stand now

The limited friends-and-family preview is technically deployed on the Internet. I am still not sending invitations yet.

There are a few remaining readiness checks around account flows, security scanning, recovery, and the final “yes, I am actually comfortable letting people in here” review.

Could I open the doors sooner? Probably.

But I have spent enough of my career fixing systems that were launched on the technical definition of “works” to know that this is not the place I want to get impatient.

---

Want to go deeper? The Longtail Forge Changelog keeps the detailed release history, the Roadmap shows where the product is headed, and you can subscribe for Longtail Forge updates if you would rather have the next one come to you.