A legtöbb kis cég nem azért nem posztol Facebook-ra, mert nincs mondanivalója — azért nem posztol, mert senki nem ül le délután ötkor elgondolkodni azon, hogy hol van a jó képe a héten, milyen felirat illene hozzá, hashtag-et hogyan válasszon, és hogy egyáltalán rátegye-e Instagramra is vagy csak FB-re legyen. Ez több munka, mint amennyit egy 4-fős ügyvédi iroda vagy egy pékség vezetője szívesen csinálna.

Erre született meg a GhostlyPost. A koncepció: odaadod neki a képeidet és a videóidat, ő meg — mint egy szellem a gépben — megírja a caption-öket, kiválasztja a legjobb képet, ütemezi a posztokat, és feltölti őket Facebook-ra meg Instagram-ra. Te annyit csinálsz, hogy rakod bele a képeket. A többit elintézi a gép.

Miért szellem?

A brand-tematikája nem véletlen. A „ghost" szó kettős jelentésű: egyrészt valami, ami a háttérben dolgozik, nem látszik (ghost-writer), másrészt játékos, nem-corporate hangulatot ad. A logó egy kedves kis szellem (ghostly.svg), a Messenger bot válaszai is szellem-tematikájúak: amikor felteszel egy képet, azt mondja „👻 Megvan, a következő posztban kiküldöm." — nem valami steril „Kérelmét fogadtuk, ügyintézője hamarosan jelentkezik."-es vállalati automatizmus.

Az a tapasztalat, hogy a KKV tulajdonosok nem a hatalmas funkciólisták miatt választanak eszközt — azért, mert valami emberközeli módon szól hozzájuk. A Ghostly pont ezt csinálja.

Architektúra — szétosztva két konténerbe

A rendszer Proxmox alatt fut, két Linux Container-ben:

Ez a setup gyakorlatilag olcsó is — havi fix költség nincs, az egész egy otthoni Proxmox szerveren van. A Cloudflare Tunnel ingyenes, és az ügyfelek webhook-jai ezen keresztül érkeznek be.

Queue rendszer — a szív

A posztolás aszinkron, three-phase pipeline-ban történik:

  1. Pre-render (15 percenként): prepare_calendar.py megnézi, hogy a következő 7 nap ütemezésében milyen slotok vannak, és mindegyikre előre elkészít egy posztot — AI kiválaszt képet, Gemini ír caption-t, berakja a content-naptárba. Az ügyfél a dashboardon előnézetben látja, és kattintással elvetheti vagy szerkesztheti.
  2. Scheduler (5 percenként): queue_scheduler.py megnézi mely posztok esedékesek most, és felvesz egy rekordot a post_queue táblába pending állapotban.
  3. Worker (1 percenként): queue_worker.py atomi módon kiszolgál egy pending posztot (UPDATE RETURNING a dupla-futás ellen), átváltja processing-ra, elposztolja Meta Graph API-n keresztül, és done-ra állítja.
Dupla posztolás védelem

Három réteg: (1) Partial unique index a (client_id, post_type, scheduled_date, scheduled_time)-ra, WHERE status IN ('pending', 'processing'). (2) Atomi claim — a worker UPDATE ... WHERE id = (SELECT ... LIMIT 1) RETURNING *-gal ragad ki egy feladatot, tehát két worker sohasem kapja el ugyanazt. (3) Stale recovery — ha egy feladat 15 perce processing állapotban van, visszarakja pending-re max 3 próbálkozásig.

5+1+15
perc — scheduler / worker / pre-render
3×
védelmi réteg a dupla posztolás ellen
±25p
konfigurálható időablak a posztokra

Az AI réteg — Gemini + OpenAI fallback

Három dologra használ AI-t a rendszer:

Ha a Gemini API nem válaszol (rate limit, outage), automatikusan átkapcsol OpenAI GPT-4o-mini-re. Ez nem ugyanaz a minőség, de jobb, mint egy „próbáljuk újra 15 perc múlva" üzenet.

A Messenger bot — a kapu

A leginkább eladható funkció nem is a dashboard, hanem a Messenger bot. Az ügyfél saját Facebook-jelenléten keresztül üzenget a GhostlyPost oldalra, és:

A parancs-rendszer tizenkét parancsot támogat: /help, /status, /schedule, /post, /reels, /next, /pause, /resume, /invoice, /bind, /unbind. A /bind KÓDNÉV-el az ügyfél egy egyszer használatos kóddal köti össze a Messenger fiókját a GhostlyPost ügyfél-fiókjával.

A webhook biztonsága HMAC-SHA256 signature-el van védve: a Meta minden callback-et aláír az app secret-jel, a mi oldalunk ellenőrzi. Ha nem egyezik, a kérés eldobódik.

Jogosultság — négy szint

Nem egyszerű admin/user felosztás, hanem négy role:

  1. SuperAdmin — minden: felhasználók, csomagok, rendszer-konfiguráció, deploy gombok
  2. Admin — ügyfelek, leads, queue, security log, deploy (de nem felhasználó-kezelés)
  3. Agent — csak a hozzárendelt ügyfelek kezelése (N:M kapcsolat az agent_clients táblán)
  4. User — csak a saját ügyfél dashboard: média feltöltés, ütemezés, branding, számlázás

Ez a séma egy fontos üzleti célt szolgál: agent partnerek tudnak kezelni több ügyfelet (pl. egy marketing ügynökség a saját kliensei nevében), anélkül hogy egymás adatait látnák.

Biztonság — a tokenek

A Meta API token az ügyfél Facebook-oldalához, ez a drágakő. Ha kiszivárog, a GhostlyPost egy spammelő botnet-é válhatna. Ezért:

Amit megtanultam

A queue az első változat soha nem volt jó. Az első verzióban egy egyszerű scheduler volt, ami közvetlenül posztolt — nem atomi, nem retry-olható, nem recovery-zhető. Amikor egy poszt közben crash-elt a worker, a feladat örökre processing állapotban maradt. Amikor két worker egyszerre indult, duplán posztolt. A partial unique index + atomic claim + stale recovery hármas együtt oldotta meg a dolgot — és ezen tanultam meg, hogy a queue-pattern nem csak technikai nyugalom, hanem ügyfél-bizalom is: a duplán posztolt „új szuper ajánlat" szörnyű benyomás.

Az AI fallback megéri. Mikor a Gemini egyszer két napig elérhetetlen volt, az OpenAI GPT-4o-mini simán átvette, az ügyfelek észre se vették. A FALLBACK_AI_PROVIDER env-változó kapcsol közöttük. Ez olyan, mint egy UPS: reméled nem kell, de amikor kell, ott van.

A Messenger bot a belépő. Az ügyfeleim 80%-a sose nyitja meg a dashboardot — Messenger-ben dobálják be a képeket, és ennyi. A dashboard az admin dolga, nem a felhasználóé. Ezt mindig úgy tervezd meg, hogy egyetlen dologra legyen szükség a felhasználó oldalán — a többit intézd te.

Ki próbálja ki?

Ott van élesben: ghostlypost.com. 14 napos ingyenes próba van most, regisztráció után önboarding wizard vezet végig. Ha kérdésed van, írj egy emailt — én veszem fel a telefont.

A gép ne helyettesítsen — szabadítson fel. Egy KKV vezető nem akar feed-stratégiát írni. Azt akarja, hogy legyen feed, és ő közben foglalkozzon azzal, amiben jó.