Trust

Security

Stabula runs code that sends traffic on your behalf, and holds the credentials it sends. Here is how both are contained.

The runner is isolated

The single rule the architecture is built around: test logic never runs on the application host. A run generates a script from your structured settings — method, URL, headers, auth, body, assertions — and that script is executed by the official k6 image in a container of its own, from a temporary directory that holds nothing but the script. There is no user-supplied JavaScript, no eval, and no shell interpolation.

Each container runs with:

  • one CPU (--cpus=1) and 512 MB of memory (--memory=512m);
  • a process cap (--pids-limit=256);
  • a read-only root filesystem, with a small noexec tmpfs for scratch;
  • its own Docker network, separate from the application's;
  • a wall-clock timeout, after which the run is stopped and marked as failed;
  • only the run's own directory mounted — never the application directory, never a secrets directory.

The directory is removed when the run ends. k6 itself is AGPL-3.0 and we run it unmodified as a separate process; no proprietary code is linked into it.

Where a test may point

Before a run starts, every target URL is validated: it must be HTTP or HTTPS, it must have a host, and that host must resolve to a public address. Requests to loopback, private ranges, link-local and unique-local addresses, and to the cloud metadata address, are refused — so Stabula cannot be turned into a probe of our own infrastructure or of yours. Stronger egress control, including per-run firewalling and DNS-rebinding protection, is on the roadmap.

Credentials

  • Auth details on a request or a step — bearer tokens, API keys, basic-auth passwords — are encrypted at rest with Active Record Encryption (AES-256-GCM) and are never returned to the browser once saved.
  • Secret values are redacted from anything we store about a run: the generated script, the runner's output, and error messages all have known secrets replaced with [REDACTED] before they are written.
  • Notification destinations (webhook URLs and their signing secrets) are encrypted the same way.
  • Passwords are stored as bcrypt hashes. We cannot read them, and neither can anyone who reads the database.

Access to your workspace

Every workspace member has a role — owner, admin, member or viewer — and every API endpoint checks it. API tokens are workspace-scoped, shown once at creation and stored as a hash. Report share links are unguessable tokens that grant read-only access to one report, never to logs, and can be revoked at any time.

Abuse and account safety

  • Sign-in, sign-up, password reset and the API are rate limited per IP and per account.
  • Repeated failed sign-ins lock an account, and unlocking goes through the email on file.
  • New accounts confirm their email address before they can create a workspace.
  • Sessions are cookie-based, HTTP-only, SameSite, and secure in production; state-changing requests carry CSRF protection.
  • Traffic is HTTPS only.

Data, backups and recovery

The application and its PostgreSQL database run in Singapore. The database is dumped nightly to object storage; run artifacts — the runner's cleaned output and the k6 summary — are stored as files in the same bucket rather than in the database. Encryption keys are held outside the repository, in the deployment's secret store, and are backed up with the database, since a backup without them cannot be decrypted.

Development practices

  • Changes go through review and an automated test suite before they are deployed.
  • Dependencies are patched as advisories appear.
  • Application errors are reported to Sentry; health endpoints and queue monitoring cover availability.

Reporting a vulnerability

Found something? Write to hello@stabula.app with enough detail to reproduce it. We will acknowledge within three working days and keep you posted until it is fixed. Please give us reasonable time to put it right before publishing, and do not run tests against other customers' data or degrade the service while you are looking. We will not pursue researchers who follow that. Machine-readable contact: /.well-known/security.txt.

What we do not claim

Stabula is a young product. We are not SOC 2 or ISO 27001 certified, and we do not yet offer single sign-on on every plan or a signed DPA as standard. If your procurement needs any of those, write to hello@stabula.app and we will tell you honestly where we are.