Ever Traduora: a self-hosted translation management platform under AGPL-3.0
Ever® Traduora™ - Open Translation Management Platform - https://traduora.co
At a glance
- What is it?
- Traduora stores project translations in a database and serves them to teams through a web UI and a REST API, with import and export across JSON, CSV, YAML, XLIFF, PO, Strings and Android XML. The hard part is not the feature list, it is the AGPL-3.0 licence and the fact that the README documents a default admin password you must change.
- Who is it for?
- Adopt Traduora if you need translation strings held on your own infrastructure and your team is comfortable with a web UI plus REST API rather than a Git-based workflow. Do not adopt it if you cannot accept AGPL-3.0 obligations or if you need a hosted service with a support contract.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Traduora addresses: translation strings with no shared home
A project with more than one language accumulates strings in several places at once. Flat JSON in a web frontend, a PO file for a backend service, an Android resources XML for the mobile app. Every one of those files has to be edited, reviewed and released together, and the people doing the editing are usually not the people who wrote the code. Traduora's answer is to make the database the source of truth. Translations live in the platform, and files are an import and export format rather than the storage layer. The README describes the product as an open translation management platform for teams, and lists import and export to JSON flat and nested, CSV, YAML flat and nested, Java Properties, XLIFF 1.2, Gettext (po), Strings and Android Resources (xml). The intended user is a team that wants to invite non-developers into the translation workflow without giving them commit access to the repository. The README also states that Ever will use Traduora from its own platforms, ever-gauzy and ever-demand, which is a reasonable signal that the maintainers run it themselves, though the README does not say at what scale or in what configuration.
How the platform is put together: Angular frontend, Node API, REST as the contract
The repository is a JavaScript and TypeScript monorepo. The topics list names angular, nodejs, api and webapp, and the README refers to a monorepo root and to an API package directory as two places from which the same yarn scripts can be run. That layout implies at least a web application and a separate API service, with the API owning the data and the web app talking to it. The README states that the workflow can be automated via a REST API, and that client to server communication should be encrypted with HTTPS/SSL in production. It does not publish an OpenAPI specification or a route list in the material available here, so the shape of individual endpoints cannot be confirmed from the README alone. What can be confirmed is the direction of data flow: formats come in through import, the platform stores them, and formats go out through export. The README mentions that automatic translation through third-party integrations is planned rather than present, using the word soon. Treat that as a roadmap item, not a capability. There is also a community-contributed CLI at github.com/iilei/traduora-cli, which the README explicitly labels as not official. If you build automation, plan against the REST API rather than the CLI.
Running it: Docker images, environment variables and the seed scripts
The README points to a Docker Hub page for pre-built images and claims a five minute setup with Docker, Kubernetes or from source, with configuration and deployment documents on docs.traduora.co. Two environment variables are documented in the README itself. TR_SIGNUPS_ENABLED=false disables self-service signups, and when that is set the platform needs a default admin user to be reachable at all. TR_SEED_DATA=true makes Traduora run the seed scripts during application startup, so the admin account exists without a manual step. Seeding can also be triggered by hand, and the README gives the commands: yarn seed:default creates the default admin user, while yarn seed runs all seeds including demo data. Both are shown as runnable from the monorepo root or from the API package directory. The admin account is created with a documented default: email local.admin@ever.co, password sTr0ngP@ssw0rd!2025, name Admin. All three can be overridden with TR_ADMIN_EMAIL, TR_ADMIN_PASSWORD and TR_ADMIN_NAME. The README notes that credentials can be changed after first login through user settings in the web interface. The published default password is a real operational hazard: if TR_SEED_DATA=true is set on an instance that is reachable before anyone logs in, that password is live. Set TR_ADMIN_PASSWORD before the first start rather than after.
Where Traduora stops being the right tool
The README's own framing is the clearest limitation. Third-party automatic translation is described as coming soon, so a team expecting machine translation inside the platform will not find it in the documented feature set. The second limitation is architectural rather than a missing feature. Because the database is the source of truth and files are an interchange format, the platform sits between your translators and your repository. That is the point of the product, but it means a release cycle now includes an export step, and anyone who edits the exported files directly creates a divergence the platform will not detect. Teams that already treat translation files as code, reviewed in pull requests with the same tooling as the rest of the repository, will find Traduora adds a hop rather than removing one. A third constraint is the licence. AGPL-3.0 is a strong copyleft licence, and the README does not offer a separate commercial or relicensing option. If you intend to offer a modified Traduora to users over a network, the licence terms matter to you in a way they do not for a purely internal deployment. This is not legal advice; read the LICENSE file and talk to counsel if the network clause applies to your product.
Maintenance and upgrade cost
Release cadence visible in the material is modest and irregular. v0.21.0 is dated 2025-06-22, and before it v0.20.4 and v0.20.3 both landed on 2025-04-07, a few hours apart, which looks like a fix released twice in one day rather than a planned schedule. The default branch is develop, not main or master, so the repository's own convention is that work lands on develop first. Anyone building from source should expect to track that branch or pin to release tags. The README points to a changelog on docs.traduora.co for release information, which is where upgrade notes would live; the README itself does not describe a migration procedure or a database schema versioning scheme. For a self-hosted deployment that means the upgrade path is something you verify against the changelog and your own database before you run it, not something the README promises. Running from source also means building an Angular frontend and a Node API, so pinning a Docker image tag is the lower-effort option for most teams. The AGPL-3.0 licence carries no per-seat or per-project cost, which is the financial argument for self-hosting here, but it shifts the entire operational cost onto you.
Alternatives and how the approaches differ
The most direct comparison is a Git-based translation workflow, where the translation files stay in the repository and translators work through pull requests or a bot that commits changes back. That approach has no database, no server to run and no separate export step, and it inherits code review, history and rollback for free. Its weakness is the one Traduora targets: non-technical translators need Git tooling or a bot that mediates for them, and there is no shared searchable index across projects. A second alternative is a commercial hosted translation management service, which removes the operational burden and usually bundles machine translation and translator marketplaces. The trade is that your strings leave your infrastructure and pricing scales with usage, which is exactly what a self-hosted AGPL project avoids. Traduora's position between those two is narrow but real: it is the self-hosted option for teams that want a shared web interface and an API without handing strings to a vendor. It is not a Git-integrated tool, and the README does not describe any repository sync feature, so teams expecting round-trip commits should look at the Git-based category instead.
Who should deploy Traduora, and what to check first
Deploy it if your translations need to stay on infrastructure you control, if your team wants a browser interface for translators who will never touch the repository, and if a REST API is enough to wire the platform into your build pipeline. Skip it if you need built-in machine translation today, if your workflow is already pull-request based and working, or if AGPL-3.0 is incompatible with how you distribute your own product. The verification list is short and specific. First, set TR_ADMIN_PASSWORD and TR_ADMIN_EMAIL before the first start, or confirm that the account created from the README defaults has been changed through the web interface. Second, decide whether TR_SIGNUPS_ENABLED should be false, and if it is, confirm that TR_SEED_DATA or a manual yarn seed:default has produced an admin account you can actually log in with. Third, read the configuration and deployment pages on docs.traduora.co, since the README defers to them and does not restate their contents. Fourth, check the changelog before any version bump, because the README documents no migration procedure. Fifth, if you plan to build on the API, note that the README does not publish a specification, so budget time to inspect the API package in the repository rather than assuming a documented contract.
Editorial conclusion
Adopt Traduora if you need translation strings held on your own infrastructure and your team is comfortable with a web UI plus REST API rather than a Git-based workflow. Do not adopt it if you cannot accept AGPL-3.0 obligations or if you need a hosted service with a support contract. Before deploying, verify the TR_SIGNUPS_ENABLED and TR_SEED_DATA interaction, and change the default admin credentials that the README publishes.
Community notes