n8n SMTP Configuration: Gmail Relay, Mailgun, SendGrid, Postmark

n8n SMTP configuration for production workflows fails when you confuse two separate email layers: system-level SMTP (the N8N_SMTP_* environment variables in your docker-compose.yml) and workflow-level SMTP (the Send Email node credentials inside n8n). The "n8n isn't set up to send email right now" error means your system-level SMTP is missing. This post covers both layers, with exact credential formats for four production providers.

We call this the Two-Channel Email Model, and understanding its three components will save you hours of misdiagnosis:

1. System Channel: The N8N_SMTP_* environment variables in your docker-compose.yml govern all platform operations (user invites, password resets, execution error alerts). This is the channel that produces the "isn't set up to send email" error when missing.
2. Workflow Channel: The Send Email node credentials you create inside the n8n UI govern all automation sends. These are completely independent of the System Channel.
3. Parity Rule: If you run n8n in queue mode, both channels must be configured on every container (main process and worker alike), or you get silent failures. The worker does not inherit SMTP config from the main service.

Every section below maps to one of these channels. When something breaks, your first question should be: which channel is failing?

Why n8n SMTP Configuration Requires Two Separate Layers

n8n separates email into two independent systems: system-level SMTP for platform operations (user invites, password resets, error recovery) and workflow-level SMTP for the Send Email node inside your automations. Configuring one does not configure the other, and every production SMTP problem starts with mixing them up.

Here's what each layer actually does:

System-level SMTP uses environment variables (N8N_SMTP_HOST, N8N_SMTP_PORT, N8N_SMTP_USER, etc.) set in your docker-compose.yml or .env file. These variables control n8n's internal platform emails. If they're missing, you can't invite team members, reset passwords, or receive execution error notifications. This is the layer that produces the "n8n isn't set up to send email right now" error.

Workflow-level SMTP uses credentials you create inside the n8n UI under Settings > Credentials. The Send Email node reads these credentials at execution time. You can have multiple SMTP credentials for different providers, and they're completely independent of the N8N_SMTP_* environment variables.

The practical consequence is that you can have a perfectly working Send Email node in your workflows while the n8n platform itself can't send a password reset. Or the reverse: system emails work fine, but your workflow emails fail because the Send Email node credential is misconfigured.

Symptom	Which Layer Is Broken	Where to Fix It
"n8n isn't set up to send email right now"	System-level	docker-compose.yml env vars
Can't invite team members via email	System-level	docker-compose.yml env vars
Send Email node returns SMTP auth error	Workflow-level	n8n UI > Credentials
Workflow emails not arriving (no error)	Workflow-level	SPF/DKIM + credential config
Password reset email never arrives	System-level	docker-compose.yml env vars

If you've been troubleshooting your Send Email node when the real problem is missing environment variables (or vice versa), you're not alone. The n8n community forum is full of threads where users spend hours debugging the wrong layer. For workflow-level Send Email issues specifically, see our troubleshooting guide for the Send Email node.

How to Fix "n8n Isn't Set Up to Send Email Right Now"

This error appears on the n8n login screen or user management page when N8N_EMAIL_MODE=smtp is not set in your environment variables, or when the required N8N_SMTP_ variables are missing. The fix takes under five minutes: add the SMTP block to your docker-compose.yml and restart.*

What Causes This Error

n8n checks for system-level SMTP configuration when it needs to send platform emails (inviting users, password resets, two-factor authentication setup). If N8N_EMAIL_MODE is not set to "smtp", or if the SMTP host/port/sender variables are absent, n8n disables all platform email features and shows the "isn't set up" message.

This is purely a system-level issue. Your workflow Send Email nodes are unaffected. But it means you can't do basic admin tasks like adding team members or recovering a forgotten password.

The Exact Env Vars to Add

Add these to your n8n service definition in docker-compose.yml:

environment:
  - N8N_EMAIL_MODE=smtp
  - N8N_SMTP_HOST=your-smtp-host.com
  - N8N_SMTP_PORT=587
  - [email protected]
  - N8N_SMTP_SSL=false
  - N8N_SMTP_TLS=true
  - N8N_SMTP_AUTH=true
  - N8N_SMTP_USER=your-smtp-username
  - N8N_SMTP_PASS=your-smtp-password
  - N8N_EMAIL_RECOVERY_MODE=true

