Couchers is a community-run hospitality platform, and its code is MIT while its brand is not

A platform, a community and a licence that stops at the code

Couchers.org is described as the next-generation couch surfing platform, and the four words in the project description are the whole proposition. Free forever, because there is no paid tier to move people onto. Community-led, because the people who use it are expected to run it. Non-profit, because the legal entity behind it is a foundation with its own directory in the repository. Modern, which is a claim about the stack rather than the model. The codebase is licensed under the MIT license, and the README says plainly that the code in this repository is licensed under it, allowing anybody to use and redistribute the code with few restrictions. What that licence does not cover is the rest of the intellectual property, which is the subject of a separate section in the same README and is worth reading before anyone builds on top of this.

The repository holds the application and its documentation side by side

The top level of the repository is small and tells you the shape of the project. There is an app/ directory with the application itself, a docs/ directory, a foundation/ directory, AGENTS.md, a .gitlab-ci.yml, a .github/ directory, and editor configuration in .vscode/ and .claude/. The fact that the CI definition is .gitlab-ci.yml while a .github/ directory also exists is the clearest signal about how the project works, because the badges in the README point at gitlab.com/couchers/couchers pipelines and at a coverage report hosted under a couchershq preview domain, so the canonical development happens on GitLab and the GitHub repository is a mirror. For a contributor that distinction matters, because an issue filed in the wrong place can sit untriaged, and the README is explicit about the flow for issues, that a developer will come and triage the issue and add it to the backlog.

The documentation set is the onboarding

The README's overview of documentation is really a table of contents for working on the codebase, and it is unusually complete for a project of this kind. The entries are:

* Getting started with dev: [app/readme.md](app/readme.md) outlines basic steps to get a dev environment set up, start here!
* Architectural overview: [docs/architecture/main.md](docs/architecture/main.md) outlines the basic workings of the app, the different components, core features, and the way they interact.
* Developer Contributor Guide: [docs/contributing.md](docs/contributing.md) explains how we work with this codebase and helps you get up and running with development.

There is more below that line, and the pattern is consistent. The CI and CD documentation is listed separately at docs/cicd.md, which lists the different functionality that is set up and how you can use it to simplify life. The database documentation at docs/database.md covers how to use the database and how to version it with Alembic when new tables or columns are added. There are tips for working with Docker at docs/docker.md, described as a way to work with docker and be less miserable, and a release checklist at docs/release-checklist.md covering the steps that need to be completed for each release. Frontend and backend developers are pointed at separate quick starts, app/web/readme.md and app/backend/readme.md, which tells you the application is split along that line.

Migrations are versioned, and that is the part to read first

The database documentation deserves a paragraph of its own, because the schema is versioned with Alembic and the rule is that you update it when new tables or columns are added. That has consequences for anyone who forks this code, and it is a good example of how a real application differs from a library. There is no single configuration knob to point at a different database; there is a chain of migrations that a deployment has to run in order, and a fork that changes the schema has to add its own migration rather than editing the existing ones. The Docker document exists for the same reason, since the local environment needs the application, its database and its frontend running together, and the README's own tone about being less miserable is a fair signal of how much setup is involved before the first page loads.

Reusing the code means removing the brand

The intellectual property section is the part of this README that most affects a technical decision, so it is worth quoting closely. The source code for the Couchers.org project is licensed under the MIT license, which does not include things like long-form Couchers blog posts or essays, and that licence allows anybody to use and redistribute the code with few restrictions. However, Couchers, Inc. owns, holds exclusive copyrights to, or owns trademarks for, other intellectual property, including the logos, colour schemes, designs and texts that appear on the platform. If you wish to reuse parts of the project, you must make sure to remove this intellectual property, including by rebranding the app, to reduce confusion and uphold the brand of Couchers.org. In practice that means a fork is a real piece of work, not a rename, and the difference in approach between the two routes is clear. A fork inherits the application and its data model and inherits the obligation to strip the brand, while building a new platform inherits nothing and owes nothing.

Translations and volunteer positions are how the work gets done

Two links in the README show how a community-run platform distributes its work. The first is translation, with a request to help translate Couchers.org through translate.couchershq.org and a status widget for the multi-language translation effort. The second is the volunteer positions page, linked from the developer contributor section with the note that you can see and apply to the current volunteer positions. The developer contributor guide is the first thing a new contributor is asked to read, and the README says it explains the workflow, the expectations and how to get started. The framing in the README is a deliberate contrast with the platform it replaces, and the note about chucking us a star in the project description says the same thing from the other side. The repository is not archived, the last push was on 2026-10-20, the default branch is develop, and the project publishes no GitHub releases, so the release checklist in the docs is the only account of how a release happens.

Editorial conclusion

Adopt the Couchers codebase if you want to run a hospitality exchange of your own and are prepared to rebrand it, because the MIT licence lets anybody use, modify and redistribute the code with few restrictions while the trademarks and design assets stay with Couchers, Inc. Do not adopt it as a drop-in for an existing product, since the repository is an application with its own data model, its own community processes and a GitLab hosted pipeline, not a library. Before you start, read the architecture document and the database documentation, and check the volunteer positions page, because the project runs on contributors and says so plainly.

Frequently asked questions

Official sources

1. Couchers-org/couchers on GitHub
2. Issues
3. License: MIT
4. Project website
5. README