ChatGPT-Shortcut's compose file pulls a moving tag and its easiest deploy loses upstream updates

The compose file resolves a floating tag and restarts itself

The compose file is four fields of substance. The service pulls a published image by a tag that ends in latest:

image: ghcr.io/rockbenben/chatgpt-shortcut:latest

It publishes one port and sets the container to restart unless stopped. Consequence: two machines running the same compose file can serve different code, because each one resolves the tag when it pulls, and nothing in the file records which digest you got. Paired with a restart policy that survives a reboot, a self-hosted instance can quietly change version while nobody is looking at it. If you need to know what you are running, that means capturing the digest once and putting it in the file, which the compose file does not do for you.

Every page date becomes the build time, not the commit time

The image build sets one environment variable and explains why in a comment:

ENV SKIP_GIT_INFO=true

The explanation says this switches off the framework's last-update display and uses the current time as the build date instead, which removes all dependence on the git directory, avoids installing git, and lets the directory be excluded from the build context, shrinking that context considerably. Consequence: a self-hosted copy has no commit-derived dates at all. Wherever the site shows its build date, it shows the moment the image was built, so two deployments of the same source commit report different build dates. That is a reasonable trade for a smaller context and a faster build, and it is invisible unless you were relying on the date.

Eighteen locales are why the build is phased and pinned to one architecture

The builder stage is pinned to the build machine's architecture rather than the target's:

FROM --platform=$BUILDPLATFORM node:24-alpine AS builder

The comment above it explains that the static output does not depend on the processor architecture, so it is built once on the native architecture, and that otherwise an arm64 leg re-running the build under emulation alongside the amd64 leg would double memory usage and get killed. A second comment notes that the build runs in phases, a few locales per process, to avoid a single-process out-of-memory across all eighteen languages. Consequence: this is a clever and correct shape for a multilingual static site, and it also means the expensive part of a multi-architecture image build happens once and is then copied. If you add a language, you are editing one data file and hoping the phase size still holds.

The three framework packages are pinned so the update script cannot move them

Most dependencies in the manifest carry a caret range. Three do not, and they are the ones that build the site:

"@docusaurus/core": "3.10.2",

The maintenance script is a single line:

"update": "npx --yes npm-check-updates -u && yarn install"

Consequence: the manifest mixes two version policies in one file, and only one of them is expressed as ranges.

The type check runs three project guards before it runs the compiler

The type check has a pre-step, and that pre-step runs three custom scripts by name:

"checks": "node scripts/checkClipboardFallback.mjs && node scripts/checkChunkReloadGuard.mjs && node scripts/checkAntdStyleWiring.mjs",

Those are followed by the actual compiler invocation, and the pre-step also regenerates project data first. Consequence: the typecheck script is not just a type check, it is a type check plus a data generation step plus three assertions about clipboard fallback, chunk reload behaviour and stylesheet wiring. A contributor fixing a type error has to get generation and all three guards to pass first, which makes the feedback loop slower but catches a class of bug a compiler cannot. The naming is the trap: nothing in the command called type check hints at the other two jobs.

A Python file sits at the root of a TypeScript project

The top level of the repository holds the TypeScript source, the documentation configuration, the container files, and a file whose extension is Python, sitting alongside the manifest and the nginx configuration. Consequence: whatever that script does, it is outside the JavaScript toolchain entirely. It is not covered by the compiler, none of the lifecycle hooks in the manifest invoke it, and the guard scripts do not look at it.

The offline edition drops the backend and the features that need one

The deployment section carries a callout for networks that are offline or inside an intranet. It points to an offline edition built for air-gapped enterprise or government networks, states that it needs no backend and no account, that data is stored locally in the browser, and that it keeps the same browsing, search, collecting and custom-prompt features. Consequence: everything in the readme that depends on a server is what goes, which is the account, the community submission and voting, the comments and the levelling system. An air-gapped install is therefore a private library with a copy button, and there is no path from it back into the community, because sharing requires the backend that edition removes.

The one-click deploy is documented as losing the update check

A tip below the deploy buttons explains the trade in the project's own words. The one-click Vercel deploy creates a new project rather than a fork, so the upstream-update check does not work. To get automatic synchronisation with the source repository, the guidance is to fork the repository first and then import the fork into Vercel, with full instructions in the deployment guide. Consequence: the path with the fewest steps gives you an instance that will never tell you upstream moved, and the fix costs a fork and an extra configuration step. For a static site that is a small price, and it is worth noticing that the project says so rather than leaving you to find out.

Editorial conclusion

ChatGPT-Shortcut fits someone who wants a searchable prompt catalogue they can browse without an account, and who wants to run their own copy rather than depend on a hosted site. It does not fit a deployment where the running version has to be identifiable, because the compose file resolves a floating tag, and it does not fit an air-gapped team that wants the community features, because the offline edition drops the backend and with it the account, voting and levelling. Before deploying, replace the floating tag with a digest or a version, decide whether the built site's dates matter to you, and if you use the Vercel button, fork first, because the documentation says the one-click path will not tell you that upstream moved.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rockbenben/ChatGPT-Shortcut on GitHub