One image, on your infrastructure
The dashboard ships as a single Docker image and runs on hardware you control. Three database engines, no product telemetry by default (nothing is sent to PostHog unless you set your own key), and no account required to pull it.
- Container to run
- 1
- Database engines
- 3
- CPU architectures
- 2
- Product telemetry by default
- 0
Pull the image
No account, no registry login — the image is public on Docker Hub. Pin a version →linux/amd64linux/arm64
The decision
What self-hosting gives you, and what it costs
There is no hosted dashboard to compare against — self-hosting is how the product runs. The honest question is not whether it is worth it, but what you take on.
Stays on your side
- Your source code. The scanner reads your repository from inside your own network. Nothing is uploaded to have its keys extracted.
- Your translations. They live in the database you pointed the container at — a SQLite file in a volume, or a Postgres/MySQL server you already operate.
- Your provider keys. DeepL, Google, LibreTranslate: the calls leave your instance, encrypted at rest with your own session secret.
- Your network boundary. The published port binds to 127.0.0.1 by default. Nothing is reachable from another machine until you decide it is.
Becomes your job
- TLS and the reverse proxy. Nothing in the image terminates TLS. Exposing it beyond localhost means putting Caddy, nginx or Traefik in front.
- Backups, and testing them. One volume or one database dump. The bundled CLI exports everything as JSON; restoring it is still on you.
- Upgrades. Pull the new tag and restart. Migrations run themselves at boot, and a failed one is not recorded, so the next boot retries it.
- Sign-in, in server mode. Several accounts on one instance sign in through the central account service we operate; you cannot run your own today.
Comes in
- Your team
- TLS and the reverse proxy.
Your instance
127.0.0.1:6001Database · SQLite / PostgreSQL / MySQL
Goes out
- Our central account
- Sign-in
- Your plan: at most every 15 min, once a deployment secret is set
- First automatic translation: account ID only
- Your translation provider, with your key
- Our site: UI language files, fetched by the browser
Your instance does contact the central account: for sign-in (always in server mode; in local mode, only for an account with no local password); and, once a deployment secret is set, for your plan (at most every 15 minutes, while the dashboard is in use) and your first automatic translation (account ID only). The browser downloads non-English UI language files from our site.
Choose
How you want to run it
Three modes, one image. The mode decides who signs in and what the instance depends on — it does not change the product.
Local
DefaultPick this if it is you, or one small team behind a network you already trust.
- A sign-in screen, with one account created at first launch.
- SQLite in a Docker volume. No second service to run.
- Your data and your sign-in stay on your machine. Non-English interface files still come from us.
Server
Multi-teamPick this if several people need their own account on the same instance.
- Sign-in, roles, and the Draft → Reviewed → Approved workflow.
- A networked database — PostgreSQL or MySQL.
- Sign-in goes through the central account service we operate; you cannot run your own today.
Desktop
No DockerPick this if you would rather not run a server at all.
- Native macOS, Windows and Linux build with the server embedded.
- Translations are stored in local SQLite and leave the machine only when you send them to a service you set up, such as a translation provider or a Git remote.
- Signing in still goes through your account online.
Pick an engine
Your database, your compose file
All three carry the same 27 tables, so the choice is not about correctness. It is about how you back the instance up and who else needs to reach it.
One file, one container
What the published image ships and what the desktop app uses. No second service, no credentials to manage. The whole instance is this file plus one Docker volume.
The port binds to 127.0.0.1 on purpose: reachable from this machine, from nowhere else. Local mode is built for one person or one small team, so widen it only behind a proxy, a firewall or a VPN you already trust.
The published port binds to 127.0.0.1 by default. Nothing is reachable from another machine until you decide it is.
Desktop vs self-hosted
What changes when you self-host
| Criterion | Desktop app | Self-hosted |
|---|---|---|
| Setup | Download and open | docker compose up -d |
| Database | SQLite, bundled | SQLite, PostgreSQL or MySQL |
| Where data lives | Your machine | Your infrastructure |
| Updates | Automatic | docker compose pull && docker compose up -d |
| Team access | Just you, on that machine | Your whole team — server mode signs in through our central account service |
What depends on Elysera today
What still depends on Elysera
This project is operated by Elysera, which holds the rights to the code. Here is what still depends on Elysera today.
Local
Your data, the server and your sign-in all run on your machine: the account you create at first launch signs in with a local password, and the session renews itself without contacting Elysera. One thing still goes through Elysera: the non-English interface files, which your browser downloads from its site (if it cannot, the interface falls back to the instance's own copy, in English where it has none). An account that signed in through the central account can set a local backup password to do without it.
Server
Sign-in goes through the central account service Elysera operates. You cannot run your own today: its code is not published, and the dashboard uses its sign-in protocol, so a standard OIDC provider is not a drop-in replacement. If it is unreachable, sign-in stops within minutes. Your plan does not change: the instance keeps the last one it saw and never lowers it on its own, except for a trial that has ended.
Desktop
Your translations are stored in a SQLite file on your machine. Signing in goes through the central account.
Leaving
Leaving with your data
Exporting runs on your own instance, with a token you set. It needs no Elysera account and no permission.
JSON, in your project's shape
One language or all of them. The file follows the shape your files had when the dashboard scanned them, flat or nested; if they were mixed, or never scanned, it is nested. Keys that have no translation yet are left out.
A full backup
One JSON file with the whole instance, restorable on another one. It needs the separate admin token.
Your locale files
They live in your own repository. The dashboard reads them and writes back through sync; stopping it leaves them where they are.
From the command line
In the Docker image, with the tokens set in the environment:
docker exec -it i18n-dashboard i18nd exportdocker exec -it i18n-dashboard i18nd backup
What is not promised
A byte-identical round trip. The export follows your files' shape, but key order and formatting can differ from your originals, so a diff against them may not be clean.
Translating your app in four steps.
Create your account
Free to start: 30 days of any plan, no card. Stays free for 1 project.
Install it
On your own server. Then open localhost:6001.
Self-hosting guidedocker compose pull && docker compose up -dmacOS, Windows or Linux. It runs its own local server.
Download the appConnect your project
Point it at a folder or a Git repository. It finds your framework and your locale files.
Translate
Pick one of 8 providers and translate a whole language at once. Google Translate works without a key.