Send transactional email from your own infrastructure not a third party
GitHub RepoImpressions2.4k

Send transactional email from your own infrastructure not a third party

@githubprojectsPost Author

Project Description

View on GitHub

Send Transactional Email Yourself: A Look at UseSend

Let's be honest, managing transactional email can be a pain. You either get locked into a third-party service with its own pricing, limits, and potential delivery issues, or you face the daunting task of building and maintaining your own email-sending infrastructure. It often feels like you have to choose between convenience and control.

What if you could have both? That's the idea behind UseSend. It's a straightforward, self-hosted solution that lets you send emails directly from your own servers, cutting out the middleman and giving you full ownership of your email pipeline.

What It Does

UseSend is a self-hosted email API server. You run it on your own infrastructure, and it provides a simple, clean API endpoint (similar to services like SendGrid or Resend) that your applications can use to send transactional emails. It handles the connection to your SMTP server (like Postfix, Amazon SES, or a similar service) and manages the queueing and sending logic, so you don't have to.

In short, it wraps the complexity of reliable email delivery into a single service you control, replacing the external API dependency with an internal one.

Why It's Cool

The cool factor here is all about simplicity and ownership. You're not adding a new third-party dependency; you're adding a internal service that removes an external one. This has some clear benefits:

  • No Vendor Lock-in: Your email-sending logic isn't tied to a specific provider's API, features, or pricing changes.
  • Cost Control: Once it's running, your main costs are just your infrastructure and SMTP service (which can be very cheap, like Amazon SES). No surprise bills based on volume spikes.
  • Privacy & Data Control: Your email data and recipient lists never leave your ecosystem. This is a big deal for compliance and peace of mind.
  • It's Just an API: For your application code, nothing much changes. You swap out the third-party API base URL for your own UseSend instance's URL. The integration pattern stays familiar.
  • Built with Go: It's a single binary, which makes it easy to deploy and run almost anywhere—Docker, a VM, or even a simple process manager.

How to Try It

The quickest way to get started is with Docker. The repository provides a clear example.

First, clone the repo:

git clone https://github.com/usesend/useSend.git
cd useSend

You can run it directly with Go or use the provided Docker example. The key is to set the necessary environment variables for your SMTP server. Check out the docker-compose.yml file in the repo for a working setup that includes a test SMTP server (MailHog) to see it in action without configuring a real email service immediately.

Once it's running (by default on port 8080), you can send an email with a simple curl command to your own server:

curl -X POST http://localhost:8080/send \
  -H "Content-Type: application/json" \
  -d '{
    "to": "[email protected]",
    "subject": "Hello from UseSend",
    "body": "This is a test email sent from my own infrastructure."
  }'

Final Thoughts

UseSend isn't for everyone. If you're a small team that just needs to get something working fast, a traditional email service is still a great choice. But if you're at a scale where cost, data governance, or reducing external dependencies matters, this project presents a compelling alternative.

It takes a complex problem and packages it into something manageable. You get the developer experience of a modern email API, but with the control and final responsibility that comes with running your own stack. It's a pragmatic tool for developers who want to own more of their chain.


Follow us for more projects like this: @githubprojects

Back to Projects
Project ID: 0f339914-9cc3-48d4-988c-85769516da7aLast updated: January 24, 2026 at 04:11 AM