Veramo and the plugin framework for verifiable data in JavaScript

A framework whose core does almost nothing

Veramo is described as a JavaScript Framework for Verifiable Data, designed to be flexible and modular, which the documentation says makes it an easy fit for a lot of complex workflows.

The structure is the interesting part. Veramo is a core plus some plugins. The core provides an entry point into the API, glues the plugins together and allows them to interoperate. Everything an agent can actually do comes from a plugin.

The list of roles an agent can perform, depending on which plugins are in use, covers the full arc of the verifiable data stack. Create and manage keys for signing and encryption. Create and manage Decentralized Identifiers. Issue Verifiable Credentials and Presentations, verify such credentials and presentations, present credentials using Selective Disclosure, communicate with other agents using DIDComm or other protocols, receive, filter, store and serve data, and control other agents remotely or act as a proxy for them.

The last item on that list has a deliberate ellipsis at the end, and it matters. The point of a plugin architecture for verifiable data is that the credential formats, the key management approaches and the transports are all things that change, and a framework that lets you substitute them is buying a specific kind of future-proofing.

The audience is a developer building something in the decentralized identity space, at a point where they need to hold keys, mint credentials and talk to other agents, and who does not want to pick one vendor's stack. The primary language is TypeScript, the licence is Apache-2.0, the default branch is next, the homepage is veramo.io, and the last push was on 2026-10-20. The most recent releases listed are @veramo/[email protected], @veramo/[email protected] and @veramo/[email protected], all from 2026-09-23, which shows the per-package release model.

The topic list names the scope: did, key-management, ssi, veramo, verifiable-credentials, with openapi alongside, which points at the generated API documentation.

One API across Node, browsers and React Native

The portability claim is made in the opening paragraphs and it deserves to be taken at face value, because for a framework in this space it is unusual.

The guidance is to create an agent, add plugins, and run on a server or a frontend or mobile, or all of them combined. Veramo runs on Node, browsers and React Native straight out of the box, with the stated benefit of saving time by using the same API across all platforms.

That claim rests on the plugin boundary rather than on any special runtime support. A plugin that manages keys, for instance, has to work in three quite different environments. In Node it can reach the filesystem, in a browser it is limited to the Web Crypto API, and in React Native it is limited to whatever native crypto the platform exposes. The framework cannot paper over that, so what it actually provides is a consistent shape for the plugin and a consistent way to construct the agent, with the platform-specific part living inside each plugin.

That is the honest characterisation, and it is also why the plugin template exists. When you write a plugin you inherit a set of conventions for configuration, for events, for how the plugin declares its own API surface, and for how it plugs into the agent, and those conventions are what make the same code work in a server and in a browser.

The alternative approach is to write the integration twice, or to target only one platform and accept that the other needs a different library. A framework that makes the shape uniform is buying you the ability to change your mind about deployment, and the cost is that you now depend on the framework's conventions rather than only on the underlying standards.

The documentation reflects that structure, with separate tutorial paths for Node, React and React Native, each of which shows the setup for identifiers and the resolver.

Building the monorepo, and the plugin development loop

The repository is a pnpm monorepo, and the build and test commands are the whole local workflow.

It uses pnpm@12 with changesets for versioning and release. The three commands you need are:

pnpm install

pnpm build

pnpm test

with a watch variant for tests as well.

The build script is a three-stage pipeline. It runs build:js, which builds each workspace package in turn with the stream flag so output is interleaved, then build:api, which runs an extract-api task per package, then build:schema, which runs a generate-plugin-schema task per package. That middle stage is the one that matters conceptually, because api-extractor is what produces the public API report for each package, and generating a schema from the plugin surface is what lets the framework describe plugins to tooling.

The package.json also shows a test layout that distinguishes unit tests from integration tests. The default test script is vitest run, and there is a separate test:ci that adds coverage. Integration tests are a separate chain: test:integration-build prepares the integration tests with a tsx script, pretty-prints the documentation examples file, and then runs the CI test command. The browser test is its own command that changes into packages/test-react-app and runs its own browser test, which is how the browser platform claim is actually checked.

