Ever Traduora: a self-hosted translation management platform for teams

The problem Ever Traduora addresses

Translation files start simple and then multiply. A project with one locale and one JSON file is fine until a second locale appears, then a third, and suddenly the strings live in five files across two repositories with no record of who changed what. Ever Traduora is built for that moment. It is a web application where a team keeps translation projects, imports existing files, edits strings in a browser, and exports the result back into the formats the application already consumes.

The intended user is a development team that wants translation state to live on infrastructure it controls. The README describes the project as an "Open Translation Management Platform" for teams, and the repository includes docker-compose files for SQLite, MySQL and PostgreSQL, which suggests the deployment target is a team's own server rather than a vendor's cloud. It is not a machine translation engine. The README says automatic translation through third-party integrations is planned ("soon"), so anyone expecting the platform itself to translate text will be disappointed by what exists today.

How the platform is put together

The repository is a monorepo. The top level holds an api directory, a webapp directory, and a docs-website directory, with lerna.json and package.workspaces.json tying them together. The root package.json exposes build scripts per package (build:api, build:webapp, build:docs) and start scripts (start:api, start:web). That layout tells you the runtime is two processes: a NestJS-style API and a separate front end, which the Dockerfile builds together into one image.

Persistence is configurable. The .env.sample lists TR_DB_TYPE with mysql, host, port, user, password and database keys, plus TR_DB_AUTOMIGRATE, which suggests schema migrations run at startup when enabled. The docker-compose.yaml default takes a different path: it sets TR_DB_TYPE to better-sqlite3 and TR_DB_SQLITE_PATH to api/data/tr_dev.sqlite3, mounting a host directory at /app/api/data so the database file survives container restarts. The compose file maps port 8080:8080, while the sample environment file uses TR_PORT=3000, so the port your API listens on depends on which configuration path you take.

Import behaviour has a documented bound: TR_IMPORT_MAX_NESTED_LEVELS defaults to 5. Deeply nested JSON or YAML beyond that depth is a real constraint worth testing before you migrate years of strings into the platform.

Installing Ever Traduora with Docker and seeding an admin

The README points to a Quickstart and to pre-built images on Docker Hub under everco/ever-traduora. The compose file in the repository is the shortest path to a running instance. It starts one service named traduora on port 8080, backed by SQLite inside the container, with the database directory bind-mounted to ./traduora_sqlite_data on the host.

docker compose -f docker-compose.yaml up

After the container starts, the web interface is reachable on http://localhost:8080. Because the compose file sets TR_DB_TYPE to better-sqlite3, no external database is needed for this first run. If you prefer MySQL or PostgreSQL, the repository also ships docker-compose.mysql.yaml and docker-compose.postgres.yaml.

When signups are disabled with TR_SIGNUPS_ENABLED=false, you need an admin account before you can log in. The README documents a seed script for exactly this case, runnable from the monorepo root or the API package directory.

yarn seed:default

The README states the default credentials are [email protected] with password sTr0ngP@ssw0rd!2025 and the name Admin, and that you can override them with TR_ADMIN_EMAIL, TR_ADMIN_PASSWORD and TR_ADMIN_NAME. Setting TR_SEED_DATA=true makes the seed run automatically at startup. The README also notes you can change the admin email, password and name from user settings after the first login, which is the step to take before exposing the instance to a network.

Format coverage and the limits you will hit

The README lists the import and export formats: JSON flat and nested, CSV, YAML flat and nested, Java Properties, XLIFF 1.2, Gettext (po), Strings, and Android Resources (xml). That is a broad set, and it is the strongest argument for the project. A team with a React front end, an iOS app and an Android app can plausibly keep all three in one place.

The limits are less advertised. Nested import depth is capped by TR_IMPORT_MAX_NESTED_LEVELS, defaulting to 5. Project count per user is capped by TR_MAX_PROJECTS_PER_USER, defaulting to 100. Throttling defaults are asymmetric: TR_THROTTLE_LIMIT is 0 (effectively off) while TR_AUTH_THROTTLE_LIMIT is 10 requests per TR_AUTH_THROTTLE_TTL of 60000 milliseconds, so login attempts are limited but general API traffic is not, unless you change it. The README does not document rollback or version history for translations, so if your workflow requires restoring a previous state of a string, check the API surface before depending on it.

The CLI is a genuine caveat. The README links to https://github.com/iilei/traduora-cli and explicitly labels it "not official CLI". Scripted workflows that depend on it are depending on a community project with its own release cadence.

Ever Traduora compared with Weblate and Tolgee

Weblate and Tolgee occupy the same problem space, and the difference is mostly in where the platform lives and how much it does on its own. Weblate is a long-standing translation platform with deep version control integration, which means it tends to treat your repository as the source of truth and sync against it. Ever Traduora's README describes import and export of files plus a REST API, which is a push-and-pull model rather than continuous repository synchronisation. If your team wants every string change to appear as a commit automatically, that distinction matters.

Tolgee appears in the search data alongside pricing and documentation queries, which suggests people compare the two on cost and hosted options. Ever Traduora's README does not describe a hosted tier; it describes Docker, Kubernetes or from-source installation, with deployment documentation on docs.traduora.co. The trade is straightforward: you avoid a vendor bill and keep the data, and in exchange you own the database, the backups and the upgrades.

One more difference is licensing. Ever Traduora is AGPL-3.0-only per package.json. If you modify it and offer it to users over a network, the AGPL's network clause is the part to read carefully. That is a factual property of the licence, not legal advice; consult a lawyer about your specific use.

Maintenance, upgrades and what the repository shows

The repository is not archived, and the last push was on 2026-09-01, which is recent enough that the codebase is receiving changes. The most recent release listed is v0.21.0 from 2025-06-22, followed by v0.20.4 and v0.20.3 in April 2025. Version numbers are still below 1.0, and the README itself flags automatic translation as a future feature, so treat the platform as maturing rather than finished.

Upgrade cost depends on your database choice. TR_DB_AUTOMIGRATE=true means schema migrations can run when the application starts, which is convenient in a container but means an upgrade and a migration happen in the same step. With SQLite that is a file you should copy first. The compose file mounts ./traduora_sqlite_data on the host, so a backup is a directory copy, which is simple but also easy to forget.

The licence is AGPL-3.0-only. The practical implication for most teams running an internal translation tool is minimal, since internal use does not trigger the network clause. The implication changes if you fork the platform and expose the modified version to external users. The README points to the LICENSE file for the full text.

Editorial conclusion

Adopt Ever Traduora if you want translation files kept on your own infrastructure and you can run a Node 20 and SQLite or MySQL service yourself. Do not adopt it if you need a hosted product with a support contract, or if you rely on automated machine translation, which the README describes as coming soon rather than shipped. Before committing, verify that the export format for your framework round-trips cleanly, and check how the default admin credentials interact with your own signup policy.

Frequently asked questions

Official sources

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