Languine: AI translation you host on your own Vercel account

Fork, deploy, then run three CLI commands

The pitch takes two sentences: click Deploy, then run `npx languine`. What the deploy button actually does is spelled out as five steps. It forks the repository to your GitHub account, creates a Vercel project with `apps/web` as the root directory, provisions serverless Postgres through the Vercel Marketplace so `DATABASE_URL` arrives without you configuring it, prompts for an API key and an optional model slug, and builds. The build runs `drizzle-kit migrate` against the fresh database, which is why there is no separate migration step in the setup instructions.

The CLI has three commands in the documented flow:

npx languine@selfhosted login --url https://languine.your-team.vercel.app
npx languine@selfhosted init
npx languine@selfhosted translate

`login` opens `/cli/token` in your browser. `init` creates a project through a tRPC call and writes the returned project id into `languine.json`, so the dashboard is optional after deployment. `translate` is the command that does the work.

There is a fourth path for CI, and it is the one most teams end up using:

export LANGUINE_BASE_URL=https://languine.your-team.vercel.app
export LANGUINE_API_KEY=<the-key-you-set-on-vercel>
npx languine@selfhosted translate

The environment variable route skips the browser entirely, which is what makes the GitHub Action version viable.

Why the install command needs a dist tag

The self-hosted CLI ships under the `selfhosted` npm dist tag rather than `latest`, and the README explains why in a blockquote: the legacy hosted backend still has users, so `npx languine@latest` continues to resolve to the 3.x CLI pointed at the old service. If you want the self-hosted build you must either write the tag every time or pin `"languine": "^4"` in your `package.json`.

That is an unusual amount of ceremony for a translation tool, and it is worth pausing on why it exists. A project that forked itself into a hosted service and then added a self-hosted mode inherits both audiences. Anyone who runs `npx languine` expecting their own deployment will silently talk to someone else's backend unless they read the note.

The GitHub Action carries the same split in its inputs, since `languine-ai/languine@v4` is the action reference and `api-key`, `base-url`, `project-id` and `create-pull-request` are the knobs:

      - uses: languine-ai/languine@v4
        with:
          api-key: ${{ secrets.LANGUINE_API_KEY }}
          base-url: ${{ vars.LANGUINE_BASE_URL }}
          project-id: prj_xxxxxxx
          create-pull-request: 'true'

One API key serves the dashboard, the CLI and the Action. Generating it with `openssl rand -hex 32` is the documented advice.

Turn on deployment protection before anything else

The README is unusually blunt about the first thing to do after deploying: enable Deployment Protection, either Vercel Authentication or Password Protection, because without it your API key is publicly visible. The dashboard and the `/cli/token` endpoint are both behind that gate, and the token page hands out the key.

The reasoning is straightforward. A single shared API key authorises the CLI, the Action and every translation job, and the only thing standing between a stranger and that key is whether the deployment requires a login. This is a different shape from most SaaS products where per user credentials and per project scoping come for free.

The architecture list makes the rest explicit. Hosting is Vercel with Next.js 16 on the App Router and the Node.js runtime. The database is serverless Postgres from the Vercel Marketplace with Drizzle ORM. Background jobs run on Vercel Workflows, described as durable, resumable and observable. Model calls go through the Vercel AI Gateway with AI SDK v6, and the gateway authenticates automatically using the project's OIDC token, so `AI_GATEWAY_API_KEY` is only needed when you run outside Vercel.

One environment variable is optional and worth getting right: `AI_MODEL` defaults to `openai/gpt-4.1`, and the README offers `anthropic/claude-sonnet-4` and `openai/gpt-4.1-mini` as examples. Since the gateway speaks a slug rather than a vendor SDK, switching providers is a one line change in the deploy configuration.

The examples directory is the real documentation

The most useful thing in the repository is not in the README. The `examples/` directory contains more than twenty sample projects, one per translation file format and framework, and they are a better argument for the tool than any feature list: `next-intl`, `next-international`, `nuxt`, `i18next`, `react-i18next`, `lingui`, `expo`, `fumadocs`, `android`, `markdown`, `monorepo`, `namespace`, `multiple`, `complex-keys`, `overrides` and `transform`.

Then the format specific ones, which are the interesting half: `ftl` for Fluent, `po` for gettext, `php` for Laravel style arrays, `react-email` for email templates, and a run of Apple platforms with `xcode-strings`, `xcode-stringsdict` and `xcode-xcstrings`. Apple's newer string catalogue format getting its own example says the project is being kept current with the platforms people actually ship on.

Reading three or four of those directories tells you how the tool behaves in practice: which keys it treats as variables, what it does with nested namespaces, how overrides work, and whether a monorepo needs per package configuration. None of that is described in prose anywhere.

Local development is a Bun workflow, matching the `packageManager` field in the root manifest:

git clone https://github.com/languine-ai/languine
cd languine
bun install
cp apps/web/.env.example apps/web/.env
bun dev

Tests are filtered by workspace, with `bun test` for everything, `bun test --filter @languine/web` for the web app and `bun test --filter languine` for the CLI. The repository is a Bun and Turbo monorepo with Biome for formatting and Changesets for versioning, and the copyright line reads Midday Labs AB.

A repository whose release history does not match its docs

Here is the gap worth knowing about. The README documents a version 4 CLI and a version 4 GitHub Action. The releases page has two entries: `v1` published on 2025-02-05 and `v.1.0.0` published three days earlier on 2025-02-02, and that second tag name carries a stray dot. Neither release has notes. There is no tagged release after February 2025 even though the repository has 2,035 stars, 10 open issues and a last push on 2026-05-09.

The root `package.json` compounds the confusion rather than resolving it. It is named `@languine/core`, marked private, and its version is `1.0.0`, which matches neither the README's version 4 nor the tag names. The real version numbers live in the workspace packages, so the manifest a reader looks at first is the least informative file in the tree.

This does not mean the project is abandoned, and the absence of GitHub releases may simply mean versions are cut on npm instead through Changesets. But a reader deciding whether to adopt it has to accept that the release history is not on GitHub, and that the version they see in the README is the one to trust. For a tool that rewrites source files in your repository, pinning the CLI version explicitly is the safer habit anyway.

Editorial conclusion

Languine is a good fit for a team that has already chosen Vercel and wants translation keys to arrive as a pull request instead of a spreadsheet. The database is yours, the API key is yours, and the AI call goes through the Vercel AI Gateway rather than a vendor account, so the pieces you would worry about leaving a SaaS are the pieces you can see. The cost is the deployment protection step that the README tells you not to skip, the absence of any tagged release past 2025 despite a README that speaks in terms of version 4, and a choice of platform that you cannot take with you. Start with the deploy button, turn on Vercel Authentication before anything else, and read `apps/web/.env.example` to see exactly what the deployment expects.

Frequently asked questions

Official sources

1. languine-ai/languine on GitHub
2. License: MIT
3. Project website
4. README
5. Releases