Dependencies & supply chain

Third-party code is part of any application's attack surface. Surplus keeps that surface manageable through a single toolchain, pinned versions, and centralized dependency management.

One toolchain

The entire monorepo uses Bun as its runtime, package manager, and test runner, pinned to an exact version (bun@1.3.0) in the root package.json. A single lockfile (bun.lock) covers every app and package, so all workspaces resolve dependencies consistently and reproducibly.

Centralized, pinned dependencies

• Shared re-exports. Common third-party libraries (Drizzle, Zod, jose, Stripe) are re-exported through @surplus/sharedDeps, giving the workspace a single place to manage and upgrade them and preventing version drift between packages.
• Pinned versions. Security- and API-sensitive dependencies are pinned to exact versions rather than floating ranges — for example the ORPC packages and the API-reference renderer — so builds are deterministic and upgrades are deliberate, reviewed changes.
• Workspace-internal dependencies are referenced with workspace:*, so internal packages always build against the in-repo source rather than a published artifact.

Reducing surface area

A few architectural choices keep the dependency footprint smaller and safer:

• No hand-rolled crypto. JWT signing and verification use the well-maintained jose library; password storage doesn't exist at all because authentication is passwordless.
• No raw SQL string building. Database access goes through the Drizzle ORM with parameterized queries.
• Managed providers handle the riskiest infrastructure (database, cache, storage), so the platform isn't maintaining that surface itself.

Build integrity

Production images build from the pinned lockfile, and the server validates its configuration at build time (see Infrastructure and secrets). A build with missing or invalid configuration fails rather than shipping.

Automated dependency scanning

GitHub Dependabot runs automatically on this repository to open pull requests when dependencies have known vulnerabilities or when updates are available. Findings are reviewed and merged through the normal PR process (including CI). This does not replace human judgment on breaking upgrades — especially for pinned packages such as ORPC — but it ensures vulnerable versions are surfaced without waiting for a manual audit.

What still needs to be documented

• Upgrade cadence — how regularly non-security dependency updates are batched and released.