FileGator v8: A Fresh Start
Modern software is never really finished. Dependencies become outdated, frameworks evolve, new vulnerabilities are discovered, and security patches need to be applied. CVEs appear every day across the software ecosystem, and even a project that works perfectly today can become harder to maintain tomorrow.
For anyone maintaining a web application, this creates a constant balancing act: keep dependencies up to date, fix vulnerabilities, maintain compatibility, and still find time to improve the product itself.
The problem isn't that dependencies are inherently bad. They save time and provide useful, well-tested functionality. The problem is that every dependency adds another piece of software you need to understand, monitor, and maintain. Multiply that across a backend, a frontend framework, a build system, and hundreds of transitive packages, and keeping everything healthy can become a project of its own.
This is something I had been experiencing with FileGator.
Version 7 was built with PHP on the backend and Vue on the frontend. It worked, but the cost of keeping its dependencies and tooling current was growing. Some parts of the stack needed significant upgrades, and the frontend had reached a point where a clean upgrade would have required a major rewrite anyway.
I had two options: spend weeks upgrading the existing stack, only to end up with essentially the same architecture, or use the opportunity to build something simpler from the ground up.
With years of Go experience behind me and a new generation of LLM-powered coding tools available, I chose the second option.
The result is FileGator v8, a complete rewrite designed around one goal: less complexity, fewer dependencies, and a simpler deployment.
The problem with v7
FileGator v7 was built with PHP on the backend and Vue on the frontend. It was a reasonable setup, and it served the project well. But over time, both sides of the application accumulated maintenance work.
PHP: a small dependency tree, but still a dependency tree
The PHP backend had relatively few dependencies. The biggest one was Flysystem, which needed to be upgraded.
That alone wasn't a reason to rewrite the application. However, it was part of a larger picture: keeping the project current meant spending time on upgrades, compatibility, and changes that didn't necessarily make FileGator better for its users.
Frontend: the JavaScript maintenance treadmill
The frontend was a bigger problem.
The Vue-based application had accumulated outdated dependencies and tooling. Some components were overdue for updates, and upgrading everything cleanly would have required substantial changes. Parts of the dependency stack were difficult, if not practical, to upgrade without a major rewrite anyway.
The JavaScript ecosystem moves quickly. Frameworks, build tools, plugins, and their dependencies all need attention. Even when an application works perfectly well, its toolchain can become a project of its own.
I could have spent weeks upgrading PHP, followed by another week or more working through the frontend. And after all that effort, FileGator would still have essentially the same architecture.
I didn't want to spend that much time just getting back to where I already was.
LLMs changed the equation
A few years ago, rewriting a mature application from scratch would have been a much bigger undertaking. You have to reproduce existing behavior, account for edge cases, implement security controls, write tests, and make sure users can upgrade without losing their data.
Today, LLMs and AI coding agents make this kind of work much more manageable.
They don't eliminate the need for engineering decisions, testing, or code review. But they can significantly reduce the effort required to implement and validate a large amount of code.
For me, this changed the economics of the decision. I had the motivation to improve FileGator, and I had the time to do it. Rather than spending that time upgrading an architecture I no longer wanted, I could use it to build something simpler.
That made a complete rewrite worth considering.
Why Go?
I've been working with Go for the past few years, and it seemed like a natural fit for a self-hosted web file manager.
Go is well suited to applications that need to be distributed and run as standalone services. It provides a strong standard library, straightforward deployment, and a relatively small runtime footprint.
Most importantly for this project, I could build FileGator without relying on a large collection of third-party libraries.
My goal for v8 was simple: use as few dependencies as possible and keep the application easy to maintain for years to come.
The backend is now written in Go, with the standard library doing almost all the heavy lifting. That means fewer external packages to track, fewer compatibility issues, and fewer upgrades that can turn into projects of their own.
Why plain HTML, JavaScript, and CSS?
I also decided to remove the frontend framework.
Modern JavaScript has come a long way, and for FileGator's interface, I didn't think a framework and its associated build tooling were necessary.
Version 8 uses plain HTML, JavaScript, and CSS. There is no frontend build step, no Node.js toolchain required to build the application, and no frontend dependency tree to keep updated.
This isn't an argument that frontend frameworks are bad. They're useful for many applications. But FileGator is a self-hosted file manager, and I wanted its frontend to be as straightforward as possible.
Less tooling means fewer things that can break, fewer upgrades to manage, and less friction when contributing to the project.
The result: a much smaller, self-contained application
The difference is substantial.
The Docker image went from approximately 300MB to just 8MB. The new image is roughly 97% smaller!
Version 8 compiles into a single Go binary that includes the application and its frontend assets. There is no separate PHP runtime, Apache installation, Node.js environment, or frontend build pipeline to deploy.
You get one binary, one runtime, and one deployment target.
For self-hosted users, this means a much smaller image to download, less storage to use, and a simpler application to run and update.
For developers, it means less infrastructure and tooling to understand before they can work on the project.
Fewer dependencies, fewer things to maintain
The rewrite was not just about reducing image size. It was about reducing long-term maintenance.
With v8, the application is essentially dependency-free, with only a few exceptions. The Go standard library provides most of what the application needs.
That gives me fewer third-party packages to monitor, fewer dependency updates to worry about, and fewer opportunities for upstream changes to introduce problems.
The frontend has no external framework or build system to maintain, either.
Of course, having fewer dependencies doesn't automatically make software secure or bug-free. Security still requires careful implementation, testing, and ongoing maintenance. But a smaller and simpler codebase gives us fewer moving parts to manage.
What about existing FileGator installations?
A rewrite is only useful if existing users have a reasonable path forward.
I wanted to preserve the familiar parts of FileGator wherever possible. Version 8 retains the same users.json format and the familiar private/ and repository/ directory layout.
That means existing Docker volumes and user data can carry over from older installations.
Configuration is also simpler. Storage and authentication settings can be managed through the admin interface instead of requiring users to edit configuration files manually.
However, v8 is a major architectural change, so please follow the upgrade guide rather than assuming that replacing the application files is enough.
The upgrade documentation explains what carries over, what changes, and how to move from an existing installation safely.
The trade-off: no more PHP shared hosting
There is one important downside.
One of the advantages of the old PHP version was that you could upload a few files to a cheap shared hosting account and run FileGator without managing a server.
That is no longer the case.
FileGator v8 requires an environment where you can run a Go binary. This could be a small VPS, a Docker container, or a systemd service on a server you control.
For many self-hosted users, this is a worthwhile trade-off for the smaller footprint and simpler deployment. But if you depend on basic PHP shared hosting, v7 may remain the better fit for your environment.
How LLMs helped build v8
I want to be transparent about how this version was made: LLMs played a major role in the rewrite.
I used an AI coding agent to help implement the new application, working under the project's written development guidelines in AGENTS.md.
The goal wasn't to generate a large amount of code and hope for the best. The rewrite was guided by explicit requirements, and the test suite.
AI assistance made it practical to tackle a rewrite of this size, but it didn't remove the responsibility to make engineering decisions, review the implementation, and verify the result.
A fresh start for FileGator
FileGator v7 served us well, but I didn’t want to spend the next several years dealing with outdated dependencies and increasingly complex tooling.
With v8, I've taken the opportunity to simplify almost everything: the backend, the frontend, the deployment process, and the way the project can evolve over time.
The result is a much smaller application, a cleaner codebase, fewer dependencies, and a solid foundation for future development.
Ready to explore the new version?
Already using FileGator? Check the upgrade documentation before migrating to the new major version.