Security & Trust at Meridian

Last updated: [PLACEHOLDER: effective date]

Meridian gives engineering and product teams a live, plain-language answer to "what's deployed where, and what changed." That means our customers trust us with metadata about their software delivery — and we treat earning that trust as a product requirement, not a checkbox.

This page describes the security practices we operate today, the data we do and don't handle, and what's next on our security roadmap. Our security program is designed to align with the SOC 2 Trust Services Criteria, and we are preparing for a SOC 2 Type II audit. [PLACEHOLDER: SOC 2 target timeline] We aim to be precise on this page: where a control is planned rather than live, we say so explicitly.

Questions? Write to [email protected].

Infrastructure and hosting

• Application hosting. Meridian runs on Fly.io in the United States (Ashburn, Virginia — region iad). Application containers run as a non-root user.
• Database. Our primary datastore is Fly.io Managed Postgres, provisioned in the same US region. All tenant data lives in this database; we do not operate a separate analytics datastore or external cache.
• Edge and DNS. Cloudflare provides DNS, CDN/proxy, and edge TLS for app.meridiansemantic.com. Cloudflare is configured in Full (strict) mode, meaning the edge cryptographically validates our origin's certificate on every connection.
• TLS everywhere. HTTPS is enforced at three independent layers: the Cloudflare edge (Always Use HTTPS, minimum TLS 1.2, TLS 1.3 enabled), the Fly.io platform (forced HTTPS), and the application itself (Rails force_ssl, which also emits HTTP Strict Transport Security headers and marks cookies secure). Origin certificates are issued by Let's Encrypt and renewed automatically.
• Infrastructure as code. Our DNS and TLS configuration is managed in Terraform. Changes are proposed as pull requests, planned automatically for review, and applied on merge — infrastructure changes get the same review discipline as application code.

Data security

Encryption in transit

All traffic between your browser and Meridian — including WebSocket connections for real-time updates — is encrypted with TLS (minimum version 1.2). Connections from Meridian to third-party APIs (GitHub, Slack, Google) are made over HTTPS.

Protection of credentials and secrets at rest

We apply protection proportional to sensitivity for every credential we handle:

As part of our SOC 2 preparation we are documenting the platform-level storage encryption guarantees provided by our hosting provider; we do not make encryption-at-rest claims here that we have not yet verified end-to-end.

Secrets management

Application secrets (API keys for integrations, signing secrets, encryption keys) are stored in Rails encrypted credentials. The decryption key is never committed to source control; it is held as a write-only platform secret injected at boot. Secret values cannot be read back from the hosting platform, and we maintain a documented rotation procedure for every secret. Production container images are built without access to production keys.

Data minimization by design

Equally important is what we don't hold:

• No source code. Meridian ingests Git metadata — commit messages, pull request titles and descriptions, release notes, deploy and CI status. We do not ingest, store, or process your repository's file contents or diffs. Our optional codebase-understanding integration runs entirely in your CI with your credentials; Meridian receives only the knowledge graph that analyzer generates — component summaries, file paths, and relationships — not your repository's files.
• No payment card data. Meridian does not store payment card information.
• No file uploads. The product does not currently accept or store customer file uploads.
• No third-party analytics or advertising trackers. The application includes no product-analytics, session-recording, or advertising SDKs.

On our roadmap

• Formalized, published data retention schedules and self-service data deletion for workspaces and users.
• Documented, tested encryption-at-rest attestation for all storage layers as part of SOC 2 readiness.

Application security

Authentication

• Sign in with Google (primary). Google SSO via OAuth 2.0, requesting only email and profile scopes. We link a Google identity to an account only when Google asserts the email address is verified, preventing account-takeover via unverified email claims.
• Email and password (secondary). Passwords are hashed with bcrypt. Sign-in uses constant-time credential checks and deliberately ambiguous failure messages to prevent account enumeration. Sign-in attempts are rate-limited by IP.
• Invitation-based access. Joining an existing workspace requires admin action — an admin-issued invitation, or admin approval of a join request from a teammate whose verified company email domain matches the workspace. Invite links are single-use, expire after 7 days, and are validated against a stored SHA-256 hash of the token.

Session security

Sessions are stored server-side in the database and referenced by a signed, HTTP-only, secure, SameSite cookie. Sessions are rotated on every sign-in (session-fixation hardening) and expire after 30 days. Signing out destroys the server-side session immediately.

Tenant isolation

Meridian is multi-tenant by workspace. Tenant records carry a workspace identifier, and access is enforced through per-request authorization scopes: scoped queries resolve within the authenticated user's current workspace, and requests with no workspace context resolve to nothing. Within a workspace, role-based access control (admin, deployer, approver, viewer) governs who can invite members, manage integrations and API keys, approve deploys, and view the audit log.

API security

The deploy-sync API authenticates with bearer tokens that are SHA-256-hashed at rest, bound to a single workspace, and scoped to specific capabilities (read, deploy, admin, codebase graph) with server-side scope enforcement. API requests are rate-limited per key, and requests presenting invalid keys are rate-limited per IP to bound brute-force attempts. Keys can be revoked instantly by a workspace admin.

Webhook verification

Inbound GitHub webhooks are verified with HMAC-SHA256 signatures using constant-time comparison, and deliveries are deduplicated to bound replay. Inbound Slack requests are verified with Slack's HMAC-SHA256 signing scheme, including a five-minute timestamp freshness window.

Audit logging

Privileged actions — member invitations, deploys, approvals, rollbacks, promotions, and more — are written to a per-workspace audit log recording the actor, action, affected resource, IP address, user agent, and timestamp. The audit log is append-only at the database level: database triggers reject any update or delete, so entries cannot be altered even by application code. Workspace admins can review the log in-app.

On our roadmap

• Multi-factor authentication (MFA) for email/password sign-in.
• Per-workspace SSO enforcement (disable the password path for your team).
• Self-service password reset and session management ("sign out everywhere").
• Content Security Policy headers.
• Default expiration for newly issued API keys.
• Expanded audit-log coverage (sign-in events, role changes, API key lifecycle).

Development and code security

• Every change ships through a pull request. Our engineering policy is that no change reaches the main branch without going through the PR flow.
• Security scanning in CI on every pull request. Continuous integration runs Brakeman (Rails static application security testing), bundler-audit (known-CVE scanning of every dependency against an updated advisory database), linting, and the full automated test suite on every PR and every push to main.
• Gated deploys. Our release pipeline deploys to production automatically only from tagged releases cut from the main branch; database migrations run as a controlled release step.
• Secret hygiene. Encryption keys and private keys are excluded from version control by policy and tooling; CI deploy credentials are held as platform secrets. Infrastructure change plans are encrypted before being stored as CI artifacts, and the pipeline verifies that the applied infrastructure change matches the plan that was reviewed.
• Dependency management. Dependency vulnerability scanning runs in CI on every change. We are adding automated dependency-update tooling as part of our SOC 2 preparation (see roadmap).

On our roadmap

• Automated dependency update tooling (e.g., Dependabot) across our repositories.
• A recurring third-party penetration test. [PLACEHOLDER: penetration testing]

Data privacy

• Privacy policy. How we collect, use, and share personal data is described in our Privacy Policy.

• Subprocessors. We use a small, deliberate set of subprocessors to run Meridian. The canonical, always-current list — including each vendor's role and processing location — lives at /legal/subprocessors; in summary:

  Subprocessor	Purpose	Customer data involved
  Fly.io	Application and database hosting (US — Ashburn, VA)	All application data
  Cloudflare	DNS, CDN/proxy, and edge TLS	All traffic in transit at the edge
  Sentry	Error monitoring	Error reports tagged with pseudonymous account/user IDs; default PII collection is disabled

  Services you connect and control yourself — your GitHub organization (source of ingested deploy/release/PR/commit metadata), your Slack workspace (deploy and approval notifications, slash commands), and Google sign-in — act at your direction under your own agreements with those providers. They are customer-directed integrations, not subprocessors, and are described in detail on the subprocessor page.

  We will update this list before engaging any new subprocessor. [PLACEHOLDER: subprocessor change notice]

• Data Processing Addendum. A DPA is available for business customers on request — contact [email protected]. [PLACEHOLDER: DPA]
• AI and your data. Meridian's AI features do not currently send your data to any third-party AI provider — there is no AI vendor on our subprocessor list. AI features operate only on the Git metadata and prose you have already ingested (commit messages, PR titles/descriptions, release notes, deploy metadata) plus your users' chat messages — never repository file contents. We do not use customer data to train AI models, and we do not permit anyone else to. If we engage a third-party AI provider in the future, we will add it to our subprocessor list and notify customers in advance.
• We do not sell customer data, and we do not use advertising or cross-site tracking on the application.

Availability and continuity

• Backups. Our managed Postgres database takes automated snapshots, and we maintain documented, runbook-driven restore procedures. As part of SOC 2 preparation we are formalizing and publishing our backup frequency, retention, and restore-testing commitments — we don't publish numbers here until we can stand behind them.
• Real-time architecture. Background processing and real-time updates run against the primary database, keeping the operational surface small and auditable.
• Incident communication. If we confirm a security incident affecting your data, we will notify affected customers [PLACEHOLDER: incident notification window] with what we know, what we've done, and what we recommend. Ongoing incident and maintenance communication is handled by email today.

On our roadmap

• A public status page for uptime and incident visibility. [PLACEHOLDER: status page]
• Published RTO/RPO targets backed by scheduled restore testing.

Responsible disclosure

We welcome good-faith security research.

• Report vulnerabilities to [email protected]. Include reproduction steps, the affected URL or endpoint, and any relevant request/response details. We will acknowledge your report promptly, keep you informed as we investigate, and credit you if you'd like (we do not currently operate a paid bug bounty).
• Safe harbor. We will not initiate legal action against researchers who make a good-faith effort to comply with this policy — that means testing only against accounts you own or have permission to use, avoiding privacy violations, data destruction, and service degradation, and giving us reasonable time to remediate before public disclosure.
• Our current reporting channels are also published at /.well-known/security.txt.

Compliance roadmap

• SOC 2. Our security program is designed to align with the SOC 2 Trust Services Criteria (security, availability, and confidentiality), and we are actively preparing for a SOC 2 Type II audit. [PLACEHOLDER: SOC 2 target timeline] Prospective customers can contact [email protected] for our current security documentation and readiness status.
• GDPR. For customers subject to the GDPR: [PLACEHOLDER: legal entity name] acts as a processor for the workspace data our customers put into Meridian, we offer a Data Processing Addendum on request, we maintain the subprocessor list above, and we accept data subject requests at [email protected]. Customer data is hosted in the United States; we describe international transfer mechanisms in our Privacy Policy and DPA. [PLACEHOLDER: DPA]
• We'll keep this page current as our program matures — dated, so you can see what changed.

Contact

• Security reports and security reviews: [email protected]
• Privacy questions and data subject requests: [email protected]
• Legal, DPAs, and contracts: [email protected]

We're happy to complete security questionnaires and walk your security team through anything on this page.