The critical variable is N8N_EMAIL_MODE=smtp. Without it, n8n ignores every other SMTP variable. N8N_EMAIL_RECOVERY_MODE=true enables the password reset flow, which you almost certainly want on a production instance.

Refer to the n8n docs on SMTP environment variables for the complete variable list.

Rain's Production Gmail Relay Config (Reference Case)

This is the exact configuration we run in production at Rain Automation on n8n version 2.33.3. Our instance processes an average of 565 workflow executions per day with a 99.97% success rate (10,028 successful out of 10,031 total executions since mid-July 2026).

# Rain Automation production n8n SMTP config
# ~/n8n/docker-compose.yml
environment:
  - N8N_EMAIL_MODE=smtp
  - N8N_SMTP_HOST=smtp-relay.gmail.com
  - N8N_SMTP_PORT=587
  - [email protected]
  - N8N_SMTP_SSL=false
  - N8N_SMTP_TLS=true
  - N8N_SMTP_AUTH=false
  - N8N_EMAIL_RECOVERY_MODE=true

Notice N8N_SMTP_AUTH=false. There's no username or password anywhere in this block. That's because smtp-relay.gmail.com uses IP-based trust authentication: you add your server's public IP to Google Workspace's SMTP relay allowed senders list, and the relay accepts connections from that IP without credentials. No App Passwords. No OAuth tokens. No credential rotation.

