Ever Gauzy: an open ERP, CRM and HRM platform you can run yourself

What Ever Gauzy replaces, and for whom

Most small and mid-sized companies end up running four or five separate systems: an HR tool for employee records and time off, a CRM for leads and pipelines, a project tracker for tasks and timesheets, and an accounting or invoicing package. Ever Gauzy's pitch is that these are one product. The README lists Human Resources Management, Customer Relationship Management, Enterprise Resource Planning, Projects and Tasks, Sales Management, and Financial and Cost Management as the main feature areas, with a longer list underneath that includes timesheets, applicant tracking, proposals, estimates, billing, inventory, equipment sharing and multi-organization management.

The intended audience is stated fairly plainly: companies, on-demand businesses, freelance businesses, agencies, studios and in-house teams. The feature list supports that reading. Time tracking and activity monitoring sit next to employee onboarding and payroll-adjacent records, and the platform supports multiple organizations, departments and teams under one install. That combination is aimed at agencies and consultancies billing client work by the hour, not at a single-product startup that only needs a kanban board.

The cost of that breadth is real. A single-purpose tool does one job and does it well. Ever Gauzy asks you to accept a shared data model across HR, sales, projects and finance, which is convenient when you want one employee record to serve timesheets, payroll rates and project assignments, and awkward when your finance team already lives somewhere else.

The architecture: headless API, separate front end, desktop clients

The repository is a TypeScript monorepo managed with Nx and Lerna, and the top-level layout reflects a split between a backend API and one or more front ends. The package.json scripts start the API and the web client as two concurrent processes, and the README points to hosted API documentation at api.gauzy.co/docs, describing the platform as headless APIs.

The deployment shape follows from that. docker-compose.yml defines an api service built from the published image ghcr.io/ever-co/gauzy-api:latest, and it includes a second file, docker-compose.infra.yml, which is where the database and other infrastructure services live. The api service takes DB_HOST as db and reads API_HOST, API_PORT and NODE_ENV from the environment, with defaults of api, 3000 and production. The web client is served separately, and CLIENT_BASE_URL defaults to http://localhost:4200.

On the client side there are three distribution forms. Gauzy Server bundles the API, a SQLite database (or connects to an external PostgreSQL instance) and serves the front end, and the README calls it the recommended option for small to medium organizations. The Desktop App bundles front end, API and SQLite in one installer and can also point at an external database or an external API, which covers both local evaluation and a client-server setup. The Desktop Timer App is narrower: time and activity tracking with screenshots and activity monitoring. Because the API is headless, all three clients talk to the same endpoints, and the hosted demo at demo.gauzy.co runs the same code from the develop branch.

Installing Ever Gauzy with Docker Compose

The repository ships several Compose files: docker-compose.yml for the standard stack, docker-compose.infra.yml for infrastructure, docker-compose.demo.yml for the demo configuration, and docker-compose.build.yml for building images locally. The README also points to a downloads page for packaged installers, so Compose is one path among several rather than the only one.

Start by copying the sample environment file. The repository includes .env.sample at the top level along with .env.docker, .env.compose, .env.demo.compose and .env.local, which tells you the maintainers expect different environment files for different deployment modes.

cp .env.sample .env

Then bring up the stack. Because docker-compose.yml includes docker-compose.infra.yml, the database and supporting services start alongside the API without a second command.

docker compose up -d

When the containers are healthy, the API listens on port 3000 and the client on port 4200, matching the defaults in the Compose file. For a first look without any local setup, the README gives demo credentials for demo.gauzy.co: the super-admin login is [email protected] with the password admin. Treat those as demo-only; the README notes that the demo database resets on each deployment to the demo environment, usually daily.

The .env.sample file also documents GAUZY_APP_VERSION and GAUZY_APP_COMMIT, which the README says are normally injected at Docker build time and are shown in the web UI footer and returned by GET /api/version. Setting them by hand is useful if you build images yourself and want to know which commit is running. Note that the sample file leaves them empty for source runs.

Where Ever Gauzy is the wrong tool

The clearest limitation is stated by the project itself. The README describes the SaaS offering at app.gauzy.co as currently in Alpha version or testing mode and asks users to proceed cautiously. If your requirement is a hosted business management service with a support contract and an availability target, this is not that today. The self-hosted paths are the ones the README presents as recommended, and self-hosting means you own the database, the backups and the upgrade window.

