Self-Hosted Test Case Management: What You Actually Take On

A security reviewer asks a simple question. Where does the test case data live, and who else can read it? For a lot of teams, that is the moment the tool choice stops being casual.

That question is what sends people searching for self hosted test case management. The usual next move is to look for an open source option, because open source sounds like the answer to a question about control. It is not, quite. Two separate decisions hide under that phrase, and only one of them costs you real work every week. This post separates them, then prices the expensive one honestly.

Open source and self-hosted are not the same decision

Open source is a question about the licence. It tells you what you are allowed to do with the code: read it, change it, run it, pass it on. That is a legal answer.

Self-hosted is a question about deployment. It tells you which computers the software runs on, and who keeps them alive. That is an operational answer.

A tool can be one without the other, and plenty are. Some open source projects have no supported way to install them yourself. Some closed products ship an on-premise build you can run in your own data centre.

Here is the short version. Open source decides whether anyone can take the software away from you. Self-hosting decides who gets paged when it stops responding at 6pm on a Friday.

If you want the licence half argued properly, we covered it in what open source actually has to mean in this category.

Why teams actually self-host

Almost nobody self-hosts on principle. In practice there are four reasons, and it helps to know which one is yours, because they carry different amounts of work.

• Data residency. A contract or a regulation says the data stays in a particular country, or inside your own network.
• A security review you cannot pass otherwise. The reviewer wants to know exactly what leaves the building. Running it yourself is the shortest path to a yes.
• Cost at seat count. Per seat pricing is fine at twelve people. At a hundred and forty it becomes a line somebody questions every renewal.
• Not wanting a vendor to hold the record. Your test cases and run history describe how your product behaves and what you shipped.

The first two are hard requirements. The last two are preferences, and preferences should be weighed against the bill below.

The bill nobody puts in the comparison

None of what follows is exotic. Most engineering teams already do all of it for something else. It is simply work that used to be somebody else's, and it never appears on a pricing page.

A database with your name on it

The tool needs Postgres, and now Postgres is yours. Someone owns its version, its settings and its disk. That person is the one who notices when the volume crosses 40 GB and nobody has looked at retention in a year.

Backups, and restores you have actually practised

A backup you have never restored is a hope, not a backup.

The job has three parts:

• Take the backup on a schedule.
• Store it somewhere the same outage cannot reach.
• Restore it into a scratch environment often enough to know the procedure works.

Teams almost always get the first part right. The third part is where the unpleasant surprises live. Try it once a quarter and write the date down.

Upgrades and the migrations inside them

New versions arrive, and some of them change the database schema.

That means reading the release notes before you pull the image. It means running the migration against a copy first. It means picking a window where a failed upgrade is recoverable.

This is an hour of attention every month or two, not a full time job. But it is an hour that belongs to a named person, or it does not happen.

Version pinning matters here. If a project only publishes a rolling tag, you cannot choose when to take a change. You get whatever landed upstream.

Certificates, attachments and the small stuff

Three things that look trivial and are not:

• TLS certificates. They expire. Automate renewal, or you find out on the day.
• Attachment storage. Screenshots and logs on test runs grow faster than anyone predicts.
• Access. Single sign on, or an account list somebody prunes when people leave.

Who gets paged

This is the real cost, and it is a people cost.

Picture a release held on a Thursday afternoon. The team needs to check what the regression suite said last week, and the server is not responding. Who fixes it?

If the honest answer is "we would ask around", you do not have an owner yet. Get one before you migrate, not after.

What a one command install actually removes

A single compose file is a real kindness. It gets you from nothing to a running system in an afternoon. It removes a genuine class of pain: dependency versions, service wiring, and the first hour of configuration guesswork.

What it does not remove is everything after day one.

It does not take your backups. It does not run your migrations. It does not renew a certificate, watch a disk, or answer a page.

Treat an easy install as evidence that a project respects your time. Do not treat it as evidence the operational work went away.

When self-hosting is the wrong answer

Three situations where paying somebody to run it is simply the better call:

• A team of three. The hours you would spend on backups and upgrades are hours nobody has.
• No compliance driver. If nothing requires the data on your hardware, you are buying control you will not use.
• Nobody who wants to own a database. Infrastructure needs a willing owner, not a volunteer nominated in a meeting.

There is a fourth version worth naming. Some teams self-host to save money, then spend more in engineering hours than the subscription cost. Do that arithmetic before, not after.

The point is that you should get to choose. A tool that can only be hosted, or only be self-hosted, has already chosen for you.

The question that only exists when you self-host

If the tool drafts test cases with AI, self-hosting raises a question hosted users never have to ask. The software is on your server. Where does the model call go?

Three things to establish before you commit:

• Whose account the request is billed to, yours or the vendor's.
• Which provider receives the prompt, and therefore your test case content.
• Whether the feature can be switched off entirely if a reviewer says no.

A self-hosted tool that quietly routes prompts through a vendor account has undone part of the reason you self-hosted. We wrote about the sane arrangement in bring your own API key.

The self-hostable options you will actually find

Search this category and the same names come back. Everything below was checked on 25 August 2026.

TestLink

The long lived one. GPL-2.0, written in PHP, around 1.6k GitHub stars. It is still maintained, which competing pages often get wrong. Version 1.9.20 is the last of the 1.9.x line, a 2.x line is in development, and the maintainer posted progress on 6 December 2025.

The catch is the exit. Its XML export carries case structure reasonably well, and keeps almost no run history. If eleven months of results are why you keep the tool, check the export before you plan a move.

Kiwi TCMS

The active one. GPL-2.0, roughly 1.2k GitHub stars, over 500,000 container pulls, and version 16.3 shipped on 24 August 2026. This is a healthy project and it deserves to be described as one.

The thing to understand is the shape of the free tier. The project documents all of it openly on its own site:

• The Community Edition container displays ads from EthicalAds inside the instance you host. Ad free images come with the Self Support subscription at 25 dollars a month, per their post of 20 August 2025.
• Builds are x86_64 only, so an Apple Silicon laptop or a Graviton instance is not covered.
• It is rolling release, with no version tagged images, so you cannot pin a version.
• Multi-tenancy sits in the Enterprise plan at 600 dollars a month, per their features page and their post of 18 February 2026.

None of that is hidden, and charging for support is a legitimate way to fund a project. It is simply worth knowing before you build a year of history in it.

Tesbo

Ours, so read this paragraph accordingly. Apache 2.0, the complete product self-hosted on your own Postgres, and no feature held back for a paid tier. Your AI provider keys stay in your account.

What it does not do is run your tests. Tesbo manages and drafts the cases. The framework, the runners and the pipeline stay yours. For the wider argument about what the record is for, we made it in the record a release rests on.

A short checklist before you commit

Take whatever shortlist you have and ask five questions:

• Can I run the complete product myself, with nothing reserved for a hosted plan?
• Which CPU architectures are built, and are version tagged images available?
• Does the running instance display or send anything I did not put there?
• If I leave later, does the export carry run history, or only the cases?
• Who on my team owns the database, the backups and the upgrades, by name?

The last question decides it. Everything else is research. That one is a commitment.

If the answers point toward moving, our migration plan post covers what to carry across and in what order.