speechgpt: 1.0.0 in the manifest, v0.5.1 in the tags, and seven build-time credentials

The manifest says 1.0.0 and the newest tag is v0.5.1 from 2023

The manifest and the tag history do not meet:

"name": "speechgpt",
"private": true,
"version": "1.0.0",
"type": "module",
"packageManager": "[email protected]",

Two releases exist, and both are from May 2023. `v0.5.0`, titled New UI Design, went out on 2023-05-14 and `v0.5.1` followed a day later on 2023-05-15. Nothing has been tagged since.

So the 1.0.0 in the manifest was never cut as a release, and the jump from the 0.x line to it exists only in a file. Because `private` is set, the package is never published to a registry either, which means the version field communicates nothing to an outside consumer. The only versions a user can observe are the two 2023 tags.

The branch itself is not abandoned. The last push was 2026-07-11, roughly three years after the last tag, so there is a long tail of commits that no release names. Anyone pinning this project is pinning a commit, and the tag history gives no indication of which commits those are.

The root of the tree also contains a tracked `.env` file next to a `.dockerignore`. The document never says what that file holds or whether it is a template.

Seven VITE_ variables, and four of them are credentials

The one-click Vercel deployment link carries seven environment variable names in its query string, and the Dockerfile declares the same seven as build arguments:

ARG VITE_OPENAI_API_KEY=REPLACE_WITH_YOUR_OWN
ARG VITE_OPENAI_HOST=REPLACE_WITH_YOUR_OWN
ARG VITE_AWS_REGION=REPLACE_WITH_YOUR_OWN
ARG VITE_AWS_ACCESS_KEY_ID=REPLACE_WITH_YOUR_OWN
ARG VITE_AWS_ACCESS_KEY=REPLACE_WITH_YOUR_OWN
ARG VITE_AZURE_REGION=REPLACE_WITH_YOUR_OWN
ARG VITE_AZURE_KEY=REPLACE_WITH_YOUR_OWN

Each is then re-exported as an `ENV` in the same stage so the bundler can read it.

That prefix is the whole problem. Vite substitutes `VITE_`-prefixed values into the client bundle during the build, so every one of these values ends up inside the JavaScript that each visitor downloads. Two of them are outright secrets, an AWS secret access key and an Azure access key, and the Polly setup step in the tutorial even specifies the permission the AWS key should carry, `AmazonPollyFullAccess`. A key shipped that way is readable by every user of the deployment.

Two things limit the damage, and both are in the document. Every argument defaults to the literal string `REPLACE_WITH_YOUR_OWN`, so skipping a value leaves an inert placeholder rather than a working credential, and the one-click link repeats that string as its guidance for optional values. Beyond that, the tutorial's first step has you enter the OpenAI key in the app's own settings screen, which keeps it in the browser rather than in a shared deployment.

Both Docker commands omit the credential step

The deployment section gives two routes and neither passes anything to the build or the container. The pull route:

docker pull hahahumble/speechgpt

docker run -d -p 8080:8080 --name speechgpt hahahumble/speechgpt

The build route:

docker build -t speechgpt:arm64 -f Dockerfile .

docker run -d -p 8080:8080 --name=speechgpt speechgpt

There is no `-e` on either run and no `--build-arg` on the build. Since the seven arguments default to `REPLACE_WITH_YOUR_OWN`, both documented routes land on an image whose credentials are placeholders, and the second route produces that image locally rather than inheriting one from the maintainer.

That is consistent rather than broken, because the settings screen is the credential path the tutorial actually teaches. It does mean the documented commands are not sufficient on their own: after either one you still have to open the app and enter a key, and a key entered that way belongs to whoever is using that browser.

Two smaller oddities sit in the same section. The pull step is headed with a stray colon, reading as `Pull the Docker image:arm64.`, and the build command tags the image `speechgpt:arm64` while the Dockerfile says nothing about target architecture at all.

The runtime container is nginx and nothing else

The second stage of the Dockerfile is a static file server:

FROM nginx:alpine

COPY nginx.conf /etc/nginx/nginx.conf
WORKDIR /usr/share/nginx/html
COPY --from=builder /app/dist .

ENTRYPOINT ["nginx", "-g", "daemon off;"]

So the shipped container has no Node process, no application server, and no runtime environment. Whatever nginx.conf sets up is the entire runtime behaviour, which is also why the documented port is 8080 without the file itself being shown.

This is the structural reason the credentials are build-time. With a static file server in front and no origin to hold a secret, every call to OpenAI, AWS or Azure has to be made from the visitor's own browser, and the key travels with it. There is no configuration change that fixes this; it follows from the deployment shape.

