PostgreSQL + Gmail: database requests done reliably
Database requests sound simple until they land on your plate at the worst time. Someone needs a new PostgreSQL database, another person wants MySQL deleted “right now,” and you’re stuck juggling SSH commands, permissions, and follow-up messages.
This is where database request automation pays off fast. Ops leads feel it during launch week. A freelancer maintaining client servers deals with it in the middle of other billable work. And a marketing team running campaigns still gets blocked when the data stack can’t keep up.
This workflow provisions PostgreSQL or MySQL over SSH, then emails the result to Gmail so requests get handled consistently. You’ll see how it works, what you need, and what to watch out for before you run it on a real server.
How This Automation Works
Here’s the complete workflow you’ll be setting up:
n8n Workflow Template: PostgreSQL + Gmail: database requests done reliably
flowchart LR
subgraph sg0["Start Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Start", pos: "b", h: 48 }
n1@{ icon: "mdi:swap-vertical", form: "rounded", label: "Set Parameters", pos: "b", h: 48 }
n2@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Database Type Check", pos: "b", h: 48 }
n3@{ icon: "mdi:swap-horizontal", form: "rounded", label: "PostgreSQL Action Check", pos: "b", h: 48 }
n4@{ icon: "mdi:swap-horizontal", form: "rounded", label: "MySQL Action Check", pos: "b", h: 48 }
n5@{ icon: "mdi:cog", form: "rounded", label: "Install PostgreSQL", pos: "b", h: 48 }
n6@{ icon: "mdi:cog", form: "rounded", label: "Install MySQL", pos: "b", h: 48 }
n7@{ icon: "mdi:swap-horizontal", form: "rounded", label: "PostgreSQL Create Check", pos: "b", h: 48 }
n8@{ icon: "mdi:swap-horizontal", form: "rounded", label: "MySQL Create Check", pos: "b", h: 48 }
n9@{ icon: "mdi:cog", form: "rounded", label: "Create PostgreSQL DB", pos: "b", h: 48 }
n10@{ icon: "mdi:cog", form: "rounded", label: "Create MySQL DB", pos: "b", h: 48 }
n11@{ icon: "mdi:cog", form: "rounded", label: "Delete PostgreSQL DB", pos: "b", h: 48 }
n12@{ icon: "mdi:cog", form: "rounded", label: "Delete MySQL DB", pos: "b", h: 48 }
n13@{ icon: "mdi:swap-vertical", form: "rounded", label: "Format Output", pos: "b", h: 48 }
n0 --> n1
n6 --> n13
n1 --> n2
n10 --> n13
n12 --> n13
n5 --> n13
n4 --> n6
n4 --> n8
n8 --> n10
n8 --> n12
n2 --> n3
n2 --> n4
n9 --> n13
n11 --> n13
n3 --> n5
n3 --> n7
n7 --> n9
n7 --> n11
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 trigger
class n2,n3,n4,n7,n8 decision
Why This Matters: Database Requests Turn Into Interruptions
Provisioning a database is rarely “just five minutes.” You have to confirm the right engine (PostgreSQL vs MySQL), ensure the server is ready, install packages if it’s a fresh box, create the database, create a user, set permissions, and make sure remote access is configured the way your team expects. Then comes the real time sink: reporting back. If you forget to email credentials, or you send the wrong database name, you’ll get a second round of messages and another context switch. Honestly, the worst part is inconsistency. Two people do it two different ways, and you only notice when something breaks.
It adds up fast. Here’s where it usually breaks down in day-to-day work.
- Requests arrive in chat or email with missing details, so you spend extra time clarifying basics like engine, name, and access needs.
- Manual SSH runs lead to small differences in permissions and authentication, which later become “why can’t the app connect?” tickets.
- Deletion is risky when it’s ad hoc, because one wrong command can remove the wrong database or leave orphaned users behind.
- Status updates live in someone’s head, so stakeholders keep asking for confirmation and you keep re-checking the server.
What You’ll Build: Provision Databases via SSH and Email the Outcome
This n8n workflow gives you a controlled way to install, create, or delete PostgreSQL and MySQL resources on a Linux server using SSH. You start it with a simple run (manual kickoff), then set the key inputs in one place: server host, SSH credentials, database engine, requested action, and the database/user details. From there, the workflow checks which engine you chose, routes down the PostgreSQL or MySQL path, and runs only the commands needed for that action. If you’re installing, it handles package setup and configuration. If you’re creating, it provisions the database and assigns the user and permissions. If you’re deleting, it removes the database and the associated user cleanly. At the end, it formats a clear result payload you can send by email, so the requestor gets a reliable confirmation without you writing a custom message each time.
The workflow starts with your inputs in n8n, then validates the database engine and action. Next, it runs server commands through SSH to install or provision the database resources. Finally, it builds a consistent output you can email through Gmail (or forward into your ticketing process if you prefer).
What You’re Building
| What Gets Automated | What You’ll Achieve |
|---|---|
|
|
Expected Results
Say you handle 10 database requests in a week across a couple servers. Manually, each one tends to take about 15 minutes between SSH work (install/create/delete), checking access, and writing a confirmation email, so you’re looking at roughly 2–3 hours of stop-and-start work. With this workflow, the execution itself is about 10 seconds, and your real time is mostly entering inputs and reviewing the email, maybe 2 minutes per request. That’s a couple hours back in a normal week, and the requests stop feeling like emergencies.
Before You Start
- n8n instance (try n8n Cloud free)
- Self-hosting option if you prefer (Hostinger works well)
- SSH access to a Linux server for running install/provision commands.
- Gmail (or SMTP email) to send results to requestors.
- Root or sudo credentials (use a privileged account on the server)
Skill level: Intermediate. You don’t need to code, but you should be comfortable verifying SSH access and understanding what “create” vs “delete” will do.
Want someone to build this for you? Talk to an automation expert (free 15-minute consultation).
Step by Step
You trigger a run with a clear request. The workflow begins with a manual kickoff in n8n, which is perfect when you want a controlled “approve then run” process. In the Configure Inputs step, you enter the server host, SSH user/password, database engine (PostgreSQL or MySQL), and the action (install, create, or delete).
The workflow validates what you asked for. It checks the selected database engine first, then routes to the right action gate. This is where you avoid messy outcomes like trying to run PostgreSQL commands against a MySQL server.
SSH performs the real work on the server. Based on your choices, n8n runs the corresponding SSH block: deploy/install packages, provision a database with a user and permissions, or remove a database and its associated user. It’s all the same repeatable path every time, which means fewer “special cases” you have to remember.
A result payload is built for your confirmation email. The final step formats output into something you can send through your email node (Gmail). That message becomes your receipt: what engine was targeted, what action ran, and what the workflow did.
You can easily modify the input fields to collect requests from a form or spreadsheet instead of manual entry. See the full implementation guide below for customization options.
Step-by-Step Implementation Guide
Step 1: Configure the Manual Trigger
This workflow starts manually so you can control when database provisioning actions are executed.
- Add the Manual Kickoff node as the trigger.
- Leave the Manual Kickoff node with default settings (no parameters required).
- Connect Manual Kickoff to Configure Inputs.
Step 2: Connect SSH Access for Server Actions
SSH access is required for all database deployment, provisioning, and removal actions.
- Open Deploy PostgreSQL and set Authentication to
privateKey. - Credential Required: Connect your sshPrivateKey credentials in Deploy PostgreSQL.
- Repeat the same sshPrivateKey credential connection for Deploy MySQL Server, Provision Postgres DB, Provision MySQL DB, Remove Postgres DB, and Remove MySQL DB.
Step 3: Set Up Configure Inputs
Default values are defined here so you can run the workflow without supplying all inputs each time.
- In Configure Inputs, add the following string fields with expressions:
- Set server_host to
={{ $json.server_host || '192.168.1.100' }}. - Set server_user to
{{ $json.server_user || 'root' }}. - Set server_password to
{{ $json.server_password || 'your_password' }}. - Set db_type to
={{ $json.db_type || 'postgresql' }}and action to={{ $json.action || 'install' }}. - Set database_name to
={{ $json.database_name || 'mydb' }}, db_user to{{ $json.db_user || 'dbuser' }}, and db_password to{{ $json.db_password || 'dbpass123' }}.
Step 4: Configure Routing and Action Nodes
Conditional gates route requests to PostgreSQL or MySQL actions based on the input values.
- In Validate DB Engine, set the string condition with Value 1 as
={{ $json.db_type }}and Value 2 aspostgresql. - Configure Postgres Action Gate and MySQL Action Gate with Value 1 set to
={{ $json.action }}and Value 2 set toinstall. - Configure Postgres Create Gate and MySQL Create Gate with Value 1 set to
={{ $json.action }}and Value 2 set tocreate. - Ensure Validate DB Engine routes to Postgres Action Gate (true branch) and MySQL Action Gate (false branch) exactly as defined in the workflow connections.
postgresql, execution will follow the MySQL branch. Use consistent values when testing.Step 5: Configure Output Result Formatting
All SSH action nodes feed into a unified result payload to capture command output and metadata.
- Open Build Result Payload and add output fields:
- Set result to
={{ $json.stdout }}and status tosuccess. - Set action_performed to
={{ $('Configure Inputs').item.json.action }}. - Set database_type to
={{ $('Configure Inputs').item.json.db_type }}and database_name to={{ $('Configure Inputs').item.json.database_name }}. - Confirm each SSH node (Deploy PostgreSQL, Deploy MySQL Server, Provision Postgres DB, Provision MySQL DB, Remove Postgres DB, Remove MySQL DB) outputs into Build Result Payload.
Step 6: Test and Activate Your Workflow
Run a manual test to validate provisioning logic before enabling the workflow for ongoing use.
- Click Execute Workflow on Manual Kickoff.
- Provide test input values (e.g., db_type
postgresqland actioninstall) to validate routing. - Confirm that an SSH node runs and Build Result Payload returns
statusassuccesswith command output inresult. - Once verified, toggle the workflow to Active for production use.
Troubleshooting Tips
- SSH credentials often fail because the server blocks password login or requires sudo. Check your server’s SSH settings (and confirm the account can install packages) before blaming the workflow.
- If you rely on a “Send Email” step (Gmail/SMTP), the message can fail silently when authentication changes. Re-check the Gmail connection in n8n and confirm the From address is allowed to send.
- Database installs can succeed but remote access still fails if firewall or bind settings don’t match your environment. Make sure the server allows the DB port and that your configuration enables the type of remote access you intend.
Quick Answers
About 30 minutes if SSH and email are already working.
No. You’ll import the workflow, connect credentials, and edit a few input fields.
Yes. n8n has a free self-hosted option and a free trial on n8n Cloud. Cloud plans start at $20/month for higher volume. You’ll also need to factor in your server/VPS cost (and any email provider limits, if applicable).
Two options: n8n Cloud (managed, easiest setup) or self-hosting on a VPS. For self-hosting, Hostinger VPS is affordable and handles n8n well. Self-hosting gives you unlimited executions but requires basic server management.
Yes, and you should. Most customizations happen in the “Configure Inputs” (Set) step, where you can add fields like environment (staging/production) or an approved request ID. You can also swap the manual kickoff for an HTTP Request trigger if you want a simple internal form, then keep the same validation gates (database type and action) so the SSH steps remain safe and predictable.
Usually it’s one of three things: the server disallows password login, the SSH user doesn’t have sudo/root privileges for installs, or the host firewall blocks access. Confirm you can SSH from your machine first. Then mirror that configuration in n8n, including the correct port. If your server uses key-based auth, update the n8n credential method accordingly.
A lot, as long as you serialize changes per server to avoid collisions.
For server-side provisioning, n8n is usually the practical choice because SSH-based automations and branching logic are first-class, and self-hosting avoids per-task pricing surprises. Zapier and Make can trigger a request and send notifications, sure, but you’ll often hit limitations once you need conditional logic like “PostgreSQL install vs create vs delete” plus structured outputs. n8n also makes it easier to keep the whole process in one place: inputs, validation, execution, and the final email payload. If you already live in Zapier for marketing ops, you can still use it upstream to collect requests, then hand off to n8n for the risky part. Talk to an automation expert if you want help choosing the cleanest split.
Once this is in place, database requests stop being a recurring interruption. You get consistency, speed, and a clean record of what happened, and you can move on to work that actually needs your attention.
Need Help Setting This Up?
Our automation experts can build and customize this workflow for your specific needs. Free 15-minute consultation—no commitment required.
