Where does your system break?Self-hosted, on-premise 24/7 load testing and performance testing

No. The controller, runners and results run on your own servers, and the license key is verified offline.

No. A test is built step by step in the web editor. If you prefer, write the same test as a JSON file and run it with the CLI.

Yes. Tests → Open file turns a k6 script or a .jmx plan into a Spitfire test and opens it in the editor; the file is read, not run. Load model, requests, checks, values taken from responses, think times and thresholds are converted; what has no equivalent, like loops, conditions and custom metrics, is reported with its line. Details in the migration guide.

"Find the breaking point" in the Run dialog climbs one scenario's load in steps (say 10, 20, 30… iterations a second) and judges each step on its own numbers against the p95 and error rate you give. The first step that fails stops the run; the run page says "met the criteria at 200 iterations/s, not at 230". If the climb stopped because virtual users ran out, it also says that this is not the system's limit.

Yes. On the test's Environments tab each environment gives its own address and variables and maps the steps' connections to its own (orders-db → orders-db-staging). You pick the environment when starting a run or a schedule and can scale the load (10% for a smoke test); the run shows which environment and scale it used. The test stays one test with one version history.

Yes. In a WebSocket step every virtual user keeps one connection, like a browser tab: it sends a message, waits for the reply or for a message the server pushes (containing a given text), and the message goes to checks and extraction. The connection carries the cookies from login and reconnects on the next step if it drops; the handshake is measured as ws_connecting. An SSE step opens the event stream and reads until the given number of events (by type or content) arrived; the time to the first event is the sse_time_to_first_event metric. Both can have thresholds. More: the WebSocket and SSE load testing guide.

Yes, with the same test; only the load model changes. A load test stays at the expected traffic, a stress test climbs the load to find the limit, a spike test jumps it within seconds and looks at the recovery, and a soak test runs for hours to catch what appears over time, like memory leaks. Run length depends on the license. More: the load, stress, spike and soak testing guide.

A runner whose connection drops and comes back within 10 seconds carries on; if it does not, the run stops, or continues without it if the test says so. If the controller is stopped (an update, a restart), it stops the active runs and stores their results first; if it goes down unexpectedly, the run closes as interrupted when it starts again. Either way the runners drop the load at once and webhook receivers get the end notice. Stop and thresholds work even while the database is slow; if some data could not be stored, the run says so as a warning.

Yes. "Shared iterations" splits a fixed number of iterations among the VUs; "per-VU iterations" has every VU run the same number. The test ends when the work is done, with a max duration as the ceiling. Across several runners the work is split exactly by each runner's share of the VUs. Good for data loading, smoke tests and one-off jobs.

No. Tests → Import API / HAR: give an OpenAPI 3, Swagger 2.0 or Postman v2.x collection, or a HAR recording (browser DevTools → Network → "Save all as HAR"), and pick requests. In a HAR, static files are dropped, tokens and ids become variables automatically, and cookies stay separate per virtual user. Only GET requests are taken by default; POST, PUT/PATCH and DELETE need a per-group approval plus the target host name, the approval is written to the audit log, and the test asks again on every run. More: the OpenAPI and Postman guide.

On the Integrations page, announce run start and end with a webhook and send live metrics over OTLP or Prometheus. Your monitoring can mark the test window from these events and tell symptoms during the test apart from real incidents.

Yes. On the single sign-on page set up your OpenID Connect provider (Entra ID, Okta, Google, Keycloak…) or your LDAP / Active Directory. Accounts can open on first sign-in, or only accounts an admin created may enter; you can limit sign-in to groups, map admin groups to the admin role and sync memberships into Spitfire groups of the same name. Password sign-in can be left to admins only; LDAP passwords are never stored in Spitfire.

Yes. On the test's page, Schedule: pick a cron and time zone; the run starts with the rights of whoever created the schedule. Under Integrations → Notification channels add a Slack, Microsoft Teams, e-mail or SMS channel (SMS works with any SMS service's HTTP API or your own gateway) and turn on "Only notify on problems": you hear when a threshold breaks, a run fails, or a scheduled run does not start (no runners, missed). The e-mail carries the run's PDF report.