This approach eliminates a class of problems we see constantly in the n8n community: expired passwords, revoked tokens, credential leaks in docker-compose.yml. But it requires Google Workspace (free Gmail accounts don't support relay), and your server IP needs to remain static. If you're on a cloud provider with elastic IPs, pin your IP before setting this up.

Across our 80 n8n workflows (37 active), 13 involve email delivery or alerting. Getting SMTP right is not optional infrastructure when email touches that many of your automations.

Queue-Mode SMTP Parity (The Silent Failure Nobody Warns About)

Every n8n SMTP guide stops after configuring the main n8n service. The assumption is that one SMTP config covers the whole stack. That assumption is wrong when you run queue mode.

If you run n8n in queue mode with a separate worker container, the worker needs the identical N8N_SMTP_* environment block as the main process. The worker sends its own error-recovery emails when a job fails. If SMTP is only configured on the main n8n service, worker failures produce no email notification at all. This is a violation of the Parity Rule in the Two-Channel Email Model: both channels, on every container, or you're flying blind.

Our production stack runs queue mode with a dedicated worker at concurrency=5, backed by Redis (Bull queue). Both the main n8n container and the n8n-runner container share the exact same SMTP environment block. We learned this the hard way: for three days, worker-side failures were silently swallowed because the runner service was missing the SMTP vars.

"We had worker executions failing for three days with zero alerts. The main n8n container was sending system emails fine, so everything looked healthy on the dashboard. It wasn't until I dug into the Redis job history that I found a string of failed runs the worker had silently dropped. The fix was two minutes of YAML, but the diagnosis cost us a weekend."

Ryan Nichols, Founder of Rain Automation

Our Execution Failure Alert workflow (one of 13 email workflows in our active stack) fires within 90 seconds of a failed execution and delivers to [email protected] via the Gmail relay config above. It has triggered 3 times since mid-July across 10,031 runs, a 99.97% success rate. But that monitoring only works when the worker can actually send the alert. Without SMTP parity, the very workflow designed to catch failures was itself silently failing.

The fix is mechanical. Copy the entire SMTP environment block from your main n8n service to your worker service in docker-compose.yml. Don't reference a shared .env file unless both services actually read it.

Restart and Verify

After adding the environment variables:

docker compose down && docker compose up -d

Then navigate to your n8n instance and check Settings > Users. If the "isn't set up to send email" banner is gone, your system SMTP is working. Send a test invite to yourself to confirm delivery.

Option 1: Gmail Relay (smtp-relay.gmail.com)

Google's SMTP relay service works without credentials when your server IP is allowlisted in Google Workspace Admin, making it the simplest option for organizations already on Google Workspace. But "simplest" comes with constraints most tutorials skip.

When to Use Gmail Relay

Gmail relay fits if you meet all three conditions: (1) your organization uses Google Workspace, (2) your server has a static IP, and (3) your daily send volume stays under Google's relay limits of 10,000 unique recipients per 24-hour period across all paid Workspace editions (per Google Workspace documentation).

If you're self-hosting n8n on a home server, a dynamic-IP VPS, or you don't have Google Workspace, skip to Mailgun or Postmark below.

Setting Up IP Allowlisting

The conventional advice you'll find in n8n community threads and most setup guides is straightforward: add N8N_SMTP_HOST=smtp-relay.gmail.com to your docker-compose.yml and restart. That advice leaves out the step that makes it work. Without IP allowlisting in Google Workspace Admin, every connection silently fails.

Here's the full process:

1. Open Google Workspace Admin Console > Apps > Google Workspace > Gmail > Routing
2. Under SMTP relay service, click Configure or Add Another Rule
3. Set "Allowed senders" to "Only addresses in my domains"
4. Under Authentication, select "Only accept mail from the specified IP addresses"
5. Add your server's public IP
6. Check "Require SMTP Authentication" = OFF and "Require TLS encryption" = ON

Without IP allowlisting, connections to smtp-relay.gmail.com are rejected silently. You'll see a connection timeout or generic TLS error in n8n logs with no useful diagnostic message. The error gives you nothing to work with, which is why so many people end up in forum threads asking why their relay config "doesn't do anything."

Alertmanager EHLO Gotcha

If you run Prometheus Alertmanager alongside n8n (we do, with 15 alert rules across 5 groups), the smtp_hello setting in alertmanager.yml must be set to your actual domain name, not the container hostname:

# alertmanager.yml
global:
  smtp_smarthost: 'smtp-relay.gmail.com:587'
  smtp_from: '[email protected]'
  smtp_hello: 'rainautomation.com'  # NOT the container name
  smtp_require_tls: true

Google's relay rejects EHLO from bare container hostnames (like "alertmanager" or "n8n-n8n-1") that don't match the sending domain. This causes Alertmanager to silently fail on every alert notification while n8n system emails work fine, because n8n handles its own EHLO correctly.

SPF Record for Gmail Relay

Add this to your domain's DNS TXT record:

v=spf1 include:_spf.google.com ~all

If you already have an SPF record for Google Workspace, this is probably already covered. Verify with MXToolbox.

Gmail Relay Credential Format (Workflow-Level)

For the Send Email node inside n8n workflows (separate from the system-level config above), use these credentials:

Field	Value
SMTP Host	smtp-relay.gmail.com
SMTP Port	587
SSL/TLS	STARTTLS
User	(leave blank if IP-authenticated)
Password	(leave blank if IP-authenticated)

If you prefer to use regular Gmail SMTP (smtp.gmail.com) instead of the relay, you'll need an App Password with 2FA enabled. Google began deprecating basic password auth in May 2022, with full enforcement for Workspace SMTP accounts completed March 2025 (per Google Workspace Admin Help), so regular account passwords no longer work.

Option 2: Mailgun SMTP

Mailgun is the production default for most n8n self-hosters who need reliable transactional email without Google Workspace. The free tier covers 100 emails per day, approximately 3,000 per month, with no expiration (per Mailgun documentation), and setup takes about 10 minutes.

I've recommended Mailgun to more n8n users than any other provider for a reason: the credential format is straightforward, domain verification is automated, and the free tier is generous enough for most automation workloads.

Credential Format

For n8n system-level SMTP (docker-compose.yml):

environment:
  - N8N_EMAIL_MODE=smtp
  - N8N_SMTP_HOST=smtp.mailgun.org
  - N8N_SMTP_PORT=587
  - [email protected]
  - N8N_SMTP_SSL=false
  - N8N_SMTP_TLS=true
  - N8N_SMTP_AUTH=true
  - [email protected]
  - N8N_SMTP_PASS=your-mailgun-smtp-password
  - N8N_EMAIL_RECOVERY_MODE=true

For the n8n Send Email node (workflow-level credential):

Field	Value
SMTP Host	smtp.mailgun.org
SMTP Port	587
SSL/TLS	STARTTLS
User	[email protected]
Password	Your Mailgun SMTP password (NOT the API key)

Here's the gotcha that trips up most people: Mailgun shows an API key and a separate SMTP password in different sections of the dashboard. They are not interchangeable. The API key goes in API-based integrations (like the n8n Mailgun node). The SMTP password goes in SMTP credential fields. Using the API key as your SMTP password produces a silent authentication failure.

SPF/DKIM for Mailgun

Mailgun auto-generates the DNS records during domain verification. You'll add two TXT records (SPF and DKIM) and one CNAME. The Mailgun dashboard shows the exact values. After adding them, click "Verify DNS Settings" in Mailgun and wait for propagation (usually under 5 minutes).

Option 3: SendGrid SMTP

SendGrid fits high-volume n8n setups or teams already in the Twilio ecosystem. New accounts get a free trial with 100 emails per day for 60 days, then paid plans start at $19.95 per month (per SendGrid pricing, updated May 2025). The unusual credential format (username is literally the string "apikey") causes most first-time setup failures.

Credential Format

System-level (docker-compose.yml):

environment:
  - N8N_EMAIL_MODE=smtp
  - N8N_SMTP_HOST=smtp.sendgrid.net
  - N8N_SMTP_PORT=587
  - [email protected]
  - N8N_SMTP_SSL=false
  - N8N_SMTP_TLS=true
  - N8N_SMTP_AUTH=true
  - N8N_SMTP_USER=apikey
  - N8N_SMTP_PASS=SG.your-full-api-key-here
  - N8N_EMAIL_RECOVERY_MODE=true

Workflow-level (Send Email node credential):

Field	Value
SMTP Host	smtp.sendgrid.net
SMTP Port	587
SSL/TLS	STARTTLS
User	apikey (the literal string, not your actual API key)
Password	Your full SendGrid API key (starts with SG.)

The most common SendGrid mistake in n8n: using your API key as the username. The username is always the literal five-character string apikey. Your actual API key goes in the password field only. Getting this backwards produces an authentication error that doesn't clearly explain what went wrong.

SPF/DKIM for SendGrid

SendGrid calls this "Domain Authentication" in Settings > Sender Authentication. It generates three CNAME records. Add them to your DNS and click Verify. SendGrid handles the SPF and DKIM signing automatically once the CNAMEs resolve.

Option 4: Postmark SMTP

Postmark consistently delivers the highest inbox placement rates among the four options. It's purpose-built for transactional email and rejects bulk/marketing sends entirely. The free Developer plan includes 100 emails per month on a permanent basis, resetting monthly, then paid plans start at $15 per month for 10,000 emails (per Postmark pricing page).

If inbox delivery is your primary concern (and for production n8n alerts, it should be), Postmark is worth the cost. Their servers have the cleanest IP reputation because they actively refuse to carry marketing email.

Credential Format

System-level (docker-compose.yml):

environment:
  - N8N_EMAIL_MODE=smtp
  - N8N_SMTP_HOST=smtp.postmarkapp.com
  - N8N_SMTP_PORT=587
  - [email protected]
  - N8N_SMTP_SSL=false
  - N8N_SMTP_TLS=true
  - N8N_SMTP_AUTH=true
  - N8N_SMTP_USER=your-server-api-token
  - N8N_SMTP_PASS=your-server-api-token
  - N8N_EMAIL_RECOVERY_MODE=true

Workflow-level (Send Email node credential):

Field	Value
SMTP Host	smtp.postmarkapp.com
SMTP Port	587 (or 2525 if ISP blocks 587)
SSL/TLS	STARTTLS
User	Your Postmark Server API Token
Password	Your Postmark Server API Token (same value for both fields)

Postmark uses the same token for both username and password. You'll find it under Servers > your server > Credentials in the Postmark dashboard.

SPF/DKIM for Postmark

Postmark auto-provisions a DKIM key and provides an SPF include during domain setup. You'll add one TXT record (DKIM) and update your SPF record to include include:spf.mtasv.net. The Postmark dashboard walks you through the exact records.

Provider Comparison Table

All four providers use port 587 with STARTTLS, making the credential format the primary differentiator. Gmail relay requires no stored credentials but demands Google Workspace and a static server IP. For every other setup, Mailgun, SendGrid, or Postmark give you a credential-based option with provider-managed deliverability.

Provider	SMTP Host	Port	Auth Username	Free Tier	SPF/DKIM Setup	Best For
Gmail Relay	smtp-relay.gmail.com	587	None (IP auth)	Workspace limits (per Google docs)	Existing Google SPF	Google Workspace orgs with static IPs
Mailgun	smtp.mailgun.org	587	[email protected]	100/day, ~3,000/mo (per Mailgun docs)	Auto-generated records	Most n8n self-hosters (balanced cost/deliverability)
SendGrid	smtp.sendgrid.net	587	apikey (literal)	60-day trial: 100/day, then from $19.95/mo (per SendGrid pricing)	3 CNAME records	High-volume senders, Twilio ecosystem
Postmark	smtp.postmarkapp.com	587	Server API Token	Free Developer plan: 100/mo permanent (per Postmark pricing)	Auto-provisioned	Critical transactional email, best deliverability

All four providers use port 587 with STARTTLS. Set N8N_SMTP_SSL=false and N8N_SMTP_TLS=true for all of them. Setting SSL=true when using port 587 causes a TLS handshake failure (the "Client network socket disconnected before secure TLS connection was established" error that fills the n8n community forums).

So which should you pick? If you're on Google Workspace with a static-IP server, Gmail relay costs nothing and works without storing credentials. For everyone else, Mailgun is the pragmatic default: the free tier is sufficient for most automation workloads, and setup is the least error-prone. SendGrid fits high-volume senders willing to pay after the trial period. Postmark fits when delivery to inbox (not spam) is non-negotiable.

SPF, DKIM, and DMARC: The Minimum You Need

Without proper SPF, DKIM, and DMARC records, your n8n emails will silently land in spam, and you won't know until a missed alert costs you real money. Every provider above requires at least SPF and DKIM to deliver reliably.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which IPs are authorized to send email for your domain. Each provider's SPF include:

• Gmail Relay: include:_spf.google.com
• Mailgun: include:mailgun.org
• SendGrid: handled by CNAME (no manual SPF)
• Postmark: include:spf.mtasv.net

Add the relevant include to your domain's existing SPF TXT record. If you don't have one yet, create a TXT record like: v=spf1 include:_spf.google.com ~all

DKIM (DomainKeys Identified Mail)

DKIM cryptographically signs your emails so receivers can verify they weren't tampered with. All four providers generate DKIM keys during domain setup. Follow each provider's dashboard to add the DKIM TXT record to your DNS.

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together and tells receivers what to do with emails that fail authentication. Start with a monitoring-only policy:

v=DMARC1; p=none; rua=mailto:[email protected]

After confirming your emails pass SPF and DKIM checks (use MXToolbox to verify), tighten to p=quarantine or p=reject.

How to Test

1. Run your domain through MXToolbox SPF Checker and DKIM Validator
2. Send a test email from n8n to a Gmail account
3. In Gmail, open the email > click the three dots > "Show original"
4. Check the SPF, DKIM, and DMARC results at the top. All three should show "PASS"

If any show "FAIL" or "SOFTFAIL", your emails may be landing in spam for every recipient. Fix the failing record before doing anything else with your n8n email setup.

A Test Workflow to Confirm Your SMTP Config

Build a one-node test workflow to verify your Send Email credential before wiring it into production automations. This takes two minutes and saves hours of debugging later.

1. In n8n, create a new workflow
2. Add a Manual Trigger node
3. Add a Send Email node connected to the trigger
4. Configure the Send Email node with your SMTP credential
5. Set "To" to your own email address
6. Set "Subject" to "n8n SMTP Test"
7. Set "Text" to "If you received this, your SMTP config is working."
8. Click "Test workflow"

If the execution succeeds but the email doesn't arrive, the problem is deliverability (SPF/DKIM), not SMTP configuration. Check your spam folder first, then verify your DNS records.

If the execution fails with a connection error, check these red flags:

• "Client network socket disconnected": You have N8N_SMTP_SSL=true on port 587. Change SSL to false, keep TLS as true.
• "Connection timeout": Your server's outbound port 587 is blocked by a firewall. Try port 2525 (Postmark) or 465 (with SSL=true, TLS=false).
• "Invalid login": Wrong credential type. Verify you're using the SMTP password (Mailgun), or the literal string "apikey" as username (SendGrid), or the Server API Token for both fields (Postmark).
• "EHLO rejected": Your SMTP client hostname doesn't match the sending domain. Relevant for Alertmanager, not typical for n8n itself.

For a deeper walkthrough of Send Email node errors, see our complete troubleshooting guide.

n8n SMTP Configuration Checklist for Production

This checklist covers every configuration point from the Two-Channel Email Model required before your n8n SMTP setup is production-ready. Run through it after initial setup and again after any docker-compose.yml change. Missing any single item can cause silent email failures.

• N8N_EMAIL_MODE=smtp is set in docker-compose.yml
• N8N_SMTP_HOST, PORT, SENDER, SSL, TLS, and AUTH are all present
• N8N_EMAIL_RECOVERY_MODE=true for password reset capability
• If using queue mode: worker container has identical SMTP env vars (Parity Rule)
• SPF record includes your provider's authorized senders
• DKIM record is added and verified
• DMARC record exists (at minimum p=none for monitoring)
• Test email sent and received (not in spam)
• MXToolbox shows PASS for SPF, DKIM, and DMARC
• If using Gmail relay: server IP is allowlisted in Google Workspace Admin

Frequently Asked Questions

How Do I Set Up SMTP in n8n for Production?

Add the N8N_SMTP_* environment variables to your docker-compose.yml file, including N8N_EMAIL_MODE=smtp, your provider's host and port, TLS settings, and credentials. Then create a separate Send Email credential in the n8n UI for workflow-level emails. Both layers need configuration for full production coverage.

What Does "n8n Isn't Set Up to Send Email Right Now" Mean?

This error means your n8n instance is missing system-level SMTP configuration. It has nothing to do with the Send Email node in your workflows. Add the N8N_EMAIL_MODE=smtp environment variable and the associated SMTP host, port, and sender variables to your docker-compose.yml, then restart the container.

Can I Use Gmail SMTP with n8n for Free?

Yes, but with caveats. Google began deprecating basic password auth in May 2022, with full enforcement for Workspace SMTP accounts completed March 2025, so regular Gmail passwords won't work. You need either an App Password (requires 2FA on your Google account) for smtp.gmail.com, or a Google Workspace subscription for smtp-relay.gmail.com with IP-based authentication. The relay option is more reliable for production but requires a paid Workspace account.

What Is the Difference Between Gmail SMTP and Gmail Relay for n8n?

smtp.gmail.com requires a username and App Password for every connection and is subject to personal Gmail sending limits (500/day). smtp-relay.gmail.com authenticates by server IP address, needs no stored credentials, and supports up to 10,000 unique recipients per 24-hour period across all paid Workspace editions (per Google Workspace documentation). The relay is the production choice; regular SMTP is for development and testing.

Why Are My n8n Emails Going to Spam?

Missing or misconfigured SPF, DKIM, or DMARC records are the most common cause. Run your domain through MXToolbox to check all three. If they pass, verify your sending domain matches your From address and that your server IP isn't on any blocklists. Also check that N8N_SMTP_SSL is set to false when using port 587 with STARTTLS.

Does n8n Queue Mode Require Separate SMTP Configuration for Workers?

Yes. The worker container sends its own error-recovery and notification emails independently of the main n8n process. If you only configure SMTP on the main service, the worker silently fails to send any email. Copy the entire N8N_SMTP_* environment block from your main n8n service to your worker service definition in docker-compose.yml.

What to Configure Next

With SMTP working at both the system and workflow level, you've solved the infrastructure prerequisite. But configuration is only half of production email in n8n.

If you haven't yet, read our Send Email node tutorial for the workflow-side setup: building trigger-based emails, dynamic templates, and multi-recipient sends. For the bigger picture on running n8n at scale, including server specs, memory limits, and cost projections, see Self-Hosting n8n in Production: Real Server Specs and Cost Numbers.

The same two-layer split applies to databases. If you run n8n on Postgres, the DB_POSTGRESDB_* variables control n8n's own storage, while workflow database access lives in a separate credential. Our n8n PostgreSQL integration guide covers the workflow side, including SSL with custom CA certificates in queue mode.

And if you're weighing n8n against Zapier or Make for your automation stack, our cost and reliability comparison covers real numbers from 10,000+ workflow runs.

Need help designing production automation workflows or configuring your n8n stack? Get in touch.

Disclosure: Some links in this post are affiliate links. If you sign up through them, Rain Automation may receive a commission at no additional cost to you. We only recommend tools we use in production ourselves.