Set up with a coding agent

Private beta

Mailway is in private beta, and we onboard teams one at a time. Join the waitlist and we'll email your invite — everything below works the moment you're in.

If a coding agent wrote your app, it probably also wrote the mail the app sends and picked the email provider. This page moves that app onto Mailway without you reading the mail code first: the agent makes the change, and the prompt asks it to start with a list of every mail your app sends and to change nothing until you have read it.

Mailway is not an email provider. It sits in front of the provider account you already have, keeps an exact copy of every mail, and sends it through that account with your own provider key. If the app has no provider account yet, create one first (provider guides).

Before you give it the prompt

1. Add your provider account, create a project, and create its credentials.

   Use the provider account your app sends through today. The console’s guided setup at /get-started does it in one pass: it adds the provider account, creates the project, attaches the provider to it, and creates an SMTP credential and a live API key. The provider guides cover each provider, including verifying your sender domain there.

2. Create what the guided setup doesn’t.

   Without the guided setup, open the project’s page, attach the provider in its Routing section, and create an SMTP credential (username mw_user_…, password mw_pass_…) in its Access section. If the app calls a provider’s SDK or HTTP API instead of SMTP, it also needs a live key (mw_live_…) for production and a test key (mw_test_…) for the sandbox. Create the test key in Access either way.

