Electronic Document Management System

An electronic document management system stores documents and adds the things a file share lacks: controlled versions, metadata you can search on, permissions that survive a file being moved, retention and disposal rules, and an audit trail. Whether you need one comes down to whether any of those five is currently causing a problem.

We sell source code you clone and run yourself, so there is nothing hosted here. Most organisations asking this question should extend what they already own before buying anything new.

What you already have, and what it is missing

The last row is why most of these projects fail. The software is rarely the obstacle; moving twenty years of documents into it with sensible metadata is, and the migration is usually attempted with the same people who have day jobs.

Retention is the requirement that actually justifies it

Version control and search are nice. Retention is the one that turns a document system from a preference into a requirement, because it is usually imposed rather than chosen.

Retention means a document is kept for a defined period and then disposed of, deliberately, with a record that it was. Organisations tend to discover they need this in one of two ways: a regulator asks how long records are kept, or a legal matter arrives and everything relevant has to be preserved and located. A shared drive answers the first badly and the second at enormous cost.

If neither applies to you, be honest about it, because retention is the feature that drags in the classification work that makes these projects long.

The metadata question decides everything else

Every capability above depends on documents carrying structured information beyond their filename: what kind of document this is, which client or matter or project it belongs to, when it was created, when it can be destroyed.

There are only two ways that metadata arrives, and both need deciding before the software is chosen. Either people enter it, which means it must be short enough that they will, or it is derived from context, which means documents are created inside a process that already knows the answers. The second is far more reliable and it is the argument for a document capability inside your existing business system rather than a separate document product.

Where the open source options fit

Several mature open source document systems exist, and they suit organisations with the internal capability to host and maintain them. The usual caution applies: self-hosting means owning upgrades, backups, and the search index, and the storage cost of documents plus their versions grows faster than people expect.

If the requirement is retention and audit for compliance reasons, check what evidence the system produces before choosing, because the report you can generate matters more than the features you can list.

When this becomes something you build

Not as a general document system. What gets built is document handling inside a product where the documents belong to a process: a claims system, a lending platform, a conveyancing tool, a compliance product where each client uploads evidence against a requirement.

In all of those the metadata problem solves itself, because the document arrives attached to a case that already knows the client, the type, and the date. That is a much better position than a general repository, and it is the reason these get built rather than bought.

What you would start from here

There is no document management in this stack. No file storage, no versioning, no metadata model, no retention rules, no full text search, and no audit of access.

What the Vault template provides is the application around it: organizations as the boundary documents belong to, roles and invitations, a Hono backend with Prisma and Kysely on Postgres, and an admin app. Because this is document handling, three specifics are worth stating. Files themselves belong in object storage rather than in the database, with the record in Postgres pointing at them. Access control has to be enforced when the file is served rather than only in the interface, or a shared link becomes a permanent hole. And if you need full text search over contents, Postgres can do a reasonable job before you reach for a separate search service.

You would write the document and version records, the metadata your process needs, the upload and serving path with its permission checks, and the retention rules if they apply.

If you need a general repository for the whole organisation, look at what your existing platform already offers first. The packs below are for documents inside a product.