Skip to content
Self-hosted

One image, on your infrastructure

The dashboard ships as a single Docker image and runs on hardware you control. Three database engines, no telemetry unless you configure it, and no account required to pull it.

Pull the image

linux/amd64linux/arm64Pin a version →

No account, no registry login, no source checkout — the image is public on Docker Hub.

Your instance, running on your own domain

i18n.example.com

All systems operational

v0.23.0server mode

  • Database1156 keysok
  • SMTPsmtp.example.comok
  • Translation providergoogle-freeok

What GET /api/healthreports on a running instance — the same probe your orchestrator and your uptime monitor read.

1

Container to run

3

Database engines

2

CPU architectures

0

Telemetry by default

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 needs a JWKS-compatible OIDC issuer — your own, or the one we operate. Local mode has no login at all.
Choose

How you want to run it

Three modes, one image. The mode decides whether there is a login screen and what the instance depends on — it does not change the product.

Local

Default

Pick this if it is you, or one small team behind a network you already trust.

  • No login screen at all — whoever reaches the port has every project.
  • SQLite in a Docker volume. No second service to run.
  • Nothing outbound. The instance depends on no one.

Server

Multi-team

Pick 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.
  • Requires a JWKS-compatible OIDC issuer, reachable at all times: your own, or the one we operate.

Desktop

No Docker

Pick this if you would rather not run a server at all.

  • Native macOS, Windows and Linux build with the server embedded.
  • Translations stay in local SQLite — nothing leaves the machine.
  • Signing in still goes through your account online.

Download the app →

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.

docker-compose.yml
Desktop vs self-hosted

What changes when you self-host

CriterionDesktop appSelf-hosted
SetupDownload and opendocker compose up -d
DatabaseSQLite, bundledSQLite, PostgreSQL or MySQL
Where data livesYour machineYour infrastructure
UpdatesAutomaticdocker compose pull && docker compose up -d
Team accessJust you, on that machineYour whole team — server mode needs an OIDC provider (yours, or ours)
Next

The rest of the procedure lives in the docs

This page is the decision: whether to run it yourself, in which mode, on which engine. Everything that comes after the first successful boot is documented in one place, so there is only ever one version of it.

  • Environment variables — every knob, its default and its scope.
  • SMTP — workflow notifications, or nothing at all if you leave the host empty.
  • Roles and permissions — who can approve a translation once several people share the instance.
  • Webhooks — signed events your own systems can react to.
  • Backup and restore — the volume, the dump, and the CLI that exports everything as JSON.
  • Troubleshooting — the errors that actually happen, and what each one means.

Open the documentation