chore(deps): bump postgres from 16-alpine to 17-alpine (matches inkeep cloud)

[dependabot]

Bumps postgres from 16-alpine to 17-alpine.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agents-api	Ready	Preview, Comment	Feb 24, 2026 8:02am
agents-docs	Ready	Preview, Comment	Feb 24, 2026 8:02am
agents-manage-ui	Ready	Preview, Comment	Feb 24, 2026 8:02am

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4b2ffe1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[claude]

PR Review Summary

(1) Total Issues | Risk: Medium

🟠⚠️ Major (1) 🟠⚠️

🟠 1) create-agents-template/ Version drift: Self-hosting templates still at postgres:16-alpine

files:

• create-agents-template/docker-compose.yml:142
• create-agents-template/docker-compose.db.yml:65

Issue: This PR updates the SpiceDB backing Postgres from 16-alpine to 17-alpine in the monorepo's docker-compose files, but leaves the create-agents-template/ files at 16-alpine. This creates version drift between the local dev environment and the scaffolded template that customers use for self-hosting.

Why: Version drift between the dev environment and customer-facing templates can cause subtle bugs when customers deploy with different Postgres versions than contributors test against. The self-hosting artifacts should stay in sync with the local dev stack to ensure consistent behavior.

Fix: Update the following files to use postgres:17-alpine:

• create-agents-template/docker-compose.yml line 142
• create-agents-template/docker-compose.db.yml line 65

Refs:

• create-agents-template/docker-compose.yml:142
• create-agents-template/docker-compose.db.yml:65

💭 Consider (1) 💭

💭 1) PR metadata PR title/description mismatch

Issue: The PR title states "bump postgres from 16-alpine to 18-alpine" but the actual changes show 16-alpine → 17-alpine. The commit history reveals the original Dependabot bump to 18-alpine was manually downgraded to 17-alpine.

Why: PR titles often appear in changelogs and merge commits. The current title may mislead readers about the actual deployed version.

Fix: Consider updating the PR title to: chore(deps): bump spicedb-postgres from 16-alpine to 17-alpine

---

🚫 REQUEST CHANGES

Summary: This is a straightforward Postgres version bump for the SpiceDB backing database. The change itself looks good, but the create-agents-template/ files should be updated alongside to maintain consistency between the dev environment and customer self-hosting templates. Once those files are updated, this PR is ready to merge.

Discarded (2)

Location	Issue	Reason Discarded
docker-compose.dbs.yml:65	Mutable Docker tag (17-alpine) instead of pinned digest	Pre-existing pattern — postgres:18 is also unpinned. Not introduced by this PR.
docker-compose.dbs.yml	Version asymmetry (main DB at 18, SpiceDB at 17)	Appears intentional — explicit downgrade commits in history suggest compatibility reasons.

Reviewers (1)

Reviewer	Returned	Main Findings	Consider	While You're Here	Inline Comments	Pending Recs	Discarded
pr-review-devops	4	1	1	0	0	0	2
Total	4	1	1	0	0	0	2

[itoqa]

Ito Test Report ❌

15 test cases ran. 13 passed, 2 failed.

This test run verified the SpiceDB Postgres upgrade from postgres:16-alpine to postgres:17-alpine in PR #2237. The core upgrade functionality works correctly: Postgres 17 starts, SpiceDB migrations complete, the authorization chain operates properly, and the Manage UI CRUD operations succeed through the upgraded database. However, two issues were identified: (1) existing Postgres 16 volumes are incompatible with Postgres 17, requiring users to delete volumes before upgrading — a breaking change that should be documented, and (2) the create-agents-template files were not updated to use Postgres 17, creating version inconsistency between the main repo and the template.

✅ Passed (13)

Test Case	Summary	Timestamp	Screenshot
EDGE-4	Successfully pulled postgres:17-alpine image. Verified image contains PostgreSQL 17.8.	0:12
ROUTE-1	SpiceDB Postgres container started with postgres:17-alpine image, reached healthy status within 5 seconds. Verified PostgreSQL version is 17.8.	1:15
EDGE-2	Postgres 17 container reached healthy status in ~2.2 seconds from fresh start. Healthcheck uses pg_isready with 2s interval and 30 retries. Well within the 60-second threshold.	1:49
ROUTE-2	SpiceDB migration ran successfully against Postgres 17-alpine. All schema migrations completed with exit code 0. No errors during migration.	2:47
EDGE-3	SpiceDB migration connected to Postgres 17 without any authentication errors. No password authentication failures, no pg_hba.conf entry errors.	2:55
ROUTE-3	Full SpiceDB stack started successfully. spicedb-postgres healthy, spicedb-migrate exited(0), spicedb serving gRPC on port 50051 and HTTP REST gateway on port 8443.	5:18
ROUTE-4	Verified Manage UI auto-login in local dev mode, navigated to dashboard, created project and agent with CRUD operations working correctly through SpiceDB on Postgres 17.	6:09
ROUTE-6	Verified API authorization chain works with SpiceDB on Postgres 17: dev-session auth (200), list projects (200), create agent (201), delete agent (204), unauthenticated rejection (401).	11:34
ROUTE-5	Production compose stack verified: spicedb-postgres-db container starts healthy with postgres:17-alpine, SpiceDB migration succeeds, Manage UI loads successfully.	16:05
ADV-4	Postgres 17 container resource usage remained stable during authorization-intensive operations. CPU stable at ~2.8%, no OOM kills or connection errors.	48:03
ADV-1	Verified graceful degradation when spicedb-postgres was stopped. UI showed error pages without hanging. After Postgres restart, UI recovered without requiring full stack restart.	49:43
ADV-2	Rapid page navigation during Postgres restart — all pages loaded without hanging indefinitely. After spicedb-postgres became healthy, UI recovered on page refresh.	50:23
ADV-3	Verified SpiceDB handles Postgres volume destruction and recreation correctly. After new container and migration, full authorization chain succeeded with no stale connection errors.	54:36

