Description: open-source Algolia alternative on Railway Category: Analytics URL: https://railway.com/deploy/oss-algolia-alternative

Our production mobile app has lost traffic from mainland Chinese iOS users since approximately September 21, 2026, 01:00 UTC (10:00 KST). The last successful request we identified was at 00:56:08 UTC. Other regions continue working. Affected endpoint: https://api-production-96da.up.railway.app Resolves to: 69.46.46.45 Findings: - Six mainland China probes, including China Unicom, China Mobile, Alibaba and Tencent networks, timed out establishing the TCP connection. - DNS resolution succeeds. The connection fails before TLS or HTTP, so there is no HTTP error or request ID. - The same endpoint returns HTTP 200 from Seoul and Singapore. - Our custom domain, https://api.mamalog.darak.studio, resolves to 69.46.46.43 and returns HTTPS 200 from three mainland China probes. - Both domains serve the same Railway service. - No deployment occurred around the outage onset. The latest deployment was September 20 at 11:57:48 UTC. Project ID: 037e9a52-cf62-4572-a7a0-8910308b2472 Service: api Service ID: 99037d5c-eeeb-42c4-9014-6e59abaf83d2 Environment: production Region: Southeast Asia Deployment ID: 67d1f098-f0d3-431c-abca-1a54805cdc48 Measurements: Failing China residential networks: https://api.globalping.io/v1/measurements/2DoMnFWDZRZ1goBpL00021Aw1 Failing China cloud networks: https://api.globalping.io/v1/measurements/2tD5eJ309WZj4P1Go00021Aw1 Working custom domain from China: https://api.globalping.io/v1/measurements/2Fp1OTFia55cZuVfs00021Aw1 Working affected domain from Korea/Singapore: https://api.globalping.io/v1/measurements/2h7hcXJzgMXSLaDrA00021Aw2 Could your networking team urgently investigate reachability to 69.46.46.45 from mainland China? Can you restore connectivity or move the existing Railway-provided hostname to a reachable ingress IP without changing the hostname? Installed mobile apps have this hostname hardcoded, so changing our custom domain alone will not restore access for existing users. We have not determined whether this is filtering or a routing issue. Please investigate the network path and advise on immediate mitigation.

Description: glue APIs with a webhook backend Category: Automation URL: https://railway.com/deploy/n8n-webhook-api

We are coordinating a logging credential rotation for two staging services using Railway CLI 5.45.7 and the public GraphQL API. Please confirm these supported server-side behaviors; this is a technical question, not a request to modify our account. 1. With an unapplied environment stage affecting only service B, does variableUpsert with exact projectId, environmentId, serviceId=A, name, value and skipDeploys:true update A's saved configuration while preserving B's staged contents, STAGED status and appliedAt:null, without creating a deployment? 2. Does a subsequent railway up targeting only service A use A's newly saved variables without applying B's pending stage? Changes to stage ID or timestamp alone are acceptable; contents and application state are what matter. 3. Alternative: if both services' approved changes may be combined, what is the supported path to merge only those changes into one staged changeset, commit it without starting any deployment, then upload exact source to service A, verify A, and only then upload exact source to B? Specifically, does environmentStageChanges(merge:true), followed by environmentPatchCommitStaged(skipDeploys:true), persist that changeset without deploying either service? How should actual variable unsets be represented and verified when decryptVariables:false returns opaque staged values? We need to preserve unrelated configuration and cannot use a normal Deploy/Apply all action that starts deployments. No new resources or plan changes are requested. Please point to the authoritative contract, or explicitly confirm the existing-stage and no-deploy behavior. We have reviewed the manage-variables documentation, staged-changes documentation and CLI 5.45.7 source. This public question intentionally contains no project, service or deployment identifiers, site names, local paths, private repository information, credential values, logs or attachments.

