[lacker]

It's an especially awkward situation because Railway is a competitor of Google Cloud, with many third parties involved. So, I just think it will take them a little more time to figure out how to message things.

To me, what it sounds like is that a Google Cloud system identified Railway as a misbehaving customer. Spam, hackers, that sort of thing. Often this happens for "platform as a service" companies, because Railway themselves probably do host some spammers and hackers, and they have their own systems for dealing with it.

So, it's quite possible that according to the Google team, Railway violated the terms of something or other, and according to the Railway team, they did not, and now everyone has to argue about it.

But who knows, this is just me guessing based on some experience running a PaaS that itself was running on top of AWS.

[smartician]

If they're a PaaS, isn't it insane for them to run their own infrastructure and the customer workloads under the same cloud account?

[fakedang]

Railway's system for dealing with hackers is a $5/mo fee gate.

Railway plays around vibecoding as they go along, and their tech practices don't inspire confidence either. Unlike other PaaS like Render or Heroku, I doubt Railway has adequate rate-limiting to stop bad apples.

[lacker]

Yeah, and rate-limiting is only one of the things a PaaS needs to handle, to avoid looking like a bad actor to the underlying platform. The trickiest thing to handle is people using your PaaS to host malware, because:

1. There may be no simple rule of thumb like "suddenly using tons of bandwidth"

2. Bad actors can open up so many accounts, you have to close them automatically

3. Malware can infect a good actor, who is unaware or struggling to deal with it