Ditt team ber om en RDS-databas. Du fixar det. Sedan kommer den irriterande delen: jaga saknade uppgifter, dubbelkolla ”körde den här?”, och försöka återskapa vad som hände för två dagar sedan utifrån en rörig e-posttråd.
Den här Gmail Sheets-automationen träffar DevOps-ansvariga först, ärligt talat, men IT-chefer och byråteam som hanterar kunders infrastruktur känner samma friktion. Vinsten är enkel: varje begäran blir en spårad radpost, och varje utfall bekräftas tillbaka till den som begärde det.
Nedan ser du hur workflowet förvandlar e-post med ”Create RDS” eller ”Delete RDS” till Terraform-styrda åtgärder, loggar hela revisionsspåret i Google Sheets och skickar ett statusmejl du kan lita på.
Så här fungerar automationen
Här är hela workflowet du kommer att sätta upp:
n8n Workflow Template: Gmail + Google Sheets: följ upp AWS RDS-förfrågningar snabbt
flowchart LR
subgraph sg0["Flow 1"]
direction LR
n0@{ icon: "mdi:message-outline", form: "rounded", label: "Gmail Trigger", pos: "b", h: 48 }
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Parse Email Content"]
n2@{ icon: "mdi:cog", form: "rounded", label: "Manage RDS Instance", pos: "b", h: 48 }
n3@{ icon: "mdi:database", form: "rounded", label: "Update Google Sheet", pos: "b", h: 48 }
n4@{ icon: "mdi:message-outline", form: "rounded", label: "Send Confirmation Email", pos: "b", h: 48 }
n0 --> n1
n2 --> n3
n1 --> n2
n3 --> n4
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 n3 database
class n1 code
classDef customIcon fill:none,stroke:none
class n1 customIcon
Varför det här spelar roll: RDS-begäranden blir snabbt röriga
Infrastrukturförfrågningar via e-post börjar ”enkelt” och övergår sedan tyst till kaos. Någon skriver ”kan du spinna upp en Postgres-DB”, men regionen saknas. Sedan ändras instansklassen. Sedan kommer ett andra mejl som säger ”ignorera mitt förra” (men du har redan börjat). När databasen väl är uppe frågar den som begärde den efter endpointen, du klistrar in den i tråden, och senare hittar ingen den. Den verkliga kostnaden är inte bara provisioneringstiden. Det är avbrotten, att behöva backa och göra om, och avsaknaden av ett revisionsspår när något går fel.
Det summerar snabbt. Här är var friktionen oftast uppstår.
- Begäransdetaljer kommer in ofullständiga, så du bränner cirka 20 minuter per begäran på att reda ut grunder som motor, region och identifierare.
- Statusuppdateringar fastnar i inkorgar, vilket gör att intressenter pingar dig eftersom de inte kan se framdrift någonstans.
- Terraform-körningar sker ”vid sidan av”, så revisionsspåret är utspritt mellan terminalhistorik och några e-postsvar.
- Att ta bort RDS är mer riskfyllt än det borde vara, eftersom spåret för vem som begärde det och när ofta är tunt.
Det du bygger: e-poststyrd RDS-provisionering med logg i ett kalkylark
Det här workflowet ger dig en mer robust ”begäran till resultat”-loop med verktyg du redan jobbar i. Det startar när ett nytt mejl landar i Gmail med ett tydligt kommando som ”Create RDS” eller ”Delete RDS”, plus nyckelparametrar (motor, instansklass, lagring, region och inloggningsuppgifter). n8n tolkar e-postinnehållet till strukturerade fält, och triggar sedan en Terraform-baserad åtgärd över SSH för att skapa eller ta bort RDS-resursen. Därefter skriver workflowet en rad till Google Sheets (eller uppdaterar en befintlig) med identifierare, konfiguration och aktuell status. Till sist skickar det ett bekräftelsemejl tillbaka till den som begärde åtgärden, så att ingen behöver gissa vad som hände.
Workflowet börjar med att ta in mejl från Gmail. Sedan extraherar n8n begäransdetaljerna och kör Terraform-kommandot för att skapa eller ta bort RDS. Google Sheets blir din löpande revisionslogg, och Gmail skickar det avslutande ”klart”-meddelandet med detaljer om lyckat eller misslyckat resultat.
Det du bygger
| Vad som automatiseras | Vad du uppnår |
|---|---|
|
|
Förväntade resultat
Säg att du hanterar 10 RDS-begäranden under en vecka. Manuellt tar det oftast cirka 20 minuter att reda ut detaljer, cirka 10 minuter att köra rätt Terraform-kommandon och fånga outputs, och ytterligare 10 minuter med uppföljningar senare. Det är ungefär 40 minuter per begäran, eller nära 7 timmar i veckan. Med det här workflowet sjunker ”mänsklig tid” till att skriva begäransmejlet (några minuter) och att granska bekräftelsen om något misslyckas, så du får normalt tillbaka större delen av tiden.
Innan du börjar
- n8n-instans (prova n8n Cloud gratis)
- Självhostat alternativ om du föredrar det (Hostinger fungerar bra)
- Gmail för att ta emot begäranden och skicka bekräftelser
- Google Sheets för att lagra begäranslogg och status
- AWS-inloggningsuppgifter (skapa en IAM-användare med RDS-behörigheter)
- SSH-åtkomst till en Terraform-runner (en server som kan köra Terraform)
Kunskapsnivå: Medel. Du bygger ingen app, men du bör vara bekväm med att koppla konton och köra Terraform i en kontrollerad miljö.
Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).
Steg för steg
Ett begäransmejl kommer in i Gmail. Triggern bevakar nya meddelanden så att du kan standardisera begäranden kring ämnesrader eller nyckelord som ”Create RDS” och ”Delete RDS”.
Mejlet tolkas till användbara fält. n8n extraherar detaljer som databasens identifierare, motor (MySQL/PostgreSQL), instansklass, allokerad lagring, region och de inloggningsuppgifter som workflowet behöver skicka in som Terraform-variabler.
Terraform provisionerar eller tar bort RDS-instansen via SSH. Workflowet ansluter till din Terraform-runner och kör rätt åtgärd baserat på kommandot som upptäcks i e-postens brödtext. Om du vill ha skyddsräcken är det här du även kan lägga in godkännandelogik.
Google Sheets uppdateras och ett bekräftelsemejl skickas. En rad läggs till (eller uppdateras) med konfiguration och status, och sedan svarar Gmail för att bekräfta utfallet, inklusive eventuell feltext som förklarar vad som misslyckades.
Du kan enkelt ändra vilket e-postformat som accepteras så att det matchar er interna begäranmall utifrån era behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: konfigurera Gmail-triggern
Konfigurera arbetsflödet så att det startar när ett e-postmeddelande kommer in och skicka sedan vidare e-postmeddelandet in i bearbetningskedjan.
- Lägg till och öppna Email Arrival Trigger.
- Ställ in Operation på
trigger. - Inloggningsuppgifter krävs: Anslut era
gmailOAuth2-inloggningsuppgifter för Email Arrival Trigger.
Steg 2: konfigurera tolkning av e-post
Tolka inkommande e-post till strukturerade fält som automatiseringen använder längre fram.
- Öppna Extract Email Details.
- Implementera logik som returnerar fält som
operation,db_identifier,db_name,db_engine,instance_class,allocated_storage,region,server_user,server_ip,pwdochrequester_email.
operation saknas eller är felstavat kommer SSH-kommandot i Provision RDS Resource inte att köra avsedd create/delete-väg.Steg 3: konfigurera RDS-provisionering via SSH
Använd SSH för att köra Terraform-kommandon som skapar eller tar bort RDS-resursen.
- Lägg till och öppna Provision RDS Resource.
- Ställ in Authentication på
privateKey. - Ställ in Command till det angivna uttrycket:
={{$json.operation === 'create' ? `# Variables SERVER_USER="{{ $json.server_user }}" SERVER_IP="{{ $json.server_ip }}" WORKSPACE_NAME="{{ $json.db_identifier }}" PWD="{{ $json.pwd }}" # SSH and run Terraform commands echo "$PWD" | ssh ${SERVER_USER}@${SERVER_IP} " cd /path/to/terraform/project && terraform workspace new ${WORKSPACE_NAME} || terraform workspace select ${WORKSPACE_NAME} && terraform init && terraform plan -out=tfplan && terraform apply -auto-approve tfplan "` : `# Variables SERVER_USER="{{ $json.server_user }}" SERVER_IP="{{ $json.server_ip }}" WORKSPACE_NAME="{{ $json.db_identifier }}" PWD="{{ $json.pwd }}" # SSH and run Terraform destroy echo "$PWD" | ssh ${SERVER_USER}@${SERVER_IP} " cd /path/to/terraform/project && terraform workspace select ${WORKSPACE_NAME} && terraform destroy -auto-approve "`}} - Inloggningsuppgifter krävs: Anslut era
sshPrivateKey-inloggningsuppgifter för Provision RDS Resource.
/path/to/terraform/project finns på SSH-värden och att Terraform är installerat, annars misslyckas kommandot.Steg 4: konfigurera loggning och statusmejl
Logga varje operation till Google Sheets och skicka ett statusmejl till den som begärt åtgärden.
- Öppna Append Sheet Log och ställ in Operation på
append. - Ställ in Authentication på
serviceAccount. - Ställ in Document till
[YOUR_ID]och Sheet Name tillRDS_Operations. - Mappa kolumner med de angivna uttrycken, till exempel region =
{{ $json.region }}, endpoint ={{ $json.endpoint || 'N/A' }}och timestamp ={{ $now.toISO() }}. - Inloggningsuppgifter krävs: Anslut era
googleApi-inloggningsuppgifter för Append Sheet Log. - Öppna Dispatch Status Email och ställ in Send To till
{{ $json.requester_email }}. - Ställ in Subject till
{{ $json.operation === 'create' ? '✅ AWS RDS Database Created Successfully - ' + $json.db_name : '🗑️ AWS RDS Database Deleted Successfully - ' + $json.db_name }}. - Ställ in Message till det angivna HTML-uttrycket som växlar baserat på
operation. - Inloggningsuppgifter krävs: Anslut era
gmailOAuth2-inloggningsuppgifter för Dispatch Status Email.
options.ccList i Dispatch Status Email så att den inkluderar er adress till driftteamet.Steg 5: testa och aktivera ert arbetsflöde
Validera hela exekveringskedjan och aktivera arbetsflödet för användning i produktion.
- Klicka på Execute Workflow och skicka ett testmejl som matchar ert förväntade format för förfrågningar.
- Bekräfta att Email Arrival Trigger skickar data till Extract Email Details, sedan till Provision RDS Resource och vidare till Append Sheet Log och Dispatch Status Email.
- Verifiera att en ny rad visas i arket
RDS_Operationsoch att den som begärt åtgärden får rätt statusmejl. - När allt är validerat, slå på arbetsflödet till Active för kontinuerlig bearbetning.
Felsökningstips
- Gmail-inloggningsuppgifter kan gå ut eller kräva specifika behörigheter. Om det skapar fel, kontrollera n8n-skärmen Credentials och bekräfta att Gmail-scope tillåter att läsa och skicka e-post.
- Om du använder Wait-noder eller extern provisionering varierar processtiderna. Öka väntetiden om efterföljande noder fallerar på tomma svar medan RDS fortfarande skapas.
- SSH/Terraform-fel är ofta miljöproblem, inte workflowproblem. Verifiera att den fjärrkörande runnern har rätt AWS-inloggningsuppgifter, att Terraform är installerat och att den har åtkomst till state-backend innan du rör parsningen.
Snabba svar
Cirka 45 minuter om dina inloggningsuppgifter och din Terraform-runner redan är klara.
Nej. Du konfigurerar främst inloggningsuppgifter och justerar reglerna för e-postparsning. Du kan behöva finjustera en liten kodnod om ditt e-postformat är unikt.
Ja. n8n har ett gratis självhostat alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna med AWS-kostnader för de RDS-instanser du skapar och servern du använder för att köra Terraform.
Två alternativ: n8n Cloud (hanterat, enklast uppsättning) eller självhosting på en VPS. För självhosting är Hostinger VPS prisvärd och hanterar n8n bra. Självhosting ger dig obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det borde du förmodligen. Du kan justera logiken i ”Extract Email Details” så att den accepterar din egen begäranmall, och sedan byta ut SSH/Terraform-steget för att köra andra moduler (snapshots, ändringar i parametergrupp, till och med ”update instance class”). Vanliga justeringar är att lägga till ett godkännandesteg för borttagningar, tvinga begäranden till en specifik region och maska lösenord från det som skrivs till Google Sheets.
Oftast handlar det om utgången auktorisering eller fel Gmail-scopes. Anslut Gmail-credential på nytt i n8n och bekräfta att den har behörighet att läsa inkommande e-post och skicka svar. Kontrollera också om du filtrerar på etiketter eller sökfrågor; en minimal mismatch i queryn kan få det att se ”trasigt” ut när det bara är så att den inte matchar några mejl.
För de flesta små team fungerar det bra med dussintals begäranden per dag, så länge din Terraform-runner och dina AWS-kontogränser hänger med.
Ofta, ja, eftersom det här inte är en enkel automation som ”flyttar data från A till B”. Du tolkar en semistrukturerad begäran, genomför infrastrukturändringar, väntar på provisionering och loggar utfall. n8n hanterar förgreningslogik snyggt, och självhosting undviker prissättning per uppgift när du börjar bearbeta många begäranden. Zapier eller Make kan fortfarande fungera om du bara vill logga mejl till ett ark och notifiera någon, men de är inte optimala för att köra Terraform på ett säkert sätt. Om du är osäker, prata med en automationsexpert och få en rak rekommendation.
När detta väl rullar slutar inkorgen att vara ert ärendehanteringssystem. Workflowet sköter loggen, skickar bekräftelserna och ger dig färre avbrott under det riktiga jobbet.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.