Ever Teams: an open work and project management platform still in progress

What the platform is, and the warning attached to it

Ever Teams is presented as Ever Teams Platform, the Workplace for Humans, an open work and productivity platform. In the README's own words it is an open work and project management platform, and the web application lives at app.ever.team.

The most important sentence in the document comes immediately after the screenshots: the platform is currently in an active development stage, work in progress, please use with caution. That is more honest than the marketing framing, and it is worth taking seriously rather than reading as boilerplate. The feature list is explicitly introduced as a list of the most important planned features, which is a second signal that some of it is not finished.

The scope is broad. The planned features cover work and workforce management, time management with time tracking and activity tracking, productivity tracking and metrics, projects with tasks and issues management, organizations and teams, tags and labels, integrations including GitHub, GitLab, Bitbucket and JIRA, and dark, black and light themes.

The topic list gives the positioning relative to incumbents, with issue-tracker, jira, jira-alternative, kanban, linear and time-tracking all present, and the screenshots cover four surfaces: the web platform, the mobile apps for iOS and Android, and a browser extension, the last of which is marked as currently work in progress with the screenshot being a temporary picture.

The primary language is TypeScript, the licence is AGPL-3.0, the default branch is develop, the homepage is ever.team, and the last push was on 2026-10-20. The recent releases are v0.142.36, v0.142.35 and v0.142.34, all on 2026-10-20, which tells you the release cadence is measured in several releases a day and the version number is a build counter rather than a stability statement.

The architecture: a platform on a platform

The structural decision is stated plainly in the Open Platforms section. Ever Teams is built on top of the company's Business Management Platform covering ERP, CRM and HRM, called Ever Gauzy, which itself is part of a larger open platform for on-demand and sharing economies.

The README is explicit about the consequence: Ever Teams actually utilize Ever Gauzy headless APIs, with a link to the Gauzy platform API documentation. So the work management product is not a self-contained application with its own data layer and its own user model. It is a client of a larger business management platform, and the shared pieces, people, organisations, time records, come from underneath.

That has a clear architectural benefit. A team that already runs the ERP or the HR system gets one source of truth for people and organisations rather than two. And it has a clear cost. The docker-compose file shows an api service running the Gauzy API image from ghcr.io, with the platform's own web client configured against it through a set of environment variables.

The compose excerpt shows the shape of a running instance:

include:
  - ./docker-compose.infra.yml

