rdgen: a web generator for custom RustDesk clients on your own server

The problem is that RustDesk clients need manual configuration

RustDesk is a remote desktop application, and a self-hosted deployment means every user has to be told to change the server address and paste in the key before the client will connect to anything. That is the friction rdgen exists to remove. The README describes it as a RustDesk client generator to use with your self-hosted RustDesk server, and the feature list is exactly the set of things a user would otherwise have to do by hand: embed the server and key into the client, set a custom app name, use a custom icon or logo, set default settings for the client, and support the RustDesk advanced settings, with a link to the project's own client configuration documentation. The audience is an administrator or IT team running a self-hosted RustDesk instance for an organisation, who wants the deployment to look and behave like their software rather than a generic open source client.

A Django application behind a small web interface

The implementation is a Django project rather than a script, and the top level entries make the structure clear. There is manage.py, the Django management entry point, a gunicorn.conf.py for the WSGI server configuration, an rdgen/ package and an rdgenerator/ package, a printer-adapter/ directory, and the Docker files. The Python dependencies are a short list: django for the web framework, requests for outbound HTTP calls, pillow for image handling, gunicorn as the WSGI server, and pyzipper for producing the password protected archives that the client download is packaged in. The Dockerfile shows the runtime shape: a python:3.13-alpine base, a non-root user created with adduser, the source copied into /opt/rdgen, dependencies installed with pip, and the Django migrations run at build time with python manage.py migrate. The container then exposes port 8000 and starts gunicorn against rdgen.wsgi:application, with a healthcheck that spiders the port every 30 seconds.

Running it with docker-compose and the variables that matter

The compose file is where the operational detail sits, and it shows a service that expects a GitHub account and a reachable URL.

services:
  rdgen:
    # use bryangerlach/rdgen:latest for the latest build
    #build: .
    image: bryangerlach/rdgen:latest
    restart: unless-stopped
    environment:
      SECRET_KEY: "django-insecure-!(t-!f#6g#sr%yfded9(xha)g+=!6craeez^cp+*&bz_7vdk61"
      GHUSER: "github_username"
      GHBEARER: "github_access_token"
      GENURL: "accessible_url_of_server"
      ZIP_PASSWORD: ""
      GHBRANCH: "master"
      PROTOCOL: "https"
      REPONAME: "rdgen"
      SH_SECRET: ""
    ports:
      - "8000:8000"
    dns:
      - 8.8.8.8
    volumes:
      - ./exe:/opt/rdgen/exe
      - ./png:/opt/rdgen/png
      - ./temp_zips:/opt/rdgen/temp_zips

The variables group into three sets. The Django variables are SECRET_KEY and the ZIP password, and the sample SECRET_KEY is literally the insecure placeholder Django generates, so it is a value to replace rather than a value to keep. The GitHub variables are GHUSER, GHBEARER for a username and access token, GHBRANCH for the branch to build from and REPONAME for the repository name, which is the mechanism by which the generator obtains the RustDesk sources. The deployment variables are GENURL, the accessible URL of the server the client will point at, and PROTOCOL for the scheme. The three volume mounts hold the built executables, the uploaded icons and the temporary zip archives, so those directories have to exist and be writable by the unprivileged user the container runs as.

Building from the command line with rdgen-cli

The README also documents a path that avoids the browser, which matters for scripted or bulk deployment. The instructions are to save your configuration from the rdgen web interface, or to generate your own, and then use that JSON file with rdgen-cli by AlekseyLapunov to build from the command line on Windows, Linux or macOS. The example invocation given is `python rdgen-cli -f my_config.json --set-version 1.4.5 --set-platform windows -s https://rdgen.crayoneater.org`, which shows the four things you control: the configuration file, the RustDesk version, the target platform, and the address of the generator to build against. The config file is the interface between the two modes, since the web interface produces the same JSON the command line consumes, so you can design a configuration once and then build it however you like.

Self-hosting the generator, and the API integration

The generator is hosted publicly at rdgen.crayoneater.org, and the README points to setup.md for hosting it yourself, which is the sensible choice for an organisation that does not want its RustDesk build pipeline depending on someone else's site. There is also an integration with the author's fork of rustdesk-api, described as currently a work in progress that might have bugs, so the generator can be reached through an API server rather than only through its web interface. The README is careful to point at an alternative for people who would rather build RustDesk on their own machine, the DVForge project, which covers the case of wanting to compile the client locally rather than have a server build it for you. The distinction matters: rdgen is about producing a configured client, and DVForge is about the build itself, so they are complements rather than substitutes.

Practical notes on icons, names and build time

The Notes section lists three things that will bite you if you skip them. Icons should be square, with 256 by 256 recommended, which makes sense given that a Windows application icon is square and a stretched one looks broken on the desktop. You should avoid special characters or non-English characters in the app name and file name, which avoids a class of installer and filesystem trouble that is tedious to diagnose later. Build time is currently 30 to 45 minutes, and that is worth planning around, because it means a request through the web interface is not instant and you should not expect to regenerate a client between two meetings. That figure also explains why the tool is built as a server with a cache of built executables and a directory of temporary zips, rather than as a script that runs on your laptop for every request.

Where rdgen is the wrong tool

The boundaries are clear. If you use the public RustDesk relay servers, none of this applies, since the entire value is embedding your own server and key. If your users are on a managed desktop fleet where you already have a packaging and deployment system, adding a self-hosted generator may be redundant, because a good software deployment tool can deliver a client with preconfigured settings by other means. The operational risk is the GitHub dependency: the generator builds from sources it fetches from GitHub using the GHUSER and GHBEARER credentials you supply, so an expired token, a rate limit, an upstream change to the RustDesk build process, or a repository layout change all break your pipeline, and the README does not describe a fallback for a failed build. There is also no version pinning guidance beyond the set-version flag in the example, and the project publishes no GitHub releases, so tracking which RustDesk version a given generated client corresponds to is on you. The alternative worth naming is distributing a stock RustDesk client with a small deployment script or configuration management payload, which avoids the build infrastructure entirely at the cost of not having a branded, preconfigured installer.

Editorial conclusion

Adopt rdgen if you run a self-hosted RustDesk server and want your users to install a client that is already pointed at it, with your branding and your default settings applied. Do not adopt it if you use the public RustDesk servers, since the entire point is to embed your own server and key. Verify first that the RustDesk version you pin is still available, that your icon is a square image, and that the GitHub credentials the generator uses still have access to the sources it builds from.

Frequently asked questions

Official sources

1. bryangerlach/rdgen on GitHub
2. Issues
3. License: GPL-3.0
4. README