LogChimp is a self-hosted feedback board with a roadmapping layer

Posts, boards and roadmaps, with the branding yours

The feature list in the README is short, and each item is a product decision rather than a technical one. The branding is customizable, so a team can run the tool under its own name and colours rather than as a branded service. Posts are created, which is the core loop, a customer or a teammate writes something up and it becomes a record. Posts are organised by boards and roadmaps, which is the part that distinguishes the tool from a plain feedback inbox, since a board is a category and a roadmap is a statement about what is planned, and a post belongs to both. There is a dashboard, described in the list as powerful, which is where the counts of what has come in live. The design goal is secure by design and self-hosted, and the project describes itself as an open source alternative to Canny, ProductBoard and UserJot, which is a useful frame because those three products are known and the differences in scope are the differences in what is missing.

A monorepo with an API package and a theme package

The repository is a pnpm workspace with a `packages/` directory, and the root manifest is private, named `logchimp` at version 0.9.0. The two packages the root scripts name are the API, `@logchimp/api`, and a theme, `@logchimp/theme`. The `server:dev` script filters the workspace down to the API package and runs its dev script, `server:start` starts it, and `build:theme` builds the theme package on its own, which tells you the theme is a separate artifact from the server rather than something compiled into it. Formatting is handled by biome, at version 2.5.14, with a `biome:format` script that writes across the repository, and the tree also holds a `biome.jsonc` configuration file, a `.prettierrc` style toolchain is absent, and the dev dependencies include lefthook for git hooks and nodemon for watching. The engine field is the strictest line in the manifest, node greater than or equal to 24 and less than 25, which is a deliberate choice that keeps the runtime uniform across the development machines and the deployed containers.

Deployment paths: Docker, Railway and a devcontainer

The getting started section is short and points at the deployment documentation, which covers self-hosting on Ubuntu and a one click deploy for cloud hosting. The repository carries the pieces for all of those routes. There is a `docker/` directory for the images, a `railway.json` for that particular hosting platform, and a `Makefile` at the root that holds the developer commands rather than the build. For people who would rather not set up a local stack at all, the README advertises a Gitpod badge for a ready to code workspace, and the tree has a `.devcontainer/` directory plus a link to GitHub Codespaces, so the development environment can be started in the browser with the same configuration the project uses. The `.nvmrc` file pins the Node version, and the `.npmrc` and `.config/` directories hold registry and tool configuration. The `.gitmodules` entry in the tree suggests at least one dependency is pulled in as a git submodule, which is worth knowing before a build fails on a fresh clone.

The integration test target tells you what the server needs

The most useful file in the repository for an engineer evaluating it is the Makefile, because the integration test target spells out the environment the server expects. The variables are named after their purpose, and the block begins like this:

LOGCHIMP_SECRET_KEY="secret-key" \
LOGCHIMP_DB_HOST=localhost \
LOGCHIMP_DB_PORT=5432 \
LOGCHIMP_VALKEY_URL=localhost:6379

Alongside those are `LOGCHIMP_WEB_URL` pointing at the web server on port 3000, the database name, user and password, and a set of `LOGCHIMP_MAIL_` variables for a mail host on port 1025, which is the port a local mail catcher listens on. So the service is a Node API talking to a PostgreSQL database, to Valkey for caching and queues, and to an SMTP server for email. The target sets `NODE_ENV` to testing and `SKIP_EE_TESTS` to false, which tells you there is a set of tests for an edition of the product that can be skipped, and then runs vitest with a separate integration configuration against a single spec file. The environment is a good proxy for the architecture, since every variable here is a service the application depends on in production as well.

End to end tests run against a live API

The second target in the Makefile is the end to end suite, and it runs from the `packages/e2e` directory with Playwright. It sets a base URL for the web application on port 3000, an API URL on port 8000, and an owner email address for the account the tests sign in with, then runs `playwright test --ui`, so the suite is meant to be watched while it runs rather than executed blind. The separation of the two ports is worth noting, since it tells you the API is a separate process from the web front end in development, which is the shape you want if you plan to scale them independently. The presence of an owner email in the environment suggests the tests provision or assume an initial account, which is a small operational detail that matters when you try the suite yourself. The tree also holds a `lighthouserc.json` and a `codacy-analysis.yml`, so there is a performance budget and a static analysis pass in the wider tooling, and the `content/` directory suggests that documentation content is kept in the repository rather than in a separate system.

Contributing here means getting sign-off first

The contributing section is unusually prescriptive, and anyone planning a pull request should read it before writing code. There are three steps: read the contributing guide, discuss the idea in the public channels, on GitHub or Discord, before starting development, with no private direct messages, and then get approval from a core team member. The stated reason is to make sure the work does not conflict with work already in progress and to prevent duplicated or conflicting contributions, which is a reasonable motive for a project with a small core team. The practical effect for a contributor is that a large pull request opened without prior discussion is likely to be turned away, so the Discord is not a nicety but a prerequisite. The project also runs a help wanted label, an OpenCollective for funding, a Discord server, and a code of conduct file, all of which point to a project organised around a small maintainer group rather than a wide contributor base.

Licence, agent policy files and the release numbering

Two things in the tree are worth a second look before you build on the project. The first is licensing. The repository records a custom licence that GitHub cannot classify, with the terms in the LICENSE file, so the permissions are not the standard MIT or Apache text and the file is the only place to read them. The second is the collection of policy and tooling files. There is an `AI_POLICY.md`, a `CLAUDE.md`, an `AGENT.md`, a `.coderabbit.yaml` and a `.cursorignore`, which together say that the project has thought about how coding agents are used in its development, and a `SECURITY.md` for reporting vulnerabilities and a `CODE_OF_CONDUCT.md`. The tooling is modern in the usual ways, with renovate for dependency updates, biome for formatting, lefthook for hooks and a GitHub Actions workflow for tests. On versions, the releases are v0.9.2 and v0.8.5 on 2026-09-05 and v0.9.1 on 2026-07-20, so the project is shipping regularly, and the last push to the repository was on 2026-10-19.

Editorial conclusion

LogChimp suits a product team that wants a feedback board it can host itself, with the branding under its own control and the data in its own database, and it suits a developer who wants to read how a self-hosted SaaS replacement is put together, since the environment variables and the test targets document the required services precisely. It is a poor fit if you need the integrations of the commercial products it compares itself to, since the README lists six features and does not mention them, and it is a poor fit if you cannot accept a custom licence, since the repository records one that GitHub cannot classify. Before you adopt it, check three things: the terms in the LICENSE file, the Node version your machine has, since the root manifest requires Node 24 and will not accept 25, and which parts of the commercial feature list you actually need, because the open source version is a board with roadmaps and a dashboard, not a full analytics suite.

Frequently asked questions

Official sources

1. Issues
2. logchimp/logchimp on GitHub
3. Project website
4. README
5. Releases