services:
  api:
    container_name: api
    image: ghcr.io/ever-co/gauzy-api:latest
    environment:
      API_HOST: ${API_HOST:-api}
      API_PORT: ${API_PORT:-3000}
      NODE_ENV: ${NODE_ENV:-development}
      DB_HOST: db
      API_BASE_URL: ${API_BASE_URL:-http://localhost:3000}
      CLIENT_BASE_URL: ${CLIENT_BASE_URL:-http://localhost:4200}

The api service listens on port 3000 by default, the client base URL is on 4200, and the compose file includes an infrastructure compose file. Alongside the base URL variables there is EMAIL_LINK_ALLOWED_ORIGINS, with a comment explaining that it lists the origins the API may put in sign-in, invite and verification email links besides the client base URL, because in this stack the Ever Teams web app is published on port 3030. There is a cloud provider variable, a set of Sentry variables for DSN, HTTP tracing, Postgres tracking, profiling and the OpenTelemetry exporter endpoints and headers, and a Jitsu server URL and write key for analytics.

So the observability story is built in rather than bolted on. An instance can be wired to Sentry, to an OpenTelemetry collector, and to an analytics endpoint through environment variables alone, with no code change and no agent to install.

Running it locally, and the difference between the demo and production compose files

There are two Docker Compose routes, and the difference between them is the practical decision you have to make when you try the platform.

The demo route runs a specific compose file for a basic configuration, for exploring functionality or a quick run, using the prebuilt Docker images, and you check the .env.demo.compose file for different settings. The production route runs plain docker-compose up with the .env.compose file, also using prebuilt images. In both cases the note says that Docker Compose will use the latest images, pre-built automatically from the head of the main branch using GitHub CI/CD.

That note is worth pausing on, because it defines the reproducibility of the whole exercise. The images you run are not pinned to a release. They are whatever the main branch produced at the time you pulled them, which is consistent with the README's own description of the project as actively changing several times a day. If you need a stable evaluation, you need to pin the images yourself, and the .env files are where the image tags live.

The prerequisites are modest. Clone the repository, have Docker Compose installed locally with a minimum of version 2.20, and pick the compose file that matches what you want to explore.

Beyond compose, the repository is a large monorepo with its own toolchain. The package.json scripts show the shape: a config script that runs a TypeScript configure script with an environment argument, separate Turbo build filters for services, types, constants, ui, hooks and utils, a start script that builds and then runs the web app concurrently, and dev scripts that build the dependency packages in order before starting the web app in development mode. The ng scripts set NODE_ENV and a maximum old space size of 8192 megabytes before running nx.

Those filters tell you the package layout, and it is the usual monorepo layering: services, types, constants, ui, hooks, utils, and a web application on top.

The stack, and what the choice of libraries implies

The technology section lists the frameworks used across the platform apps, and it is a mainstream modern stack rather than an unusual one.

Turborepo and TypeScript lead, with Nx and Lerna for workspace management, NodeJs, Next.js, React and React Native with Expo for the mobile client, and Tailwind for styling. The UI component libraries are shadcn/ui, Radix and HeadlessUI, with GitHub Actions for CI, Storybook described as a frontend workshop for building UI components and pages in isolation, and DigitalOcean and Vercel for hosting.

Two things in that list are worth a note. The first is that Storybook is present, which means the design system is expected to be worked on as components in isolation rather than only inside pages, and the project publishes a Storybook instance at storybook.ever.team along with visual builders at builders.ever.team. The second is the combination of three headless component libraries, which is more than most projects need, and is a hint that the platform has more than one surface, with the web, the mobile app and the extension each picking what fits.

The repository root confirms the scale and the tooling expectations. There are apps/, a .changeset/ directory for versioned changes, a .husky/ directory for git hooks, a .yarn/ directory and a .yarnrc indicating Yarn with a specific version, .nvmrc and .node-version, a .cspell.json for spell checking, an .eslintrc.json and a .prettierrc, a .stylelintrc.json for CSS, a .sentryclirc and a .snyk file for dependency scanning, a Layerfile set for deployment, a Procfile, an app.json for deployment platforms, a crowdin.yml for translation, and a .codemap/ directory.

The AI-assistant directories are also conspicuous: .agent/, .agents/, .augment/, .claude/, .codex/, .cursor/, .opencode/, together with AGENTS.md, CLAUDE.md and AUGMENT.md, and a ZENCODER.md. A project of this size that has been developed substantially with coding assistants leaves the configuration behind, which is a pattern worth noticing when reading a codebase like this one.

What a team should check before adopting it

There are three questions, and the first two are answered by the README and the third is not.

First, does the feature set you need actually exist yet? The features are presented as planned, the platform is labelled work in progress, and the browser extension is marked as such. If your requirement is time tracking or project and issue management, those are the parts most clearly described. If your requirement is deeper integration with a specific external service, the integrations list names GitHub, GitLab, Bitbucket and JIRA, and you would need to check the documentation for the depth of each.

Second, what does the AGPL-3.0 licence mean for you. For internal use at a company, an AGPL application used over a network carries obligations around offering the corresponding source to users who interact with it. This is a legal question rather than an engineering one, and the right step is to read the licence and the LICENSES.md file in the repository with whoever handles that in your organisation. The project does maintain a CREDITS.md with lists of libraries and software included in the platform and information about licences, which is a good sign about the level of licence hygiene, though it is not a substitute for advice.

Third, the thing the README does not answer is what it costs to run. There is no resource requirement, no sizing guidance, and no statement about the database or the queue. The compose file shows a Postgres-tracking Sentry variable, which hints at a relational store, and the base image is the Gauzy API image, so the data model lives in the platform underneath. For an evaluation, that means the realistic question is whether your organisation already has the Gauzy platform in the picture, because if you do, the headless API relationship is an advantage, and if you do not, you are adopting two projects rather than one.

The final practical point is the release cadence. Several tagged releases a day on a platform that is still in work in progress means the version number tells you little, so pinning the Docker images rather than tracking the head of main is the more useful discipline here.

Editorial conclusion

Adopt Ever Teams if your organisation already runs the Ever Gauzy platform or wants a work and project management product whose people, organisation and time data come from a shared source rather than from a second silo, and if you are prepared to evaluate a fast-moving codebase. Do not adopt it as a stable system today, because the README calls the platform work in progress and the release tags move several times a day, and do not adopt it without checking the AGPL-3.0 obligations with whoever handles licensing in your organisation. Before you commit, run the demo compose file to see the actual product, pin the Docker images rather than tracking the head of main, and read the CREDITS.md licence inventory to understand what the platform pulls in.

Frequently asked questions

Official sources

1. ever-co/ever-teams on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases