GPTLink: self-hosted AI chat with users, orders and paid plans

The problem GPTLink solves, and the people it is aimed at

Running a chat UI against an API key is a weekend project. Running one that takes money is not. The moment you want accounts, a quota, an order record and a code a customer can redeem, you are writing a billing system with a chat box bolted on. GPTLink's README frames the project as a way to stand up an AI chat site in a few steps, and the feature list is explicit about the commercial parts: custom paid plans, redeem codes, task-based referral, order handling. That is the actual product. The conversation with the model is the easy half.

The intended operator is someone who wants a branded chat endpoint for their own users, most likely in the Chinese market. The README points at WeChat website apps, WeChat official accounts and WeChat Pay as optional integrations, and the default timezone in the Dockerfile is Asia/Shanghai. If your users do not live in that ecosystem, the payment and login integrations are dead weight you will configure around rather than use. The project also expects you to bring your own model access: either an OpenAI key or a key from the vendor's own service at gpt-link.cn, which the README recommends and describes as requiring no review and no proxy.

How the pieces fit: Hyperf backend, Vue frontend, Nginx in one image

The repository is split into three top-level application directories plus configuration. gptserver is the Hyperf PHP backend, gptweb is the chat frontend, gptadmin is the management frontend, and conf/ holds the Nginx site config that gets copied into the image. The frontend source lives in a separate repository, gptlink/gptlink-web, and the deployment scripts live in gptlink/gptlink-deploy. The README states that the new admin source is still in development, so gptadmin is present in this repository as a built artifact rather than as something you can read and modify from the public tree.

The Dockerfile shows the runtime shape. It starts from hyperf/hyperf:8.0-alpine-v3.11-swoole, installs Nginx and vim, copies all three application directories into /app, drops in conf/nginx-default.conf, and runs composer install with --no-dev --optimize-autoloader --ignore-platform-reqs inside gptserver. PHP settings are appended to /etc/php8/conf.d/99_overrides.ini: a 128M upload limit, a 1G memory limit, and the timezone. The container starts with bash /app/gptserver/start.sh, so the PHP server and Nginx come up together from one process tree. That is a single-container design, which is convenient for a first run and awkward once you want to scale the API layer separately from the web layer.

Installing GPTLink with Docker and reaching the console

The README recommends Docker and points at the gptlink-deploy repository for the full deployment documentation, which lists PHP environment deployment, Docker deployment and Docker Compose deployment. The repository ships its own Dockerfile, whose CMD is the only start command the repository defines:

CMD ["bash", "/app/gptserver/start.sh"]

That line is what the container runs, so the PHP server and Nginx come up from one entrypoint. The image installs dependencies during the build, which is why the Dockerfile runs composer install before the CMD. The relevant build step, copied from the Dockerfile, is:

RUN cd /app/gptserver && \
    composer config --no-plugins allow-plugins.easywechat-composer/easywechat-composer false && \
    composer install --no-dev --optimize-autoloader --ignore-platform-reqs && \
    ln -sf /usr/share/zoneinfo/${TIMEZONE} /etc/localtime

Before you start the container for real, create the environment file. The README says the configuration lives in gptserver/.env and that if the file does not exist you should rename gptserver/.env.example to .env. The detailed key list is in docs/ENV.md rather than in the README, so read that file before assuming a key name.

Once the container is up, the chat page is at http://your-domain-or-ip and the admin console is at http://your-domain-or-ip/admin. The README states the administrator credentials come from the ADMIN_USERNAME and ADMIN_PASSWORD configuration values, and that if these are not supplied the defaults are admin and admin888. Note the README prints ADMIN_USERNAME twice in that sentence; the second one is the password. Change both before the instance is reachable from the internet. API documentation is served at /api/docs/default for the user side and /api/docs/admin for the admin side.

Where GPTLink gets in your way

The admin frontend is the biggest gap. The README's version plan has an unchecked box for admin open source, meaning the admin source is not open. You get a working admin console in the image, but you cannot read it, patch it, or build a fork of it from this repository. If your deployment depends on modifying admin behaviour rather than just using it, you are blocked until that box is ticked.

The licence situation is contradictory and worth resolving before you ship anything commercial. The README ends with an Apache License Version 2.0 notice pointing at the Apache Foundation text, but the repository metadata carries no licence identifier and there is no LICENSE file listed among the top-level entries. A README statement is not the same as a licence file in the tree, and the discrepancy is exactly the kind of thing a legal review will flag. The description advertises free commercial use; the repository does not currently back that claim with a detectable licence file.

Operationally, the single-container layout means the PHP process and Nginx share a filesystem and a lifecycle. Restarting one restarts the other. The composer install runs with --ignore-platform-reqs, which means dependency platform checks are skipped at build time; that is a build convenience that can hide extension mismatches until runtime. And the model side is not neutral: the README recommends the gpt-link.cn key over the OpenAI key, which makes an external vendor part of your critical path if you follow that advice.

What you would use instead, and how the approach differs

The obvious comparison is a chat UI front end that talks to a provider directly, with no backend of your own. Those projects give you a conversation page and a key, and stop there: no accounts, no order table, no redeem codes. GPTLink's difference is that it is a small commerce application first. The user, order and task models are the product, and the chat is the thing being sold. If you do not intend to charge anyone, that whole layer is overhead you will maintain and never use.

The second alternative is building the same thing on a general web framework with a payment library. That gives you full control over the admin surface, which GPTLink currently withholds, at the cost of writing the account, order and task scaffolding yourself. The trade is legibility against time: GPTLink hands you a running system whose admin half you cannot read, while a from-scratch build hands you a readable system that does not run yet. Which one is wrong for you depends entirely on whether you need to modify admin behaviour or merely operate it.

Maintenance, upgrades and the licence question

The last push to the default branch was on 2026-08-14, so the repository is not abandoned, but the release history tells a different story about cadence: v1.3.2 in September 2023, v1.3.3 in November 2023, v1.3.4 in March 2024, and no tagged release since. Commits continue while releases do not, which means the version you pin may not correspond to the code you are running. If you deploy from master rather than from a tag, record the commit you built.

Upgrade cost is concentrated in two places. The backend dependencies are locked by composer.lock inside gptserver and installed with --no-dev, so a PHP or Hyperf upgrade means rebuilding the image rather than patching a running container. The frontend is a separate repository, gptlink-web, so a UI change and a backend change arrive through different paths and can drift. Budget for rebuilding the image on every upgrade rather than for incremental patches.

On licensing: the README states Apache License Version 2.0, and the repository metadata does not. Apache 2.0 is permissive and includes an explicit patent grant, which is friendlier for commercial use than a copyleft licence would be, but you should not treat a README line as the operative grant. Confirm with the maintainers which licence applies, and check whether the separately hosted gptlink-web and gptlink-deploy repositories carry their own licence files, since those are the parts you would actually redistribute in a fork.

Editorial conclusion

Adopt GPTLink if you want a working chat frontend with accounts, orders and redeem codes without writing that layer yourself, and you accept that the admin UI ships as part of the deployment rather than as open source. Do not adopt it if you need the admin code to audit, if you want a licence file you can read before deploying, or if you cannot operate PHP, MySQL and Nginx. Before committing, verify three things: that gptserver/.env.example exists and covers the keys you need, that your API key works against the endpoint you configure, and whether the admin open-source checkbox in the README has been ticked since you last looked.

Frequently asked questions

Official sources

1. gptlink/gptlink on GitHub
2. Issues
3. README
4. Releases