An AGPL resume builder whose example environment file ships a service-role key

A service-role token and a seeded admin password sit in the tracked environment example

The example environment file is not a list of empty placeholders. It contains a complete Supabase service-role JSON web token, with the role claim, a fixed issue time and a fixed expiry, alongside the matching anonymous token. Below that it seeds an administrator address and a password of Admin123, and it sets a flag that auto-grants the paid subscription so local work skips payment entirely. The file's own framing is that these are the values the Docker path expects, and the documentation's only warning on the subject is a single line telling you to create a local account with credentials you control and not to reuse example credentials in development or production. That warning is correct and easy to miss, because the values look like configuration rather than like a login.

The free plan wants your own key and the trial wants a payment method

The product facts are two sentences and they set the terms plainly. The application is open source and self-hostable, and the free plan supports your own AI provider keys. The paid plan is twenty dollars a month and provides model access funded by the application rather than by you. Underneath, the live demo line adds a third condition in the middle of a row of separators: a payment method is required for the optional trial. So the three states a visitor can be in are a free plan on their own key, a trial that needs a card, and a paid plan on the application's own access. The environment example marks the application's route as the required one, naming an aggregator key as needed for the default models and identifying two of them by name, so the free path is the one that avoids handing the application a key at all.

The documented variables and the example file are not the same set

The configuration step in the documentation shows an environment block, and the example file shows another. The documented block names a database URL, a Supabase URL, a Supabase anonymous key, a Google key, two variables for the auth library, and two Stripe keys. The example file prefixes the Supabase variables for client exposure, adds a service-role key the documentation never mentions, and for the model providers lists only an aggregator key, an Anthropic key and an OpenAI key. The OpenAI one is annotated as retained for compatibility with custom and legacy deployments rather than as a current option, and the Google key from the documentation is absent. So a reader who copies the documented block literally writes variables the shipped example never declares, and a reader who copies the example never sets the auth or database variables the documentation insists on.

The test command hardcodes a package manager store path

supabase db push --db-url=your_supabase_db_url schema.sql

The database step is the ordinary part of the setup. The test script is not. It does not call a test runner by name; it calls a JavaScript file by a fully qualified path four directories deep inside the package manager's own virtual store, with the runner's exact version spelled out inside that path, followed by a glob for test files inside the source tree. That path only exists on a machine where the lockfile was installed with that precise version of the runner, through that package manager. Bump the runner and the script points at a directory that is no longer there; install with the other package manager and the layout does not exist either. The documentation says pnpm is recommended but npm works, and the repository carries both a lockfile and a package manager config file, so the advertised second option is not the one the test command assumes.

An AGPL project with no licence field where a scanner would look

The licence is stated in three places and absent from the fourth. The documentation headline describes the project as free and open source, one of the badges points at the GNU AGPL version 3 text, and the tree contains a licence file with an extension appended to the name. The manifest, which is the only machine-readable place a tool can check, has no licence key at all. It carries a name, a version, a private flag and then goes straight to scripts. For a project whose distribution model depends on the copyleft obligations of that licence, that omission is the kind of gap automated compliance scanning reports first and a human notices last. The file name compounds it slightly, since the conventional names a scanner probes for are the bare word and a text extension.

Seven provider packages, five brand names and one gateway on the critical path

The stack section names five model providers: one for content generation, one for a competing assistant, one for a search company's models, one for a low-cost option and one for fast inference. The manifest carries a provider package for each of those five, and two more: an enterprise cloud variant of the Google package, and a provider adapter for a model aggregator. The example environment file then marks the aggregator key as the required one for the application's default models and names those defaults individually. So the gateway sits on the critical path for the out-of-the-box experience, and it appears nowhere in the stack section, where the reader is shown five direct integrations and no routing layer. The two counts describe different architectures and the documentation only offers one of them.

Two telemetry paths are wired into a tool that stores your employment history

The dependency list contains a resource detector and a Node SDK for distributed tracing, and separately a hosted product-analytics package built for observing model calls. Both are ordinary choices in a commercial SaaS. What makes them worth naming here is the combination with everything else the project says about itself: the application is self-hostable, it is described as having no hidden costs, and the only data it holds is a person's work history, education, skills, salary expectations and the jobs they applied to. A person who reads the pricing paragraph and concludes that nothing leaves their machine would not find either package mentioned in the documentation, since the stack section covers the frontend, the model providers and the database and stops there.

Three deployment targets, four agent configuration files and a shell profile at the root

The top-level tree describes a project being run four different ways. There is a Compose directory for the full local stack, a Helm chart for a Kubernetes deployment, and a Vercel config for a serverless one, and the documentation covers only the first of them. Alongside those sit four artefacts aimed at coding agents: a rules file for one editor, a configuration directory for a second, a directory for a third tool, and an instruction file at the root. Two more entries are out of place. A shell profile is committed at the repository root, which is a developer's own environment rather than anything the application reads, and a markdown file named for tests sits beside the source while the test glob points at files inside the source tree instead.

Editorial conclusion

resume-lm is worth a look if you want an applicant tracking aware resume editor you can run yourself, because the whole stack, a Postgres instance, an auth service, a cache and the app, comes up with one Compose file, and row level security is described as the rule that keeps users to their own rows. It is the wrong choice if you intend to paste a real employment history into a hosted instance without reading what the dependency list does with it, since two telemetry paths are wired in by default. Before you start, read the example environment file end to end, because it contains a service-role token, a seeded admin address and password, and a flag that grants the paid plan locally, and replace all three. Then check whether your package manager matches the one the test script assumes, and note that the documentation's variable names and the file's variable names are not the same set.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. olyaiy/resume-lm on GitHub
4. Project website
5. README