A second constraint is operational weight. The Compose environment exposes a long list of optional integration variables, including Sentry, PostHog, OpenTelemetry, Jitsu, and a set of GitHub App and OAuth credentials. They are all optional, but the surface area tells you what a production deployment can grow into. Running this for five people on a laptop is easy; running it as the system of record for a company means thinking about Postgres, object storage for screenshots, and where the tracking data goes.

A third issue is documentation depth. The README links to docs.gauzy.co and marks it as work in progress, and points to the GitHub wiki for usage guidance. Neither the README nor the Compose file describes how to upgrade between releases or how to roll back a bad one. The release history shows frequent version bumps, including three releases within two days in late August 2026, so you will be upgrading often if you track releases. Decide your pinning strategy before you migrate real data, not after.

Finally, the platform is broad rather than deep in any single area. If you need an accounting system that satisfies a specific national tax regime, or an ATS with deep sourcing automation, a focused product will likely fit better than a module inside a larger suite.

How it compares with Odoo and with assembling separate tools

The obvious comparison is Odoo, which also bundles CRM, HR, projects, inventory and accounting under one roof. The difference in approach is licensing and packaging rather than features. Odoo's core is open source under LGPL, with a large set of modules sold under a proprietary licence and a hosted enterprise tier. Ever Gauzy is AGPL-3.0 across the repository, and the project's own commercial offering, the SaaS at app.gauzy.co, is described as Alpha. So with Odoo you are choosing between a mature paid edition and a community edition with a narrower module set; with Ever Gauzy you are choosing a single licence and self-hosting as the realistic default.

The second comparison is the opposite strategy: keep your existing tools and integrate them. A team already running a dedicated CRM plus a dedicated time tracker gets better depth in each and pays in duplicate employee records and reconciliation work. Ever Gauzy's value proposition is precisely the elimination of that reconciliation, since one employee record feeds timesheets, project assignment and HR data. If your current tools already share a clean identity model, the gain is smaller than the marketing implies.

The third comparison is Ever Teams, from the same organization. The README describes it as an open work and productivity platform built on React and React Native that connects to the Ever Gauzy headless APIs. That is not a competitor but a companion: if you want Gauzy's backend with a different front end, that is the route the project itself suggests.

Licence, upgrades and the cost of staying current

The repository is licensed AGPL-3.0, and the LICENSES.md file at the top level suggests third-party components carry their own terms that are worth reading separately. AGPL-3.0 is a strong copyleft licence with a network clause: if you modify the software and let users interact with it over a network, you are expected to offer them the corresponding source. That matters most if you plan to embed Gauzy in a product you sell. This is not legal advice, and the specific obligations depend on what you modify and how you distribute it, so the licence text and your own counsel are the sources to consult.

The practical upgrade cost is visible in the release cadence. Versions v111.39.5, v111.39.6 and v111.39.7 all landed between 2026-08-27 and 2026-08-28, and the last push to the repository was on 2026-08-28. That is a fast-moving develop branch. The README says pre-releases of desktop and server apps are built from the staging environment and can be pointed at https://apistage.gauzy.co through settings, which gives you a way to test a release before it reaches production. What the documentation does not provide is a migration guide or a rollback procedure, so pinning to a specific tag and keeping your own database backups is the only reliable safety net the project describes.

If you build from source rather than using the published images, note the memory settings in package.json. The build scripts pass NODE_OPTIONS=--max-old-space-size=12288 for standard builds and 30000 for the Docker variants. That is a large memory ceiling for a monorepo build, so size your build machine accordingly.

Editorial conclusion

Adopt Ever Gauzy if you want ERP, CRM, HRM and time tracking behind one login and you are willing to run the stack yourself, either from the published ghcr.io images or from the Server installer. Do not adopt it if you need a vendor-hosted service with a stability guarantee: the README describes the SaaS tier at app.gauzy.co as Alpha and says to use it cautiously. Before committing, verify two things. First, whether your intended deployment path works end to end, since the README documents Docker Compose, a Server installer and desktop apps but not the upgrade or rollback procedure for any of them. Second, how AGPL-3.0 applies to your product, because the network-copyleft clause reaches modified versions you expose over a network, and that is a question for your own counsel rather than for this article.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes