← Back to Trust Center

Infrastructure & dependency management

EFFECTIVE: MAY 1, 2026 · LAST UPDATED: MAY 1, 2026

This document describes how Arx runs and maintains its production infrastructure, manages secrets and credentials, and keeps third-party dependencies current. It is the public-facing summary of our internal infrastructure and dependency management procedures.

1. Production topology

Arx is deployed on managed cloud providers; there is no on-premise component. The production environment comprises:

• Vercel (US) — serves the marketing site at foundersarx.com and the authenticated web app at app.foundersarx.com. Each deployment is an immutable build identified by commit SHA.
• Railway (US) — runs the Fastify API at api.foundersarx.com and background workers (e.g., scheduled news digest, deck-view aggregation). Services run in isolated containers with private networking between services in the same project.
• Supabase (US/EU) — managed PostgreSQL, authentication, and object storage. Project networks are isolated; database connections are over TLS only.
• Cloudflare (or equivalent provider) — DNS and edge protections. DDoS mitigation and bot filtering at the edge.

2. Network security & TLS

• All public endpoints terminate TLS 1.2 or higher. Lower protocol versions are rejected.
• HTTPS is required for every customer-facing surface; HTTP requests are redirected to HTTPS.
• HSTS is enabled on production hosts with a long max-age and includeSubDomains.
• Certificates are issued and rotated automatically by Vercel and Railway through their managed certificate authorities.
• Internal traffic between Railway services uses private networking; the public API ingress is the only entry point exposed to the internet.
• Database connections from the API use TLS and are authenticated with a service role credential that has only the privileges it needs.

3. Secrets & key management

• Production secrets live in the hosting providers' encrypted environment-variable stores (Vercel and Railway).
• Secrets are scoped per environment (production, preview, development) and per service.
• Application-layer encryption keys (e.g., the 32-byte AES-256-GCM key that wraps customer OAuth tokens) are provisioned only to the production API process and are not present in any developer environment.
• Secrets are rotated on a defined cadence and immediately on any suspected compromise. Rotations are tracked in our internal change log.
• Source control is scanned for high-entropy strings and known credential patterns; matches block the commit.
• Engineers' access to provider consoles is gated by hardware-backed two-factor authentication.

4. Dependency inventory & sourcing

• The codebase is a single pnpm-managed monorepo. The pnpm-lock.yaml file is the canonical inventory of every JavaScript / TypeScript dependency and its version.
• New dependencies require a written justification in the pull request that adds them: what problem is it solving, what alternatives were considered, what is the upstream maintenance status.
• We prefer well-maintained packages with a clear release cadence and active issue triage. We avoid packages with named-author-only maintenance, unclear licensing, or recent abandonment signals.
• Direct dependencies are pinned in package.json using semver caret ranges; transitives are locked by the lockfile.
• Container base images are pinned to specific tags rather than latest and are refreshed on the patching cadence below.

5. Dependency scanning

• pnpm audit runs on every pull request and on a daily schedule against the main branch.
• Container images are scanned for known CVEs before deploy.
• Provider security advisories (Supabase, Vercel, Railway, Stripe, Resend, Anthropic, OpenAI, Perplexity, Google) are monitored; advisories that affect us trigger a tracked remediation task.
• Findings flow into the same backlog used for SAST findings and external vulnerability reports (see /responsible-disclosure).

6. Patching cadence

Patching follows a severity-based schedule from the time we become aware of the issue:

• Critical (active exploitation in the wild, or remote unauthenticated impact on Arx) — patch within 7 days, with an emergency change window if necessary.
• High — patch within 30 days.
• Medium — patch within 60 days.
• Low — patch within 90 days or in the next scheduled release.

Any deviation from these targets requires a written risk acceptance with a compensating control and a review date. Operating-system and platform patches are applied automatically by the managed providers; we monitor their changelogs and incident statuses.

7. Infrastructure change management

• Infrastructure changes — environment variables, provider settings, custom domains, scheduled jobs — go through a written change ticket and, where possible, are represented in code (e.g., Vercel and Railway project configuration).
• Significant changes (new deployable, new region, new public ingress) require peer review.
• Every deploy event, including commit SHA, deployer identity, and outcome, is retained by the hosting provider.
• Production access events at the provider level (console logins, role changes) are logged and reviewed.

8. Backup & disaster recovery

• Database backups. Supabase performs continuous point-in-time backups on the production project; we rely on a recovery window of at least 7 days. Backups are encrypted at rest and stored by the provider.
• File storage. Data room and pitch deck files are stored in Supabase Storage with versioning enabled; deletes are soft for the customer's retention window before becoming permanent.
• Restore testing. We periodically restore a recent backup into an isolated staging project and verify schema and sample-row integrity. Restore tests are documented in our internal change log.
• RPO / RTO. Recovery Point Objective ≤ 1 hour and Recovery Time Objective ≤ 8 hours for the full production environment; per-workspace restoration is targeted at ≤ 1 hour.
• Provider outage. If a hosting provider experiences a regional outage, we communicate status to customers via the status page and direct customer notice; we do not currently maintain a multi-region active-active deployment, but providers' built-in regional redundancy applies.

9. Vendor & subprocessor due diligence

Before adding a new subprocessor we evaluate (i) its security posture and any independent assessments (SOC 2, ISO 27001), (ii) the contractual protections it offers (DPA, SCCs where applicable), (iii) the data we will send it and whether the integration can be designed for least access, and (iv) its incident-response and breach-notification commitments. The current subprocessor list is published at /subprocessors. We notify customers in advance of material changes.

10. Contact

• Security & infrastructure questions — security@foundersarx.com
• See also — Security overview, Secure SDLC, Subprocessors, Responsible disclosure

This page is the public summary of our infrastructure and dependency management procedures. Detailed runbooks and provider-specific configuration documentation are available to assessors under NDA.