Journey Lanes

Security

Built to point at real systems

Journey Lanes reads your code, signs in to your environments and calls your APIs. These are the rules it follows while doing that, and how it keeps what it learns. Everything here describes what the software does; there are no certifications claimed on this page.

Hosting and data

  • Servers and the database run at Hetzner Online GmbH, Germany.
  • Database backups are encrypted as they are made, with a key that isn’t kept on the servers, and kept at most 30 days.
  • Every recipient of personal data is listed in the privacy policy, and the sub-processors in the data processing agreement. The trust page has them together, with answers to common security questions and the agreement as a PDF to sign.
  • Deleting a flow, project or organization deletes its history at once.

Accounts and sessions

  • Passwords are hashed with argon2id.
  • Two-step sign-in: after the right password, a 6-digit code goes to the account’s email, and only that code, entered in the same browser within 10 minutes, finishes signing in. Codes work once, are stored only as a keyed hash, and stop after 5 wrong tries. You can trust a browser of your own for 30 days; platform admins always enter a code.
  • Authenticator app: anyone can sign in with a code from an authenticator app (TOTP, RFC 6238) instead of the email code. The key is stored encrypted, each code works once, and 10 recovery codes (stored only as a hash) cover a lost phone. A password reset link then needs a code from the app too. Platform admins need an app for their pages.
  • Sessions are a random 256-bit token in an http-only cookie; only a hash of it is stored. Sessions last 14 days after their last use and end 30 days after signing in.
  • Sign-in, reset and sign-up attempts are rate limited per address and email. A locked account stays usable from a browser that signed in to it before, so someone else’s failed attempts can’t lock you out.
  • Reset and invite links work once, expire, and are stored only as a hash. Setting a new password signs you out everywhere else.
  • Requests that change something are refused when they come from another site. The one exception is the address where a SAML identity provider posts its answer, which is checked by its signature and its single-use request instead.
  • Owners and admins see an audit log of who changed what in their organization. Each entry is sealed to the one before it, so a changed or removed entry shows.

Single sign-on

  • Organizations can sign in through their own identity provider with OpenID Connect or SAML 2.0. A sign-in through it skips the email code: the identity provider’s own checks, such as its two-step sign-in, take its place.
  • Only addresses in a domain the organization proved with a DNS record sign in through its identity provider, so one organization’s provider can’t sign in people of another. A domain belongs to one organization and is checked again every day; when another organization verified a more specific one (eu.example.com under example.com), its people are that organization’s. Public suffixes such as co.uk can’t be claimed.
  • Each account is linked to who it is at the identity provider at its first sign-in. If the provider later gives the same address to someone else, they can’t sign in until an owner relinks it.
  • OpenID Connect uses the authorization code flow with PKCE, a single-use state tied to the browser, and a nonce. The ID token’s signature, issuer, audience and expiry are checked against the provider’s published keys, and an address the provider marks unverified is refused.
  • SAML answers must carry a signed assertion, checked with a maintained library against the certificate you uploaded. Only the signed part is read, an answer with more than one assertion or with a DOCTYPE is refused, and the signed assertion itself must reply to a sign-in started in the same browser in the last 10 minutes. Each assertion signs in once. Sign-ins started from the identity provider’s portal aren’t accepted, and a link can’t start a sign-in on its own.
  • Addresses of identity providers are checked like every other outbound call: private and internal addresses are refused. Client secrets are stored encrypted.
  • An owner can require single sign-on: password sign-in, codes and reset links then stop for addresses in the organization’s domains, and their password sessions and the API tokens they made end, also for a domain verified later or an owner who stops being break-glass. Owners chosen as break-glass can still sign in with a password and code; every such sign-in is recorded and emailed to the owners. Platform admins never sign in through an organization’s identity provider.
  • A session from single sign-on ends when the identity provider’s session ends, and after 12 hours at most unless the organization sets another limit.

Code hosts

  • GitHub is connected through a GitHub App with read-only access to the contents and metadata of the repositories you choose. No GitHub token is stored: each read uses one that GitHub expires within an hour.
  • An installation is only accepted after the person connecting it signs in with GitHub and it is one their account can see.
  • GitLab and Bitbucket use OAuth with read-only scopes; their tokens, and tokens you paste, are stored encrypted.
  • From a repository, what was found is kept, not the source files (flow files you keep for Journey Lanes become flows).

Your credentials

  • Environment passwords, client secrets, API keys, two-factor secrets, passkeys and saved sign-ins are stored encrypted with AES-GCM and never sent back to the browser.
  • When an environment starts sending its sign-in to a different server, its stored secrets are removed and must be entered again, so someone who may edit but not read them can’t send them elsewhere.
  • Alert webhooks are only ever shown as their host. Deploy hook and relay agent tokens are shown once and stored as a hash.

Run history

  • Tokens are never stored in run history, and sign-in calls are kept with every credential masked.
  • From live environments, replies are kept only as their shape unless an owner chooses to keep bodies; then emails, citizen service numbers and sensitive fields are masked before anything is stored. Of the headers, only harmless ones are kept.
  • Live runs are deleted after the environment’s retention, 30 days unless an owner sets another period.

Live environments

  • Create, update and assign steps are skipped until you allow writes for that environment.
  • Load tests run only where you allowed them, and the access audit never sends delete probes to a live environment.
  • Load tests and audits only run against domains your project has verified by DNS record or file, so nobody can aim them at someone else’s API.
  • Tours never include deletes.

Calls Journey Lanes makes

  • Addresses you enter are resolved before every call and must be public: private, loopback, link-local, metadata and internal addresses are refused, and so are server-management ports. Redirects are checked again.
  • A redirect to another origin carries only harmless headers; credentials stay behind, whatever the header is called.
  • A step’s request always stays on its environment’s address. Webhook addresses must use https.
  • Calls come from 88.198.26.110, which you can add to a firewall’s allow list.

Private networks

  • A private network is only reached through a relay agent you run. It connects out, never listens, and calls only the hosts on its allow list, which lives on your side.
  • It refuses link-local and cloud metadata addresses even when they are listed, and can be limited to read-only methods.

The sign-in browser

  • Login pages that need JavaScript open in a separate service. Every sign-in gets a Chromium process of its own, closed afterwards, so tenants never share a browser, a renderer or a cache.
  • All of its traffic goes through a proxy that applies the same address rules as every other call, when each connection is made. It may only reach public addresses on ports 80 and 443, never this installation’s own servers.
  • A sign-in is ended at its deadline whatever the page does, and one organization can’t take every slot.

Who sees what

  • Access is decided per organization and per project: viewer, editor or owner.
  • People outside a project get “not found”, so ids don’t reveal what exists.
  • The people who run Journey Lanes have no access to your projects unless your organization invites them.

Request log

  • For investigating incidents, API requests are logged with the route pattern (never the ids in it), the status, the account and organization, the network the request came from (the address shortened to its network) and the browser family. No bodies or query strings.
  • The log is kept 30 days.

AI

  • Claude is only called when someone asks: drawing a flow, “Help me” or “Explain this failure”.
  • “Explain this failure” takes no text from the person asking; the server builds it from that run and the project’s own code, with anything that looks like a credential masked again.
  • What goes to Anthropic is listed in the privacy policy.

Check what your roles can reach

The access audit shows, per role and endpoint, what is allowed that shouldn’t be.

Create an account See how it works