Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan
januari 22, 2026

Replicate till WordPress – publicera AI-bilder smidigt

Rickard Andersson Partner, Nodenordic.se

Din innehållspipeline fastnar på ett väldigt trist ställe: du genererar en AI-bild, och sedan slösar du tid på att ladda ner den, byta namn, ladda upp den till WordPress och senare leta upp den slutliga URL:en igen.

Den här Replicate WordPress-automationen slår hårdast mot content marketers, men byråägare och solooperatörer känner av den också. Du får röriga mediebibliotek, inkonsekventa filnamn och “var tog den där bilden vägen?”-ögonblick som gör publiceringen plågsamt långsam.

Det här arbetsflödet gör om en enda prompt till en WordPress-hostad bild-URL (och kan även posta till X). Du får se vad det automatiserar, vilka resultat du kan förvänta dig och vad du behöver för att köra det stabilt.

Så här fungerar automationen

Det fullständiga n8n-arbetsflödet, från trigger till slutligt resultat:

n8n Workflow Template: Replicate till WordPress – publicera AI-bilder smidigt

Problemet: AI-bilder skapar fortfarande manuellt jobb

Att generera en bild är enkelt. Att publicera den snyggt är det som tar tid. Du skapar en banner i en flik, laddar ner ett slumpmässigt filnamn som “output (7).webp”, laddar upp till WordPress och gör sedan samma dans för inline-bilder. En vecka senare är mediebiblioteket en soptipp av dubbletter, inkonsekventa slugs och “final-final-v2”-filer. Det värsta är den mentala belastningen: varje inlägg blir ett litet driftprojekt, och det går inte att skala utan att något glider igenom.

Det eskalerar snabbt. Och det går nästan alltid snett på samma få ställen.

  • Att ladda ner och ladda upp bilder igen tar ungefär 10 minuter per bild, även när du jobbar snabbt.
  • Filnamn matchar inte din inläggs-slug, vilket gör framtida ändringar och granskningar irriterande.
  • Team förlorar tid på att be om länkar eftersom ingen vet den slutliga WordPress-media-URL:en.
  • Valfri social delning blir en separat uppgift, så den antingen hoppas över eller görs inkonsekvent.

Lösningen: generera i Replicate, ladda upp till WordPress automatiskt

Det här n8n-arbetsflödet tar tre indata (en prompt, en filnamnsslug och ett Flux-modellval) och gör om dem till ett publicerat WordPress-mediaobjekt med en snygg, publik URL. Det börjar med att förbereda rätt modellinställningar så att du får ett konsekvent output-format och kvalitet. Sedan anropar det Replicate för att skapa bilden, väntar på prediktionsresultatet och hämtar den genererade bildfilen. Därefter laddas den upp direkt till WordPress media, med din slug så att biblioteket hålls organiserat. Om du vill kan det också posta samma bild till X (tidigare Twitter) och returnerar ett enda payload med WordPress-URL:en plus metadata från båda uppladdningarna.

Arbetsflödet startar när ett annat arbetsflöde (eller en manuell körning) skickar in prompt, slug och model. Replicate genererar bilden, WordPress lagrar den och du får tillbaka en public_image_url som du kan klistra in i inlägg direkt. Inga loopar med nedladdning och uppladdning.

Det här får du: automation vs. resultat

Exempel: så här ser det ut

Säg att du publicerar 5 blogginlägg i veckan och att varje inlägg behöver 4 bilder (en banner plus 3 inline). Det är 20 bilder. Manuellt, om du lägger cirka 10 minuter per bild på att ladda ner, byta namn, ladda upp och kopiera URL:en, hamnar du på ungefär 3 timmar i veckan. Med det här arbetsflödet skickar du in en prompt och en slug på under en minut, och väntar sedan på att generering och uppladdning blir klara. Du får tillbaka WordPress-bildens URL automatiskt, så “adminjobbet” är i princip borta.

Det här behöver du

  • n8n-instans (prova n8n Cloud gratis)
  • Alternativ för egen hosting om du föredrar det (Hostinger fungerar bra)
  • Replicate för att generera bilder med Flux-modeller
  • WordPress för att lagra media och leverera publika URL:er
  • X (Twitter) för att valfritt publicera bilder i sociala kanaler
  • Replicate API-token (hämta den i inställningarna för ditt Replicate-konto)
  • WordPress-applikationslösenord (skapa det i WP-användarprofilen)
  • X API-inloggningsuppgifter (skapa en app i X Developer Portal)

Kompetensnivå: Medel. Du klistrar in API-nycklar, testar några körningar och bekräftar behörigheter för din WordPress media-endpoint.

Vill du inte sätta upp det här själv? Prata med en automationsexpert (gratis 15-minuters konsultation).

Så fungerar det

