# lotus asks you to run a shell script and then log in as change_me, and stopped releasing in March 2023

> An open-source pricing and billing engine you host yourself, positioned as a control panel on top of a stack you already own. The install path is three commands ending in a published default password, the release series stopped three and a half years ago, and the root package file is a two-dependency stub.

**uselotus/lotus** — Open Source Pricing & Packaging Infrastructure

- Repository: https://github.com/uselotus/lotus
- Stars: 1,839 · Forks: 137
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/uselotus-lotus

## Three commands, then sign in with the password printed in the README

The self-host path is presented as the only version, and it is genuinely short. Install Docker Desktop and start it, clone and move into the directory in one line:

```sh
git clone https://github.com/uselotus/lotus.git && cd lotus
```

then run the script:

```sh
./scripts/self-host.sh
```

with a note that if the script lacks permission to run, run chmod 755 on it first.

Then step four is the one worth reading twice. You open the homepage at localhost and sign in using the ADMIN_USERNAME and ADMIN_PASSWORD you defined, or the default, which is given in the guide as a code block:

```py
username: change_me
password: change_me
```

So the documented first run of a billing system ends at a login screen with a password published in its own README. The credentials live in an environment file at env/.env.prod, which the guide points you at afterwards as the optional step. Two things follow from the order of those instructions. The defaults are reachable before anything has been changed, and the file the credentials belong to is named for production rather than for a first run.

Nothing here says the container ports are bound to localhost rather than to the host, so whether that login is reachable from another machine is worth finding out before you start it.

## Three releases in three days in March 2023, and commits as recent as two days ago

The release history is three entries and then silence. Version 0.10.0 was published on 2023-03-21. Version 0.10.1 followed on 2023-03-23, and 0.10.2 followed on the same day, minutes later.

The last recorded push to the repository is dated 2026-10-01, two days before the version of this writing. So the tree is moving and the version is not. Anything you install from the default branch is three and a half years of unreleased work on top of a 0.10.2 tag, and there is no version number in the running system that tells you which side of that line you are on.

Three releases inside forty-eight hours is also the shape of a version being pushed rather than a project being versioned, which is consistent with a small team shipping a migration and cutting two patches on the day it went out.

For an adopter the practical consequence is that the release list is not a useful upgrade path, and neither is the commit log a useful changelog. If you deploy this, pin the commit, and read what changed in the tree between the tag and your commit rather than trusting the version number to describe it.

## The stack list has seven entries and the tree has a few the list never mentions

The tech stack is written as seven lines: React with TypeScript, Postgres with the TimescaleDB extension, Redpanda, Redis, Python with Django, Celery for background jobs, and Go for microservices.

That is an unusual combination in the places it matters. Two datastores that both look like caches for different purposes, one relational and one streaming, plus a time-series extension on the relational one. Two languages in the back end with a job queue between them. And a stream broker where most pricing systems would have none.

The tree adds pieces the list does not mention. There is a go.work and a go.work.sum, so the Go side is a multi-module workspace rather than one service. There is a proxy/ directory, which is a network hop the stack list does not account for and which is the kind of thing that changes where a request can fail. There is a gen/ directory for generated code. There are two compose files, one for development and one for production, and the guide does not say which of them the self-host script uses.

Then the working setup: an editor config, a pre-commit configuration, a Renovate configuration for dependency updates, an app.json, and a directory of design resources.

## The root package file has two dependencies, no name and no workspaces field

The package file at the root of the repository is this:

```json
{
  "dependencies": {
    "lodash": "^4.17.21",
    "react-content-loader": "^6.2.0"
  },
  "devDependencies": {
    "@ant-design/icons": "^5.0.1",
    "@types/lodash": "^4.14.191"
  }
}
```

There is no name, no version, no private flag, no scripts block, and no workspaces declaration. Two runtime dependencies and two development ones, for a project whose stated front end is React with TypeScript. No typescript package, no react package, no build tooling. So this file is not the manifest for the application, and the front end must have its own inside the frontend directory.

Two details point at a package manager setup that is only half declared. A yarn.lock sits at the root, and a lock file at the root normally means workspaces, but this manifest does not declare any. And the development dependencies include an Ant Design icon package while the manifest declares no Ant Design itself, so the icons are a dependency of something this file does not describe.

None of it breaks the product. It does mean the root of the repository does not tell you how to install anything, and the guide's npm-free instructions are all you have.

