## Summary
Promote the production registry image from `1.8.0` to
[`1.8.1`](https://github.com/modelcontextprotocol/registry/releases/tag/v1.8.1).
This release includes #1509, which adds a short ingress cache and a
scoped rate-limit increase for the exact public registry-list endpoints.
## Staging verification
- release tag points to `f52dc8525a`, the
commit deployed to staging
- staging deployment and CI workflows completed successfully
- both registry replicas became ready with zero restarts
- rendered NGINX configuration kept the root route at 180 RPM with
buffering off
- exact `/v0/servers` and `/v0.1/servers` routes rendered at 600 RPM
with buffering on
- live cache probe returned `MISS`, then `HIT`
- health and unrelated routes remained uncached
- no application 5xx, serious NGINX errors, or application error logs
were observed after rollout
## Release artifact
- release workflow completed successfully
- `ghcr.io/modelcontextprotocol/registry:1.8.1` is available for
`linux/amd64` and `linux/arm64`
## Deployment and rollback
Merging this PR triggers the production Pulumi deployment automatically.
Monitor registry pod readiness, NGINX reloads, cache behavior, origin
request volume, 429/499/5xx responses, and publish requests exceeding 10
seconds.
Rollback by restoring `mcp-registry:imageTag` to `1.8.0`.
Promotes production to the
[`v1.8.0`](https://github.com/modelcontextprotocol/registry/releases/tag/v1.8.0)
release.
- `deploy/Pulumi.gcpProd.yaml` → `imageTag: 1.8.0` (one line).
- The release build for `v1.8.0` completed successfully, so the image is
present in ghcr.
- **Merging this triggers `deploy-production.yml`** (it's path-filtered
to `deploy/Pulumi.gcpProd.yaml`); the PR itself doesn't deploy.
### Notable behavior changes in v1.8.0
- **Org-namespace publishing now requires org Owner** (via GitHub login
/ PAT). Member-level publishers lose org publish — intended tightening.
- Stricter validation may reject some previously-accepted package
metadata / names (#1310, #1331, #1411).
- New: cargo (crates.io) package registry support (#1207).
### After merge
- Confirm prod `/v0/version` reports `1.8.0` before treating the rollout
as done.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
## Summary
- Bump `mcp-registry:imageTag` from `1.7.7` → `1.7.8` in
`deploy/Pulumi.gcpProd.yaml`
- v1.7.8 ships the metrics fix that stops counting client-cancelled
requests as server errors (#1255). Under scraper-driven load, clients
with short timeouts close the socket while PG is still iterating; the
handler converts `context.Canceled` to a 500 and the metric middleware
was bumping `mcp_registry_http_errors_total` even though NGINX recorded
499 and never delivered a response. This is what's been firing the daily
~17:00 UTC `Availability dropped below 95%` alert.
- Also includes a CI-only `pulumi/actions` 6.6.1 → 7.0.0 bump (#1254).
No registry runtime impact.
- Staging is on `4e14707` (the v1.7.8 commit) and
`staging.registry.modelcontextprotocol.io/v0.1/version` reports it.
## Test plan
- [ ] Confirm release workflow's `ko-push` job has published
`ghcr.io/modelcontextprotocol/registry:1.7.8` before merging
- [ ] Watch deploy-production roll the registry pods to `1.7.8`
- [ ] Hit `https://registry.modelcontextprotocol.io/v0.1/version` and
confirm `git_commit` matches `4e147072f0`
- [ ] Through the next ~17:00 UTC scraper burst, watch in Prometheus:
- `mcp_registry_http_errors_total{status_code="500",
path="/v0.1/servers"}` should stay flat
- `mcp_registry_http_requests_total{status_code="499",
path="/v0.1/servers"}` should grow during the burst
- The `Availability dropped below 95%` alert should not fire on
cancellation-only bursts
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
- Bump `mcp-registry:imageTag` from `1.7.6` → `1.7.7` in
`deploy/Pulumi.gcpProd.yaml`
- v1.7.7 is a security patch covering three findings (validator
hardening, attribute-context UI escaping, IPv6 SSRF blocklist
extension); see the v1.7.7 release notes
- Staging is on `f5f40bd` (the v1.7.7 commit) and verified end-to-end:
- `/v0.1/version` reports the new commit
- `/v0.1/validate` rejects a poisoned `websiteUrl` with
`website-url-invalid-characters`
- `/` HTML serves the `escapeAttr` helper
## Test plan
- [ ] Confirm release workflow's `ko-push` job has finished publishing
`ghcr.io/modelcontextprotocol/registry:1.7.7` before merging
- [ ] Watch deploy-production workflow rolls the registry pods to
`1.7.7`
- [ ] Hit `https://registry.modelcontextprotocol.io/v0.1/version` and
confirm `git_commit` matches `f5f40bd...`
- [ ] Spot-check the catalogue UI loads cleanly
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Promotes
[v1.7.4](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.4)
(#1225) to production: registry pod memory request `256Mi → 512Mi`,
limit `512Mi → 1Gi`.
## Why
#1221 doubled pgxpool `MaxConns` 30→60 per pod without bumping the
registry pod memory limit. pgxpool keeps per-connection state in the Go
process (prepared statement cache, scratch buffers, row iteration state)
so peak per-pod memory shifted from ~330 MB to ~450 MB against the 512
MiB limit. Pod `tx49f` was OOMKilled at 17:01 UTC on 2026-04-29.
## Validation so far
- Staging deployed cleanly via `deploy-staging.yml` after #1225 merged
- Both staging pods running with `req=512Mi limit=1Gi` ✓
- Rolling update was clean — no failed health checks during the
transition
- Both pods spread across nodes (q716 + 7exo)
## Deployment
**Zero downtime** — Deployment template change only, rolling update with
`maxSurge: 1, maxUnavailable: 0`. No PG involvement (no
`max_connections` change, no shared_preload_libraries change).
## Test plan
- [x] v1.7.4 release built and pushed
(`ghcr.io/modelcontextprotocol/registry:1.7.4`)
- [x] Staging deployed cleanly with new limits
- [ ] Prod Pulumi run applies cleanly; rolling update completes
- [ ] Prod pods come up with `req=512Mi limit=1Gi`
- [ ] After 24h: no OOMKills on either pod, peak memory stays under ~600
MB
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Promotes
[v1.7.3](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.3)
to production. Contents:
- **#1220** — `RemoteURL` filter SQL rewritten to use JSONB containment
(`@>`) instead of `EXISTS jsonb_array_elements`. The new form is
GIN-indexable; the old form forced a full table scan. Local benchmark:
40,398 → 294 buffer reads, 17 ms → 1.6 ms. Maps to prod's 10,005 ms
cold-cache observation.
- **#1221** — pgxpool `MaxConns 30→60`, `MinConns 5→10`. PG
`max_connections 100→200`. Explicit PG `resources:` block (was unset).
## What this addresses
- **#1220**: yesterday's 17:08 UTC `Publish Endpoint Latency` alert
(`dev.storage/mcp` publish took 14.8s with `remotes_ms=10980` —
pinpointed by the per-phase slog from #1215).
- **#1221**: yesterday's 17:35–17:40 UTC `Availability dropped below
95%` alert and 18:17 UTC `Publish Endpoint Latency` re-fire. Both were
scraper-driven concurrency on `/v0/servers` (~15 req/s sustained from
ServiceNow + others). With the bumped pool, the queue at the Go HTTP
layer should clear faster instead of blowing up to 20–35s nginx-level
latencies.
## Deployment caveat
The PG `max_connections` change is a postmaster-level setting → CNPG
triggers a PG restart on the next prod Pulumi run. With `instances: 1`
this is brief downtime — staging took **~30s** during the equivalent
restart, with **one registry pod bouncing once** on its 8-attempt
DB-retry budget before recovering on the next kubelet restart.
**Time the merge for a low-traffic UTC window.** Alert history suggests
very early UTC (02:00–04:00) is quietest.
## Resource impact
PG node memory is currently 39% (~2.4 GiB / 6 GiB allocatable).
Worst-case PG memory growth with `max_connections=200` lands around 3–4
GiB, putting the node at ~65% — fits with headroom. Empirically, prod PG
has peaked at **413 MiB** in the last 30h of incident data, so the
proposed 4 GiB limit is ~10× the historical max — guardrail not
constraint.
## Post-merge
CNPG handles `pg_stat_statements` extension creation automatically (no
manual `CREATE EXTENSION` step needed — it was already done in v1.7.2's
deploy).
Verify after deploy:
```bash
PATH=/opt/homebrew/share/google-cloud-sdk/bin:$PATH
# max_connections actually changed
kubectl exec -i registry-pg-1 -c postgres \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-- psql -U postgres -tAc "SHOW max_connections" # expect: 200
# resources block applied
kubectl get pod registry-pg-1 \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-o jsonpath='{.spec.containers[?(@.name=="postgres")].resources}{"\n"}'
# pgxpool MaxConns reflected (registry app uses 60 per pod after restart)
kubectl exec -i registry-pg-1 -c postgres \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-- psql -U postgres -tAc "SELECT count(*) FROM pg_stat_activity WHERE datname='app'"
```
## Test plan
- [x] v1.7.3 release built and pushed
(`ghcr.io/modelcontextprotocol/registry:1.7.3`)
- [x] Staging deployed cleanly; PG restarted and came back with
`max_connections=200`; one staging pod bounced as expected
- [ ] Prod Pulumi run applies cleanly; brief PG restart
- [ ] Confirm `SHOW max_connections` returns 200 on prod
- [ ] Confirm `publish complete` events show `remotes_ms` < 10ms
- [ ] Watch for any "too many connections" errors during the rollout
window (none expected — Pulumi orders CNPG cluster before Deployment, so
PG accepts the new conn limit before pgxpool tries to use it)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Promotes
[v1.7.2](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.2)
(PR #1215) to production:
- **Row-constructor cursor pagination** — fixes the 760ms list query
that was the root cause of today's pool-exhaustion alerts. Local
benchmark shows /v0/servers paginated requests dropping from ~30ms (cold
cache, 100K rows) to ~0.05ms.
- **Per-phase publish slog** — `publish complete` events now include
validate / lock / remotes / version_checks / unmark / db_create timings
so the next slow publish is self-diagnostic.
- **pg_stat_statements** — aggregate query visibility we didn't have
during today's incident.
## Deployment caveat
The CNPG cluster spec change for `pg_stat_statements` triggers an in-pod
postgres restart on the next prod Pulumi run. Staging took **~45–70s of
registry unavailability** during the equivalent restart. The DB
retry-with-backoff in v1.7.1 covers most of it, but registry pods may
bounce once before they reconnect (one staging pod hit `Failed to
connect after 8 attempts` then recovered on its next restart).
**Time the merge for a low-traffic UTC window** — the alert history
suggests very early UTC is quietest.
## Post-merge action
Once the prod Pulumi run completes, run once on the existing cluster:
```bash
PATH=/opt/homebrew/share/google-cloud-sdk/bin:$PATH
kubectl exec -i registry-pg-1 -c postgres \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-- psql -U postgres -c "CREATE EXTENSION IF NOT EXISTS pg_stat_statements"
```
Verify:
```bash
kubectl exec -i registry-pg-1 -c postgres \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-- psql -U postgres -d app -c "
SELECT round(mean_exec_time::numeric, 2) AS mean_ms, calls,
substring(query, 1, 80) AS q
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;"
```
## Test plan
- [x] v1.7.2 release built and pushed
(`ghcr.io/modelcontextprotocol/registry:1.7.2`)
- [x] Staging deployed cleanly; `pg_stat_statements` is collecting on
staging
- [ ] Prod Pulumi run applies cleanly; brief PG restart
- [ ] Run `CREATE EXTENSION` on prod
- [ ] Confirm `publish complete` events contain per-phase timings on the
next publish
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Promotes
[v1.7.1](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.1)
to production. Contents: the hardening + diagnostics from #1211.
What's in v1.7.1 (vs v1.7.0):
- Pulumi-managed IAM bindings for the default compute SA so
fluentbit-gke and the GMP collector can ship logs/metrics (already
applied to live cluster manually)
- `PodDisruptionBudget` with `minAvailable: 1` +
`TopologySpreadConstraints` to keep pods spread across nodes
- `StartupProbe` (30 × 5s) covering the new DB-retry budget
- Bounded retry-with-backoff on initial DB connect in
`cmd/registry/main.go`
- Memory request 128→256Mi, limit 256→512Mi
- `slog` `validate_ms` timing on the publish path so the next slow
`/v0/publish` is self-diagnostic
## Test plan
- [x] v1.7.1 release workflow built and pushed image successfully
(`ghcr.io/modelcontextprotocol/registry:1.7.1`)
- [x] Pulumi.gcpProd.yaml diff is the single-line image bump
- [ ] On merge, `deploy-production.yml` rolls out v1.7.1 — watch for
clean rolling update (`maxSurge: 1`, `maxUnavailable: 0`) and confirm
both pods reach Ready
- [ ] After rollout, confirm `Starting MCP Registry Application v1.7.1`
shows up in Cloud Logging from the new pods
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
- Bumps production image tag from `1.6.0` to `1.7.0` in
`deploy/Pulumi.gcpProd.yaml`
- Corresponds to the [v1.7.0
release](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.0)
- Notable change: includes #1201 — fixes#1081 (`isLatest` no longer
stranded after soft-delete) and ships migration `014_heal_is_latest`
that auto-heals affected servers (e.g.
`io.github.containers/kubernetes-mcp-server`) on deploy
## Test plan
- [ ] Verify Pulumi preview shows only the image tag change
- [ ] After deploy, confirm migration 014 ran and
`io.github.containers/kubernetes-mcp-server`'s `/versions/latest`
returns `0.0.61` (or whichever is highest non-deleted)
- [ ] Sample a few unaffected servers and confirm `isLatest` is
unchanged
- [ ] Confirm overall service health
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
- Bumps production image tag from `1.5.0` to `1.6.0` in
`deploy/Pulumi.gcpProd.yaml`
- Corresponds to the [v1.6.0
release](https://github.com/modelcontextprotocol/registry/releases/tag/v1.6.0)
## Test plan
- [ ] Verify Pulumi preview shows only the image tag change
- [ ] Deploy and confirm the service is healthy
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
- Updates the production image tag in `deploy/Pulumi.gcpProd.yaml` from
`1.4.1` to `1.5.0`
## Test plan
- [ ] Verify the Pulumi deployment picks up the new image tag
- [ ] Confirm the v1.5.0 container image exists in the registry
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR bumps prod to v1.4.1
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR promotes the version of the registry in prod to 1.4.0
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR promotes prod to 1.3.10
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
This needs to be merged after we merge
https://github.com/modelcontextprotocol/registry/pull/726 and we cut a
release for v1.3.7
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Promotes prod to 1.3.3, the main changes are making mcpb package version
optional and also fixing the enforced schema validation.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Bumps prod to 1.3.2
Note
https://github.com/modelcontextprotocol/registry/actions/runs/18570490434
needs to complete before merging
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR fixes the docs and the image reference for prod since
they don't expect to have the v prefix there.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
---------
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR bumps prod to v1.3.0
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
The following PR moves away from automatically promoting latest releases
to production in favour of specifying the released version explicitly
via a PR & Review process.
Still sets the image tag to latest for now so we can enable it
separately whenever we decide 👍
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
This includes infra setup for metrics collection and visualisation
## Motivation and Context
It is important to have basic observability setup, so that common issues
can be identified quickly
## How Has This Been Tested?
- Tested on local
- Tested on one of the production setup
## Breaking Changes
No
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [X] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [X] My code follows the repository's style guidelines
- [X] New and existing tests pass locally
- [X] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
- This includes set up of following components:
- Victoriametrics single node cluster for storing metrics data with
persistent storage configuration for local and production env.
- Vmagent with target discovery for mcp-registry pods with scrape
interval of 30s.
- Grafana for visualising metrics and setting alerts.
- Datasource of victoriametrics is pre-configured as config map
- Persistent volume for basic configuration
- Sqlite for local and Postgres for production setup for storing
dashboard, alerts etc details
## Metrics in action
<img width="1422" height="666" alt="Screenshot 2025-08-31 at 4 35 28 AM"
src="https://github.com/user-attachments/assets/e54ce846-653c-4fa3-aa7a-fe277f0810e6"
/>
---------
Co-authored-by: Adam Jones <adamj@anthropic.com>
Co-authored-by: adam jones <adamj+git@anthropic.com>
## Motivation and Context
- Adds credentials for the new MCP Registry Login GitHub Apps (local,
staging, prod)
- Adds support for "none" auth to publisher
## How Has This Been Tested?
- Tested publisher workflows locally
- Unit and integration tests passing
## Breaking Changes
None
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
---
Merging based on Tadas's approval review, and only making minor docs changes on top of that.
Fixes#264. Adds endpoints:
```
/v0/auth/github # exchange a github token for a registry token that gives you access to namespaces io.github.username and io.github.org for your orgs
/v0/auth/none # get a registry token for namespace io.modelcontextprotocol.anonymous (only for testing/local dev purposes)
```
Updates `/v0/publish` to accept one of these registry tokens.
## Motivation and Context
See #264
## How Has This Been Tested?
- Running locally and getting a token from `/v0/auth/none` and then
publishing to `/v0/publish`
- Updating the integration tests that get a token and then publish, and
them passing
## Breaking Changes
This is a breaking change to the auth API. This is fine for registry
given it's not deployed yet.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: adam jones <domdomegg@users.noreply.github.com>
Adds the Pulumi code to:
- Deploy the registry (and associated services e.g. mongodb) to Google
Cloud Platform (GCP), on top of Google Kubernetes Engine (GKE)
- Sets up proper environments and secrets management
- Uses the real container image, now that it's published in #225. At the
moment attached to latest, we might want to pin the version later (or
perhaps always use `latest` in staging, and pin prod)
- Uses real domains (`staging.registry.modelcontextprotocol.io`) rather
than examples (``)
## Motivation and Context
Setting up infrastructure to deploy it. I set something up in Azure in
#227, although not super robust (e.g. no service accounts etc.). Think
we will use GCP as:
- the maintainers have experience with GCP, but none with Azure
- costs are quite low, and Anthropic is happy to cover them in the short
term
- means we only have to maintain one login system (just Google Cloud
Identity), not two (Google Workspace + Azure)
## How Has This Been Tested?
Deployed this to a staging and production cluster. Try it yourself at:
```bash
curl -H "Host: staging.registry.modelcontextprotocol.io" -k https://35.222.36.75/v0/ping
```
(will be sorting out domains very soon)
## Breaking Changes
NA - just adds support for GCP deployment
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Expected follow-ups:
- GitHub Action setup to deploy things to the cluster from GitHub, to
avoid gatekeeping to just the people with the secrets.
