Spitfire

Spitfire release notes

Your installation tells you about a new release itself: admins see its notes and the update command for that installation at the top of the UI. The command backs up the database first and keeps the settings (Updating).

0.32.0 · 2026-10-10latest

  • Trace drill-down on the Backend tab: click a test request's trace id to open its spans as a waterfall (service, operation, duration, error, database statement). Spans come from Spitfire's OTLP receiver, otherwise from the run's Tempo or Jaeger connection; when the trace is not found, it says so.
  • Where the time went: from the test requests' traces, each load stage shows which service and database the time was spent in (span self time) as a share; the request's time outside the trace (network, load balancer) is its own row. The breaking point finding names the component whose share grew most, with the measured values (e.g. orders-db 12% → 71%). Shares are computed from the sampled (slowest and failed) requests.

0.31.0 · 2026-10-10

  • Browser step: next to the protocol load, a few real browser (headless Chromium) VUs take a user journey (open the page, click, type, wait, check the text) and measure what the user sees: LCP, CLS, INP, TTFB and load time. The Browser card on the run page colours them with Google's thresholds and says when a busy runner (browser_lag) makes them unreliable.
  • New image algebransoft/spitfire:<version>-browser: runners with Chromium label themselves browser, and runs with browser steps go only to them. The Runners page offers this image when adding a runner. License: browser VUs per run, free 1, Growth 5, Scale 20, Enterprise unlimited.

0.30.0 · 2026-10-10

  • Performance budgets and PR/MR comments on the free edition: licenses without these features (the free edition, Project pass, Quarter, monthly subscriptions) save budgets on 1 test and --pr-comment works on 1 repository. The repository is registered by the first comment; an installation admin resets it on the License page. No limit on the yearly plans and Enterprise. This needs the 0.30.0 CLI too; older CLIs still skip the comment on the free edition.

0.29.0 · 2026-10-10

  • The way to upgrade: limit messages open the right part of the buy page (add-on packs for users, virtual users and requests/s on a paid key, the upgrade for the other limits, the plans on the free edition). On the License page an installation admin opens the buy page with the key through Upgrade the plan, Buy add-on packs and Renew: the page fills in the key and credits the time left. The limit hit and the key travel after the address's #, which goes to no server; Spitfire sends nothing anywhere.

0.28.0 · 2026-10-10

  • Streaming the audit log to a SIEM (Enterprise): Audit log → Streaming to a SIEM. Syslog (RFC 5424; TLS, TCP or UDP) or a signed webhook (X-Spitfire-Signature). Entries go as they are recorded, in order and at least once; when the target cannot be reached it retries from where it stopped, and nothing is lost on a controller restart. Every event is hash-chained to the previous one, so the receiver can verify that nothing was left out or changed. The audit table stays append-only.

0.27.0 · 2026-10-10

  • SCIM 2.0 provisioning (Enterprise): Okta, Entra ID and other identity providers create, update and deactivate users and manage group memberships (Single sign-on page → SCIM). A deactivated user's sessions, mobile sign-in and API tokens stop working at once. New users are created with the chosen SSO method in the chosen workspace; a deleted account stays disabled with its tests and audit trail. The last enabled admin cannot be deactivated; every change is audited.

0.26.0 · 2026-10-10

  • HTTP/3 (QUIC): pick it as the HTTP version in the test options; HTTP and GraphQL steps go over QUIC (for CDNs and servers with HTTP/3 on). Timings are the same; the QUIC handshake shows as both connecting and TLS time. No fallback to HTTP/2.
  • MQTT 5: with version 5 on an MQTT connection, publishes and requests get user properties, content type and message expiry; an incoming message's user properties reach checks and extractors as headers. Request/reply matches by correlation data: only the request's own reply is accepted, late replies to earlier requests are not. 3.1.1 stays the default.

0.25.0 · 2026-10-10

  • AWS SQS / SNS step: send to a queue (FIFO group and deduplication IDs, delay, message attributes), receive with long polling and delete (or keep), and publish to an SNS topic. Sent messages are stamped; receive steps measure sqs_e2e_latency for the same runner's messages.
  • AWS connection type: region and an access key (stored encrypted) or the machine's own credentials (environment, profile, IAM role; only an installation admin can turn this on); a custom endpoint for LocalStack, ElasticMQ or a VPC endpoint.

0.24.0 · 2026-10-10

  • NATS step: core publish, subscribe (shared with a queue group) and request/reply; publish to JetStream (measured to the stream's ack) and consume from a pull consumer (a durable consumer shared by the runner's VUs, created to start from new messages when missing). Publishes are stamped: steps that wait for messages or consume from JetStream measure nats_e2e_latency for the same runner's messages (as with Kafka).
  • NATS connection type: servers; user/password, token, NKey seed or a .creds file (stored encrypted); TLS; shared connections per runner or one per VU; JetStream domain.

