v2.1.0

What's new

This release hardens how BridgePort manages compose files and adds a more inspectable Fragments UI. The headline fix closes a stale-config trap where auto-managed compose could silently overwrite an operator-set composePath and then abort a deploy before touching the running container (observed on v2.0.1). Fragments gain a read-only view and a drill-down "Used by" list, and bcryptjs moves to v3. One migration applies automatically on container start.

---

Database migrations

One migration, applied automatically on container start — no manual steps.

• add_auto_manage_compose — adds an autoManageCompose opt-in flag to each environment's Operations settings, defaulting to off. Safe table-redefine that preserves all existing rows; existing deployments keep their current compose paths and behavior. (#213)

---

Features

Fragments: read-only view, drill-down usage, and visible includes (#215)

The Fragments page no longer forces you into the editor just to read a fragment, and "Used by" is now something you can actually follow.

• Read-only view action — an eye icon opens a read-only modal (name, description, content, usage) with an Edit button to switch into the existing editor, mirroring the Config Files view→edit flow.
• "Used by" is now a list, not a number — the count is a clickable expander that lazily loads the referencing config files and their attached services as links. Zero-usage rows render an unobtrusive "—". The fetch is cached per fragment, so re-expanding doesn't refetch.
• Included fragments shown in the Config File view — the read-only config-file modal now lists its included fragments in order; previously this was only visible while editing.

Pure frontend — no API or schema changes; it surfaces data the existing endpoints already returned.

---

API changes

None. No HTTP API surface changed this release. Note that the new API Stability Policy (below) now governs how future changes here are classified and communicated.

---

Fixes

Compose: operator-set paths are now sacred, generated compose is validated (#213)

BridgePort could overwrite a deployment's composePath with its own generated path — even when an operator had pointed it at a hand-maintained compose file — and the generated file could key its service on service.name instead of the deployment's containerName. When those disagreed, the deploy aborted with No such service: <containerName> before recreating the container, so the old container kept serving stale config while vars and synced files all looked correct. A "redeploy" appeared to succeed while changing nothing.

• An operator-set composePath is never overwritten — it survives deploys, service re-creation, and Terraform re-imports.
• Generated/template compose is validated before deploy — the top-level services: key must match the deployment's containerName, otherwise the deploy is refused with an actionable error instead of aborting mid-rollout. The dry-run preview surfaces the same mismatch as a warning.
• The default-compose generator now keys on containerName (was service.name), fixing the mismatch at the source.
• Every composePath change is audit-logged with its source (generator / terraform-import), so this class of drift is attributable.

Behavior change for new deployments: auto-setting composePath is now opt-in per environment (autoManageCompose, default off) under Settings → Operations → Compose Files. Existing deployments are unaffected. For a brand-new deployment that uses a generated compose file with the opt-in off, BridgePort no longer persists composePath, so a later restart uses docker restart <container> rather than docker compose (redeploys are unaffected — the file is regenerated and compose up runs regardless). Enable autoManageCompose to restore compose-managed restarts for new deployments.

Slack: clearer deployment notifications (#210)

Slack deployment messages were missing the one thing you want at a glance — which image deployed — and were inconsistent between success and failure.

• The deployed image reference is now shown on its own line.
• The internal Type: system.deployment_success debug line was removed.
• Failure reason is inline on failed deployments (truncated to 500 chars) — no click-through.
• The View Service button now appears on both success and failure (previously failures only).

---

Under the hood

bcryptjs 2 → 3 (#211)

Bumped the auth password-hashing library from 2.4.3 → 3.0.3, a major version behind. Existing $2a$ hashes minted on v2 continue to authenticate under v3 (the bcrypt wire format is stable across the bump; v3 only changes the default prefix to $2b$ for new hashes) — verified by a dedicated backward-compatibility regression test. No call-site or login changes; no users are re-hashed or locked out. Dropped the now-redundant @types/bcryptjs stub since v3 bundles its own types.

Other notable bumps

• @xyflow/react 12.10 → 12.11, react-router-dom 7.16 → 7.17, @sentry/* 10.55 → 10.56 (#206)
• Backend dependency-group bumps: @aws-sdk/*, ioredis, mysql2, @types/node (#207)
• CI: codecov/codecov-action 6 → 7 (#205)

---

Documentation

HTTP API stability & deprecation policy (#212)

Added docs/api-stability.md (linked from the README and CONTRIBUTING): what semver means for the HTTP API, what counts as breaking vs additive, the deprecation window, the per-release "API changes" discipline, and how clients should pin against /openapi.json and discover server version/capabilities. Existing 2.x deprecations are listed retroactively with their removal targets.

README & docs refresh (#204)

Redesigned README header (centered hero, badge rows, nav) and a docs refresh reflecting BridgePort's growth into a multi-server, topology-aware Docker ops platform — still SSH-based, self-hosted, SQLite, no Kubernetes.

Code of Conduct (#209)

Added the Contributor Covenant v2.1.