Given all the developments with and around ChatGPT this year (see, e.g., https://quitgpt.org/), I wonder why Railway decided to focus on it, still. And why not rather collaborate with, e.g., Anthropic; especially when dealing with people's private servers etc?

Description: scheduled reports and cron workflows Category: Automation URL: https://railway.com/deploy/n8n-cron

Project truthful-caring (ee1d7a37-1af2-491d-9fcf-0bbfe52b76ed), production environment (58ec7745-b8b6-45cd-8bdd-eb64dbe39a19), service Supa (dcb68bad-37c7-4e88-8e29-173611046334). MobileMessage webhook delivery stopped after 2026-09-19 14:40:18 UTC. Last known successful source IP: 209.38.21.135 (current egress confirmation pending). Their delivery worker reports connection timeout/no response for both supa-production-060b.up.railway.app and ai-jane.com.au, path /api/v1/sms-webhook/mobilemessage. The earlier investigation found no deployment at onset and no subsequent provider HTTP requests across the deployment history. Fresh evidence on deployment 45896aab-2035-4a18-a211-74a0258cf288: during 2026-09-21 07:20 to approximately 07:50 UTC, 179 HTTP requests were logged; 17 webhook requests were all our local probes from 115.70.99.7. Successful probes to both hostnames used HTTP/2, returned 200 in 3-12 ms, and were handled by edge region asia-southeast1-eqsg3a. Example successful request ID: R1bSBCKQFeJhlXfmrpb1w at 07:39:26.765263940 UTC on ai-jane.com.au. Please investigate edge filtering/rate limits and TCP/TLS routing for the provider source IP, including any changes around onset. Can your edge telemetry show connection attempts that never produce HTTP logs? MobileMessage says it cannot expose its worker diagnostics to frontline support, so we are requesting engineering escalation there too. Bypass assessment A Cloudflare relay could test a different ingress route, but the handoff's proposed immediate-200/background-forward design has a failure gap: the provider stops retrying as soon as it sees success, even if forwarding subsequently fails. If built, acknowledge only after durable queue acceptance, then forward with bounded retries and dead-letter handling. Keep retries within the backend's 12-hour dedup retention; manually review expired events rather than blindly replaying days later. Keep the existing poller. Changing MOBILEMESSAGEINBOUNDMINAGESECONDS to 30 would reduce the nominal grace-plus-poll delay to roughly 30-90 seconds, plus processing/scheduling time. It does not repair webhook delivery. This is an undeployed option requiring the explicit production-change approval specified in AGENTS.md and docs/INSTRUCTIONAUTHORITY.md section 4

My Flutter Web service has been stuck on "scheduling build on Metal builder (builder-cbuxkt)" for over 10 minutes without executing a single line of the Dockerfile. The build never starts and eventually fails with "Failed to build an image." What I've tried: \- Multiple redeployments \- Switched builder back and forth between Nixpacks and Dockerfile \- Updated the Dockerfile to use a lighter base image (debian:bookworm-slim instead of ghcr.io/cirruslabs/flutter:stable) \- Verified Root Directory and Dockerfile path (/Dockerfile) are correct Build logs only show: \\\` scheduling build on Metal builder "builder-cbuxkt" scheduling build on Metal builder "builder-cbuxkt" Setup: \- Branch: main \- Builder: Dockerfile at /Dockerfile \- No Root Directory set (Dockerfile is at repo root) \- Plan: Hobby (paid) This seems to be an infrastructure issue on Railway's side as the configuration is correct and was working before. Please advise.

Project: peaceful-peace (da8019e9-f74b-46c3-a5a0-f33e06bd6b91) Service: WHK (35da46cc-117c-45a1-915a-b03f77927ac1) Environment: production (d08b554b-3675-4d43-8759-fa669a07d61b) Custom Domain Details: - Domain: www.werkhervattingskas.nl - Domain ID: 925afc00-3a94-4c4d-989c-bd17297b812f - Status: Verified=no, Certificate=ISSUING (stuck >72 hours since 2026-09-18) - Railway UI: Waiting for DNS update; CNAME green check; TXT yellow warning Current DNS Configuration (verified live via Google/Cloudflare DNS): - CNAME: www → tny9s8i5.up.railway.app (propagated) - TXT: railway-verify.www.werkhervattingskas.nl = railway-verify=83fd70d116b71f0ea7657a5dad8cd60f8abed43d29e958ee4f1b08c7c43c524b (live) Current TLS: - Live CN/SAN still .up.railway.app (custom cert not issued) DNS Environment: - Nameservers: TransIP; DNSSEC enabled - No CAA records blocking Let's Encrypt on apex - Apex werkhervattingskas.nl on same service: Verified=yes, VALID certificate Request: Please investigate why ownership verification is not completing for this subdomain despite correct CNAME and TXT for >72 hours. Do NOT require domain deletion/recreation. Please do not delete any Railway domains.

Hello Railway Support, We run a FastAPI application with Uvicorn 0.34.0 behind Railway Public Networking. A POST endpoint requires HTTPS and a dedicated Bearer token. Railway terminates TLS before forwarding requests to the application. The internal proxy peer IP varies between requests, so allowlisting individual IPs with FORWARDEDALLOWIPS is unreliable. When the proxy is not trusted, the application sees request.url.scheme == "http" and rejects the request. We do not want to trust all IPs, guess a proxy CIDR, or rely solely on client-spoofable Host/forwarded headers. Bearer authentication must remain, but it does not prove that a request passed through the HTTPS proxy. Could you confirm: Is there an officially supported configuration that allows only Railway’s Public HTTPS proxy to reach the application’s listening port, blocking direct public and private-network access? If so, what are the exact settings and limitations? Does Railway provide a verifiable proxy identity mechanism that does not depend on source IPs—for example, proxy-to-application mTLS or cryptographically signed forwarding metadata? If neither is available, what supported configuration do you recommend for reliably enforcing HTTPS at this endpoint without trusting all proxies or adding another proxy service? Please include the relevant documentation, whether X-Forwarded-Proto is overwritten or sanitized by the edge, and any plan or runtime requirements. Thank you.