0.23.0 · 2026-10-10

  • GraphQL step: a POST with the query, variables (JSON, templates allowed) and operation name. A response with errors fails the step even with HTTP 200, and the first error message shows in the error samples (can be turned off for expected partial results). "Load schema" lists the root fields with introspection and fills in the query and example variables for the field you pick. Steps with a mutation need the write confirmation; subscriptions are not supported.
  • The API import reads GraphQL: give the endpoint as the address (read with introspection) or upload an introspection result; every query and mutation you pick becomes a GraphQL step, and mutations ask for confirmation as operations that change data.

0.22.0 · 2026-10-10

  • SAML 2.0 single sign-on: sign in with ADFS, Entra ID, Okta, Keycloak and other SAML identity providers (Single sign-on page → SAML 2.0). The identity provider gets the entity ID and the ACS, or the SP metadata; the IdP's metadata comes from its URL or as XML. Sign-in always starts at Spitfire: the response's signature, audience and validity are checked, an encrypted assertion is opened, and responses Spitfire did not ask for are refused. As with OIDC: e-mail domains, allowed and admin groups, group sync and accounts created on first sign-in.

0.21.3 · 2026-10-10

  • Full backup and restore: ./install.sh docker --backup FILE (Kubernetes: kubernetes --backup) writes the database and the installation's keys (SPITFIRE_SECRET_KEY included) to one file encrypted with a passphrase you choose; --restore FILE restores it on this or a new machine after installing. The current database is backed up first; a newer release's backup is refused on an older installation. Works on a Helm installation too.
  • Docs: the Spitfire GitLab template under CI/CD (include remote + extends; the CLI comes from your controller and its SHA-256 is checked, with the merge request comment and the summaries).