On the run page, Report → Download PDF or Share link. The link shows the HTML and PDF report without signing in; it lasts 1–90 days, can be revoked at any time, and every view is written to the audit log. Reports come in Turkish or English.

Create a token under profile menu → API tokens, add it to the pipeline as the SPITFIRE_TOKEN secret, and run spitfire cloud run "Test name" in a step. The CLI comes from the controller or the Docker image; the CI button on a test's page prepares GitHub Actions and GitLab CI steps. The step exits 0 (passed) or 99 (thresholds failed).

Docker or Kubernetes, on amd64 and arm64; Linux, macOS and Windows (Docker Desktop, one PowerShell command). A runner in a remote location can also run without Docker: with systemd on Linux, as a Windows service on Windows.

The code stays valid until the first admin exists and is stored: SPITFIRE_SETUP_CODE in ~/spitfire/deploy/docker/.env on Docker, the spitfire-secrets Secret on Kubernetes. The controller log also prints setup_code=, and re-running the installer shows the same code.

Yes. Save the certificate, the key and, if needed, the private CA to trust once under Connections → Client certificate (mTLS); HTTP, WebSocket and SSE steps pick it under "Client certificate". The key is stored encrypted and never enters the test definition; saving checks the certificate and key belong together, and the Test button checks the certificate has not expired.

You decide: the Data retention setting on the License page keeps per-second chart data, run logs and error samples (90 days by default), whole runs and the audit log for their own number of days; what you leave empty is kept forever. Tests' baseline runs are never deleted, and the page shows what would go before you save. The audit log is append-only: only entries older than 30 days are deleted this way, and the deletion is recorded too. On the free edition per-second results are kept for at most 7 days.

The yearly plans and the one-time month (and Project pass and Quarter licenses bought before) do not renew automatically; we remind you by e-mail 14 and 3 days before the end. When the license ends, a 14-day grace period starts and the application says so. After it Spitfire runs within the free edition's limits (1 user, 1 run at a time, 100 virtual users, 500 requests/s, 15-minute runs, 1 runner and 1 location, 7 days of results, 1 scheduled test, 1 notification channel and 1 synthetic monitor (at most every 15 minutes)); starting new runs needs a free key or a new license. Nothing is deleted: tests, runs and reports stay, extra users become read-only, extra schedules pause, the SSO settings are kept. Paste the new key on the License page and the limits open again at once, without reinstalling.

The application tells you about a new release itself (from a signature-checked release list), and security updates are marked. Updating is the same single install command: the database is backed up first and the settings kept; if anything goes wrong, --rollback returns to the previous release and its data. Runners installed without Docker update themselves from the Runners page or with auto-update.

For the yearly plans and the one-time month, the day you first enter the key on Spitfire's License page. Install a week after you got the key and you still lose no days; just enter it within 30 days of it being issued. The License page shows the activation date, the end and the days left; the key is still verified offline.

It is taken off. Paste your key under “Upgrade my license” on the buy page: upgrade a Project pass or a one-time month within 30 days of issue and all you paid comes off; for the Quarter, Growth and Scale yearly, the value of the days left does (Growth to Scale too). It shows as its own line on the invoice. Days left are rounded up in your favour; the credit never exceeds the new plan's price and nothing is refunded. The new key replaces the old one.

Growth, Scale and Enterprise yearly have a price lock: renew with your current key within the last 30 days before the end and the new year costs what your original order paid (or the list price, if it went down). The lock covers one period. The new period starts the day after the current one ends, so renewing early loses no days.

Price lock: renew your yearly license with your current key in the last 30 days before the end and the new year costs what you first paid, or the list price if it went down. If you bought Growth yearly today for $2,900 incl. taxes, you pay $2,900 incl. taxes again when you renew on time, even if the list price has gone up. The lock covers one period; a license bought as a renewal renews at the current price next time. Synthetic monitoring: your scenario runs on production at low load every 1–60 minutes and alerts you on Slack, Teams, SMS or e-mail when it breaks or slows down; yearly gives 10 monitors on Growth and 30 on Scale, other plans 1. PR comments: the CI run is compared with the baseline run and posted as a pull/merge request comment; a breached per-endpoint performance budget fails the pipeline. Add-on packs: raise the limits without changing plan: +5 users ($419 / year), +2,000 virtual users (+10,000 requests/s) ($749 / year), +4 hours of run length ($299 / year), +5 runners · +2 locations ($499 / year), +10 servers (metrics) ($119 / year), +5 databases (metrics) ($119 / year).

