Procurement answers, written down.

Who the vendor is

KordLoom LLC, a Texas limited liability company with no outside investors, so the decisions about SwitchTender are made by the people who build it. The continuity questions every vendor review asks are answered below, in writing.

What happens if the vendor disappears

This is the right first question to ask of any vendor, so it has the strongest answer we can give: one that does not require trusting us. The license file verifies offline against a key compiled into the binary, so nothing stops working when our servers do. A lapsed or unrenewable license drops the install to Community and takes nothing: your data, run history, audit chain, receipts, and every Community feature keep working, enforced in the source rather than promised in a slide. The public core's source is public today under BSL 1.1, every release of the public core converts to Apache 2.0 two years after it ships, and the continuity section of the terms accelerates that conversion to immediate if KordLoom ceases business. Your receipts verify forever with the open verifier, which is a separate tool precisely so that proof of what your infrastructure did never depends on this company existing. The paid build is different, as the next paragraph explains.

This is also the answer to source code escrow. Escrow exists to hand you the code, and the right to keep using it, if the vendor goes under. For the public core you already have both: its source is public now, and the continuity clause makes every published version of it Apache 2.0 on the day it triggers, with no escrow agent in between. The paid build's source is not public and we do not offer source escrow for it. Paid features run to the end of your term, and every paid build we delivered keeps running in Community mode after that. If your review needs a continuity arrangement for the paid build, ask, and we will put one in a signed agreement.

Who supports it, and on what clock

Pro and Team support is email support from engineering with defined severities and clocks. On Pro, every report gets a first response within two business days. On Team, Severity 1 and Severity 2 reports get a first response within one business day, and Severity 1 is worked first. A missed Severity 1 clock extends the license term by one month at no charge for each miss. The clocks are set where we can honor them every time. Enterprise puts an SLA on the order form, with its coverage and clocks stated there. The definitions are in the terms, so the commitment is checkable. Self-rescue is deliberately the strongest line: offline verification, one-command backup and restore, and an upgrade path proven in public CI mean the product needs us as little as possible.

How a security report is handled

Reports go to security@switchtender.com and are acknowledged within two business days, a commitment made in the terms. A confirmed vulnerability is fixed in a tagged release and described in the release notes; we do not sit on fixes to batch them, because a known-vulnerable install that thinks it is current is the worst state a security tool can put a customer in.

How you know the binary is ours

Releases are built in public CI from the public repository, signed, and published with checksum manifests and build provenance attestations, so you can verify that the artifact you downloaded was built by the release workflow from the tagged source, not on somebody's laptop. The verification commands are in SECURITY.md. A software bill of materials is generated for every release archive and published beside it as a .sbom.json asset, so your review reads the dependency inventory of the exact artifact you deploy, not a description of it. Every release published from the public repository has both. The paid build is built from the private repository and delivered by presigned link. It ships with a SHA256SUMS manifest signed with cosign, which you verify before install. It does not currently ship a software bill of materials or a build provenance attestation.

How it is tested

Every commit runs the full suite under the race detector, against both storage backends, SQLite and PostgreSQL, and a scheduled job fuzzes every parser in the module, a list a test holds to the source so a new parser cannot be written and quietly never fuzzed. Beyond unit and integration suites, a public end-to-end supertest stands up a real Kubernetes cluster in CI and proves the claims a customer actually relies on: install, RBAC, approvals, evidence, crash recovery with a worker killed mid-run, an in-place upgrade from the previous published release with all data surviving and rolled back again, active-active high availability with one of two replicas killed mid-run while the run completes exactly once and the chain stays unforked, and disaster recovery from a sealed backup restored into a destroyed-and-rebuilt install. It runs on every push to main, its badge is on the repository, and a release cannot publish unless both it and the full CI suite finished green on the exact commit being released: the release workflow refuses otherwise, in code you can read.

Upgrades, backups, and getting out

An upgrade is a binary swap or a Helm upgrade, and the supertest proves the previous release upgrades in place, tokens, history, chain, and receipts intact, before a release can publish; the release gate refuses to publish over a missing or failed run. That proof covers both shapes: the single-node install, upgraded and then rolled back in place with the chain verifying and new work executing on the older binary, and the licensed PostgreSQL shape with its dedicated worker, upgraded in place with the schema reused and nothing a paying customer had taken by it. Backup is one command producing a single sealed file; restore is one command, and the restore reports exactly what it wrote, kind by kind. Getting out is the same honest answer: your data is in SQLite or PostgreSQL you host, exports are open formats, receipts verify with an open tool, and nothing about leaving needs our permission or our uptime.

What data ever reaches the vendor

Nothing, by architecture rather than policy: no telemetry, no license server, no phone-home, no usage reporting, and the terms forbid us adding one to a running agreement. What we ever hold is what you email us: a licensing conversation, a support thread, an invoice contact. The deliberate exceptions are services that only work because data reaches us. A hosted witness, on Team or Enterprise, receives chain heads and counters and nothing else: no run content, host names, credentials, or personal data. Evidence custody, on Enterprise, receives what the order form says before you send anything. For a data-processing review: without those services there is no processing of your infrastructure data to review, and we will complete your DPA or privacy questionnaire on request to say so formally.

Questionnaires, paperwork, and certifications

We complete security questionnaires and vendor-onboarding paperwork for Team and Enterprise purchases, and a W-9 and standard invoice terms, net 30, are available on request. We are not SOC 2 certified today and do not pretend to be: SwitchTender is self-hosted, we hold none of your operational data, and the audit trail the product produces is independently verifiable, which is the control most questionnaires are actually asking about. Where your process needs a document we do not have yet, ask: the honest current answer, in writing, is what this page is for.

The limits, stated plainly

SwitchTender does not claim every change to your infrastructure went through it: anyone holding their own SSH key can change a host behind it, and the receipts prove what SwitchTender ran, not what it never saw. The product documentation states its trust boundaries explicitly rather than rounding them up, because a control whose limits are hidden is not a control. If your review needs those boundaries in detail, the threat model, the vendor risk review, and the continuity doc are written for exactly that reading, and you can ask us the hard version directly.

Questions from a review go to hello@switchtender.com, and we answer them in writing so your file has something to hold.