0.21.2 · 2026-10-10

  • Helm chart: Spitfire now installs with Helm too (helm repo add spitfire https://spitfire.tr/download/helm). The same pieces and security settings as the installer; the keys are generated on the first install, kept on upgrades and left by uninstall. On a Helm installation the Version card shows helm upgrade as the update command.
  • Docs: "With Helm" under Installation; the Spitfire GitHub Action under CI/CD (taner-akdemir/spitfire-action@v1: the run, the pull request comment and the job summary in one step); a ready-made Grafana dashboard for the Prometheus metrics under Schedules and monitoring.

0.21.1 · 2026-10-09

  • A threshold filtered on a location: when no runner of the run is in it, the warning at the start of the run now says what happens: the threshold measures nothing; at the end a count is 0 and any other statistic fails with "no data". It used to say the threshold would pass, so a typo in a location name showed only as a failed run.

0.21.0 · 2026-10-09

  • Documentation is now inside Spitfire: "Documentation" in the menu (under Help). An order-of-work roadmap from installing to CI/CD, installation and licence, users and access, runners, the test editor, load model and thresholds, test data, runs and results, every protocol (SQL query mix, query suggestions from the schema and the SSH tunnel included), importing, CI/CD, schedules and synthetic monitoring, version comparison, observability, mocks/chaos/capacity and troubleshooting; Turkish and English, 26 pages, more than 220 screenshots. Works on offline installations too.
  • The ? button in every page header opens that screen's documentation in a side panel (at the right section). Search the docs with Cmd/Ctrl+K.
  • A WebSocket step marked as changing data now needs the explicit confirmation when a run, dry run, schedule, monitor or comparison starts, like SQL, MongoDB, Redis and HTTP writes (it used to start without it).

0.20.0 · 2026-10-08

  • Licenses: Project pass, Quarter, Growth and Scale keys can now also be signed by the web shop's admin panel, with a separate, limited panel key. Spitfire accepts them for at most 3 years, with the plan's built-in limits plus the add-on packs bought and the plan's own features, and refuses a key that claims more. Monthly subscription, Enterprise and agency keys cannot be issued with it. The License page and the support bundle show "Issued by: panel". Earlier versions refuse panel-issued keys, so updating is recommended.

0.19.1 · 2026-10-08

  • Query suggestions from the schema: a foreign key column's suggested value range now comes from the table it points at (orders.customer_id ranges over the customers, not the orders). Before, most lookups asked for rows that do not exist.

0.19.0 · 2026-10-08

  • Query suggestions from the schema (installation admins only): Connections → "Suggest from schema". From your own Spitfire server, Spitfire reads your database's catalog (schemas, tables, columns, primary keys, indexes, foreign keys, row estimates; never table data) and suggests SELECTs from it: lookup by id, by an indexed column, foreign key joins, pagination and counts. Each suggestion is checked with EXPLAIN (the query itself never runs) and full table scans are flagged; the ones you pick become a query mix step or separate steps. PostgreSQL, MySQL/MariaDB, SQL Server and Oracle.
  • Consent first: before the first read the admin reads and accepts a consent text; who agreed, when, from which IP and browser, for which connection, with which text version, which scope and which warnings were shown is stored in the database and in the audit log. A new consent is asked when the connection's address, user, tunnel or production flag changes, when the scope widens or the text changes; a consent can be revoked (the record stays).
  • Privilege check: the connected user's privileges are read; read-only shows green, write privileges orange, superuser/admin a red warning plus an extra checkbox. A ready script creating a least-privilege read-only user is shown for each database. SQL connections gain a "production" flag that brings a strong warning.
  • Optional sample values (with a separate consent): a bounded sample of real key values is taken from a table into a data file for the parameters; the values stay on your server.
  • SSH tunnel for SQL connections (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle): reach the database through a bastion with a key or a password. The server's host key is always verified ("trust on first use" shows the fingerprint for you to confirm); passwords and keys are stored encrypted and never returned by the API. The tunnel works on the controller and on the runners during load tests. Only installation admins may change SSH settings.

0.18.0 · 2026-10-08

  • SQL query mix: up to 200 weighted queries in one step; each iteration runs one, picked by weight. Each query's count, share, p50/p95/p99 and error rate show separately on the run page, in the HTML/PDF report and the CLI summary; a threshold can target one query ("filter": {"check": "<name>"}).
  • SQL bulk add: paste statements or pick a .sql file; they are split by PostgreSQL, MySQL/MariaDB, SQL Server (GO) and Oracle (/) rules and listed with line numbers and read/write kind. A repeated statement is taken once with its count as the weight; writes come unticked. Output: one query mix step, or one step per statement.
  • Import from production statistics: paste pg_stat_statements or MySQL performance_schema digests as CSV/TSV, or (admins) read them read-only through the connection; the weight is the call count, parameters bind to a CSV column or fake data.
  • SQL write protection rewritten: it follows each database's own rules (MySQL # comments, PostgreSQL nested comments and $ strings, SQL Server [names] and GO, Oracle q'' strings); a write counts only where a statement starts, so replace() or a column named update no longer makes a read a write. FOR KEY SHARE, LOCK IN SHARE MODE and SQL Server lock hints are caught too. On SQL Server and Oracle a warning says reads do not run in a read-only transaction.
  • Support bundle: "Download support bundle" on the System events page — controller and runner logs, version and install details, settings with secrets removed, the license status (not the key), the last 30 days of events and a summary of recent failed runs in one zip. Its contents are listed before the download; nothing is sent anywhere on its own. When the UI is down: ./install.sh --support-bundle or install.ps1 -SupportBundle.
  • System events (installation admins): panics, server errors, runners connecting and dropping, failed runs, the license, the update check, the database, SSO/LDAP and notification channel failures, kept 30 days and filterable.
  • Error code: on a server error the UI shows an "Error code" (with a copy button); the same code finds the request in the log and the support bundle.
  • Panics no longer bring the controller or a runner down: an API request answers 500 with an error code, background jobs restart, and a panic in a protocol driver counts as a failed request while the runner keeps going.
  • The controller log is also written to the data volume (20 MiB × 5; SPITFIRE_LOG_FILE, SPITFIRE_LOG_MAX_SIZE_MB, SPITFIRE_LOG_MAX_FILES); the runner's --log-file now rotates too. Existing installations get this with the update command.

0.17.6 · 2026-10-08

  • License ending banner: yearly licenses show the ending banner 30 days before the end; a monthly subscription 7 days before its renewal and a one-time month 7 days before its end (before: 5 days for the subscription, 30 days for the one-time month).

0.17.5 · 2026-10-08

  • Comparative runs (version A/B) are out of preview: the "Preview" badge is gone. The feature and its license rules are unchanged.

0.17.4 · 2026-10-08

  • Monthly subscription: the note on the License page is corrected: if a payment does not go through, the installation returns to the free edition's limits 5 days after the period end (the note wrongly said 7 days; the behaviour is unchanged).
  • The install scripts also show the free key link at the end: Spitfire runs 14 days without a key, then you get the key by e-mail at spitfire.tr/en/free-key.
  • Observability: the Prometheus connection's "Query API" option is gone; the connection uses the Prometheus HTTP API and the systems that serve it (Grafana Mimir, Thanos, VictoriaMetrics). If a connection was saved with that option, point its URL at a Prometheus-compatible query endpoint.

0.17.3 · 2026-10-07

  • Monthly subscription: the License page shows the next renewal day, and 5 days before it a banner says "Your subscription renews automatically from your card on {date}"; when the period is over you are reminded to paste the new month's key. A month that was not paid now returns to the free edition's limits 5 days after the period end (1 day of grace on monthly keys); nothing is deleted.
  • Yearly and one-time licenses show the ending banner in the last 30 days (14 before). Hover the info icon on a banner to see what happens and what to do.

0.17.2 · 2026-10-07

  • The grace after a monthly subscription key ends is now 3 days instead of 14. A monthly key already runs 7 days past the period end, so a month that was not paid returns to the free edition's limits after about 10 days. Yearly and one-time licenses keep their 14 days.

0.17.1 · 2026-10-07

  • Feedback: the user menu has "Send feedback". The link opens the form on spitfire.tr in your own browser; Spitfire itself sends nothing. Tell us what is missing, what works for you or what to do next.
  • The License page names the one-time monthly plans correctly: Growth 1 month and Scale 1 month (a 30-day Scale key used to show as "Scale yearly"; its term and limits were already right).

0.17.0 · 2026-10-05

  • gRPC streams: besides unary, server-streaming, client-streaming and bidirectional methods can be called, with the schema from server reflection or .proto files. Options: a list of messages or a repeated message, a pause between messages, ending after N responses or a duration. New metrics: time to first message, per-message latency for bidi, the gap between responses, messages sent and received; all accept thresholds, and the run page has a "gRPC streams" table.
  • Kafka end-to-end latency and consumer lag: produced records are stamped, and when consumed on the same runner the time from produce to consume is measured (p50/p95/p99). Consumer group lag is watched every 2 seconds during the run: the test's own group and any group you name in lagGroups, such as your real service's group. Polling is read-only and never touches offsets. Lag accepts thresholds and shows on the run page's Kafka card, in reports and in comparisons.

0.16.0 · 2026-10-05

  • Scale plans: Scale yearly and Scale monthly. 15 users, 10,000 VUs, 50,000 requests/s, 8-hour runs, 30 runners, 6 locations and 3 concurrent runs. With the monthly subscription a new Scale monthly key arrives by e-mail every month.
  • Concurrent-run limit: how many test runs may be active at once is now part of the license. Free edition and Growth plans 1, Scale 3, Enterprise unlimited. A comparative run (all its arms and rounds) and an A/A calibration count as one run; synthetic monitor checks don't count. A start over the limit is refused with a clear message, and a scheduled run is skipped and recorded. Paid keys issued before this limit have no concurrent-run limit. The License page also shows how many runs are active now.

0.15.0 · 2026-10-05

  • Sequential comparison mode: with a single environment, or environments that share resources, the two releases take turns on the same environment (A, B, A, B; 2 rounds by default, up to 5). You switch the release: between turns Spitfire waits and tells you with a run.switch_needed webhook; confirm in the UI, with "spitfire cloud continue" or an API call. With a version endpoint on the environment it sees the switch itself. If no switch comes within 30 minutes (configurable) the comparison is invalid.
  • In sequential mode the verdict card says "sequential comparison" and the uncertainty band is wider: the difference between rounds goes into the interval, so the band is at least 1.4 times as wide as in concurrent mode. The shared-infrastructure warning switches to sequential mode in one click.
  • CLI: spitfire cloud run --compare ... --compare-mode sequential [--rounds N] [--switch-timeout 30m] [--auto-switch]; Enter on a terminal also confirms the switch. A scheduled sequential comparison on one environment needs a version endpoint.

0.14.0 · 2026-10-04

  • Comparative runs in CI: spitfire cloud run "<test>" --compare A=<env>,B=<env> --label-a v2.3 --label-b <version> runs both arms at once, prints the per-step difference and answers with its exit code: 0 better or no difference, 98 worse, 97 invalid (an arm failed, or the pre-check failed with --strict), 99 a threshold breach in arm B. Inconclusive exits 0 by default, 98 with --fail-on-inconclusive. GitHub Actions and GitLab CI examples are in the README.
  • Scheduled comparative runs: a schedule can compare two environments instead of starting a plain run. Comparisons from CI and schedules come with Growth yearly and Enterprise (compare_ci); starting one in the web UI is unchanged.
  • A new run.compared event when a comparison ends: the verdict, the three largest differences and their confidence intervals go out by webhook, and Slack, Teams, e-mail (with the PDF) and SMS channels are notified. "Only problems" channels hear worse and invalid only. Existing channels get the event; JSON webhook receivers will see a new event type, which can be switched off per channel.
  • PR/MR comment: "v2.4 vs v2.3: worse. checkout p95 +26% (±4%)." Comparative report: HTML and PDF with the verdict card on the first page, then the difference table; share links keep working after the arm runs are deleted.

0.13.1 · 2026-10-04

  • Growth monthly subscription keys: with the monthly subscription a new key arrives by e-mail for every month paid and is entered on the License page. These keys unlock the Growth limits and comparative runs and are valid for at most 40 days; the License page shows the plan as "Growth monthly". Yearly, free and other keys work as before.

0.13.0 · 2026-10-04

  • Comparative runs, A/A calibration: while both environments run the same version, "Calibrate" runs a short comparison and records the environments' natural difference per step. Later comparisons show the raw, calibration and corrected differences; the verdict uses the corrected one and the acceptable threshold can't be narrower than the calibration's noise band. The verdict card says when there is no calibration, when it is older than 30 days or made with another test version.
  • Closer to the root cause: when a run's threshold breaks or a breakpoint test breaks, the resource series at that moment are ranked by their jumps and saturation signals (CPU, memory, connection pool, queue) and a measured finding is written: "The system broke at 560 VUs; at the same time the orders-db connection pool filled up and checkout CPU went from 41% to 97%." Spitfire says only what happened at the same time, never why.
  • Resource series on the run charts: a series from Prometheus or OTLP (e.g. pod CPU) is drawn over the run's own charts, aligned with the load stages. The Prometheus connection also works with Grafana Mimir; token-in-header auth added.
  • Mobile: encrypted push when a threshold breaks or a spike happens during a run, when a synthetic monitor goes down and when a comparison comes out worse; high-priority abort from the app (POST /runs/{id}/abort); approving data-changing steps from the phone with biometric verification, recorded in the audit log.

0.12.0 · 2026-10-04

  • Comparative runs, equivalence check: before starting, the chosen runners send 20 light requests to each environment (GET or HEAD only) and show reachability, median response time, TCP connect time, TLS and HTTP version side by side, with warnings on differences ("environment B is 18 ms further from the runners"). Environments gain declared fields (CPU, memory, pod count, database version and data volume, cache state, environments they share resources with); a warning appears when both use the same database or server. An optional version endpoint (JSONPath, header or plain text) reads each arm's version at the start; when both match it offers to record an A/A test. Warnings and versions are kept with the comparison and shown on the verdict card.

0.11.0 · 2026-10-04

  • SMS notification channel (Integrations → Notification channels → SMS (HTTP)): sends through any SMS service's HTTP API or your own SMS gateway, also on a network closed off from the internet. The URL, method (GET/POST), headers and body (form, JSON or raw text) are defined by a template; placeholders such as {phone}, {phones}, {message} and {run_url} are encoded correctly. Success means 2xx plus, optionally, a text the response must or must not contain. Secrets are sealed, numbers are masked in logs, and an hourly SMS cap (20 by default) keeps costs in check. The form previews the request with secrets hidden and shows how many SMS parts a message takes; the test SMS shows the service's answer. By default it sends on problems only.
  • Slack, Teams and e-mail notifications now give a synthetic monitor's failure reason in the installation's language.
  • Fixes: validation messages show the variable as {{name}}; thresholds below a millisecond show their value in notifications instead of "0 ms".

0.10.0 · 2026-10-03

  • Comparative runs: per-step p50, p95 and p99 differences now come with a confidence interval (bootstrap, 95% by default; 90%, 95% or 99% in the comparison dialog), e.g. "+27% (±3%)". The error-rate difference uses a two-proportion test. When an interval crosses the acceptable-difference threshold the step is "inconclusive" and a longer run is suggested; the overall verdict is better, no difference, worse or inconclusive. The comparison page explains how to read the results.
  • The comparison page is tidier: in the step and stage tables p95 sits in one cell ("219 → 268 ms"), the difference and its confidence interval stacked, p50 and p99 in a row's details. Rows that mix steps of very different latency (whole run, stages) show no p50 interval. In the comparison dialog arm A starts on the latest normal run's environment, and numbers follow the UI language.

0.9.0 · 2026-10-03

  • Comparative runs (preview): test the old and new version of a release in two environments at the same time with the same load. Every runner splits its VUs equally between the two arms, load stages change on both arms at the same instant, and a comparison is marked invalid if an arm drops. The live screen overlays A and B with the current difference; the result shows per-step and per-stage differences, warm-up excluded, and a threshold verdict: better, no difference or worse. On a test's page: Run → Comparative run. Confidence intervals, A/A calibration, CI and sequential mode come in later releases.
  • In a comparative run the license limits apply to both arms together; the free edition has 1 comparative run a month. Comparative runs need current runners; runners update themselves.
  • Fix: the breakpoint test looked at roughly a step's 1st percentile instead of its p95, so a slow tail never broke a step. It now decides on p95.

0.8.0 · 2026-10-03

  • A license's term now starts on the day its key is first entered on an installation; new keys must be entered within 30 days of being issued. Earlier keys still run from their issue date. New keys also work on older Spitfire versions.
  • The License page shows the plan, activation date, end date, days left, add-ons and the plan's features; the key ID can be copied for upgrades and renewals on the buy page.
  • Admins see a yellow banner 14 days before the end and a red one once the grace period starts; it can be dismissed for the day.
  • A renewal key starts its new term the day after the old end date; Growth add-ons (users, VUs and requests/s, run length, runners and locations) are added to the plan's limits.
  • Synthetic monitoring, performance budgets and PR/MR comments come with Growth yearly and Enterprise. Project pass and Quarter have the free edition's synthetic monitoring (1 monitor, at most every 15 minutes). The check looks at the key's feature list, not the plan name; earlier paid keys without a feature list have everything on.
  • The Turkish UI keeps technical terms as engineers say them: SSO, endpoint, backend, observability, fault injection, dry run, uptime, runner token, header, body.

0.7.1 · 2026-10-03

  • Synthetic monitoring: why a check failed or was slow is now written in the language of the UI and of the notifications (e.g. "1 of 5 checks failed"); it used to appear in English in the Turkish UI too. The English text in webhooks is unchanged.
  • Error rate charts show values below 1% with two decimals, so the axis labels no longer repeat.
  • In the English UI the buy link on the License page goes to the English purchase page.

0.7.0 · 2026-10-03

  • Synthetic monitoring: a test runs on production at low load every 1, 5, 15 or 60 minutes. Only a summary is kept (success, step durations, an error sample), not a full run. The monitoring dashboard shows uptime, step duration trends and the latest failures. Consecutive failures or a slow step send one alert to your notification channels, and a "recovered" message when it is back. Tests that change data need an explicit confirmation. The free edition has 1 monitor (at most every 15 minutes).
  • Performance check per pull request: the test run in CI compares itself with the reference run and comments on the GitHub pull request or GitLab merge request (p95, p99 and error rate per step; the same comment is updated on every push). A breached per-step performance budget fails the run. The test page charts the p95 trend of recent runs by commit or version tag.
  • Toward the root cause with OpenTelemetry: Spitfire installs no agent; it reads the system's own data. Your OTel Collector can export to Spitfire over OTLP, or Spitfire queries Prometheus, Tempo, Jaeger and Loki. Traces, metrics and logs of the run window are matched with the load stages; findings say only what the data shows. A new Backend tab on the run page. Adding a W3C traceparent to requests is a test setting (off by default).
  • Mock services: test doubles of outside services such as payment, SMS and cargo, with configurable latency, error rate and templated responses. Templates for iyzico, PayTR, a generic SMS provider and a generic cargo API. They run inside the controller (SPITFIRE_MOCK_ADDR) or as a separate `spitfire mock`.
  • Turkish test data: scenario variables such as {{fake.tckn}}, {{fake.iban}}, {{fake.phone}}, {{fake.fullName}}, {{fake.city}}, and "Generate data" on the Data files page for a CSV. The values pass the checks but belong to no real person or account.
  • Agency workspaces: several client workspaces in one installation. Tests, connections, secrets, results, schedules, monitors and notification channels are isolated between them. Report branding per workspace (logo, company name, colour). Everything that exists moves to the Default workspace; a single-workspace installation looks the same. The number of workspaces comes with the license.
  • Tests from real traffic: the endpoint mix and arrival rates are derived from access logs (nginx, ALB/ELB, CSV) or trace exports, and a test is generated. Logs are not stored; token, password and session-like values are removed while reading.
  • Capacity estimate: from a breakpoint run, "about N instances for X concurrent users", written as an estimate with its assumptions.
  • Fault injection under load (Kubernetes): delete selected pods or add network latency during a run and measure the recovery time. Off by default; an installation admin chooses the allowed namespaces, every run asks for confirmation again, and it is recorded in the audit log.
  • Fixes: for tests with data-changing HTTP steps, the run dialog and the editor's try run did not show the confirmation, so such tests could not be started from the UI. The threshold that aborted a run did not reach the run page and the CLI (exit code 97).

0.6.0 · 2026-10-03

  • Plans: a license key now carries its plan (Project pass 30 days, Quarter 90 days, Growth yearly, Enterprise yearly). The License page shows the plan, its term and its limits; payment is one-off, with no automatic renewal.
  • New free edition limits: 1 active user, 100 concurrent VUs, 500 requests/s, 15-minute runs, 1 runner and 1 location, 7 days of results, 1 scheduled test, 1 notification channel. SSO/LDAP and the audit log are in the paid plans; the free edition's PDF and shared reports say "Made with Spitfire Free". Every protocol and CI pass/fail stay open in every edition.
  • A 30-day transition for existing free installations: the previous limits and features stay until then, and the app shows the end date. Afterwards nothing is deleted: extra users become read-only, extra scheduled tests and notification channels pause, SSO settings are kept but not used.
  • Free license key: sent by e-mail from spitfire.tr/en/free-key and verified offline; Spitfire sends no data anywhere. An installation without a key runs for its first 14 days, then needs a free or paid key to start new runs; tests and results are kept.

0.5.20 · 2026-10-03

  • The image moved: Spitfire is now algebransoft/spitfire on Docker Hub. The install command and updates use the new address on their own; systems installed under the old name switch when updated to this release, and --rollback pulls earlier releases from the new address too. The runner, gate and CI examples in the UI show the new name; update remote runners and CI steps that name the image to algebransoft/spitfire.
  • The ready-made connection for a single product is gone from the Integrations page; integrations are now plain webhooks, OTLP and Prometheus. Webhook and OTLP settings made through it keep working as they are and are edited on the Integrations page.

0.5.19 · 2026-10-02

  • E-mails now go out as HTML too: run notifications with a bar in the result's colour, a metrics table and an Open the run button; the password reset and the SMTP test look the same. The plain-text version stays in the mail (clients without HTML show it) and the run's PDF report is attached as before. There are no remote images: opening a mail calls nobody and it shows complete on a network closed off from the internet.

0.5.18 · 2026-10-02

  • Forgot password, on the sign-in page and in the mobile app. With e-mail set up (Integrations → E-mail and the public address) the user gets a one-time link valid for 30 minutes; otherwise the request shows on the Users page and an admin sets a temporary password. The reply is the same for every address and never tells whether an account exists.
  • A password an admin sets for someone else is now temporary by default: at the next sign-in the user picks their own before anything else (can be turned off on the Users page).
  • Users change their own password from Change password in the user menu. Every password change ends all sessions of the account and is written to the audit log.
  • When nobody can sign in (the only admin forgot their password), on the controller's host: spitfire-controller reset-password <email> (Docker: docker compose … exec controller, Kubernetes: kubectl exec). Installation guide → Forgotten passwords.
  • After an update the UI no longer opens a stale cached page that 404s: index.html is revalidated on every load, versioned files are cached for good.

0.5.17 · 2026-10-01

  • Mobile notification groundwork (Infrastructure → Mobile & Gate, admin): run events such as started, finished and failed reach the phones of users who may see the test. Each notification is encrypted per phone (X25519 + AES-256-GCM) and carries only the test name, result and status, no measurements or targets. The spitfire.tr relay in between cannot read it. Off by default and free.
  • Spitfire Gate: where the controller cannot reach the internet, another machine that can carries the notifications. The gate only connects outward (to the controller and the relay), installs like a runner with install-gate.sh and stops when its token is revoked. A controller with internet access needs no gate and sends the notifications itself (honouring HTTPS_PROXY).
  • SSO for the mobile app: OIDC sign-in returns to the app (spitfire://auth). The code is bound to the PKCE verifier of the app that started the sign-in, so another app that catches it cannot use it.
  • The mobile app itself (live runs, Stop, results, findings) will be announced when it is in the stores; this release prepares the server side.

0.5.16 · 2026-10-01

  • On-demand runners on Kubernetes: with install.sh kubernetes --on-demand-runners N, when a run asks for more runners than are idle the rest start as pods, the run starts once they connect and the pods are deleted when it ends; with --runners 0 no load generator stays up. The Run dialog suggests a runner count from the test's peak VUs. The controller gets pod rights only in its own namespace and only while the option is on.
  • Bulk import: select several k6 scripts, JMeter plans or Spitfire tests in Tests → Open file; each is converted, validated and listed with its report, and the ones you pick are saved as tests. A whole folder on the command line: spitfire convert <folder> -o tests/ -r report.csv.
  • The k6 converter now handles check(http.get(...), {...}) (the request inside check).
  • Kubernetes install fixes: a fresh install without a proxy stopped silently at step 2, and an update reset the NodePort and service type to the defaults. Both are fixed.
  • The English UI shows run progress as "55%" instead of "%55".

0.5.15 · 2026-10-01

  • Dark theme: the UI now opens in a dark theme by default (warm black background, light text, orange accents). The sun/moon button in the top bar switches to the light theme; the choice is remembered in that browser. Charts and status colours are tuned for both themes.
  • Brand colours: the logo and favicon match spitfire.tr; buttons, the active menu item and links use the Algebran Soft orange (#E1672B). PDF/HTML report headers are orange too.
  • Slack and Teams notifications: the "warning" stripe is now amber, so it is not mistaken for the brand orange.

0.5.14 · 2026-10-01

  • Open k6 and JMeter tests: Tests → Open file turns a k6 script (.js, .ts) or a JMeter plan (.jmx) into a Spitfire test and opens it in the editor. Load model, requests, headers and bodies, checks and assertions, values taken from responses, think times, thresholds and variables are converted; the file is read, never run. What has no equivalent (loops, conditions, custom metrics, data files, non-HTTP requests) is reported with its line number.
  • Find the breaking point: from the Run dialog, one scenario's load climbs in steps; each step is judged on its own p95 and error rate, and the first that fails stops the run. The run page states the capacity ("met the criteria at 200 iterations/s, not at 230"), the step table and why; when virtual users ran out, it says that this is not the system's limit.
  • Findings: a finished run's page lists what its own numbers show: a clearly slowest step, kinds of errors (5xx, 429, other 4xx, timeouts, refused connections, DNS/TLS), throughput that stopped following the load, iterations that could not start, long connection setup, a gap between locations, failed checks, a regression against the baseline, a long latency tail. A rule fires only when the effect is clear and never claims a cause inside the system.
  • Environments: on the editor's Environments tab each environment (staging, production…) gives variables their values and maps the steps' connections to others of the same type. The Run and Schedule dialogs pick the environment, scale the load by a percentage and change variables for that run only; the run records and shows what it used. CLI: --env, --scale, --var.

0.5.13 · 2026-09-30

  • Regression alerts against the baseline: when a test has a baseline run, every finished run is compared with it (p95, p99, error rate, requests/s; with the test's tolerances). Slack, Teams and e-mail messages list what got worse; a clear regression also sends the new run.regressed event (off by default on new channels). You hear that a nightly test slowed down before any threshold breaks.
  • Failed request samples: the run page shows a few failed requests per step and outcome (target, error, failed check, a few response headers, the first 2 KB of the body). Tokens in the address are masked, cookies are never kept, steps that do not fail cost nothing; errorSamples "off" in the test's options turns them off.
  • Test version history: versions, who saved them and the diff with the current one on the test page; an old version is restored as a new one (history is kept).
  • Client certificates (mTLS) and private CAs: a new Client certificate type under Connections; HTTP, WebSocket and SSE steps pick it. The key is stored encrypted and never enters the test definition; saving checks the certificate and key belong together, the Test button checks it has not expired.
  • Data retention setting (License page): days kept for per-second data and logs, runs (at least 7; baselines are never deleted) and the audit log (at least 30). The page shows what would be deleted before you save. The audit log stays append-only: only this pass may delete entries older than 30 days, and it records that it did.
  • Tests → Open JSON: a test definition file (e.g. from spitfire.tr/en/examples) opens in the new-test editor.

0.5.12 · 2026-09-30

  • Behaviour changes (read before updating): a threshold that measured nothing now fails the run (a CI gate no longer turns green on a step that never ran); SSO sessions end after 24 hours and password sessions after 30 days, however often they are refreshed; a password inside a Mongo/AMQP/MQTT URL is refused (use the encrypted password field); gRPC steps use 8 connections per runner by default ('connections' on the connection); a user sees only the data files their groups' tests use.
  • Results: a data binding draws rows only for the scenarios that use it, and exhausted unique data stops only the scenarios that read it. A Host header set on a step is sent. A redirected request's duration covers every hop. SQL reads include the wait for a pooled connection. A value that could not be extracted falls back to its default instead of keeping the previous iteration's. A run's final rows are never lost, and a run no longer stays 'running'.
  • Robustness: a crash inside a step fails that iteration, not the runner. A runner that reconnects during a run has its measurements merged in full. WebSocket ask takes only messages after the request, and the buffer is capped at 32 MB; a WebSocket/Kafka address that changes every iteration no longer piles up connections. The ramping-vus chart counts VUs still finishing an iteration.
  • Security: a stored secret (SMTP/LDAP password, OIDC secret, webhook secret and headers, OTLP headers) must be entered again when its destination host changes. CSV exports are protected against formula injection. /metrics shows non-admins only their groups' runs. SSO sign-in starts are rate limited per address.
  • Interface: a series hidden in a live chart's legend and the tooltip stay put. Leaving the test editor with unsaved changes asks first. If someone saved the test after you opened it, your save is refused instead of overwriting theirs. A failed background refresh keeps the last data. Signing out clears the cache. Editing a schedule keeps its location split and labels. The group, compare and notification test pickers list more than 200 tests.
  • Other: a schedule whose owner is disabled or whose test is archived fails once and is turned off (an archived test's schedule never fires). A connection that tests use cannot be renamed (change the tests first). Webhook delivery history is kept to the last 200 per webhook.

0.5.11 · 2026-09-30

  • Automatic runner updates: with the Runners page switch on (off by default), runners installed without Docker update themselves as soon as they are idle when the controller carries a newer signed release. One at a time per location, never one in a run; a release that failed on a runner is not tried on it again. The audit log shows them as 'system (auto-update)'.
  • A runner that is being updated is no longer handed a new run (manual updates included).

0.5.10 · 2026-09-30

  • Undoing an update: ~/spitfire/install.sh docker --rollback (Kubernetes: kubernetes --rollback; Windows: -Rollback) first dumps the current database, then restores the newest dump and starts the release that took it. Changes made after that dump are lost; running it again undoes the rollback.
  • Pre-update dumps now record the image that took them; the backup message shows the rollback command.

0.5.9 · 2026-09-30

  • Runners installed without Docker (systemd, the Windows service) update themselves: 'Update' next to an older runner on the Runners page ('Update all' when there are several). The runner downloads the new release from the controller over the gRPC port, checks Spitfire's signature itself, accepts nothing unsigned or older, and restarts; a runner in a run is not updated.
  • Existing runners installed without Docker get this after running their install command once more. Docker and Kubernetes runners keep updating with their image.

0.5.8 · 2026-09-30

  • A 'Version and updates' card on the License page: installed version, install kind, the last check's result (and why it failed), outbound proxy, 'Check now' and the update command for this installation.
  • The release list is signed: a list whose signature does not hold is not shown, so a fake 'security update' notice cannot reach admins.
  • Corporate proxies: the install command passes HTTPS_PROXY, HTTP_PROXY and NO_PROXY on to the controller (Docker, Windows, Kubernetes); the update check, webhooks and SSO go out through it.

0.5.7 · 2026-09-30

  • Update notice: the controller looks at spitfire.tr once a day; when a newer release is out, admins see its notes and the update command for this installation in the UI (SPITFIRE_UPDATE_CHECK=off turns it off; only the version number is sent).
  • The Runners page marks runners older than the controller as 'older release'.

0.5.6 · 2026-09-30

  • The session key lives in a cookie scripts cannot read (HttpOnly); when the session ends the UI returns to sign-in.
  • A page that fails shows its error alone; the menu stays.
  • The UI loads faster: pages load separately, first load down from 1.5 MB to ~0.6 MB; fonts and icons ship with it (no request to Google).
  • Form labels are tied to their fields (screen readers).

0.5.5 · 2026-09-30security

  • Security: a runner whose token is revoked leaves after its run; X-Forwarded-* only from proxies (SPITFIRE_TRUSTED_PROXIES); the UI is served with a CSP; share links are rate-limited.
  • An update to another release dumps the database first (backups/*.dump).
  • Webhooks and notifications go through a durable queue; a restart loses none.
  • Stopping the controller stops active runs and stores their results.
  • Kubernetes: non-root, read-only pods with NetworkPolicies.
  • A saturated runner puts a warning in the run; /metrics also shows the controller's own health; JSON logs.

0.5.4 · 2026-09-30security

  • Security: sign-in attempts are limited per address and per account; concurrent password hashing is capped.
  • A runner that reconnects no longer aborts a healthy run; after a controller restart runners drop the load at once and the end notice goes out.
  • Runs can be stopped and thresholds work even while the database is slow.