Self-hosted load testing: on your infrastructure, data in your network

Spitfire is a load testing and performance testing platform that runs on your own servers. The controller, the database and the runners that generate the load sit in your data center, your private cloud or your AWS/Azure VPC. Test definitions, connection details and results never leave your network.

Why run load tests on your own infrastructure

A load test touches the most sensitive parts of a system: sign-in flows, payment APIs, databases, Kafka topics. The test definition holds addresses, user names, tokens and sometimes records that look like real data. The results show where and at which load the system struggles. Sending any of that to an outside service is, in many organizations, something a security and compliance review has to approve.

With a self-hosted installation the question does not come up. And because the load is generated inside the network, you can test internal services, databases and message queues that are not exposed to the internet, directly; you do not open your test environment to the outside.

Your data stays in your network

• The controller, the Postgres database and the runners run on your servers.
• Test definitions, data files, connection details and results are never sent to Spitfire or to third parties.
• Connection passwords, tokens and client certificate keys are encrypted with AES-256-GCM in the database; tests use a connection by name and never see the password.
• You set the retention periods: one for per-second data, run logs and failed request samples, one for whole runs (at least 7 days) and one for the audit log (at least 30 days).

The license is verified offline

The license key is signed and verified inside the installation without going online; there is no license server to phone home to. That is why Spitfire also works in air-gapped networks. The only outbound call the product makes on its own is reading the signed release list on spitfire.tr once a day; SPITFIRE_UPDATE_CHECK=off turns it off.

No extra charges for test time, virtual-user hours or metric volume: you generate the load on your own servers, and the license price is fixed.

Runners on your infrastructure: Docker, Kubernetes, Windows

Installing is one command. On a single machine, Docker brings up Postgres, the controller, the web UI and two runners together:

curl -fsSL https://spitfire.tr/install.sh | bash -s -- docker

The kubernetes mode installs the same into the current kubectl context. Pods run as non-root, with a read-only root filesystem, no capabilities and the RuntimeDefault seccomp profile; NetworkPolicies let only the controller reach Postgres and only the installation's own runners reach the internal runner port.

• On-demand runners (Kubernetes). If you do not want load generators running all the time, the controller starts the missing runners as pods of the same image when a run asks for more than are idle, and deletes them when it ends.
• Load from other locations. A runner installs with one command on a server in another city or cloud region (with Docker or without it, as a systemd unit or a Windows service). One run's load is split across locations by percent.
• No inbound ports. Remote runners dial out to the controller; the connection uses TLS and the runner checks the controller's key against a SHA-256 pin. Runners join with a revocable token.
• Signed updates. Releases are signed with Ed25519; runners verify the signature before running a new release. Running the install command again updates in place; when the version changes, it dumps the database first.

By your organization's rules: identity, permissions, audit

Users sign in with the company identity: OpenID Connect (Entra ID, Okta, Google, Keycloak) or LDAP / Active Directory. Roles and groups are mapped from the identity provider; users see only their groups' tests, and running a test is a separate right per group. An append-only audit log keeps who did what, when and from where, and exports as CSV. In tests that touch production, SQL and MongoDB writes, dangerous Redis commands and HTTP requests that change data are flagged; the run does not start until the person starting it has seen the list and confirmed.

Single sign-on and reading the audit log are in the paid plans; every testing feature and protocol is open in the free edition too.

After installing

Tests are built in the web editor without code; HTTP, gRPC, WebSocket, Kafka, SQL, MQTT, AMQP, Redis and MongoDB are built in. The same installation includes synthetic monitoring of user journeys on production and an OpenTelemetry connection that aligns your systems' own traces, metrics and logs with the load stages; they run in your network too.

Frequently asked