❌ Failed (2)

Test Case	Summary	Timestamp	Screenshot
EDGE-1	Postgres 17 cannot start with existing Postgres 16 data volume. Container enters restart loop with FATAL error. Users must delete volumes before upgrading.	18:34
EDGE-5	Version inconsistency: create-agents-template uses postgres:16-alpine while main repo uses postgres:17-alpine. Template files were not updated by this PR.	19:30

EDGE-1: Existing Postgres 16 volume compatibility with Postgres 17 – Failed

• Where: Docker container startup with pre-existing data volume

• Steps to reproduce:

  1. Start the SpiceDB stack with postgres:16-alpine to create a Postgres 16 data volume
  2. Stop containers without removing volumes (docker compose down without -v)
  3. Change the image to postgres:17-alpine (as this PR does)
  4. Attempt to start the container with the existing volume

• What failed: Postgres 17 container enters a restart loop with FATAL error: "database files are incompatible with server. The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.8."

• Code analysis: Examined the docker-compose files where volumes are defined. The spicedb-postgres-data volume in docker-compose.dbs.yml persists data at /var/lib/postgresql/data. When the image is upgraded from Postgres 16 to 17, the data directory format is incompatible.

• Relevant code:

  docker-compose.dbs.yml (lines 64–79)

  spicedb-postgres:
    image: postgres:17-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: spicedb
      POSTGRES_PASSWORD: spicedb
      POSTGRES_DB: spicedb
    ports:
      - "5434:5432"
    volumes:
      - spicedb-postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U spicedb"]
      interval: 2s
      timeout: 3s
      retries: 30

  docker-compose.yml (lines 142–155)

  inkeep-agents-spicedb-postgres-db:
    image: postgres:17-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=spicedb
      - POSTGRES_PASSWORD=spicedb
      - POSTGRES_DB=spicedb
    volumes:
      - inkeep-agents-spicedb-postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U spicedb"]
      interval: 2s
      timeout: 3s
      retries: 30

• Why this is likely a bug: This is a breaking change for users upgrading from an existing deployment. PostgreSQL major version upgrades do not support in-place data directory upgrades — users must either dump/restore data or delete volumes. This PR changes the default image version without documenting the required migration steps, which will cause existing deployments to fail.

• Introduced by this PR: Yes – this PR modified docker-compose.dbs.yml and docker-compose.yml to change from postgres:16-alpine to postgres:17-alpine.

• Timestamp: 18:34

EDGE-5: create-agents-template still uses postgres:16-alpine — version inconsistency – Failed

• Where: create-agents-template/docker-compose.db.yml and create-agents-template/docker-compose.yml

• Steps to reproduce:

  1. Check the SpiceDB Postgres image version in main repo files: docker-compose.dbs.yml (line 65) and docker-compose.yml (line 143)
  2. Check the SpiceDB Postgres image version in template files: create-agents-template/docker-compose.db.yml (line 65) and create-agents-template/docker-compose.yml (line 142)
  3. Compare the versions

• What failed: Main repo uses postgres:17-alpine but template files still use postgres:16-alpine. This creates inconsistency between the main repo and the project template used to bootstrap new deployments.

• Code analysis: Examined the PR changes to see which files were modified. Only docker-compose.dbs.yml and docker-compose.yml were updated. The template files in create-agents-template/ were not included in the PR, leaving them with the older Postgres 16 version.

• Relevant code:

  create-agents-template/docker-compose.db.yml (lines 64–79)

  spicedb-postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: spicedb
      POSTGRES_PASSWORD: spicedb
      POSTGRES_DB: spicedb
    ports:
      - "5434:5432"
    volumes:
      - spicedb-postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U spicedb"]
      interval: 2s
      timeout: 3s
      retries: 30

  create-agents-template/docker-compose.yml (lines 141–154)

  inkeep-agents-spicedb-postgres-db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=spicedb
      - POSTGRES_PASSWORD=spicedb
      - POSTGRES_DB=spicedb
    volumes:
      - inkeep-agents-spicedb-postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U spicedb"]
      interval: 2s
      timeout: 3s
      retries: 30

• Why this is likely a bug: New projects bootstrapped from create-agents-template will use Postgres 16 while the main repo uses Postgres 17. This version inconsistency means template-based deployments won't match the main repo's configuration, potentially causing confusion and compatibility issues when developers reference the main repo's documentation or when templates are later upgraded.

• Introduced by this PR: Yes – this PR updated the main repo files but missed updating the corresponding template files, creating the inconsistency.

• Timestamp: 19:30

📋 View Recording

Screen Recording