Community and support

Where to get help, report a problem, and follow what's changing. Cobblr is a source-available project you run yourself, so most of this happens in the open on GitHub or from inside your own instance.

Get help

• Read the docs first. The Troubleshooting section covers the common install and runtime snags, and most feature pages under Using Cobblr answer the "how do I" questions.
• GitHub. The code, issues, and discussion all live at github.com/CobblrHQ/core. If the docs don't answer your question, open an issue and describe what you are trying to do.
• The in-app feedback button. Every workspace has one, as a small pill in the corner or a row in the sidebar. On your own instance it does something different from what you might expect, and Feedback on a self-hosted instance below is worth reading before you use it.

Feedback on a self-hosted instance

Feedback you send from inside your own Cobblr stays on your own box. It is saved to that instance and read by whoever administers it, under the operator console's Feedback view. It does not reach the Cobblr project, so nobody outside your instance will answer it. The button says so: on a self-hosted instance it reads Save to this instance rather than "Send feedback".

That is the right behaviour for a tool you run yourself, and it is genuinely useful when other people use your instance: their reports land with you, which is who can act on them.

To get a Cobblr bug to the people who can fix it, use the two buttons that appear underneath on a self-hosted instance:

• Copy report puts a formatted report on your clipboard.
• Open an issue opens a new GitHub issue with the title and body already filled in.

Either way the report carries the context a maintainer would otherwise have to ask for: the page you were on, your browser and window size, and your instance's build, Node and Postgres versions and enabled modules. It deliberately carries nothing that identifies your instance, your users, or your data, because all of it goes public.

Report a bug

Open an issue at github.com/CobblrHQ/core/issues, or use Open an issue in the feedback button to have most of this filled in for you. A good report gets a fix faster:

1. What you did, as concrete steps someone else can repeat.
2. What you expected to happen, and what actually happened.
3. Your setup: how you're running Cobblr (the Docker setup from Self-hosting), your browser, and whether it's on a phone or a desktop.
4. Anything from the logs, if the app showed an error or a container logged one. docker compose logs output is often the deciding clue.

Screenshots help for anything visual. If the bug is in the docs rather than the app, use the Edit this page link at the bottom of any docs page, or open an issue on the docs repository.

This is a small project. Issues are read and worked through as time allows, so a clear, reproducible report is the best way to get yours moving.

Request a feature

Two ways, pick whichever fits:

• Use in-app feedback if the idea is for your own instance and the people on it, since that is where it stays.
• Open an issue on GitHub if you want the Cobblr project to see it, or want it in the open where others can find it, add to it, or say they want it too.

Say what you're trying to accomplish, not only the feature you have in mind. The underlying goal often points at a simpler change, or one that already exists.

Contribute

If you want to fix or build the thing yourself, the Contributing guide covers how changes get in, and the code contribution guide is the checklist a pull request is reviewed against. Doc fixes, bug fixes, and new drivers are all welcome.

Follow along

Cobblr keeps a changelog. New releases and what's in them show up in the app's What's new entry in the account menu, and every change lands in the public repository. Watching or starring the repository is the way to see releases as they ship.