# backend-br/vagas: a GitHub issue board for Brazilian backend jobs > backend-br/vagas is not software you install. It is a recruiting board that runs entirely on GitHub issues, with labels for seniority and contract type, and it is aimed at Brazilian backend developers and the companies hiring them. **backend-br/vagas** — Espaço para a divulgação de vagas para desenvolvedores backend via issues do Github. - Repository: https://github.com/backend-br/vagas - Stars: 7,989 · Forks: 201 - Language: Unknown - License: MIT - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/backend-br-vagas ## What backend-br/vagas is, and the problem it removes Most job boards are databases with a web form on top. backend-br/vagas is the opposite: the repository README describes it as "Espaço para a divulgação de vagas para desenvolvedores backend via issues do Github", a space to advertise backend developer openings through GitHub issues. The repository itself contains almost nothing executable. The top level holds .github/, .gitignore, CODE_OF_CONDUCT.md, CONTRIBUTING.md, LICENSE, README.md and a doc/ folder for images. The postings are not files in the tree. They are issues. That choice solves a specific annoyance. A recruiter or a developer who wants to publish a role does not need an account on a job site, a paid listing, or a form that asks for the same data twice. They open an issue on a repository they already have access to. A candidate does not need to register anywhere either. They read the issue, and the conversation happens in the same thread, in public. The audience is narrow on purpose. The topic list names backend, backend-jobs, brasil, emprego, empregos, hiring, jobs, remote-jobs and trabalho-remoto. If you are hiring for frontend, the README points you to frontendbr/vagas instead, and it lists sibling repositories for QA, chat-bot, PHP, .NET, Rust, Kotlin, Vue.js, Android, Flutter, iOS, Go, React, Python and Node.js, plus regional boards for Ceará, Angola and Portugal. This is one node in a family of boards, not a general-purpose product. ## How a posting actually works: issues, labels and subscriptions The mechanism is GitHub's own issue machinery, and the README is explicit about the flow. You open an issue, and you fill in the data following the standard template that the issue generates. The template is the schema. There is no JSON manifest, no YAML front matter, no validation step beyond whatever the template and the maintainers enforce by hand. The second half of the process is labelling. The README asks the poster to state which labels should be added, covering the desired experience level and the form of hiring (contratação). Those labels are the board's only structured filter. A reader who wants senior remote roles has to trust that the labels were applied correctly, because nothing in the repository validates them. Distribution is deliberately passive. The README says you can receive updates by email or through GitHub notifications by clicking Subscribe on the issue you are interested in. There is no digest, no matching algorithm, no alerting service in the repository. If you want to hear about a role, you watch that specific issue. The screenshot in doc/images/subscribe.jpg exists to show where that button is. The README also mentions a second way to read the board: searching and filtering Backend BR postings on openings.dev, at the path /communities/backend-br/vagas. According to the README, each result there still links back to the original issue in this repository. So the canonical record is always the issue; openings.dev is a reading layer over it. ## Posting your first role: open an issue, then ask for labels There is nothing to install. The README gives no CLI, no package, no Docker image and no self-hosting instructions, because the project is a repository of issues rather than a running service. The first real use is opening an issue. Go to the issues page and start a new one. GitHub will pre-fill the standard template that the project provides through its .github/ configuration. ```bash # no install step: the board runs on GitHub issues # open a new issue at: # https://github.com/backend-br/vagas/issues ``` Fill in the generated template with the role details, and in the issue body state which labels you want, naming the experience level and the contract type. The README describes this as informing which labels should be added. What you should see afterwards is an open issue in the list, and once the labels are applied, a posting that readers can find by level and hiring form. If you are the candidate rather than the poster, the equivalent first step is to open an issue you care about and click Subscribe, which the README identifies as the way to get updates by email or GitHub notifications. For filtering across many postings, the README's other route is the openings.dev community page for backend-br, where results link back to the original issues. Before posting anything, read CONTRIBUTING.md. The README points to it as the contribution guidelines, and it is the only place in the repository that can carry rules beyond what the README states. ## Where the issue-as-database model breaks The biggest limitation is that labels are the entire data model. The README asks posters to say which labels to add, but nothing in the repository enforces that a level or contract label is present, correct, or consistent between two postings. A role described as senior in the title and labelled mid-level is not caught by any check. Anyone building a filter on top of this board inherits that noise. There is also no lifecycle. The README does not document closing, expiring or archiving a filled role. An issue that has been filled can stay open, and a reader subscribing to it has no documented signal that the vacancy is gone. Compare that with a conventional board, where a posting has a status field and disappears on a schedule. Notifications do not scale. Subscribing is per issue, so a candidate tracking ten openings is managing ten subscriptions. There is no keyword alert, no saved search inside the repository, and no email digest described in the README. The filtering story lives outside the project, on openings.dev, and the README treats that as a complement rather than a feature of the repository. Finally, the board is public by construction. Every posting, every question and every reply is visible, and it is indexed like any other GitHub issue. A company that wants to keep salary bands, headcount plans or a confidential search out of public view is using the wrong tool. This is a broadcasting channel, not a hiring pipeline. ## How it differs from a conventional job board The obvious alternative is a dedicated job platform, and the README itself points to one: openings.dev, which mirrors and filters the Backend BR postings. The difference in approach matters. A platform like that owns the data. It ingests postings and presents them in its own interface with its own search, and the README notes that each result still leads back to the original issue, which tells you where the source of truth sits. Against a generic platform, backend-br/vagas wins on friction and loses on structure. Posting is free and immediate if you have a GitHub account, and the thread doubles as the application channel, so a candidate can ask a question in public and see the answer. What you give up is everything a database gives you: typed fields, deduplication, expiry, an API you can query programmatically, and any guarantee that two postings are described the same way. Against the sibling boards, the difference is scope rather than mechanism. frontendbr/vagas, pydevbr/vagas, Gommunity/vagas and the rest run the same issue-based model for a different specialism, and backend-pt/vagas and backend-ao/vagas do it for Portugal and Angola. Choosing between them is choosing an audience, not a technology. The README credits frontendbr as the inspiration and states that this page is a fork of theirs, so the pattern is inherited rather than invented here. ## Maintenance, licence and the cost of staying listed The repository is not archived, and the last push was on 2026-08-31, which is recent enough that the board is clearly still receiving activity. That said, the maintenance burden is unusual: there is no code to upgrade, no dependency to patch and no release to track, because the project retrieved no releases. The upgrade cost is zero in the software sense and non-zero in the editorial sense, since the value of the board depends on maintainers applying labels and on posters keeping their issues honest. The licence is MIT, stated in the README and present as a LICENSE file at the top level. For a repository whose content is job postings rather than source code, the practical reading is that the repository's own material is permissively licensed. It says nothing about the terms of any individual job, and it is not a statement about how a company may use the postings. If you plan to republish listings elsewhere, that is a question for the individual posters, not something the MIT text settles. This is a description of what the repository states, not legal advice. Contribution rules live in CONTRIBUTING.md, which the README links as the guidelines to follow, and behaviour expectations live in CODE_OF_CONDUCT.md. Both are files in the repository rather than sections of the README, so anyone posting should read them directly. The README does not document rollback, editing history or a takedown process for a posting that turns out to be wrong. ## Conclusion Adopt backend-br/vagas if you are a backend developer in Brazil who already lives in GitHub notifications, or a company willing to post a role as a public issue and answer questions in the thread. Do not use it if you need structured, machine-readable postings, applicant tracking, or a private hiring funnel; there is no schema and no API beyond what GitHub gives you. Before relying on it, open the issue template, read CONTRIBUTING.md to see what a complete posting looks like, and check whether the maintainers actually apply the level and contract labels you request, because that labelling is the only filter the board offers. ## FAQ ### What is backend-br/vagas? It is a space for advertising backend developer job openings through GitHub issues, as the README describes it. The postings live as issues rather than files, and the repository also links to sibling boards by area, technology and location. ### How do I post a job on backend-br/vagas? Open an issue and fill in the data following the standard template the issue generates, then state which labels should be added, naming the experience level and the form of hiring. The README points to CONTRIBUTING.md for the contribution guidelines. ### How do I get notified about new backend-br/vagas postings? The README says you can receive updates by email or through GitHub notifications by clicking Subscribe on the issue you are interested in. There is no digest or keyword alert in the repository, so tracking several roles means subscribing to several issues. ### Is there a way to search and filter backend-br/vagas postings? The README mentions searching and filtering Backend BR postings on openings.dev at the path /communities/backend-br/vagas, and states that each result still leads to the original issue in this repository. ### Do I need to install anything to use backend-br/vagas? No. The README gives no install, package or self-hosting steps, because the board runs on GitHub issues. You need a GitHub account to open an issue or to subscribe to one. ### What licence does backend-br/vagas use? The README states that it is licensed under MIT, and a LICENSE file sits at the top level of the repository. That covers the repository's own material, not the terms of any individual job posting. ## Sources - [backend-br/vagas on GitHub](https://github.com/backend-br/vagas) - [Issues](https://github.com/backend-br/vagas/issues) - [License: MIT](https://github.com/backend-br/vagas/blob/master/LICENSE) - [README](https://github.com/backend-br/vagas/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/backend-br-vagas