3. Put them in the app’s environment variables.

   Use your hosting platform’s environment variables or secrets. For SMTP: MAILWAY_SMTP_HOST (smtp.mailway.net in production, smtp.mailway.dev in development and preview builds), MAILWAY_SMTP_USERNAME, and MAILWAY_SMTP_PASSWORD. For the HTTP API: MAILWAY_API_URL (https://api.mailway.net in production, https://api.mailway.dev in development and preview builds) and MAILWAY_API_KEY (the live key in production, the test key in development and preview builds). Don’t paste them into the agent’s chat. What you type there goes to the agent’s vendor, and the prompt below never needs them.

The prompt

Give it to your coding agent unchanged, in Cursor, Claude Code, Codex, Lovable, Bolt, or any other. Copy prompt copies its Markdown source, links included.

Prompt for your coding agentCopy prompt

Move this app’s outgoing email onto Mailway. Mailway sits in front of the email provider the app already uses: it sends every mail through my own provider account and keeps an exact copy of it. Read mailway.net/llms.txt before you start.

I want three things from this change: to read every mail the app sends, to test mail without it reaching a customer, and to keep the provider I already have.

1. List every mail first, then stop. Find every place in this codebase that sends email, and every mail another service sends for the app, such as Supabase Auth. Show them as a table: the mail, what triggers it, who receives it, its template or text, and how it’s sent today (SMTP, an SDK, an HTTP API, or another service). Under the table, point out anything that looks wrong: a link built from localhost or a development URL, a template value that can be empty, code that can send the same mail twice (on a retry, a page reload, or a double click), and test text or test addresses. If you see a reason this move won’t work for this app, say so there. Then stop, and change nothing until I tell you to go on.
2. SMTP. If the app sends over SMTP, change only the connection settings: the host from MAILWAY_SMTP_HOST, port 587 with STARTTLS, and the username and password from MAILWAY_SMTP_USERNAME and MAILWAY_SMTP_PASSWORD. If port 587 is blocked or hangs where the app runs, use 2525, also with STARTTLS.
3. A provider’s SDK or HTTP API, for example the Resend SDK. Replace those calls with Mailway’s send endpoint, POST {MAILWAY_API_URL}/v1/send, with the key from MAILWAY_API_KEY. Keep every field of each mail: from, to, cc, bcc, reply_to, subject, html, text, attachments, and headers. Write a from with a display name as {"email": …, "name": …}, because Mailway doesn’t accept the "Name <address>" string. Send an Idempotency-Key header of 12–40 characters (letters, digits, - and _). Build it from something unique to this one mail, such as the order ID or the reset request’s ID, so a retry of the same mail repeats the key. Never reuse a key for a later mail: Mailway keeps every key for the life of the project and answers a repeat without sending.
4. The sandbox for development and preview builds. Production uses smtp.mailway.net, or https://api.mailway.net with a live key (mw_live_…). Development and preview builds use smtp.mailway.dev with the same SMTP credential, or https://api.mailway.dev with a test key (mw_test_…). Mailway keeps sandbox mail and sends none of it to a provider unless someone releases it in the console.
5. Mail another service sends. Don’t change code for it. If the service lets me set custom SMTP, as Supabase Auth does, tell me where to turn it on and list the values to enter.

When you’re done, tell me:

• which environment variables to set, with the production value and the development and preview value of each;
• which mail from the list to trigger first in a preview build, so I can read it in the Mailway console under Mails;
• which settings of the old provider the app no longer uses. Don’t remove them until I confirm that a real mail sent through Mailway reached my inbox.

Rules. Adapt the change to the existing code. Don’t add a standalone example. Never put a secret in the code or in a committed file, and never ask me to paste one into this chat.

What it asks the agent for, in this order:

• The list of every mail the app sends, as a table: what triggers each mail, who receives it, its template, and how it’s sent today. Under it, the agent is asked to point out what looks wrong, such as a localhost link or a value that can be empty, and then to stop. Read this list closely before you tell it to go on. A mail on it you didn’t know about is the first one to open in the sandbox.
• SMTP: only the host, port, and credential change. The message itself is relayed byte-for-byte, apart from the automatic exceptions.
• A provider’s SDK or HTTP API: those calls move to Mailway’s send endpoint, with every field of each mail kept.
• The sandbox for development and preview builds, so nothing a test sends reaches a customer unless someone releases it.
• Mail another service sends, such as Supabase Auth: settings for you to enter, no code (see Supabase Auth mails).
• What’s left for you: the environment variables to set, the first mail to try, and the old provider settings the app no longer uses. The prompt asks the agent to leave those settings in place until you confirm that a real mail sent through Mailway reached your inbox.

Check what the app sends

1. Read the list. Compare it with what you expect your app to send, and look at what the agent flagged. Then tell it to go on.

2. Send each mail from a preview build. Sign up, reset a password, buy something: whatever triggers each mail on the list. With the sandbox settings, every mail shows as Captured in the console’s Mails page, and none is delivered.

3. Open each one. Look at the links (they should point at your real domain, not localhost), the names and amounts filled into the template, the recipients, and how many times each mail was sent.

4. Send one real mail. From production, trigger a mail to an address of your own (sign up with it, for example) and find it in Mails. Its timeline shows when Mailway received it and whether a provider accepted it. If Mailway receives your provider’s delivery events, it also shows whether it was delivered.

Supabase Auth mails

Supabase Auth sends sign-up confirmations, magic links, and password resets itself, not through your app’s code. To send them through Mailway, turn on custom SMTP in your Supabase project’s SMTP settings and enter:

Field	Value
Host	smtp.mailway.net
Port	587
Username	your SMTP username, mw_user_…
Password	your SMTP password, mw_pass_…
Sender email	an address on your project’s sender domain, for example auth@yourapp.com
Sender name	your app’s name

The sender domain must be verified at your provider, or the provider refuses the mail. We haven’t tested this with Supabase yet.

These mails carry sign-in links

Mailway keeps auth mails like any other mail, and a sign-in link or a reset link in a stored mail still works until it expires. Admins see every project, and developers and members see the projects they have project access to. Give project access only to the people who should see these mails (roles).

Limits worth knowing

• Free sends up to 1,000 mails a month and 100 a day, through 1 provider account, from 1 sender domain. See plans for the rest.
• Mailway handles only the mail your app sends. It has no inbox, so replies go wherever the mail’s From or Reply-To points.
• Whether a mail reaches the inbox still depends on your sender domain and your provider (deliverability).