En prompt kommer in från ett annat arbetsflöde (eller en manuell körning). Du skickar tre fält: bildprompten, sluggen du vill att WordPress ska använda och Flux-modellen du vill ha (som flux-schnell för billigare körningar eller flux-1.1-pro för högprioriterade visuella assets).

Arbetsflödet förbereder ett modell-payload. Det bygger inställningarna som Replicate förväntar sig, inklusive saker som output-format och kvalitetsrelaterade parametrar, så att dina bilder kommer tillbaka i en förutsägbar form.

Replicate genererar bilden och returnerar en output-URL. n8n startar prediktionen och hämtar sedan det färdiga resultatet. Det betyder att du inte behöver sitta och uppdatera manuellt.

WordPress tar emot uppladdningen (och X kan också göra det). Bilden laddas upp till WP media, och arbetsflödet slår ihop resultaten så att du får ett enda svar som innehåller den publika WordPress-bild-URL:en plus eventuell social metadata.

Du kan enkelt ändra modellvalet för att matcha bildens prioritet utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementering

Steg 1: Konfigurera starttriggern för underflödet

Det här arbetsflödet kan startas antingen av ett annat arbetsflöde eller manuellt för testning.

  1. Öppna Subworkflow Start Trigger och bekräfta att arbetsflödesindata inkluderar prompt, slug och model.
  2. Öppna Manual Launch Trigger för att använda den för manuella körningar under utveckling.
  3. Säkerställ att både Subworkflow Start Trigger och Manual Launch Trigger är kopplade till Prepare Model Config.

Använd Manual Launch Trigger under uppsättningen så att ni kan skicka in exempelvärden för prompt, slug och model för snabb testning.

Steg 2: Anslut Replicate API för bildgenerering

Dessa HTTP-anrop startar prediktionsjobbet och hämtar den genererade bildutdata.

  1. Öppna Start Prediction Call och ställ in URL till = https://api.replicate.com/v1/models/{{ $json.model }}/predictions.
  2. I Start Prediction Call, ställ in Method till POST och JSON Body till {{ $json.model_config }}.
  3. Verifiera att headers i Start Prediction Call inkluderar content-type = application/json och Prefer = wait.
  4. Öppna Fetch Prediction Output och ställ in URL till {{ $json.output || $json.output[0] }} för att hämta den resulterande bilden.
  5. Inloggningsuppgifter krävs: Anslut era httpHeaderAuth-uppgifter i Start Prediction Call och Fetch Prediction Output.
  6. Inloggningsuppgifter krävs: Om er Replicate-setup använder bearer auth, anslut även httpBearerAuth-uppgifter i båda noderna.

⚠️ Vanlig fallgrop: Om Replicate API returnerar ett auktoriseringsfel, bekräfta att era httpHeaderAuth- eller httpBearerAuth-uppgifter är aktiva och innehåller rätt API-token.

Steg 3: Sätt upp Prepare Model Config

Den här kodnoden bygger den modellspecifika konfigurationen som skickas till Replicate.

  1. Öppna Prepare Model Config och behåll JavaScript-koden som mappar modellnamn till inställningar.
  2. Bekräfta att logiken kontrollerar inkommande model-värde och kastar ett fel om modellen inte stöds.
  3. Säkerställ att det returnerade objektet inkluderar model och model_config, vilket krävs av Start Prediction Call.

Lägg till fler modellkonfigurationer i Prepare Model Config om ni planerar att stödja fler Replicate-modeller.

Steg 4: Konfigurera uppladdning av utdata och sammanställning av svar

Den genererade bilden laddas upp till WordPress och X parallellt och aggregeras sedan till en slutlig payload.

  1. Öppna Upload Image to WP och ställ in URL till https://articles.emp0.com/wp-json/wp/v2/media.
  2. I Upload Image to WP, ställ in Content Type till binaryData och Input Data Field Name till data.
  3. Bekräfta att headern Content-Disposition är satt till =attachment; filename="img-{{ $('Prepare Model Config').item.json.slug }}.jpg".
  4. Inloggningsuppgifter krävs: Anslut era wordpressApi-uppgifter i Upload Image to WP.
  5. Öppna Upload Media to X och ställ in URL till https://upload.twitter.com/1.1/media/upload.json?media_category=TWEET_IMAGE.
  6. I Upload Media to X, ställ in Content Type till multipart-form-data och bekräfta att body-parametern media använder formBinaryData från data.
  7. Inloggningsuppgifter krävs: Anslut era twitterOAuth1Api-uppgifter i Upload Media to X.
  8. Fetch Prediction Output skickar utdata till både Upload Image to WP och Upload Media to X parallellt.
  9. Verifiera att Combine Upload Results slår ihop båda uppladdningssvaren, och att Aggregate Items sätter Aggregate till aggregateAllItemData.
  10. Öppna Assemble Output Payload och behåll return-objektet som bygger fälten public_image_url, wordpress och twitter.

