Description: Self-host MariaDB — the open-source MySQL-compatible database Category: Storage URL: https://railway.com/deploy/mariadb-database

Description I’m experiencing a persistent GitHub source connection issue with Railway. The repository is visible and selectable when creating a new Railway project from GitHub. Railway successfully builds and deploys the application from that repository, and the deployed service works correctly. However, immediately after deployment, the service’s Settings → Source section shows: “GitHub Repo not found” The source connection appears to be lost even though the initial deployment was successfully created from that same repository. When I click Connect Repo and search for the repository again, Railway reports: “No repositories found — try a different search” ##Repo details: GitHub repository: https://github.com/atrx07/aveline-bot owner: atrx07 default branch: main visibility: public already tried- - Disconnected and reconnected the repository source. - Refreshed the available repository list. - Uninstalled and reinstalled the Railway GitHub App. - Confirmed the Railway GitHub App has access to the repository. - Confirmed the correct GitHub account owns the repository. - Created an entirely new Railway project. - Confirmed the repository is still visible in the initial “New Project → Deploy from GitHub” window. - Confirmed the same issue occurs again after the first deployment. additional- The repository is consistently visible during initial project creation, so Railway clearly has access to it at that stage. The problem appears specifically after the service has been created: the persisted source association becomes unavailable or points to an invalid GitHub installation/reference. The application itself deploys and runs successfully. The only broken part is the retained GitHub source connection and therefore automatic deployments.

Description: Self-host Qdrant — fast vector search at scale for RAG & AI Category: AI/ML URL: https://railway.com/deploy/qdrant-vector-search

We're seeing recurring, severe stalls on plain COMMIT (and occasionally other statements — INSERT, DELETE, SELECT FOR UPDATE) with no application-level cause. Confirmed via logmindurationstatement=200 and railway logs -s Postgres --json: - 2026-07-12: bare COMMIT, 20016ms, zero concurrent traffic on the DB at the time (ruled out lock contention, replication, WAL archiving — nothing else was connected). - 2026-07-13: 07:29:16 UTC bare COMMIT, 20016ms; 10:25:52 UTC an activitylog INSERT (10928ms) and its COMMIT (10157ms) stalled back-to-back on the same connection. - 2026-07-20: DELETE on cartitems (7.4s) and a bare COMMIT (4.6s). - 2026-07-21: INSERT on lockers, 16.5s. - 2026-07-22: INSERT on activitylog, 12.5s. - 2026-07-25 08:43 UTC: COMMIT (9.7s) blocking a lock on an orders row (8.6s downstream wait). - 2026-07-25 17:04 UTC: bare COMMIT stalled 28.8s. Because a lockForUpdate() on a carts row was held across that COMMIT, three subsequent add-to-cart requests for the same cart queued behind it (23.6s, 11.2s, 4.3s waits) — this is what surfaced app-side as "add to cart very slow," with PHP-FPM's slow-log catching 5-6s+ requests and the frontend's retry logic turning it into duplicate POSTs / 499s. - 2026-07-26 07:22:07 UTC: bare COMMIT, 42996.719ms (43s) — new record. - 2026-07-26 07:34:23 UTC: bare COMMIT, 22971.856ms, same morning, same cascading lock-wait pattern on the carts table (wait chains up to 32.9s). We checked and ruled out: - Checkpoint I/O as a trigger (checkpoints logged just before/after each incident were themselves fast, 2-4s, and didn't overlap the stall windows). - Application-level causes (no long-held locks from our own code paths preceding these; the holder transaction's own COMMIT is what's stalling, not something the app is doing wrong). With synchronouscommit=on and no replica/archiving to sync against, the only thing a bare COMMIT waits on is the local WAL fsync — so this points to storage/disk-layer latency on the volume backing this Postgres instance, not anything at the SQL/application layer. We also found what looks like the same failure mode reported by a different Railway user on a different project: https://station.railway.com/questions/severe-postgres-disk-i-o-latency-38s-c-22bb5414 Given the trend (20s → 28.8s → 43s over two weeks) and the external report suggesting a shared-storage-host issue rather than something specific to our instance, could you: 1. Check whether our Postgres volume is on a degraded storage host (similar to the linked report), and migrate it if so. 2. Let us know if there's a way to get ahead of this proactively (host health monitoring, a dedicated/non-shared volume tier, etc.) rather than reacting to individual stalls. Happy to provide our project/service IDs, exact log excerpts, or a specific timestamp window if that helps you correlate against host-level metrics on your end.

