Security

On your machine

The proxy and the request inspector run locally. Captured traffic is capped, kept in your home directory, and deleted every time the daemon restarts. It is never uploaded to us.

In transit

Our servers terminate HTTPS, which is what makes the certificate on your Public URL valid. They see each request in plaintext, pass it to your machine over an encrypted tunnel, and stream the response back without writing any of it down. With a TCP tunnel we pass bytes along without reading them, so if your own application terminates TLS the contents stay closed to us.

In our logs

One line per request: method, host, path and query string, status, duration, and the visitor's IP address. Never headers, cookies, user agents, or any part of a body. The IP is read from the network socket rather than a forwarded header, so a visitor cannot forge it.

On our servers

Your account and billing details, the Public URLs you create and their transfer totals, custom domains and their certificates, any Snapshot you publish, team membership, and the audit log. Nothing from the traffic itself.

Where it lives

Everything stored is in the European Union.

Account, teams, Public URLs, audit log

Amsterdam, PostgreSQL on DigitalOcean

Snapshot archives

Amsterdam, private bucket, signed URLs only

Traffic relay

Amsterdam, Singapore, San Francisco and New York. Nothing stored

Transactional email

Stockholm, Amazon SES

Payments and card data

Stripe, United States

Operational logs

Grafana Cloud. Can contain IP and email addresses

Retention

Usage analytics and transfer records are deleted after 12 months, and provisioning logs after 90 days. A Snapshot is deleted from storage when you delete it or the Public URL it belongs to.

Encryption in transit

Visitors reach us over TLS 1.2 or newer, and TLS 1.3 wherever the browser supports it. Plain HTTP only redirects. The connection from our servers to your machine is encrypted with TLS 1.3. Certificates come from Let's Encrypt and renew automatically.

How secrets are held

Certificate private keys are held in memory on the servers that need them and are never written to disk. API tokens are stored as hashes, and access passwords as scrypt hashes, so a password is checked without ever being readable. Everything else sits behind the controls below: the database is not reachable from the internet, and production access is limited to one person.

Four controls

A Public URL is reachable by anyone who has the link until you lock it. You can add a password page, a secret link, IP allow and deny rules, or user-agent rules. Deny rules are evaluated first, so a blocked address cannot get in with a valid password.

Enforced on our servers

Not on your laptop, so protection keeps working while your machine is asleep. Passwords are stored and checked as scrypt hashes, never in readable form. The session cookie is host-scoped, HttpOnly, Secure, and SameSite=Lax, and both it and the secret-link token are stripped before the request reaches your app. Failed attempts are rate limited per IP address.

Signing in

LocalCan accounts have no passwords at all, so there is no password database to breach. You sign in with a six-character code emailed to you, with Google or GitHub, or through your own identity provider.

Single sign-on and provisioning

The Teams plan includes SAML 2.0 and OIDC sign-on and SCIM 2.0 provisioning, validated against Okta, with no add-on fee. Deprovisioning a member removes them, rotates their license key, tears down their Public URLs, and revokes every session they have.

You cannot be locked out

The emailed code stays available on every account, including on domains routed to an identity provider. A misconfigured or unreachable provider can never lock a team out of its own billing and licenses.

Audit log

Owners and admins on a subscription plan see team, license, billing, single sign-on and SCIM activity in the dashboard, with the source IP address and user agent on each entry. The log is append-only, and entries keep reading correctly after the resource they refer to is gone.

Local certificate authority

To serve .localdomains over HTTPS, LocalCan generates a root certificate authority unique to your machine. The private key is written with owner-only permissions, never leaves your disk, and trusting it goes through your operating system's own dialog. LocalCan never installs a certificate silently.

AI agents

The MCP server runs as a local process with no port of its own, and is read-only until you explicitly enable write access. Header redaction is on by default and covers authorization headers, cookies, and API keys, so an agent can read the traffic without reading your credentials. Every write call is logged.

Telemetry and code signing

Usage analytics are off until you turn them on, and nothing is sent before you do, not even error reports. The macOS app and command-line tool are signed with an Apple Developer ID and notarized, and macOS verifies that signature on every update.

Access and network

Production access is limited to one person, over SSH with keys. The database, the cache, and the internal API are not reachable from the internet. Application secrets are scoped per service rather than shared across the stack.

Monitoring and releases

Alerting covers the servers that carry your traffic and the certificates that protect it, including crash loops, a host going silent, renewal failures, and disk exhaustion. Deploys roll out one service at a time and roll back automatically on failure.

Every Public URL is authenticated

A Public URL only serves traffic while a licensed device is connected to it, and every connection is authenticated before any traffic flows. Creating and deleting a URL is recorded in the audit log with the actor and the source IP address.

Abuse reporting

Tunneling tools attract bad actors, and we do not ignore that. Free-plan URLs are served with a noindex header so they stay out of search results, the password gate and the comment endpoints are rate limited per IP address, and reports of phishing or malware go to abuse@localcan.com.

GDPR and the DPA

Our Data Processing Addendum takes effect automatically for business customers, with no signature round required, and a countersigned copy is available on request. It names us as the processor for team member data, tunnel traffic, and Snapshot archives, and commits us to breach notification and to assisting with data subject requests.

Subprocessors and residency

Every subprocessor is named in section 9 of the Privacy Policy, which stays the single source of truth for that list. Connecting your own identity provider adds none, because provisioning data is stored in the same European database as everything else.

Security review

We answer reasonable written security questionnaires, and the DPA provides for an audit once a year by prior agreement. Send a questionnaire to support@localcan.com and we will fill it in.

Where to send it

Email security@localcan.com, also published at /.well-known/security.txt. Please include the affected component, the steps to reproduce, and what an attacker could achieve.

What we commit to

We acknowledge a report within three business days and send a substantive update within fourteen. Fix timelines are agreed case by case, based on severity.

Safe harbour

Good-faith research that stays within your own account and your own Public URLs, avoids other customers' data, and does not degrade the service will not be met with legal action from us.