Find published research by company, product, platform or technology.
Showing 1–10 of 10 dossiers
Railway now patches and redeploys affected workloads for known CVEs and refreshes dependent services after credential rotation—but only when those credentials use Railway variable references.
Railway has not confirmed every customer was breached. Precautionary all-customer rotation guidance, revoked API tokens and deployment disruption make this actionable for builders.
The useful change is operational rather than a new PostgreSQL feature: Railway is packaging major-version migration into a managed workflow while keeping the two dangerous boundaries explicit — downtime during the upgrade and post-upgrade writes lost if you revert.
Agents and operations tooling can inspect HA health, trigger switchovers, restore to a timestamp and change connection pooling from one machine-readable surface. That increases automation power, but recovery actions still create real operational boundaries such as brief failover interruption and forked PITR services.
Railway’s managed MySQL path can now gain automatic failover without rebuilding the database elsewhere. The trade-off is real operational complexity: conversion briefly drops connections, hard-coded URLs need manual repair, replicas are for failover rather than read scaling, and each extra database/proxy node consumes billable resources.
The August 28 transition is now active, and Railway’s current documentation removes an earlier ambiguity about new services in existing projects. Config as Code is legacy-only from here; production users should migrate and validate `.railway/railway.ts` before the December hard cutoff.
Railway Cloud Agents are managed, persistent development machines rather than a new model or harness. They reuse developers’ existing agent credentials, sleep when disconnected by default, retain disk state, and live inside Railway project environments—blurring the boundary between remote coding workspace and deployment platform.
PingCAP reports an internal-systems breach affecting TiDB Cloud account and SQL-editor records; customers should rotate management keys and credentials shared in support tickets.
The incidents do not have a proven common attacker. Wiz's forensic evidence shows downstream abuse and resale of stolen keys, not that every platform breach caused the same misuse.
The affected-customer count and entry point remain unconfirmed. Revoking keys at the issuing provider matters more than simply changing a platform variable.