# DeepLX Serverless: a translation endpoint you can drop onto Vercel

> DeepLX Serverless exposes the DeepL web interface as a plain HTTP endpoint written in JavaScript, so it runs on a serverless platform without a token, a compile step or a native module, and the whole service installs with four dependencies.

**guobao2333/DeepLX-Serverless** — Free DeepL API for Serverless

- Repository: https://github.com/guobao2333/DeepLX-Serverless
- Website: https://deeplx-serverless.vercel.app
- Stars: 562 · Forks: 156
- Language: JavaScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/guobao2333-deeplx-serverless

## What the project is, and the premise it rests on

DeepLX Serverless is a lightweight NodeJS project built on the DeepL web version that needs no account token, and it is written entirely in JavaScript. That last detail is the practical point rather than a stylistic one. It means there is no recompiling and no packaging step: you install the dependencies and you can start running. The premise is that the translation endpoint the DeepL website itself calls can be used directly, which is why the project is MIT licensed and why the three projects in the thanks section are the ones it builds on, the OwO-Network DeepLX project, another serverless implementation and a Vercel deployment. The project's own description of what it is, a free DeepL API for serverless, is the honest summary.

## Deploying it locally, and the one-line test

The prerequisites are a server or device running Nodejs 22 or newer, or Docker, or a serverless function platform, and optionally a Vercel account. The local deployment path is a clone, an install and a start.

```bash
git clone https://github.com/guobao2333/DeepLX-Serverless
cd DeepLX-Serverless
npm i
npm run start && npm run test:post
```

The start and the post test are chained with an ampersand so the service comes up and the test hits it immediately, which is the fastest way to confirm the whole path works before you deploy it anywhere. Configuration is done by editing the .env file or by passing startup parameters, and the parameters take precedence over .env, which the documentation flags as important. The npm scripts are correspondingly small: the start script runs the server with the .env file loaded if it exists, the test script runs a test file, the start:sl script runs the serverless entry point instead, and test:post runs the post test.

## The serverless entry point and the Vercel deployment

The api/ directory holds the serverless entry point, and the start:sl script runs api/index.js rather than src/server.js, with the same environment loading. That split is what lets the same codebase run as a long-lived Node service or as a function that a platform spins up per request. The project ships a vercel.json, and the deployment path is the Vercel clone button, with an optional Vercel account listed as a prerequisite. The runtime contract is simple. The package is an ES module, the main entry is src/server.js, the engine requirement is Node 22 or newer, and the dependency list is short enough to read in full: cors, dotenv, express and yargs, with express at version 5.

## Docker, and the two ways to get an image

A prebuilt image is published to the GitHub container registry and can be run directly.

```bash
docker run -d -p 6119:6119 ghcr.io/guobao2333/deeplx-serverless
```

Or you can build it yourself from the Dockerfile in the repository.

```bash
docker build -t deeplxs .
docker run -d -p 6119:6119 deeplxs
```

The Dockerfile is a two stage build on the node LTS alpine image, with a deps stage that copies the package manifests and installs, and a final stage that copies the node_modules across and then the source. The port 6119 is exposed, and the container runs as the non-root node user rather than as root, with npm start as the command. A .dockerignore is present at the top level.

## The startup parameters, and the one worth thinking about

Startup parameters override the .env file, which the documentation marks as important, and the -h option lists all of them. The example given is the one that matters most in practice, the -c parameter that allows all cross-origin requests.

```bash
npm run start -- -c
```

The parameters exist because the same script has to work in several places. On a personal machine or inside a container you control, allowing every origin is a convenience that removes a class of browser errors. On a public serverless deployment, where anyone can call your function, the same flag turns your endpoint into an open relay that other people's web pages can call from a visitor's browser, which is a different decision with a different risk profile. The rest of the project is a translation service, but the parameter is the difference between a private tool and a public proxy, so it is worth deciding on purpose rather than by copying a command.

## Calling the endpoint over HTTP

The HTTP interface is a POST to the translate path on port 6119, with a Content-Type of application/json and a JSON body carrying the text, the source language code and the target language code, where the language codes are the usual short forms such as zh and en. The full parameter list is in the project wiki rather than in the readme, which is where to look for the options beyond the text and the two language codes. The internal API is a single exported function, and the example shows the call shape with the text, the target language, the source language and a boolean flag.

```javascript
import { translate } from './src/translate.js';
translate('how are you?', 'en', 'zh', false)
.then(result => {
  console.log(result)
});
```

The repository also ships test.js and test_post.js, which are the scripts behind the test and test:post commands, so you can check the endpoint from the command line before writing any client code.

## The disclaimer, and where this fits

The project states plainly that it is not an official DeepL product and has no affiliation with DeepL, and it says not to rely on it, because it is built on the web version and the interface and protocol may change at any time, which can make it stop working. The advice for anyone with a large amount of content to translate is to use the official DeepL translation API, because the project is always subject to the DeepL web version's policy. That is a candid statement of the trade, and it is the same trade every unofficial web-client wrapper makes. The release history shows a v3.2.0 on 2026-10-13, a v3.1.0 on 2026-10-06 and a v3.0.2 from January 2025, and the last push to the repository was on 2026-10-13.

## Conclusion

DeepLX Serverless fits a developer who needs translation in a side project, a self-hosted tool or a serverless function and does not want to sign up for a paid API key, since the whole thing installs with npm i and runs with a start script. It does not fit anyone with a lot of text to translate, because the project itself says not to rely on it and points at the official API, as the web interface it calls can stop working at any time when the upstream protocol changes, and it does not fit a team that needs a guaranteed service level. Before you deploy it, read the disclaimer, keep the upstream policy in mind, and if you put it on a public host decide deliberately about the -c flag, since allowing all cross-origin requests on a shared deployment is a decision rather than a default.

## FAQ

### Do I need a DeepL account token to use DeepLX Serverless?

No. The project is built on the DeepL web version and needs no account token, which is the point of it. The prerequisites are Nodejs 22 or newer, or Docker, or a serverless function platform, and optionally a Vercel account.

### How do I run DeepLX Serverless locally?

Clone the repository, change into the directory, run npm i, and then npm run start with npm run test:post chained after it. The start script runs src/server.js with the .env file loaded if it exists, and the serverless variant is the start:sl script which runs api/index.js instead.

### How do I call the translate endpoint?

Send a POST to the translate path with a JSON body containing the text, the source language code and the target language code, with a Content-Type of application/json. The full parameter list is in the project wiki, and the translate function is also exported from src/translate.js for internal use.

### Is DeepLX Serverless reliable enough for production use?

The project says not to depend on it, because it is built on the DeepL web version and may stop working when the interface or protocol changes, and it advises using the official DeepL translation API if you have a lot of content to translate. It is always subject to the DeepL web version's policy.

## Sources

- [guobao2333/DeepLX-Serverless on GitHub](https://github.com/guobao2333/DeepLX-Serverless)
- [License: MIT](https://github.com/guobao2333/DeepLX-Serverless/blob/main/LICENSE)
- [Project website](https://deeplx-serverless.vercel.app)
- [README](https://github.com/guobao2333/DeepLX-Serverless/blob/main/README.md)
- [Releases](https://github.com/guobao2333/DeepLX-Serverless/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/guobao2333-deeplx-serverless