## The README is a template with empty badge blocks and an empty contributors section

The document is a well-known community template, and it says so in its first line by linking to a pull request against that template. The structure is marked with HTML comments naming the sections: project shields, project logo, getting started, contributing, about the project, and licence.

Several of those sections are empty. The shield block is a row of anchor tags with no images inside them, including a link to make a pull request, a contributors anchor, a stargazers anchor, a Slack invite, the licence file and the commit log. The logo block is a single empty anchor. At the very bottom, after the licence section, there is a contributors graph anchor with no contributors in it.

So the first screen of the README is a row of links to nothing, followed by two paragraphs describing the product. That is a cosmetic problem, but it is worth knowing because a badge row that used to show a build status, a release and a licence would be the first place a reader would look for the answer to the question this repository makes urgent.

The licence itself is stated plainly, distributed under the MIT licence with the file in the tree, and the contributing section points at both a fork-and-pull-request instruction and an external guide.

## The instructions are split across three places, two of which are outside the repository

Self-hosting instructions live on a documentation site under a self-hosting page. Development setup instructions live on the same site under a contributing page. And the repository itself carries a docs directory, a contributing file, a code of conduct and a security file.

So the same two tasks, install this and contribute to this, each have two addresses, and the ones a reader is sent to first are the ones outside the tree. The README's contributing section adds a third option in the form of a feature request template link with a label parameter already filled in, which is a nice touch and also the only place in the document where an issue template is named.

The positioning is stated clearly enough to be useful without the rest of it. Lotus is a pricing and billing engine for deploying, monitoring and experimenting with custom subscriptions, and it describes itself as a flexible and modular control panel on top of an existing quote to cash stack, integrating data from several systems to work out a pricing scheme. The four feature headings are usage-based pricing with flexible prorations, plan management, experimentation tooling covering backtests, A/B tests and forecasts, and integrations with an existing monetisation stack.

None of that describes a replacement for your billing system. It describes a layer that sits above the payments, customer management and data systems you already run.

## Conclusion

Lotus is a serious piece of infrastructure with an MIT licence and a self-host path that works in three commands, and the risk in it is all in that first hour. Change the two credentials before the first sign-in, find out which of the two compose files the self-host script actually uses, and understand that a production compose file plus a published default password is the combination that gets picked up. Then read the release dates rather than the commit dates: three releases in three days in March 2023 and commits two days ago describe two different things, and if you deploy this you are deploying whatever is on the default branch, not 0.10.2. The documentation for both self-hosting and contributing lives outside the repository, which is where to look when the local files stop answering.

## FAQ

### How do you install and run lotus?

Install Docker Desktop and start it, clone the repository and change into the directory in one command, then run the self-hosting script at scripts/self-host.sh, running chmod 755 on it first if the shell refuses. The homepage is then on localhost, and you sign in with the admin username and password you set or with the published default.

### What are the default lotus admin credentials?

The guide gives the default sign-in as the username change_me and the password change_me, taken from the ADMIN_USERNAME and ADMIN_PASSWORD environment values. Those live in a file at env/.env.prod, which the guide points you at afterwards as the optional configuration step.

### What is the latest release of uselotus/lotus?

Version 0.10.2, published on 2023-03-23, half an hour after 0.10.1 on the same day and two days after 0.10.0 on 2023-03-21. The last recorded push to the repository is dated 2026-10-01, so the tree has moved well past the newest tag.

### What is the uselotus/lotus tech stack?

Seven items are listed: React with TypeScript, Postgres with TimescaleDB, Redpanda, Redis, Python with Django, Celery for background jobs, and Go for microservices. The tree also holds a Go workspace file, a proxy directory, generated code, and separate development and production compose files.

### Does lotus replace an existing billing stack?

No. It describes itself as a modular control panel on top of an existing quote to cash stack, integrating with the payments, customer management and data systems you already run. Its self-hosted version is described as currently the only version, with documentation hosted on an external site.

## Sources

- [Issues](https://github.com/uselotus/lotus/issues)
- [License: MIT](https://github.com/uselotus/lotus/blob/main/LICENSE)
- [README](https://github.com/uselotus/lotus/blob/main/README.md)
- [Releases](https://github.com/uselotus/lotus/releases)
- [uselotus/lotus on GitHub](https://github.com/uselotus/lotus)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/uselotus-lotus