Security · Knittrix

Your documents stay yours.

This page is the unvarnished list of what we run, how it's configured, and what we've audited. Skim it, or pull the section that answers your specific question.

01 · How we think about your documents

How we think about your documents

Construction documents are legal contracts, payment applications, employee data, project financials, and intellectual property. They are sometimes the only authoritative copy of a project decision. We treat them with the weight that implies.

We don't believe in security theater. We describe exactly what we run, in plain language, with the gaps marked. If a control is a configuration toggle in production, we say so. If something isn't yet implemented, we say that too.

Skim this page top-to-bottom for the philosophy, or jump straight to the structured section below for specific facts. If your IT contact needs something we haven't listed, write hello@knittrix.com.

02 · Storage

Where your documents live.

Documents and rendered page images live in Cloudflare R2, a tenant-prefixed object store. Reads are served via short-lived signed URLs so links stop working soon after they're generated. Temporary exports auto-expire on a two-day lifecycle.

  • Cloudflare R2 (knittrix-prod bucket).
  • Versioning enabled on the production bucket.
  • Two-day lifecycle on /exports/ — temp exports auto-delete.
  • Document and page reads served via 300-second-TTL signed URLs.
  • Multi-tenant key prefix (tenant_<id>/...) — keys cannot be derived across tenants.

03 · Access

Who can see what.

Authentication is email + password or OAuth via Microsoft and Google. Authorization combines a per-tenant role taxonomy with per-project membership: an Estimator on Project A doesn't see Project B's documents. Open signup is closed in production — new tenants are onboarded by Knittrix-issued invitation.

  • Every tenant-scoped table carries a tenant_id foreign key with ON DELETE CASCADE. Tenant isolation is enforced at the data layer, not just the app.
  • OAuth via Authlib for Microsoft and Google, alongside email + password.
  • 8-role construction-firm taxonomy (Principal, PM, PE, Super, Estimator, Scheduler, Accounting, Office Admin) plus per-member granted/revoked permission overrides.
  • Per-project membership — an Estimator on Project A doesn't see Project B's documents.
  • Session cookies use the Secure flag in production (HTTPS-only).
  • Session and invite tokens are hashed at rest in the database.
  • Open signup is closed by default in production. New tenants are onboarded via platform invites issued by Knittrix.

04 · Network & API

How traffic moves.

Public traffic terminates TLS at Fly's edge with auto-renewing Let's Encrypt certificates. The API enforces an origin-check middleware on unsafe-method requests and per-route rate limits that protect against credential stuffing, scraping, and ingest abuse.

  • TLS via Let's Encrypt, auto-renewed by Fly.
  • Content-Security-Policy with explicit allowlist for Cal.com (frame-src), Cloudflare Insights (script-src + connect-src), and Anthropic and Voyage (connect-src).
  • Origin-check middleware rejects unsafe-method API requests from non-allowlisted origins (APP_BASE_URL + KNITTRIX_DEV_WEB_ORIGINS).
  • Per-route rate limits: signup 10/hr/IP, login 50/hr/email + per (email, IP) pair, chat 10/min + 500/day per (tenant, user), export 1/hr/tenant, tenant-delete 3/day/tenant, waitlist 5/hr/IP.

05 · Operations

How we run it.

The application runs on Fly.io with Fly Managed Postgres for durable state. Secrets never live in .env on disk — production credentials are Fly secrets, developer credentials are macOS Keychain. Every state-changing request writes an audit-event row that ties the change to a tenant and user.

  • Postgres on Fly Managed Postgres — daily backups, point-in-time recovery.
  • Production secrets in Fly secrets — never in .env on disk.
  • Dev secrets in macOS Keychain — never in .env on disk.
  • Pre-commit gitleaks scan blocks credential commits at the developer machine.
  • Security headers (X-Content-Type-Options nosniff, X-Frame-Options DENY, Referrer-Policy, Permissions-Policy).
  • Audit events table — every state-changing action records (tenant, user, action, timestamp).

We run pip-audit and pnpm audit manually before deploys. Automated CI scanning is on the roadmap.

06 · Ask us anything specific

Ask the specific question.

The list above is what we currently run. It will change as we ship — we'll update this page when it does, and we won't quietly remove gaps.

Pilot customers get the controls listed above plus a real person to ask about specific concerns. If your IT or legal contact needs something we haven't documented — a Data Processing Agreement template, a control narrative, an access-review walkthrough — just write us. We respond within two business days.

For specific questions, write hello@knittrix.com.