metasfresh: a Java and PostgreSQL ERP you can self-host

What metasfresh is for, and who it fits

metasfresh is an ERP system aimed at companies in industry and trade. The README states the goal plainly: fast and easy-to-use enterprise software, with scalability and flexibility named as the reasons a company would pick it over generic business software. The functional surface visible in the repository and the README is the classic order-to-cash chain: sales orders, shipments, invoices, material receipts, plus accounting and CRM topics listed on the repository.

The audience is narrower than the tagline suggests. This is not a tool you adopt in an afternoon. It is a full ERP with a three-tier architecture, a web front end, a REST API and a PostgreSQL database underneath. The people who benefit are operations teams at small and mid-sized trading or manufacturing companies that want to own their data and their deployment, and that have at least one person comfortable with Linux, Docker and database backups. If nobody on staff can read a Docker guide or run an installer, the project's own documentation will not carry you.

One detail in the README is easy to miss and matters for planning: metasfresh publishes a stable release every Friday, with one skipped week at the end of the year. That is a much faster cadence than the numbered releases in the repository suggest, and it means the version you install from the download page is not the same thing as the tagged releases you see listed.

Architecture: Spring Boot services behind a React front end

The README describes a 3-tier architecture with a REST API and a web front end written in HTML5, ReactJS and Redux. The repository layout backs that up. There is a backend/ directory and a frontend/ directory at the top level, alongside distribution/, docker-builds/, e2e/, docs/ and misc/. The primary language is Java, with PostgreSQL, Spring Boot, React and JavaScript among the repository topics.

That split has practical consequences. The backend and the front end are separate artifacts that get built and shipped together, which is why the project calls itself a monorepo and points contributors at git sparse-checkout rather than a plain clone. The README gives the reason indirectly: checking out only the part you need is the recommended workflow. If you plan to modify the web UI, you work in frontend/; if you plan to touch business logic or the REST layer, you work in backend/. Pulling the whole tree when you only need one side is wasted disk and wasted build time.

The data layer is PostgreSQL, which is the piece you will actually operate. Every upgrade, every backup and every restore touches that database, not the Java services. Treat the database as the system of record and the containers as replaceable.

Installing metasfresh with Docker or the Ubuntu package

The README offers two supported paths: Docker and an Ubuntu installer. It does not put the commands inline. It links to a documentation page titled "How do I setup the metasfresh stack using Docker?" and another for the installation package, and it points at the download page for the latest server update. Because the README does not reproduce the compose file or the installer command, the honest starting point is to fetch those pages rather than guess at flags.

The download page is where the project says to get the release. The README describes it as a stable release published every Friday.

Once the stack is running, the README's first-steps list is the shortest path to a working system. It links, in order, to logging on, changing the interface language, running the initial setup wizard, creating a sales order, creating a shipment and creating an invoice. That sequence is deliberate: the setup wizard configures your company before any transactional document makes sense.

For contributors rather than operators, the README recommends git 2.25.0 or later and the git-sparse-checkout feature. The example it gives starts with:

git sparse-checkout init --clone

The README states that this leaves you with just the files in the repository root, such as the README itself. From there you can narrow or widen what is checked out:

git sparse-checkout set frontend

That command checks out the frontend code. To return to a full working tree, the README gives:

git sparse-checkout disable

A monorepo of this size is the case sparse-checkout was built for, and the project is right to push it. A plain clone of an ERP with a Java backend, a React front end and end-to-end tests is a lot of history for someone who only wants to read the API layer.

Release cadence versus tagged versions

This is the part of metasfresh that deserves the most scrutiny before adoption. The README says a stable release is published every Friday. The repository's listed releases tell a different story: 5.175 in June 2023, 5.174 in March 2022, 5.173 in November 2021. The gaps between tagged releases run to more than a year, while the README promises weekly drops through the download page.

The two are not necessarily contradictory. A project can publish frequent builds to a download page while tagging repository releases rarely. But the discrepancy is real and it affects you directly: the version you install from the download page, the version referenced by the release badge in the README, and the latest tag in the repository may all be different numbers. Before you deploy, decide which of those is your source of truth and record it. If you later need to reproduce a problem or roll back, an unrecorded version is the first thing that blocks you.

The repository does carry a ReleaseNotes.md file at the top level, and the README points readers there for improvements and bug fixes. That file is the place to check what changed between the version you run and the version you are considering. The README does not document a rollback procedure, so plan your own before an upgrade rather than after.

Where metasfresh is the wrong choice

The clearest limitation is operational. metasfresh is self-hosted software with a PostgreSQL dependency and two installation paths that both assume a real server. There is no indication in the README of a managed cloud offering, a support contract or a hosted trial. If your organisation wants to buy ERP as a service and never see a container, this is not that product.

The second limitation is the upgrade burden. A weekly release cadence is a benefit only if you have a process to consume it. Teams that deploy once and revisit the stack a year later will find themselves several versions behind with no documented rollback path in the README. That is not a defect in the software, but it is a real cost that the marketing line about being fast and flexible does not mention.

The third is scope. metasfresh covers accounting, CRM, manufacturing and management topics, which sounds broad until you need something outside the order-to-cash and inventory flow. The README describes the system at a high level and links to documentation for the rest. Anyone evaluating it against a specific industry requirement should read the documentation collections for admins and users before assuming a feature exists.

Finally, the licence is worth confirming rather than assuming. The README carries a GPL badge linking to a LICENSE.md file, while the repository metadata does not state a licence at all. If your plan involves embedding metasfresh in a product you distribute, read the actual licence file and get your own advice.

metasfresh compared with ERPNext and Tryton

The most common comparison for metasfresh is ERPNext, which is also a full open source ERP with accounting, inventory and manufacturing. The difference in approach is the stack and the deployment model. ERPNext is built on Python and a MariaDB or PostgreSQL backend, with a Frappe framework underneath, and it is widely deployed through a container-based bench tool. metasfresh is Java and Spring Boot on PostgreSQL, with a React and Redux front end and a REST API. If your team already runs JVM services and PostgreSQL, metasfresh fits the operational shape you have. If your team writes Python, ERPNext asks less of you.

The second comparison people reach for is Tryton, which takes a different architectural line again: a smaller core with business modules layered on top, rather than a monorepo shipping a backend and a web front end together. Tryton's model rewards teams that want to assemble only the modules they need. metasfresh's model rewards teams that want a single integrated system with a documented web UI and a defined first-steps path.

Neither comparison is settled by a feature list. The practical question is which stack your operators can run at 2am when the database is unhappy. metasfresh's answer is a PostgreSQL instance you control and a set of Java services you restart. That is a fine answer, and it is not the same answer ERPNext or Tryton gives.

Editorial conclusion

Adopt metasfresh if you need a self-hosted ERP covering sales orders, shipments and invoices, and you have people who can run a Docker or Ubuntu stack on PostgreSQL. Do not adopt it if you need a hosted service with a published support contract, or if you cannot absorb a version upgrade yourself. Before committing, verify three things: which release tag you are actually deploying, whether the Docker setup guide matches your host, and how far the ReleaseNotes.md file for your target version differs from the one you run today.

Frequently asked questions

Official sources

1. Issues
2. metasfresh/metasfresh on GitHub
3. Project website
4. README
5. Releases