Not necessarily. Growth and Scale yearly take add-on packs: +5 users ($419 / year), +2,000 virtual users (+10,000 requests/s) ($749 / year), +4 hours of run length ($299 / year), +5 runners · +2 locations ($499 / year), +10 servers (metrics) ($119 / year), +5 databases (metrics) ($119 / year); prices incl. taxes. Packs added to a running license are priced for the days left and come with a new key. If Growth with packs comes near the Scale price and fits within Scale's limits, the buy page suggests Scale; if it does not fit, or Scale with packs reaches Enterprise level, it suggests Enterprise.

Prices in US dollars are what you pay; nothing is added at checkout. We are a company in Türkiye and sales abroad are exempt from Turkish VAT, so your invoice shows 0% VAT. Depending on where you are, your business may have to account for VAT or sales tax itself (in the EU, for example, under the reverse charge); your accountant can tell you. Prices in Turkish lira are before VAT (20%), which is added at checkout.

Yes. When the first friend takes a free key with the invite code in your account, you both get a 10% coupon; from the 2nd to the 5th invite yours grows by 5% each time (30% at the 5th). After 5, each invite adds 30 days to a yearly license or 3 days to a one-time month. Details: Invite a friend.

Growth and Scale are bought by card; bank transfer and proforma are not taken on the buy page at the moment. If your organisation pays only by transfer, write to us. Enterprise is sold by quote: quote form; 1 production + 1 test installation, support by e-mail weekdays 09:00–18:00 UTC+3 (Istanbul); 1 business day is the time to a first response, not to a fix.

For one testing period (before a launch or a campaign), the one-time month; for continuous testing (CI, nightly runs), yearly: it costs less a month, and only the yearly plan has price lock, synthetic monitoring, PR comments, add-on packs. Both have the same plan limits. Growth: 5 users, 3 concurrent runs; per run 2,000 virtual users, 10,000 requests/s, 4-hour runs, 10 runners and 3 locations; e-mail support, answered within 2 business days. For several teams, several runs at once or more load, Scale: 15 users, 5 concurrent runs; per run 10,000 virtual users, 50,000 requests/s, 8-hour runs, 30 runners and 6 locations; e-mail support, answered within 1 business day. If you need more than that, unlimited concurrent runs or priority support, Enterprise yearly has no limits, by quote. The yearly and one-time monthly plans are paid once; the license does not renew itself and nothing is charged again. Every testing feature and protocol is open in every edition. Team and organisation features (SSO, audit log, multiple runners) are in the paid plans.

Scale and team features: 1 user, 1 run at a time, 100 virtual users, 500 requests/s, 15-minute runs, 1 runner and 1 location, 7 days of results, 1 scheduled test, 1 notification channel and 1 synthetic monitor (at most every 15 minutes). SSO / LDAP, the audit log and multiple runners are in the paid plans; PDF and shared reports say "Made with Spitfire Free". Every testing feature, all protocols and CI pass/fail are open. 14 days after installing, new runs need a free key: you get it by e-mail, it does not expire and is verified offline. Your tests and results never leave your servers; the only request Spitfire makes on its own is a daily version check that sends just its version number and can be turned off.

With a comparison run. Pick the environment running the old release as A and the one running the new release as B. Spitfire runs the same test against both at the same time, and every runner splits its load evenly between them. The result shows the difference and the verdict for every step: better, no difference, or worse. Version comparison →

Before it starts, Spitfire compares the two environments and warns about the differences it sees. To measure how the environments differ on their own, run a calibration with the same release on both; later comparisons show that difference apart from the result.

Between two runs at different times the network, the caches and the load on shared infrastructure can change. Running both at once spreads those outside effects evenly over the two sides; what is left is the difference the release makes.

Yes. In sequential mode the two releases take turns on the same environment (A, B, A, B); each time you switch the release, Spitfire moves on to the next round.

Yes. Give spitfire cloud run the --compare flag; if the new release is worse the step exits with 98 and the deployment stops.