A self-hosted tool for Agile retrospectives and team health checks, developed at the State of Geneva, is now publicly available on GitHub. RetroGemini lets teams run real-time retrospectives while keeping every piece of their feedback on infrastructure they control. According to the project's README on GitHub, the software is already used by around 30 internal teams in the Geneva administration, and it is released into the public domain.
What RetroGemini does
Retrospectives are a regular ritual in Agile and Scrum practice. At the end of a work cycle, team members review what went well, what did not, and what should change. RetroGemini supports this process with structured sessions rather than an open-ended board of sticky notes, according to the repository. Teams can also run team health checks, which give members a regular way to report how they feel about their work and their colleagues.
The project describes its workflow as built for real facilitation. Sessions follow a clear sequence, and the tool keeps follow-up work visible after the meeting ends. Actions, decisions, health check results, and reports remain accessible over time, so a retrospective does not disappear once the call is over.
Collaboration happens in real time, and the interface is available in English and French. For a bilingual public administration or an international company, that language support can matter as much as the feature list.
Why the location of team feedback matters
The repository explains the reasoning behind the project. Candid retrospective feedback can be sensitive, because team members often discuss problems with managers, processes, or colleagues. The developers say that their public administration could not send this kind of feedback to external cloud services, and that motivated the decision to build a tool that runs entirely under the organization's control.
That principle is the core of the project. The application and its data stay on the organization's own servers, and the core application makes no external service calls. It can run on an isolated network, which the README presents as a key requirement for some users.
Who the software is aimed at
The README names several types of organizations that it considers a strong fit:
- Public-sector bodies
- Healthcare providers
- Financial institutions
- Organizations working under strict regulation
- Privacy-conscious companies
- Air-gapped environments with no internet access
It also says that teams who simply prefer to own their tools and data are a good fit. Optional features, including email notifications through SMTP and AI-assisted functions, are disabled unless an administrator configures them. No external service is required at runtime.
Deployment options, from quick test to production
Trying it out
The quickest route is a local Docker setup. According to the repository, users open a browser at localhost on port 8080, create a team, and start a retrospective. A named Docker volume keeps test data across container restarts.
For a one-click trial, the project offers a button that creates a free personal evaluation instance on Render from the latest published Docker image. The repository warns that this option is not suitable for a real team. Render's free web services sleep after 15 minutes without traffic and use an ephemeral filesystem, so the SQLite data is cleared whenever the service sleeps, restarts, or redeploys.
Running it in production
The README lists several steps for production use. Administrators should set a stable session token secret, keep it in a secret manager, and place the application behind an HTTPS reverse proxy before exposing it outside a trusted network. The configuration is handled entirely through environment variables, and a sample file lists the available options.
The project supports two database backends. SQLite suits a simple single-container or single-pod deployment, while PostgreSQL is recommended for production and multi-pod setups. When several pods run at once, the real-time layer can use Redis or the PostgreSQL adapter to keep participants connected to the same session.
Documentation also covers Kubernetes, OpenShift, and Railway. The container runs as a non-root user and exposes health and readiness endpoints for orchestration platforms. On Railway, the README warns that a persistent volume must be attached, or SQLite data will be lost during redeployments.
Under the hood and built-in resilience
The frontend uses React 19, TypeScript, Vite, and Tailwind CSS. Data is stored in SQLite with write-ahead logging or in PostgreSQL. The container is built on Node 26 Alpine.
The project says it is designed to survive rolling updates. Session state is persisted, WebSocket clients reconnect automatically, and participants rejoin their active session. For teams that deploy updates during working hours, this behaviour reduces disruption to a live retrospective.
Quality checks, accessibility, and AI features
According to the repository, every pull request runs linting, TypeScript checks, unit and integration tests, a production build, dependency review, CodeQL analysis, and container vulnerability scanning. Accessibility is also tested on every pull request, using an axe-core run over six screens and an accessibility linting plugin. The project's accessibility document describes what is tested, what has been fixed, and what remains to be done.
The developers say the software was built with extensive help from AI tools, including Gemini, Claude, and Codex. The README is clear that this describes the development process rather than a runtime dependency. The application works without an internet connection or an AI service. Administrators may optionally connect an OpenAI-compatible model for grouping suggestions and summaries, and those features stay off until they are configured.
Outlook for teams and contributors
RetroGemini is an example of a public body publishing software that it uses internally, under a licence that places no conditions on reuse. The Unlicense means that anyone may use, copy, modify, and distribute the code for any purpose. The project invites bug reports, feature requests, translations, documentation improvements, and code contributions, and it asks organizations that deploy the tool to share their experience so others can learn from it.
For teams that have been reluctant to use cloud-based retrospective tools because of data concerns, the release offers a concrete alternative to evaluate. Organizations will still need to weigh the operational cost of hosting the software themselves, including backups, security updates, and infrastructure management.
Related: Lightweight Server Monitoring: Beszel Adds Docker Stats and Alerts · Termix: Free Self-Hosted Server Management Platform Built on Plugins
Comments (0)