[Sites] Deployment marked "Active" and "Ready" but router returns router_deployment_not_found (both custom domain and native appwrite.network preview URL)
- Dominant language
- TypeScript
- Stars
- 57.4k
- Forks
- 5.7k
- Avg merge
- 14h 50m
- Merged PRs (30d)
- 276
Description
### 👟 Reproduction steps
1. Have a Site on Appwrite Cloud with a custom domain configured, domain rule type set to "Active deployment" (e.g. mercadolaw-front.cobradevs.xyz).
2. In the Deployments list, delete several older deployments.
3. Trigger a new deployment (manual deploy from a Git branch, e.g. `test`) and wait for it to finish building — status shows "Ready".
4. Activate that deployment — it shows the green "Active" dot in the Deployments list.
5. Visit the custom domain in a browser (incognito, hard refresh), or click "Visit" on the deployment detail page (the native `*.appwrite.network` preview URL).
6. See error.
### 👍 Expected behavior
The site should serve the content of the deployment currently marked "Active" — both via the custom domain and via the native `*.appwrite.network` preview URL.
### 👎 Actual Behavior
Both the custom domain and the native `*.appwrite.network` preview URL return HTTP 404 with:
{"type":"router_deployment_not_found","message":"This page is empty, activate a deployment to make it live.","code":404,"version":"0.9.44"}
...despite the deployment being marked "Active" and "Ready" (build succeeded in 1m11s, 9.74MB output — not an empty build). This also reproduces inside Appwrite's own embedded preview iframe in the console: both the deployment detail page and the site overview page show the "This page is empty, activate a deployment to make it live." placeholder for a deployment that is marked Active.
Before deleting the old deployments, the custom domain was serving a *different, stale* deployment ID (visible via the `X-Appwrite-Deployment-Id` response header) than the one marked "Active" in the console, for 45+ minutes after activation. Requests to different edge nodes (nyc, mia, pdk) returned inconsistent `X-Edge-Rule-Cache` states (`hit` vs `miss`) for the same hostname at the same time — suggesting the domain→deployment routing rule is cached per edge node and not invalidated consistently on activation.
Deleting the old deployments to try to force a clean state made it worse: the router now can't resolve *any* deployment for the site, even with a valid Active/Ready deployment present.
This looks related to #12227, though there the error is a container-not-ready 500 that resolves after a delay, while here it's a consistent `router_deployment_not_found` that has not resolved on its own.
### 🎲 Appwrite version
Appwrite Cloud
### 💻 Operating system
Linux
### 🧱 Your Environment
- Site: mercadoLaw-front-test
- Custom domain: mercadolaw-front.cobradevs.xyz, domain rule type "Active deployment"
- DNS: domain registered at Namecheap; Appwrite-managed DNS zone (delegated nameservers ns1/ns2.appwrite.zone) shows "Not verified" and has been in that state for ~1 month — current live routing works through Appwrite's standard A/AAAA/CNAME records added directly at the registrar, not through the Appwrite-delegated zone.
- No Cloudflare or other third-party CDN/proxy in front of the domain — confirmed via response headers (X-Appwrite-Project-Id, X-Edge-Location, etc. present directly).
- Deployment source: manual deploy from GitHub branch `test`.
### 👀 Have you spent some time to check if this issue has been raised before?
- [x] I checked and didn't find similar issue
### 🏢 Have you read the Code of Conduct?
- [x] I have read the [Code of Conduct](https://github.com/appwrite/.github/blob/main/CODE_OF_CONDUCT.md)
Contributor guide
Research direction
Start by reproducing the failure through the deployment activation flow and both the custom domain and native appwrite.network preview URL. Trace how the router resolves the active deployment and how domain-to-deployment rules are cached across edge nodes. Done means an Active and Ready deployment serves its content consistently through both URL types, including the embedded preview.
Written by the indexing model from the issue text.
Assessment
- Domain
- backend-api-design, cloud, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100