Release Architecture: Legacy

Before Wombat, before the unified DocsHub architecture, and before thousands of people were visiting the documentation, DocsHub was a much simpler project.

It was originally built for one purpose:

to provide a simple, offline, self-hosted portal for documents.

There was no elaborate design.

There was no central ecosystem.

There was barely a reason to call it a platform.

It was simply useful.

This page documents how that small system gradually became the documentation platform that eventually required Wombat.

The Beginning — A Local Document Portal

The original DocsHub was designed to run locally on my own infrastructure.

The priority was functionality rather than presentation.

Documents needed to be available in one place, accessible without relying on an external service, and easy to maintain.

The interface was intentionally minimal.

There were no ambitions of building a public documentation platform at this stage.

It was simply a tool for managing and accessing documents.

Making It Shareable

Eventually, documentation needed to be shared outside of the local network.

That changed the requirements.

A system designed for one person using a local document portal suddenly needed to be understandable and usable by other people.

The interface gained some basic styling and navigation.

A simple indexing system was introduced to make documents easier to find.

It was still very basic, but DocsHub had begun moving away from being a purely local utility.

The SnapDock Effect

The next major change came with the development of SnapDock.

SnapDock needed public documentation.

Once documentation for a real public project had to be maintained, the limitations of the original DocsHub architecture became much more obvious.

The solution was to turn DocsHub into a centralised documentation portal.

Instead of creating isolated documentation sites for individual projects, DocsHub could provide a common place for projects to publish their documentation.

This was the beginning of the modern DocsHub ecosystem.

Growth Creates a New Problem

Centralising documentation solved one problem and created another.

As the number of projects and documents increased, the systems that had been perfectly adequate at a smaller scale became increasingly difficult to maintain.

The index was largely manual.

Search relied on relatively fragile logic and manually maintained data.

Adding or changing documentation could require updates in multiple places.

Eventually, maintaining the documentation infrastructure itself was becoming a significant task.

The system was still working.

But it was beginning to require more effort to maintain than the documentation it was supposed to support.

That was the point where a larger architectural change became necessary.

From Local Hosting to Public Infrastructure

Originally, DocsHub was hosted directly on my own infrastructure.

The system ran locally on my node, with Cloudflare providing the public-facing connection.

This worked well while traffic remained relatively small.

Then people started using it.

As traffic grew into the thousands, the limitations of the local server became increasingly obvious.

The hardware could serve the documentation, but it was never designed to become a public documentation platform receiving significant external traffic.

The problem was no longer the software alone.

Infrastructure had become part of the problem.

GitHub + Cloudflare

The practical solution was to move the public hosting workload away from the local server.

DocsHub was moved toward a static deployment model using GitHub for hosting/build infrastructure and Cloudflare Workers for the public delivery layer.

This provided several important advantages:

• extremely low hosting costs
• reliable public availability
• global delivery
• automatic deployment
• reduced dependence on local hardware
• a practical way to handle increasing traffic

Most importantly, it allowed DocsHub to continue growing without requiring expensive infrastructure.

For a hobby project, this was an excellent solution.

The Next Infrastructure Problem

The irony of successful growth is that eventually even free infrastructure has limits.

DocsHub continues to grow, and traffic is now high enough that the limits of the current GitHub and Cloudflare-based architecture need to be considered seriously.

This does not mean the current infrastructure has failed.

It means DocsHub has reached the point where infrastructure needs to be designed around the platform rather than simply adapted to it.

Research is therefore underway into suitable cloud VM infrastructure for the next stage of hosting.

The goal is to find an environment that provides enough capacity for continued growth without introducing unnecessary infrastructure costs.

Why Not Host It Locally Again?

Ideally, I would like DocsHub to return to locally controlled infrastructure.

That is still the long-term preference.

The problem is geography.

I live in rural Queensland, Australia, where my current internet connection is effectively a can on a string compared with what a public service needs.

The hardware is not necessarily the limiting factor.

The network is.

Until that changes, public-facing infrastructure needs to live somewhere with reliable connectivity.

Why This Leads to a Commercial Model

This history is one of the reasons the ZFordDev ecosystem is gradually moving away from being purely hobby-funded.

There are more ideas, projects, and infrastructure requirements than I can reasonably fund from a personal hobby budget.

The limiting factor increasingly isn’t whether something can be built.

It is whether there is enough time, infrastructure, hardware, and money to build it properly.

The goal of the commercial model is therefore not to lock away the software that already exists.

It is to remove the financial barrier that prevents the ecosystem from growing.

The direction is intentionally simple:

Keep the core software accessible.

Let people self-host when they want to.

Provide hosted services for people who would rather pay for the convenience.

Revenue from those services can then go back into infrastructure, development, hardware, and the continued development of the ecosystem.

From Hobby Project to Platform

DocsHub did not begin with a grand architecture.

It evolved because each stage created a new requirement.

A local document portal became a shareable site.

The shareable site became a project documentation system.

The project documentation system became a centralised portal.

The centralised portal became infrastructure serving thousands of visitors.

And that infrastructure eventually became large enough that the original architecture could no longer comfortably support it.

That progression is what ultimately led to Wombat.

Wombat is not a rejection of the original DocsHub.

It is the result of everything the original DocsHub taught us.

Legacy in Perspective

The original DocsHub was never designed to become what it eventually became.

That is precisely why its history matters.

Every limitation of the old system helped identify something the next generation needed to solve.

Legacy was built to be useful.

Wombat was built to make that usefulness scalable.

Capybara will build on that foundation for the public platform.

Status

Generation: Legacy Role: Historical architecture Origin: Local self-hosted document portal Public hosting: GitHub + Cloudflare Successor: Wombat Historical status: Retired / preserved for reference