ManyChat charges you a monthly subscription for one core trick: someone comments “LINK” on your reel, and a DM with your link lands in their inbox a second later.<\/p>\n\n\n\n
That trick is a webhook, a keyword match, and one API call. It doesn’t need to cost anything.<\/p>\n\n\n\n
OpenReply<\/a> is an open-source (MIT) version of exactly that \u2014 Instagram comment-to-DM automation you self-host with your own API keys. No seat limits, no plan caps, no monthly bill. It uses Meta’s official Instagram API: no scraping, no browser automation, no handing over your password. Your account stays inside Meta’s rules, which matters if you’d like to keep it.<\/p>\n\n\n\n In this post I’ll walk you through the full setup: hosting, environment, the Meta app (the part that actually takes time), and testing it end to end.<\/p>\n\n\n\n Two processes, two datastores. A Next.js web app serves the dashboard, the OAuth callback, and the incoming webhook. A separate long-running Node worker consumes the send queue and actually fires the DMs. They share a Postgres database (campaigns, logs, accounts) and Redis (the BullMQ queue and rate limiter).<\/p>\n\n\n\n The split matters for hosting: the web app runs happily on Vercel, but the worker can’t \u2014 serverless functions die, and a queue consumer has to stay up. So the recommended free-tier stack is Vercel for the web app and Railway for the worker plus Postgres and Redis.<\/p>\n\n\n\n One rule you cannot break: the web app and worker must share the same Set expectations now: the code deploys in minutes. The Meta app setup is where you’ll spend an afternoon the first time. That’s not OpenReply’s fault \u2014 it’s just Meta.<\/p>\n\n\n\n If you just want to poke around before deploying:<\/p>\n\n\n\n Two processes, always. Do Railway first, because Vercel needs the database URLs from it. Create a project, add PostgreSQL, add Redis, then add the worker as a GitHub Repo service pointing at your fork. Override the worker’s build and start commands:<\/p>\n\n\n\n Don’t leave the default On connection strings: Railway gives you two URLs per datastore. The internal ones ( Run once from your machine using the public Postgres URL.<\/p>\n\n\n\n Import your fork as a new Vercel project (it auto-detects Next.js), add every environment variable, and deploy. Key values: Generate the secrets like this:<\/p>\n\n\n\n Plus a This is the slow part, and the setup guide is refreshingly honest about it. The short version, with the traps that catch everyone:<\/p>\n\n\n\n Connect your account in the app (Settings \u2192 Connect Instagram), create a campaign on one of your posts with a keyword like If nothing arrives, This is my favourite detail in the repo. The setup guide includes a ready-made prompt for Claude Code or Cursor \u2014 you open a clone of the repo in your assistant, paste the prompt, and it walks the entire setup with you: generates the secrets, deploys both processes, then steps you through the Meta dashboard one screen at a time, asking for values only you can provide. It even includes rules telling the assistant to diagnose failures by querying the Postgres tables directly instead of guessing.<\/p>\n\n\n\n One caution the docs make and I’ll repeat: you’ll be pasting real secrets into a chat. Only do that in tooling you trust, and rotate anything you pasted once you’re live.<\/p>\n\n\n\n This is exactly the pattern I teach inside my community \u2014 self-hosting the tools everyone else rents, with AI doing the heavy lifting on setup. If you want to go deeper on builds like this, that’s what AI Business Mentors<\/a> is for.<\/p>\n\n\n\n Everything above covers running OpenReply for your own accounts, or a handful you add as testers \u2014 no App Review needed. If you want strangers to connect their own Instagram to your hosted instance, Meta requires Advanced Access review: a screencast of the full flow, written permission justifications (drafts are included in the repo), and business verification with real legal documents. Meta scrutinises automated-DM apps and often rejects the first submission. Most self-hosters skip this entirely and just run their own instance for their own account \u2014 which is the whole point anyway.<\/p>\n\n\n\n An afternoon of Meta dashboard pain buys you a ManyChat replacement that runs free on Vercel and Railway’s free tiers, keeps your account inside Meta’s official API, and tracks clicks per campaign. If comment-to-DM is part of how you distribute content \u2014 and if you’re gating lead magnets behind comments, it should be \u2014 this is one subscription you no longer need.<\/p>\n\n\n\n Build with me<\/p>\n\n\n\n Inside SeanNoCode I show you how to self-host tools like this, wire them into a real client-getting system, and build a one-person AI business around them \u2014 live Q&A, course library, and a community of people actually shipping.<\/p>\n\n\n\nWhat you get<\/h2>\n\n\n\n
\n
How it’s built<\/h2>\n\n\n\n
DATABASE_URL<\/code>, REDIS_URL<\/code>, and ENCRYPTION_KEY<\/code>. The web app encrypts your Instagram token; the worker decrypts it to send. Different keys and every single send fails.<\/p>\n\n\n\nWhat you need before you start<\/h2>\n\n\n\n
\n
your-app.vercel.app<\/code> URL is what everything points at.<\/li>\n<\/ul>\n\n\n\nOption 1: Run it locally first<\/h2>\n\n\n\n
git clone https:\/\/github.com\/diwenne\/openreply.git\ncd openreply\nnpm install\ncp .env.example .env # fill in the values per docs\/setup.md\ndocker-compose up -d # starts Postgres and Redis\nnpm run db:migrate\nnpm run dev # web app on http:\/\/localhost:3000\nnpm run worker # second terminal \u2014 this sends the DMs<\/code><\/pre>\n\n\n\nnpm run dev<\/code> receives the webhooks; npm run worker<\/code> sends the messages. If comments come in and no DM ever goes out, the worker is the first thing to check. For Meta to reach your local machine you’ll need a tunnel like ngrok http 3000<\/code>, with your tunnel URL used everywhere a public URL is required.<\/p>\n\n\n\nOption 2: The production setup<\/h2>\n\n\n\n
Step 1 \u2014 Railway: Postgres, Redis, worker<\/h3>\n\n\n\n
Build Command: npm run db:generate\nStart Command: npm run worker<\/code><\/pre>\n\n\n\nnpm run build<\/code> \u2014 the worker doesn’t need a Next.js build, and any build step that touches the database will fail because the worker can’t reach Postgres at build time.<\/p>\n\n\n\n*.railway.internal<\/code>) are for the worker \u2014 faster and free of egress inside Railway’s network. The public ones (*.proxy.rlwy.net<\/code>) are for Vercel and for running migrations from your machine. Give Vercel an internal URL and it will hang and time out \u2014 this is one of the classic mistakes.<\/p>\n\n\n\nStep 2 \u2014 Migrate the production database<\/h3>\n\n\n\n
DATABASE_URL=\"postgresql:\/\/...proxy.rlwy.net...\/railway\" npm run db:migrate<\/code><\/pre>\n\n\n\nStep 3 \u2014 Vercel: the web app<\/h3>\n\n\n\n
NEXTAUTH_URL<\/code> is your Vercel domain, DATABASE_URL<\/code> and REDIS_URL<\/code> are the public<\/em> Railway URLs, and ENCRYPTION_KEY<\/code> is the exact same value as on the worker.<\/p>\n\n\n\nopenssl rand -base64 32 # NEXTAUTH_SECRET\nopenssl rand -hex 32 # ENCRYPTION_KEY (must be exactly 64 hex chars)<\/code><\/pre>\n\n\n\nCRON_SECRET<\/code> and a WEBHOOK_VERIFY_TOKEN<\/code> (any random string \u2014 you’ll paste the same value into Meta’s webhook config later). The full variable table is in the repo’s docs\/setup.md<\/a>.<\/p>\n\n\n\nThe Meta app: where the afternoon goes<\/h2>\n\n\n\n
\n
INSTAGRAM_APP_ID<\/code> and INSTAGRAM_APP_SECRET<\/code> from the Instagram product page, FACEBOOK_APP_SECRET<\/code> from Settings \u2192 Basic. Trap:<\/strong> the Instagram app ID is a different number from the Facebook App ID. Use the one under the Instagram product.<\/li>\n\n\n\nhttps:\/\/your-app.vercel.app\/api\/instagram\/callback<\/code> \u2014 exact, no trailing slash.<\/li>\n\n\n\nhttps:\/\/your-app.vercel.app\/api\/webhook<\/code>, verify token = your WEBHOOK_VERIFY_TOKEN<\/code>, subscribe to the comments<\/code> field. Use the console’s Test \u2192 Send to My Server button to confirm delivery \u2014 it’s a two-step control, and only the second click actually POSTs.<\/li>\n\n\n\nTest it end to end<\/h2>\n\n\n\n
TEST<\/code>, then comment that keyword from a different account<\/strong> \u2014 OpenReply deliberately ignores your own comments. Watch for the DM.<\/p>\n\n\n\n\/api\/health<\/code> is your friend: it reports the database, Redis, queue, and worker heartbeat. If worker.healthy<\/code> is false, no DM will ever send no matter how perfect your Meta config is. Beyond that, the Postgres tables tell the whole story \u2014 WebhookEvent<\/code> for delivery, DmLog<\/code> for send status, OperationalEvent<\/code> for worker errors.<\/p>\n\n\n\nOr: let an AI assistant drive it<\/h2>\n\n\n\n
One honest limitation<\/h2>\n\n\n\n
The bottom line<\/h2>\n\n\n\n
Stop renting your stack<\/h3>\n\n\n\n