Impress is a Node.js application server that tells you where not to use it

The weak sides come first

The description is unusually honest about where the server does not fit. The weak sides are stated as: not a good choice for content publishing including blogs and online stores, server-side rendering, serving static content and stateless services. The strong sides follow: security and architecture for enterprise-level applications, long-lived connections over websocket to minimize overhead for the cryptographic handshake, and no third-party dependencies. That ordering is a decision, and it tells you the shape of the tool. A server built for stateful services, with a protocol-agnostic API, run-time type validation and real-time in-memory data processing, is not going to be a good static site generator host, and pretending otherwise would waste everybody's afternoon. The stack size claim is in the same spirit, since the total Metarhia technology stack size is less than 2mb, which is what you get when the dependencies are internal and trusted rather than third-party npm packages.

An endpoint is a file, and routing is automatic

The API model is the easiest part to understand. API auto-routing calls to the endpoint, for rapid API development, with no need to add routes manually. An endpoint is a file, and the example given is a path like application/api/example.1/citiesByCountry.js, where the .1 suffix names the API version. The file exports an async function that destructures its arguments and returns a result:

async ({ countryId }) => {
  const fields = ['cityId', 'name'];
  const where = { countryId };
  const data = await db.select('City', fields, where);
  return { result: 'success', data };
};

The client side then calls it through the metacom client, which gives a typed-looking call with the arguments as an object:

const res = await metacom.api.example.citiesByCountry({ countryId: 3 });

So adding an endpoint means adding a file, and the version number lives in the filename rather than in a router table. The documentation and specifications live in a separate Contracts repository, which is where the contract-based approach becomes concrete.

Application code runs in isolated contexts

The security model is built into the execution model rather than bolted on. Applied code needs to be simple and secure, so the approach is sandboxing with v8 isolated contexts, worker threads and JavaScript closures. That gives you two things at once. The v8 isolates mean an endpoint cannot reach into another endpoint's memory, so a bug in one API call does not become a data leak in another, and the worker threads mean CPU-bound work does not block the event loop, which is what makes the multithreading claim useful rather than decorative. The feature list adds code protection with reference pollution prevention and prototype pollution prevention, and code sandboxing for enhanced security and execution context isolation. For a server whose selling point includes security, running user or third-party logic in a separate isolate is a much stronger answer than a documentation warning.

Domain code is separated from system code

The architectural stance is stated as a set of principles rather than a diagram. Domain code should be separated from system code, so the project uses domain driven design, a layered onion architecture, dependency injection, and the SOLID and GRASP principles, with a contract-based approach. In the feature list the same idea appears as layered architecture with an api layer, a domain logic layer, a data access layer and a system code layer that is hidden. That hidden system layer is what the auto loader and the start hooks work against, so an application file never has to know about the server internals, and it is also what lets the same application code run under the same conventions in a different Metarhia deployment. The schemas directory at the top of the repository backs the contract side, providing schemas for the API contract, data structures validation and the domain models, which is what makes run-time type validation possible rather than aspirational.

State lives in memory and I/O is lazy

The performance argument is one line and it is the heart of the design. No I/O is faster even than async I/O, so the server holds state in memory, shares it among multiple threads and uses lazy I/O for persistent storage. That is a coherent position for a stateful server, where the hot path is a read of something you already have, and the disk is only touched when something must be persisted. The sharing among threads is not trivial in Node, which is why inter-process communication and shared memory are used for state management, and why the process and thread model is part of the product rather than an implementation detail. The database access layer is compatible with PostgreSQL with SQL-injection protection, and the persistent sessions with authentication, groups and anonymous sessions are also held in this layer. Caching for APIs and static files is in-memory, and the API concurrency features give request execution timeouts plus an execution queue with both timeout and size limitations.

The rest of the server surface

The remaining features are the ones you would expect from an application server and are worth skimming because they show the intended operating mode. The application server supports different API styles, RPC over AJAX and over Websocket, REST, and web hooks, and the protocols are HTTP, HTTPS, WS and WSS. The auto loader provides start hooks and generates namespaces for code and dependencies, live reload watches the filesystem and reloads code as it changes, and graceful shutdown runs stop hooks. Load balancing is simple, with redirection to multiple ports. Buffered logging is lazy write with rotation that keeps logs a number of days, plus a console interface. File utilities cover upload, download, partial content and streaming. Task management runs scheduled tasks at specific intervals or certain times. Testing is built in, with the integrated Node.js native test runner and table-test support. The package scripts reflect that, with the test script running lint, a type check and then the native test runner.

Requirements, dependencies and what is still on the list

The requirements are specific. Node.js v18.15 up to v24.x per the requirements list, though the package engines field requires Node 22 or newer. Linux, tested on Fedora v36-42, Ubuntu v20-25, CentOS v8-9 and RHEL v8-10. PostgreSQL v12-17 with v15 or newer recommended. OpenSSL v3.0 or newer for https and wss, and certbot is recommended but optional. The runtime dependencies are all internal to the Metarhia stack, metacom for the client, metaconfiguration, metalog for logging, metaschema, metautil, metavm and metawatch, which is what the no third-party packages claim means in practice. The TODO list is short and specific about what is not there yet, with server health monitoring, database migrations, a state synchronisation mechanism with transactions and subscription, and multi-tenancy support all listed for the nearest future, three to six months out. The release history is v3.1.2 and v3.1.1 on 2025-10-01 and v3.1.0 on 2025-09-20, the last push was on 2026-10-18, and the licence is MIT with the copyright held by the Metarhia contributors from 2012 to 2025.

Editorial conclusion

Impress fits a team building a stateful backend or a private cloud platform where the API contract, the domain model and the data access layer are all first class, since the auto-routing, the schema validation and the shared memory state are the whole point of the design. It does not fit a content site, a blog, a store or anything static, and the documentation says so plainly rather than leaving you to discover it. It does not fit a team that wants to reach for popular npm packages, because the runtime dependencies are internal and trusted only, and the total technology stack is under two megabytes. Before you adopt it, read the TODO list, since health monitoring, database migrations, transactional state synchronisation and multi-tenancy are all listed as future work, and check the Node version, since the engines field requires Node 22 or newer.

Frequently asked questions

Official sources

1. License: MIT
2. metarhia/impress on GitHub
3. Project website
4. README
5. Releases