There is a veramo CLI entry point as well, a cross-env invocation of the package's bin/veramo.js, which is what the CLI guide in the documentation refers to.

The repository layout is consistent with that: packages/ for the workspace, __tests__/ for the shared integration suite, scripts/ for the release and docs tooling, .changeset/ for the versioning metadata, and a vitest.config.mjs at the root. There is also a .prettierrc, a renovate.json for dependency updates, a commitlint.config.js for commit message linting, and a docsconfig.json.

Writing a plugin, and how the pieces find each other

The plugin model is the part of Veramo that determines whether it is pleasant to work with, and the documentation treats plugin authoring as a first-class path rather than an afterthought.

There is a plugin template repository, and it is preconfigured with GitHub Actions for checks and automatic updates using renovate-bot, so that a plugin can stay in step with the latest versions of Veramo and be notified if upcoming API changes break anything. The documentation is careful about the limits of that automation, since it depends on the tests you write for your own plugin. Depending on what you intend to develop, some code from the template can be safely removed, and the embedded comments should guide you, with a pointer to reach out if something does not make sense.

The phrase that the plugin can be notified if upcoming API changes break anything deserves a second look, because it implies a stable published API surface with change detection, and that is what api-extractor gives you. The API report per package is what allows the framework to say that a change is breaking, rather than discovering it in someone else's build.

The mechanism the plugins use to find each other is described in the documentation as the Event System, which has its own advanced guide. The core glues the plugins together and allows them to interoperate, and the event system is how that is expressed: plugins publish and subscribe rather than calling each other directly, which is what lets the set of plugins change without rewriting the glue.

The repository contains the Veramo core package, which the documentation says only becomes relevant when you add plugins to it. The maintainers also keep some core plugins in the monorepo to provide functionality out of the box, while making clear that a lot more can be done than is present in the codebase. The integration test suite in __tests__/shared is where the examples and code samples live, and the documentation points there for working code rather than describing the API in prose.

Where Veramo is the wrong choice

Three limits follow from the design, and they are all consequences of the same decision.

The first is that you inherit a framework to get one capability. If your requirement is to verify a JWT signature, or to mint a single credential format, or to store a DIDs document, then a focused library does that with far less surface. Veramo's value appears when you need several of these capabilities together and want them to interoperate, and it is close to zero for a single one. The plugin dependency graph is a real cost when the graph has one node.

The second is that the plugin ecosystem is a dependency you do not control. The documentation says plugins can be developed by anyone and that Veramo provides the glue that can make them interoperate, and it invites contributions of feedback and fixes. That openness is the point of the project, but it means your security posture depends on third-party packages that the framework does not review for you. Verifiable data is exactly the domain where an unreviewed key management plugin is a serious dependency, and the plugin list you assemble is effectively your own trust boundary.

The third is the version churn implied by the setup. Renovate is configured to keep plugins in step with the latest versions of Veramo, and the package releases here are at 7.0.2 with the default branch named next. A framework whose versioning follows the mainline development branch of the standards it implements will move, and moving a framework means moving every plugin in the graph.

The alternative worth comparing against is implementing the pieces directly against the underlying specifications, or using a single-purpose library per capability with your own integration layer. The difference in approach is that Veramo gives you a uniform agent model and a documented plugin contract, and the direct route gives you no framework at all but full control over what is in the dependency tree. For a team already committed to the SSI ecosystem, the plugin contract is worth a great deal. For a team that needs one credential type and no federation, it is overhead with a documentation site attached.

Editorial conclusion

Veramo is a good fit for a team that needs to issue or verify Verifiable Credentials and wants one API across a Node backend, a browser front end and a mobile app, because the plugin architecture is what makes the same code path work in all three, and the framework already covers keys, DIDs, credentials, selective disclosure and DIDComm. It is a poor fit if you only need one of those things, since a single-purpose library would be smaller and easier to reason about, and a poor fit if you cannot commit to the plugin dependency model, because the core deliberately does nothing without plugins attached. Before adopting, read the plugin list and the API extractor configuration, since the core package is only relevant once you have plugins, and note the default branch is next with a 7.0.2 package release in September 2026.

Frequently asked questions

Official sources

1. decentralized-identity/veramo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases