jsreport, a reporting server where the report is a JavaScript template

A report is a template, and the engine decides the output format

jsreport is a reporting server letting developers define reports using JavaScript templating engines like handlebars. That single sentence contains the design. The report definition is a template, and the output format is a property of the engine that renders it, so the same definition can produce HTML, PDF, Excel, DOCX and other formats.

That is a meaningful difference from a reporting tool where a report is a visual object assembled in a designer and the export format is chosen at design time. Here the template is the source, the engine is the target, and the same data pipeline feeds both. The trade is that you get the flexibility of code and you give up the immediacy of a designer, although the project also ships a visual studio, so both routes exist.

The advanced features are listed in the same breath as the templating: user management, a REST API, scheduling, the designer, and sending emails. A reporting server that only rendered documents would be a document converter, and the scheduling and the user management are what turn it into an operational component that a business runs on a schedule.

The project describes itself as an open-source platform for designing and rendering various reports, and the official site is jsreport.net, with the documentation at jsreport.net/learn covering the concepts, the guides, the clients and the general documentation. The topics attached to the repository are excel, pdf and reporting, which tells you the output formats the maintainers care about most.

The repository is not archived, the last push was on 2026-10-09, and the release tags are 4.14.2 from 2026-09-11, 4.14.1 from 2026-08-05 and 4.14.0 from 2026-08-04, so the release line is active with fairly frequent patch versions.

Installing, and the two ways to get a server

The basic installation goes through the npm CLI, in four commands:

npm install -g @jsreport/jsreport-cli
jsreport init
jsreport configure
jsreport start

The three verbs separate the concerns that usually get tangled. init sets up a project directory, configure is the interactive step where you choose the extensions, the database and the storage you want, and start runs the server. That ordering is deliberate, because a jsreport installation is a configuration choice as much as a code choice, and a setup that is answered once interactively is easier to reproduce than one assembled by hand.

The alternatives are a compiled binary or the official Docker images, and the on-prem page at jsreport.net/on-prem covers both. The compiled binary matters for a specific reason. The repository root contains a file called detectInExeVfs.js, and the presence of that file next to an executable-license.txt tells you the distribution is built as a single executable with the JavaScript files embedded, and the detection script exists to unpack or locate them at runtime.

For a container deployment the Docker image is the usual choice, and the README header carries a Docker pulls badge pointing at the jsreport/jsreport repository on Docker Hub.

The distinction between the bundled distribution and the full set of extensions is the part to get right. The official distribution in npm, in Docker, or as a compiled binary includes the most commonly used extensions, but the list of available extensions is much longer, and you may want to install some of the missing ones as well. The packages/ directory in the repository holds the official extension packages, and the documentation lists them too. You are also not limited to the extensions the project provides, because you can implement your own, with a guide on implementing a custom extension linked from the README.

Embedding it in an existing Node application

The Node.js section covers the case where jsreport is one component inside an application you already have, and it splits into two routes with different costs.

The first is the official distribution. The documentation covers adapting the jsreport distribution using Node.js and integrating it into an existing Node.js application, and the point is that the official distribution wires the most popular extensions into the ready-to-use package, so you get a working server with a defined set of features and the job is configuration rather than construction.

The second is jsreport-core. If you are skilled, you are free to start from the ground using jsreport-core, which is the package at packages/jsreport-core in this repository. That is the assembly path, where you pick the extensions you need, wire the storage and the database yourself, and take on the responsibility for a configuration that the distribution would otherwise have made for you.

The practical difference shows up in the failure modes. The distribution path fails when an extension you need is missing, and the fix is to add it. The core path fails when you forgot to add an extension, wire a database or configure storage, and the fix is to read more of the core documentation. For a team that has a specific reporting requirement and already knows the shape of it, the core is often the better answer, and for a team that wants reports working this week, the distribution is.

The repository is a Yarn monorepo, and the packages/ directory is where the individual packages live, which is the same directory you read to find the extension list.

A monorepo with a build step, and the studio hot reload

The development section shows the monorepo setup, and the package.json at the root describes it precisely. The root package is named jsreport, is marked private, and its description is javascript based business reporting. The workspaces field points at packages/*, so every package under that directory is a workspace member.

The scripts are five. build runs node scripts/build.js, compile runs node scripts/compile.js, start runs node server.js, and test runs node scripts/test.js. There is also a performance script, node --expose-gc --max-old-space-size=100 tools/performance.js, which is a sensible way to run a memory benchmark in Node, since the garbage collector has to be exposed to be measurable and the heap is pinned so the numbers are comparable between runs.

The test setup uses mocha, and the standard configuration in the package.json sets the mocha, browser and node environments, and excludes the data directory and the exceljs package from the standard rules. That last exclusion is interesting, because it says the exceljs package does not follow the project's own style rules, which is a pragmatic choice for a vendored dependency but worth knowing if you are reading the codebase as a style reference.

The package manager is pinned exactly, with a yarn version and a hash in the packageManager field, which is how a monorepo avoids a transitive resolution difference between a developer machine and CI.

The studio is a separate thing from the server. The README notes that the studio extensions development with hot reload can be started with a specific environment setting, which is the workflow for anyone working on the designer itself:

set NODE_ENV=jsreport-development&&yarn start

And the tests for an individual package run with yarn workspace @jsreport/jsreport-scripts test, so the per-package loop does not require running the whole monorepo.

The licence has a condition in it

The licensing section is the part of this README that a technical reader should not skim, because the terms are not what the LGPL badge suggests.

The copyright is Jan Blaha, 2025. The README then asks whether you want to use jsreport for a personal purpose, in a school project or in a non-profit organization, and answers that you do not need the author's permission, just go on and use it. Crucially, that permission extends further than it might appear, since you can use jsreport without the author's permission also when having a maximum of 5 templates stored in jsreport storage.

So the boundary is a number of stored report templates rather than a category of user. For commercial projects using more than 5 stored report templates, the README points at the pricing page. Under any of the licences, free or not, you are allowed to download the source code and make your own edits.

In every case, there are no warranties of any kind provided, and the text spells out the usual disclaimer, that the software is provided as is without warranty of any kind, and that in no event are the authors or copyright holders liable for any claim, damages or other liability arising out of the use or other dealings in the software.

The licence identifier used for the project is LGPL-3.0. The practical reading is that the code is available under an open source licence and the hosted offering has a usage threshold, which is a dual arrangement rather than a contradiction.

The vulnerability policy is also stated, and it is pragmatic. They update vulnerable jsreport dependencies based on npm and Snyk audits during every release, and the instruction to wait until the next version rather than filing a ticket is because most audit findings are in code paths that are not used. The example given is a potential eventual denial of service through a dependency parsing some internal config, which in fact cannot happen. For a report with a direct, replicable impact on jsreport security, the README asks for an email to [email protected] and promises a fix as soon as possible. The snyk package is a direct dependency of the root package.json, which is how the audit runs in the pipeline.

Editorial conclusion

jsreport suits a team that needs a reporting layer and wants to define reports in code rather than in a drag and drop designer, since the report definition is a template and the output format is a property of the engine rather than of the tool. It is the wrong choice if you expect an open source licence to cover commercial deployment without conditions, because the README sets a specific limit for free use, with up to five stored report templates before the commercial pricing applies, and it is the wrong choice if you need the full feature set from a single package, since some extensions are not in the official distribution and have to be added. Before installing, read the licensing section rather than assuming LGPL-3.0 means unrestricted use, and check the packages/ directory for the extension you need rather than planning around the default bundle.

Frequently asked questions

Official sources

1. jsreport/jsreport on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases