kForge — Multi-client software forge and continuous integration

The problem

Forges and continuous-integration engines on the market are built for a single organisation. The day you serve several — because you are a service company, because you have subsidiaries, because each entity must be isolated — you do not configure one more client. You install one more platform.

• Twelve clients means twelve subscriptions, twelve admin consoles, twelve upgrades to schedule, and the same question asked twelve times by your operations team.
• Next to the forge there is almost always a CI engine billed by the minute or by the seat, and a code-analysis tool with its own licence and its own notion of a user.
• Then a spreadsheet, or one more subscription, to produce the deployment metrics you present to the board.
• And an issue tracker that ignores commits, with commits that ignore issues.
• Four products, four notions of a user, four audit trails — and nobody able to answer plainly: “what exactly did this release ship?”

What kForge does

The four products in a single application, with one client model and one installation. Your repositories stay where they are: kForge aggregates them, runs your pipelines, analyses your code, and computes your metrics on what it actually deployed.

Your repositories, whatever the forge

A project aggregates GitHub, GitLab and local repositories — including bare repositories on your own servers, which most tools simply ignore. History, branches, tags, diffs, blame, full-text commit search, and reference comparison across several repositories of the same project. Pull requests and forge issues are mirrored and readable without switching tabs.

• Change tracking: the agent watches the directory of a local repository; polling and signed webhooks (GitHub, GitLab) cover remote ones.
• An issue can be escalated to the parent tenant — from a client to the tenant serving it, for instance — if that parent allows escalations; tenants following it are notified of its status changes.
• A forge issue becomes a kForge issue, with its labels and its history.
• A commit links to an issue, and the issue shows the commits that resolved it.

Continuous integration, nothing reinvented

Stages, jobs in a dependency graph, matrices, execution in a shell, a container, Kubernetes or over SSH. Nine trigger types, including periodic execution of a sandboxed script and URL polling whose state survives a restart.

• Twelve quality gates block a release on test coverage, measured latency, security findings or a regression against a baseline.
• Your pipelines import and export as YAML — and also export to GitHub Actions format. Reversibility is built in from the start.
• The dependency graph of a run is drawn on its page, with the actual order in which jobs ran.
• kForge has no scheduler of its own, no runner of its own, no artefact store of its own: it compiles your pipelines down to the Kore platform, which executes them.

Code analysis, with a life cycle

Twenty-eight built-in analysers, plus your own, grouped into profiles. A finding is not a log line: it has a fingerprint, it is suppressed or deleted durably — the exclusion survives later runs — and its fix is proven from one run to the next. A finding becomes an issue or a risk in a single action, without duplicates.

• A triage tool, not a counter: the value lies in triaging findings, and that is where the effort goes.
• We do not sell static analysis as a vulnerability detector. A static finding is a hypothesis — the engine sees the sink, never the guard sitting just above it. That is why the product focuses on verification rather than volume.

The metrics you present to the board

Deployment frequency, lead time for changes, time to restore service, change failure rate — computed on your real runs, with automatic performance-level ranking.

• And counted on both paths: deployments launched by a pipeline and those launched from the command line.
• A metric that saw only half of reality would be worse than no metric — because it would look credible.
• A page of composable charts tracks pipeline runs and deployments over time, starting from ready-to-add templates.

An AI that works on your code without access to a machine

Most development assistants assume two things: command-line access, and a machine to work on. For many organisations that is precisely what makes AI unacceptable — and the question is quickly settled. kForge takes a different approach: the application exposes 63 tools to an agent, grouped into five business profiles, served by its own API.

None of these five profiles grants a shell or filesystem access. There is no machine to designate, no working directory to open, no system account to create. The agent sees what the API exposes, under the identity of the person driving it, and nothing else. As a result, the assistant becomes usable in production, not only on a developer workstation.

What kForge changes

Who it is for

Frequently asked questions