LibreSign turns document signing into a Nextcloud workflow you control
Control how your documents get signed
At a glance
- What is it?
- LibreSign is a Nextcloud app that gives an organisation control over how documents get signed, with signing order, roles and rules per flow, internal and external signers in one request, reminders, validation of signed documents and certificate status, and a traceable record of every action. It is AGPL-3.0 software, and the repository is a full PHP and Vue application with an OpenAPI surface and its own build and test stack.
- Who is it for?
- Adopt LibreSign when signing is part of a controlled internal process, when the documents must stay inside your own Nextcloud, and when you want an auditable record rather than a vendor's dashboard. Do not adopt it if you need the throughput, the identity proofing or the legal framework of a commercial signing provider, because this is a self-hosted workflow tool and you run the instance.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A Nextcloud app, not a signing service
LibreSign's one line summary is control how your documents get signed, and the next paragraph sets the scope. It helps you control how document signing works across your organisation, organisations use it with Nextcloud to run signing workflows that match internal rules, legal requirements and daily processes, and it gives teams clear visibility into who signed, when they signed, and how each request moved through the process.
The Nextcloud dependency is the defining architectural fact. This is an app, with an appinfo directory and an .nextcloud-release.yml file in the repository, and the feature list says it works directly with Nextcloud files, users and sharing context. A document that lives in a shared folder is a document that can be sent for signature without being exported to another system and copied back.
That framing also explains the difference in approach against a commercial provider. A hosted signing product gives you a workflow you configure through their interface and stores your documents on their infrastructure. LibreSign gives you a workflow you configure in configuration files and store on your own Nextcloud, with the trade being that you operate, secure and update the instance yourself.
The licence is AGPL-3.0-or-later, stated in the SPDX headers at the top of the source files and as agpl in the package manifest, with a COPYING file and a LICENSES directory in the tree. The project is published by LibreCode coop and contributors, the site is libresign.coop, and the last push to the main branch was on 2026-10-20.
Rules, order, roles and the request record
The key features list is the product description, and it is specific enough to be useful.
You define signing order, roles and rules per document flow, and you can include internal and external signers in the same request. You request and track signatures from start to completion, and you send notifications and reminders to signers. You keep a traceable record of requests, actions and validations. You validate signed documents and certificate status. You work directly with Nextcloud files, users and sharing context, and you integrate signing with other systems through APIs.
The Why LibreSign section frames the audience: teams where signing is part of a controlled business process, who want to define clear signing rules by role, stage or document type, who need traceability for audits, legal checks and internal reviews, who want signing aligned with existing approval and governance processes, and who want to adapt workflows to how their organisation works instead of following fixed external models.
That last point is the real differentiator. A commercial product asks you to map your process onto its workflow. LibreSign is positioned as the thing you shape to match your process, which is also why the configuration surface is so central to the design.
The repository shows the implementation shape of that: lib for the PHP side of the app, src and templates for the Vue frontend, an l10n directory with Transifex configuration for translations, and a docs directory. The frontend dependencies in the package manifest are the Nextcloud Vue component set, alongside CodeMirror for the rich editing surfaces and the LibreSign pdf-elements package for the PDF parts of the interface.
Three OpenAPI documents describe the integration surface
Integrating with other systems is a stated feature, and the repository shows how much weight that carries. There are three OpenAPI documents at the top level: openapi.json, openapi-administration.json and openapi-full.json, plus a redocly.yaml configuration for handling them.
The split matters more than the file names suggest. A single API document for a project like this would be either enormous or deliberately vague, and three documents with distinct names suggest a deliberate separation between the public surface that a signing request or an integration needs, the administrative surface for managing the application's own configuration, and a complete document that covers everything for tooling that needs the full picture.
The package manifest shows the generation is part of the build. The typescript:generate script runs openapi-typescript with a -t flag, and the package includes an override that pins openapi-typescript to the project's own typescript version, so the generated types cannot drift from the compiler the rest of the frontend uses. The typecheck-staged variant in the tooling, and the ts:check script running vue-tsc with --noEmit, mean the generated types are checked against the code that uses them.
For an adopter building an integration, that gives you a concrete starting point: three documents to read, generated client types to consume, and a tool that regenerates them when the specification changes. The documentation repository at github.com/LibreSign/documentation and the developer manual at docs.libresign.coop/developer_manual are linked from the README as the places where this is written down in full.
Make, Composer, Vite, Vitest and Playwright
This is a full application repository rather than a library, and the tooling reflects that.
The Makefile states its own dependencies in a comment: make, npm, curl for fetching phpunit and composer when they are not installed, and tar for building the archive. It also says that Make is the discoverable project task interface, while the Composer and npm scripts remain the implementation source of truth for the PHP and the frontend tooling. The targets cover development setup, a reset that removes and reinstalls the development dependencies, building the frontend assets for development and for production, watching the assets while editing, and separate unit and integration test runs.
The version handling in the Makefile is a nice detail for a release-driven project. The release version is read out of appinfo/info.xml with sed, the major version is derived from it, and the changelog file for that major release is resolved from docs/changelogs. So the packaging step and the changelog are derived from the same source of truth rather than from a number typed in two places.
The frontend side is Vite for bundling, Vitest for unit tests, Playwright for end-to-end tests with its own report and UI modes, ESLint and Stylelint for the code, and vue-tsc for type checking. The script list also shows a watch mode that uses chokidar with polling enabled, which is the sort of detail that only appears in a project built on a slow network filesystem.
The PHP side has its own quality tools in the repository root, psalm.xml for static analysis, rector.php for automated refactoring, a .php-cs-fixer configuration, and infection.json5, which is the configuration for mutation testing, a technique where the test suite is checked by deliberately breaking the code to see whether the tests notice.
A manifest ahead of the latest release
The version numbers in this repository are worth reading carefully, because they do not line up.
The published releases are v15.0.7 on 2026-10-05 and v15.0.8 on 2026-10-07, plus a nightly build tagged Nightly 15.0.8 (stable35) from 2026-02-06. The package manifest, however, declares the version 16.0.0-dev.2, and the package is marked private with the description A app for signing documents.
So the main branch is a development line for the next major version, while the released artefacts are on the 15.x line, and the nightly tag is a moving target built from a stable branch. For anyone pinning a version, the tag to use is the release tag, not the manifest version, and the manifest version tells you which line the code you are reading belongs to.
This is a project with a serious release process rather than a hobby repository. The badges show it: a test workflow, a coverage status on Coveralls, a REUSE compliance status from the reuse.software service, which matches the LICENSES directory and the SPDX headers in the source, a good first issue label, and a Zenodo DOI badge describing the project as a Verified Digital Public Good.
The README also points at a roadmap project board for the current product direction, at the issue tracker for bugs and suggestions, and at Transifex for translations, and it asks organisations that depend on LibreSign to sponsor the project, saying that sponsorship directly supports ongoing maintenance, reliable releases, better documentation and long-term continuity.
What to weigh before you adopt it
The honest limits of the project are visible in the documentation rather than hidden.
The first is scope. LibreSign is a signing workflow inside a Nextcloud, not a complete identity and trust platform. The feature list mentions validating signed documents and certificate status, and the topic tags name CFSSL and the CFSSL API among the dependencies, so certificate handling is part of the design, but the project does not present itself as a qualified trust service provider, and a regulated workflow that depends on the issuing and validation of qualified certificates will need more than this app provides.
The second is the operational cost that follows from being a Nextcloud app. You are running Nextcloud, keeping the app up to date with the platform, managing the certificate files your signing flows depend on, and operating a mail path for the notifications and reminders the feature list promises. The sponsorship note in the README is a candid statement of that: ongoing maintenance and reliable releases are what sponsorship pays for.
The third is the licensing, and it deserves a sentence of care. AGPL-3.0-or-later applies to the app, and for a Nextcloud application distributed to organisations the network use of the licence is worth understanding before you modify and deploy it. The SPDX headers in the files, the COPYING file and the LICENSES directory are the places to read that, and the REUSE tooling shows the project keeps that metadata consistent.
The practical summary is this. If signing in your organisation is a workflow with rules, roles, reminders and an audit trail, and the documents should stay in your own file share, LibreSign is a strong fit. If signing is a customer-facing product with identity verification, qualified certificates and a support contract, this is the wrong tool, and the comparison is with a commercial provider rather than with another open source project.
Editorial conclusion
Adopt LibreSign when signing is part of a controlled internal process, when the documents must stay inside your own Nextcloud, and when you want an auditable record rather than a vendor's dashboard. Do not adopt it if you need the throughput, the identity proofing or the legal framework of a commercial signing provider, because this is a self-hosted workflow tool and you run the instance. Before you deploy, read the official documentation at docs.libresign.coop, pin the version you test, because the repository manifest sits on 16.0.0-dev.2 while the latest release is 15.0.8, and check whether the application keys you need, such as your certificate authority, are available in your environment.
Frequently asked questions
What is LibreSign?
It is a Nextcloud app that gives an organisation control over how documents get signed, with signing order, roles and rules per flow, internal and external signers in one request, notifications and reminders, validation of signed documents and certificate status, and a traceable record of requests, actions and validations.
How is LibreSign installed and built?
As a Nextcloud app, with the official documentation at docs.libresign.coop and a separate documentation repository and developer manual. For local work the Makefile is the discoverable interface, with targets for development setup, frontend builds and test runs, and it needs make, npm, curl and tar.
Can LibreSign be integrated with other systems?
Yes, integrating signing with other systems through APIs is a listed feature. The repository carries three OpenAPI documents, openapi.json, openapi-administration.json and openapi-full.json, with a redocly.yaml configuration, and the package manifest includes a script that generates TypeScript types from them.
Under what licence is LibreSign released?
AGPL-3.0-or-later, stated in the SPDX headers in the source files and as agpl in the package manifest. The tree carries a COPYING file and a LICENSES directory, and the project tracks REUSE compliance, so the licence metadata is kept in step with the code.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/libresign-libresign)Was this useful?