Deckgauge

The engineering cockpit that never leaves your server

Analytics

Software Engineering

Developer Tools

GitHub

Visit WebsiteSee on Product HuntGithub ⧉Twitter ⧉

Hi Product hunt, I'm Yaniv, founder of CodPal — we do CTO-as-a-service. Every few weeks one of us steps into a new company as its (often fractional) CTO, and the first job is always the same: work out what is actually happening in engineering, fast. Not the version in the status deck. Where delivery is stalling, which teams are overloaded, whether the roadmap matches reality. The problem is that every company is a different puzzle. Some live in Jira, some in Azure DevOps, some in GitHub Issues, and more than one tracked work in a spreadsheet and somebody's memory. You inherit all of it at once, and leadership wants answers in week one. Deckgauge is what we built for ourselves to answer that. It syncs Jira, GitHub, GitLab and Azure DevOps into one Monday-style board, then turns the same history into the things we needed to see: DORA metrics, cycle and review time, WIP, what each team is actually spending its time on, and who is carrying the delivery. Roadmaps are generated from live board status. It let us sit down with a division lead on day one and talk about their plan in their language, instead of asking them to explain their tooling to us first. One thing up front, because it's the fair objection: a per-engineer view can obviously be used to rank and blame people. That isn't why we built it and it isn't how we used it — we wanted it to find the engineer who has gone quiet or is carrying too much, so we could go and help them. The tool doesn't settle that question on its own; whoever is holding it does. But I'd rather argue about that openly than ship it quietly. We've now opened it up. Self-hosted by default — Postgres, ClickHouse, Keycloak, Fastify, Next.js, all in Docker Compose. Your tickets and commit data stay on your own infrastructure and never reach us. Every integration is read-only; nothing is ever written back to Jira. On the licence, since it'll be the first question: FSL-1.1-Apache-2.0. That's source-available rather than OSI open source — read it, run it, modify it and self-host it for anything except building a competing product, and each release converts to Apache 2.0 two years after publication. There's a hosted demo seeded with a fictional company; link and credentials are in the README. It's one shared instance on a small VM, the data is synthetic, and it resets periodically. Rough edges I know about: first sign-in needs a page reload, the demo signs you out after 30 minutes idle, and password reset there isn't wired to a mail server. The self-hosted install is meant to be one command, and I'd really like to know where that breaks on a machine that isn't mine. Happy to get into metric definitions, the ClickHouse schema, or why the board and the analytics share one ingest.