Why your app's emails fail on Railway, Render, and Vercel

Here is a bug that has cost more late nights than almost any other. Your app sends email perfectly on your laptop. You deploy it. Suddenly the emails stop, and the only clue in your logs is a line like this:

ERROR [MailService] send failed: Error: Connection timeout

No authentication error. No rejected recipient. No bounce. Just a connection that hangs and dies. You double-check your API key, your credentials, your domain, and everything looks correct. So what changed between your laptop and production?

Your host is blocking SMTP.

What is actually happening

Most modern application hosts block outbound SMTP by default. Railway, Render, Fly.io, Vercel, DigitalOcean App Platform, and Google Cloud all do some version of this. They close outbound TCP on the ports email uses to leave a server: port 25, and usually 465, 587, and 2525 as well.

They do it for a good reason. SMTP ports are the classic exit route for compromised apps and spam scripts. If a platform left them open to every free and trial project, its IP ranges would be blocklisted within days, and every customer’s mail would suffer. So the ports stay shut unless you are on a paid tier and explicitly ask for them to be opened.

This is why the bug looks so strange. Your laptop has no such restriction, so SMTP works there. Your production host silently drops the connection, so it times out there. Same code, same key, same credentials. The only difference is the network you are sending from.

Railway states it plainly in their networking docs: SMTP is disabled on Free, Trial, and Hobby plans, and they recommend using an HTTPS email API instead. Render and the others land in the same place.

How to confirm it in one minute

Before you change anything, prove it is the ports. From inside your production environment (a deploy shell, an SSH session, a one-off command), try to open a raw connection to your email provider’s SMTP host:

# swap in your provider's SMTP host
nc -zv -w 5 smtp.sendbyte.africa 587

If it hangs and times out, the port is blocked upstream. Run the exact same command from your laptop and it will connect immediately. That contrast is the whole diagnosis: the problem is not your account, your key, or your provider. It is the network path your host allows.

The fix: send over HTTPS, not SMTP

The durable fix is to stop sending email over SMTP and start sending it over an HTTPS API. Email APIs send on port 443, the same port your app already uses for every other outbound request. Hosts never block 443, because blocking it would break the entire internet. So there is nothing to unblock, no plan to upgrade, and no support ticket to file.

It is also the method the hosts themselves recommend. You are not working around them; you are doing the thing they point you to.

With SendByte the change is small. If you are on SMTP today, you are pointing a mail library at smtp.sendbyte.africa. Swap that for a single HTTPS call using the same live key and the same verified domain.

Direct request:

curl -X POST https://api.sendbyte.africa/v1/emails \
  -H "Authorization: Bearer sk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Your App <no-reply@yourdomain.com>",
    "to": "user@example.com",
    "subject": "Verify your account",
    "html": "<p>Your code is 123456</p>"
  }'

Node, with our SDK:

import { SendByte } from '@sendbyte/node';

const sendbyte = new SendByte('sk_live_YOUR_KEY');

await sendbyte.emails.send({
  from: 'Your App <no-reply@yourdomain.com>',
  to: 'user@example.com',
  subject: 'Verify your account',
  html: '<p>Your code is 123456</p>',
});

That is the whole migration. No new port, no plan change, no reverse DNS, no waiting on a host to flip a switch. And because it runs on 443, it will keep working the next time you move hosts.

If you would rather keep SMTP

Sometimes SMTP is the pragmatic choice, usually because you are running a framework or legacy app that only speaks SMTP and you do not want to touch it. In that case you have two options. Upgrade your host to a paid tier that permits outbound SMTP, then redeploy so the change takes effect. Or run the mail-sending part of your app somewhere without the restriction. Both work, but both cost more and leave you exposed the next time you change platforms, which is why we lead with the API.

SendByte supports both paths deliberately. The relay lives at smtp.sendbyte.africa on ports 587, 465, and 2525 for the apps that need it, and the REST API is there for everything else. If you can choose, choose the API.

The takeaway

If your emails work locally and time out in production with a connection timeout and nothing else, do not spend the night re-checking your API key. Check whether your host blocks outbound SMTP. It almost certainly does. Move the send to an HTTPS API and the problem disappears for good.

New to SendByte? You can start sending in a few minutes on the free tier, priced in Naira, with the same API shown above.