Summary: Our service workout-tracker (project devoted-rejoicing / production) cannot connect to our MongoDB Atlas M0 cluster. Connections silently hang for the full timeout (no SYN-ACK, no RST) on port 27017, while all other outbound traffic from the same container works normally. Failing continuously since 2026-08-01 21:19 UTC. What we already ruled out: - Atlas IP Access List: 0.0.0.0/0 is active. - - Cluster health: Atlas shows "ready to use" (green), replica set healthy (1 PRIMARY + 2 SECONDARY). - - Connection string unchanged, standard mongodb+srv:// scheme. - - Both Railway and MongoDB Atlas status pages show fully operational. - - Restarted the deployment: no change. - - Moved the service region from US West to US East to match the Atlas cluster's stated region and redeployed: no change, identical NetworkTimeout errors immediately after the new deployment went active. Diagnostic run directly inside the container via the Railway web Console: Container egress IP: 162.220.234.6 DNS resolves fine to 3 distinct hosts: customer-apps-shard-00-00.f03lwe.mongodb.net -> 35.238.151.175 customer-apps-shard-00-01.f03lwe.mongodb.net -> 35.239.145.160 customer-apps-shard-00-02.f03lwe.mongodb.net -> 34.41.217.74 General outbound works fine: curl -s -o /dev/null -w "%{httpcode}\n" --max-time 5 https://www.google.com -> 200 Connecting to the Atlas cluster IP on port 27017 hangs for the entire timeout, no RST, no response at all (silent drop, not "connection refused"): time (timeout 6 bash -c 'cat < /dev/null > /dev/tcp/35.238.151.175/27017') -> real 0m6.002s, EXIT:124 (killed by timeout, never connected) Control test, same port 27017, different destination (portquiz.net, built to accept connections on every port) connects instantly: time (timeout 6 bash -c 'cat < /dev/null > /dev/tcp/portquiz.net/27017') -> real 0m0.090s, EXIT:0 This rules out a blanket port-27017 block on Railway's side in general — arbitrary destinations on port 27017 work fine. The block is specific to the 3 Atlas cluster IPs (all Google-Cloud-owned addresses, consistent with the cluster's stated US East / Virginia region). App-level symptom for context: our Python/PyMongo backend retries 3x with socketTimeoutMS=8000 and connectTimeoutMS=8000, every attempt fails with NetworkTimeout to all 3 shard hosts, resulting in a 503 on /api/auth/register and /api/auth/login. This is currently blocking all new user registrations and logins. Ask: could you check whether egress IP 162.220.234.6 (or the underlying NAT range for this service) is being filtered/rate-limited on the way to Google-Cloud-hosted destinations, or whether reassigning/rotating the service's egress IP would help? Happy to provide any additional deployment/project details needed. Thanks for any help.

Description of issue: I'm unable to access my n8n service. The domain is main-production-dc88.up.railway.app, which resolves correctly via DNS (IP: 69.46.46.91), but the browser shows "ERRCONNECTIONTIMEDOUT". Troubleshooting done so far: - Flushed DNS and set Google DNS (8.8.8.8) - this fixed DNS resolution - Ran PowerShell Test-NetConnection: main-production-dc88.up.railway.app -Port 443 fails (TcpTestSucceeded: False) - Ran the same test on google.com: TcpTestSucceeded: True - meaning general internet connectivity is fine - Checked Railway status page - shows "Fully Operational" Error message: ERRCONNECTIONTIMEDOUT The deployment logs show "Editor is now accessible via: main-production-1846.up.railway.app" - I tried this domain too, but it returned a "Not Found" error. Is anyone else experiencing connectivity issues with this IP/domain? Any help would be appreciated.

Description: Self-hosted CouchDB for Obsidian LiveSync Category: Storage URL: https://railway.com/deploy/calm-blue-1

Im setting enableServerless to be true on my Postgres database and when I redeploy it still says online, same for my python service, but appears to work fine for my node server. Do I need to do anything different for these nodes?

Hi Railway team, I'm using Railway Pro. I have a Railway-managed MySQL database. The database itself is healthy: - MySQL starts successfully. - Logs show "ready for connections". - Private Networking works correctly. - Services inside Railway can connect to mysql.railway.internal. However, Public Networking is not reachable. Current public endpoint: altaria.proxy.rlwy.net:51845 -> 3306 From multiple external networks (including mobile hotspot), every TCP connection times out. Tests: nc -vz -w 5 altaria.proxy.rlwy.net 51845 Result: nc: connectx to altaria.proxy.rlwy.net port 51845 (tcp) failed: Operation timed out I have already: - Recreated the Public TCP Proxy - Restarted the MySQL service - Confirmed MySQL is listening on port 3306 - Tested from multiple networks Could you please check whether the TCP proxy for this service is correctly provisioned? Thank you.

I have two problems: 1. stale pre-deploy command persists even if I push substantial code changes -- config has new command, but logs show that old command failed. 2. same for build command finally I asked the agent to "please run a fresh deployment from scratch" but I believe it's much easier to add a "clear cache" button to deployments. your call, of course -- but this has caused me significant headaches on multiple projects already. thanks for listening!