⚠️ Vanlig fallgrop: Om uppladdningar till WordPress misslyckas, verifiera URL:en till media-endpointen och att ert WordPress-konto har behörighet att ladda upp media.

Steg 5: Testa och aktivera ert arbetsflöde

Kör ett fullständigt test för att bekräfta att bilden genereras, laddas upp till båda destinationerna och att den slutliga payloaden sammanställs korrekt.

  1. Klicka på Execute Workflow i Manual Launch Trigger och ange exempelvärden för prompt, slug och model.
  2. Bekräfta att Start Prediction Call returnerar ett prediktionssvar och att Fetch Prediction Output laddar ner bilden.
  3. Verifiera att både Upload Image to WP och Upload Media to X lyckas och producerar svarsdata.
  4. Kontrollera att Assemble Output Payload har en giltig public_image_url och ifyllda wordpress- och twitter-objekt.
  5. När allt är validerat, aktivera arbetsflödet så att det kan köras via Subworkflow Start Trigger i produktion.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • WordPress-inloggningar kan löpa ut eller sakna mediabehörigheter. Om uppladdningar misslyckas, kontrollera din WP-användares applikationslösenord och bekräfta att kontot kan ladda upp media.
  • Om du använder väntbeteende indirekt (Replicate-prediktioner plus hämtningstiming) varierar processtiderna. Öka väntetiden eller lägg till retries om hämtsteget returnerar en ofullständig prediktion.
  • X (Twitter) API-åtkomst är lätt att konfigurera fel. Om X-uppladdningen misslyckas, verifiera appens skrivbehörigheter och kontrollera loggarna i utvecklardashboarden efter blockerade media-endpoints.

Vanliga frågor

Hur lång tid tar det att sätta upp den här Replicate WordPress-automationen?

Cirka 30 minuter om du redan har API-inloggningsuppgifterna redo.

Behöver jag kunna koda för att automatisera Replicate WordPress-automation?

Nej. Du kopplar mest ihop konton och klistrar in API-nycklar. Arbetsflödets logik är redan byggd.

Är n8n gratis att använda för det här Replicate WordPress-automationsarbetsflödet?

Ja. n8n har ett gratis alternativ för egen hosting 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 in Replicate-kostnader (till exempel kostar flux-schnell cirka 3 USD per 1 000 bilder).

Var kan jag hosta n8n för att köra den här automationen?

Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen hosting på en VPS. För egen hosting är Hostinger VPS prisvärd och hanterar n8n bra. Egen hosting ger obegränsade körningar men kräver grundläggande serveradministration.

Kan jag anpassa det här Replicate WordPress-automationsarbetsflödet för olika Flux-modeller och bildstorlekar?

Ja, och det bör du. Du kan växla mellan black-forest-labs/flux-schnell, black-forest-labs/flux-dev och black-forest-labs/flux-1.1-pro genom att ändra modellindatan som skickas in i arbetsflödet. För konsekvent bildformat och stil justerar du inställningarna som byggs i kodsteget “Prepare Model Config” (saker som bildförhållande, steg, guidance och output-format). Många team behåller en “banner-preset” och en “inline-preset” så att sajten ser sammanhållen ut utan extra redigering.

Varför misslyckas min Replicate-anslutning i det här arbetsflödet?

Oftast är det en ogiltig eller utgången Replicate API-token. Skapa en ny token i Replicate, uppdatera sedan autentiseringsuppgiften i n8n och kör en testprompt igen. Om det bara misslyckas ibland kan du slå i rate limits eller hämta prediktionsoutputen för tidigt, så att lägga till en retry eller en något längre väntetid brukar lösa det.

Hur många bilder kan den här Replicate WordPress-automationen hantera?

Om du hostar n8n själv finns ingen begränsning för antal körningar, så det beror främst på din server och API-gränser. På n8n Cloud beror dina månatliga körningar på plan-nivå, och det här arbetsflödet använder normalt en handfull steg per bild. I praktiken används upplägg som detta ofta runt 1 000 bilder i månaden utan problem, så länge ditt WordPress-hotell klarar uppladdningarna.

Är den här Replicate WordPress-automationen bättre än att använda Zapier eller Make?

Ofta, ja, eftersom det här flödet har nytta av HTTP-anrop i flera steg, förgrening (WordPress plus valfri X) och att slå ihop resultat snyggt till ett enda output. n8n är också bättre när du vill hosta själv och köra många körningar utan att kostnaden sticker i väg varje gång du skalar innehåll. Zapier eller Make kan vara snabbare för enkel tvåstegspublicering, men du kan hamna i begränsningar när du lägger till “vänta på prediktion”, filhantering och flera destinationer. Om du vill ha hjälp att välja, prata med en automationsexpert.

När det här väl rullar blir bildpublicering en bakgrundsuppgift i stället för en flaskhals. Du får snygga WordPress-URL:er på beställning, och ditt mediebibliotek slutar spåra ur i kaos.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Launch login modal Launch register modal