SMTP connection failures
jon-salmon
HOBBYOP

3 months ago

I've recently discovered that a production service I've been running on Railway has been silently failing for several months due to SMTP ports being blocked by railway. Is there anyway this can be resolved?

I have not seen any communication about this breaking change being deployed, which has severely degraded my trust in the platform as a whole. I've generally been very impressed by the service - especially what I though was very good communication. This trust has now been completely broken by the release of breaking changes like this without any communication.

I understand from other people finding this issue that this is enabled on the Pro plan, but why do I need to pay for more usage than I need to just run a simple service? Looking at the pricing page there is nothing there that indicates there are any feature differences between the two plan.

What is the policy for communicating breaking changes like this the future?

As stated above, I've been a big fan of railway in general but I'm seriously considering migrating to a different provider given the apparent willingness to break production workflows with out prior warning. Any other 'production' service I've used has always given 6 months+ of notice for any breaking changes (if they ever break anything).

Paying $20 per month for practically 0 CPU usage and < 1.5 GB of ram is comparatively a rip off.

$10 Bounty

10 Replies

Railway
BOT

3 months ago

Hello,

Outbound SMTP is only available on the Pro plan and above, while Free, Trial, and Hobby plans have SMTP disabled.

For sending emails from your application, please use a dedicated email service that provides HTTPS APIs. More information can be found in our documentation:

https://docs.railway.com/reference/outbound-networking

Best regards,

The Railway Team


Status changed to Awaiting User Response Railway 3 months ago


jon-salmon
HOBBYOP

3 months ago

This didn't used to be the case as I was previously able to send smtp emails on the hobby plan. Why wasn't this breaking change communicated to me in advance as this has broken my production system for several months?

What steps are you taking to ensure breaking changes are communicated to users in future? Without such a process railway.com can hardly be described as suitable for production systems.


Status changed to Awaiting Railway Response Railway 3 months ago


jon-salmon
HOBBYOP

3 months ago

Also, your bot has completely ignored large parts of my initial message


uxuz
MODERATOR

3 months ago

Hey, the SMTP ports were supposed to be blocked for everyone. If I remember correctly, it was a misconfiguration in the firewall which allowed the ports to be used. This has now been fixed, however since the pro plan is for production and customers on the pro plan have used SMTP for their production workloads, a decision was made to allow SMTP on the pro plan. Railway still recommends using HTTP APIs to send emails regardless of your plan.


dbsaw
PRO

3 months ago

Try using HTTP APIs.
check this out it might help: Email API · Start sending today · Resend


Status changed to Solved brody 3 months ago


jon-salmon
HOBBYOP

3 months ago

Not all services support using platform API's (see chatwoot for example) and, arguably more importantly, you have completely ignored the main part of my question about what Railway's deprecation policy is and why there wasn't due notice of this change. Even if a feature is unintentional, once it is released to production is is implicitly part of the API and therefore should not be removed without careful management and timely deprecation notices.


Status changed to Awaiting Railway Response Railway 3 months ago


jon-salmon

Not all services support using platform API's (see chatwoot for example) and, arguably more importantly, you have completely ignored the main part of my question about what Railway's deprecation policy is and why there wasn't due notice of this change. Even if a feature is unintentional, once it is released to production is is implicitly part of the API and therefore should not be removed without careful management and timely deprecation notices.

uxuz
MODERATOR

3 months ago

Hey, Railway technically didn't deprecate any feature, it was never meant to be a feature to begin with, SMTP was blocked for everyone, regardless of your plan. Railway marks deprecated features, such as the Nixpacks builder in advance with enough time for anyone to migrate away. You can read more about the SMTP misconfiguration from this changelog.


jon-salmon
HOBBYOP

3 months ago

Except it wasn't blocked for everybody - it was enabled for everybody. I appreciate that maybe it wasn't meant to be a supported feature, but given that it was enabled for at least several months I think that qualifies as it being a feature from the perspective of requiring proper deprecation notice. In the changelog you link you mention that you where aware that many users were using this feature, yet still didn't feel the need to gracefully handle the deprecation???!


loosie94
HOBBY

3 months ago

"SMTP was blocked for everyone, regardless of your plan."

Except that is was NOT!
But hey, all you need to do is upgrade to there (minimal!) $20,- per month plan.

What a joke...


jon-salmon
HOBBYOP

2 months ago

I'm taking this silence from the railway team as an admission that they have no deprecation policy. Given this railway.com should only be used for hobby projects at most.


Loading...