The same shape explains the privacy claim. `dexie` and `dexie-react-hooks` are in the dependency list, which is IndexedDB in the browser, and that is the mechanism behind the feature bullet reading Privacy First, All data is stored locally. There is no server-side store to leak, and equally no server to broker a key. The two facts are the same design decision seen from opposite ends.

Build ordering is otherwise careful: `package.json` and `bun.lock` are copied and installed with `--frozen-lockfile` before `COPY . .`, so a host `node_modules` cannot overwrite the installed tree.

Privacy First is a feature bullet beside @vercel/analytics

The feature list opens with `Open source and free`, then claims `Privacy First` on the grounds that all data is stored locally, followed by `Mobile friendly`, support for over 100 languages, speech recognition, and speech synthesis.

The dependency list includes `@vercel/analytics` at `^2.0.1`. A web analytics package sitting in the same repository as a privacy-first claim is a contradiction the document never addresses, and nothing on this page says whether it is enabled, gated, or only loaded on the hosted deployment.

The language claim has visible support. Three packages back it: `i18next` at `^22.4.13`, `react-i18next` at `^12.2.0`, and `@types/i18next` at `^13.0.0`.

That last one is the first of four type packages placed in `dependencies` rather than `devDependencies`, alongside `@types/react-speech-recognition`, `@types/react-transition-group` and `@types/uuid`. They compile to nothing at runtime, so they inflate the install for every deployment without changing what the app does.

The recognition claim is supported by `react-hook-speech-to-text` at `^0.8.0`, which is the built-in path, with `microsoft-cognitiveservices-speech-sdk` at `^1.26.0` covering the Azure integration for both recognition and synthesis.

Two AWS SDK generations for one integration set

Three AWS SDK v3 clients are declared together at `^3.303.0`: `@aws-sdk/client-polly`, `@aws-sdk/client-transcribe-streaming` and `@aws-sdk/polly-request-presigner`. Then the whole v2 package is added on top:

"@aws-sdk/client-polly": "^3.303.0",
"@aws-sdk/client-transcribe-streaming": "^3.303.0",
"@aws-sdk/polly-request-presigner": "^3.303.0",
"aws-sdk": "^2.1348.0",

So one integration carries two generations of the AWS SDK at once. The three v3 clients cover Polly synthesis, streaming transcription and request presigning, so whatever v2 is still doing, it is doing something those three names do not cover.

The scripts are short enough to list:

"dev": "vite",
"build": "tsc && vite build",
"preview": "vite preview",
"format": "prettier --write \"src/**/*.{ts,tsx,js,jsx,json,css,scss,md}\""

There is no test script, no lint script, no typecheck script and no clean script. Type checking happens only as the first half of `build`, which means the first thing that would catch a type error is a full production build.

The lockfile matches the declared package manager. `[email protected]` is pinned in `packageManager` and the tree carries `bun.lock` with no npm or yarn lockfile, and the Dockerfile installs with `bun install --frozen-lockfile`.

The tutorial configures synthesis and never Azure recognition

The setup guide has three steps. The first is the OpenAI key, entered under Settings in the Chat section, with a link out to a third-party tutorial on obtaining one. The second and third are both optional synthesis providers, both configured under the Synthesis section: Azure TTS takes an Azure Region and Azure Access Key, and Amazon Polly takes an AWS Region, an AWS Access Key ID and a Secret Access Key, with the note that the key should carry the `AmazonPollyFullAccess` policy.

What is missing is the recognition half. The feature list advertises speech recognition through both a built-in path and an integration with Azure Speech Services, and the Azure SDK package is present. But both optional steps sit under Synthesis, and no step anywhere tells you how to point recognition at Azure. A reader who wants cloud recognition rather than the browser's own has the package and no procedure.

The Polly step is the most precise thing in the guide, down to naming the exact managed policy the key needs, which makes the omission on the recognition side look like an oversight rather than a decision.

Two smaller gaps in the same document. The screenshots section is an HTML table holding three empty cells, so it renders as a blank strip, and the README is mirrored in Chinese at `docs/README.zh.md` alongside a developer guide and a changelog.

Editorial conclusion

Use speechgpt if you want a private, per-browser way to talk to ChatGPT and you are willing to supply your own key through the app's own settings screen. Two things to settle first. Never deploy the published Docker image expecting it to work with your credentials, because both documented commands skip the step that passes any, and a self-hosted nginx deployment has nowhere else to keep a key except the browser bundle that every visitor downloads. And note the name collision: speechgpt is also the name of an unrelated speech-language-model research project, which is what most people searching the term are looking for. If that is you, this repository is not it.

Frequently asked questions

Official sources

1. hahahumble/speechgpt on GitHub
2. License: MIT
3. Project website
4. README
5. Releases