Switch from Manychat to OpenReply

Turn one Instagram comment into an automatic DM you control. In this guide, you’ll rebuild one Manychat comment-to-DM automation in OpenReply, test it with a second account, and only then decide whether to retire the old setup. Your first win: someone comments GUIDE on a reel and receives your link in their inbox. Tiny word, big job.

The honest trade: OpenReply is free, open-source software you host yourself. The dashboard demo cannot send messages for you. Hosting, email delivery, and an optional connection provider can cost money, and you’re responsible for keeping the app running. It focuses on Instagram; it is not a one-click replacement for every Manychat channel, contact, or complex flow.

Your pre-flight checklist

• An Instagram Business or Creator account, access to its Meta Business Suite, and a second Instagram account to test with.
• Access to your existing Manychat automations so you can record the trigger, message, link, and any follow-up steps before changing anything.
• A GitHub account, a place to host the app and an always-on worker, PostgreSQL, Redis, and email delivery for sign-in. OpenReply’s setup guide uses Vercel, Railway, and Resend as an example. Check their current costs and account requirements first.
• A little patience for setup. If hosting and environment variables sound like a different language, use the coding-assistant prompt below or ask someone comfortable deploying web apps to help.

Pick one small automation first. If you depend on WhatsApp, email, advanced branching, contact data, or other Manychat features, inventory them separately and confirm how you’ll replace them before canceling anything. The project does not promise an automatic Manychat import.

1. Map your current automation

Open the Manychat automation you want to move. Write down the Instagram post or reel, trigger keyword, public reply, DM text, destination URL, buttons, and any follow-up messages. Note where contacts and opt-ins go and whether another tool needs that data. Keep private contact exports and credentials out of shared documents and AI chats.

For our fictional example, the reel offers a free checklist. The trigger is GUIDE, the public reply is “Check your DMs!”, and the DM says “Here’s your checklist: [your link].” Replace the example link with a real, tested HTTPS URL. We’ll carry this same example all the way through.

2. Choose your Instagram connection

OpenReply offers two routes, and both still require you to host OpenReply yourself:

• Zernio: an optional paid provider and OpenReply sponsor. It handles the Instagram connection without your own Meta app. Check the linked provider guide for its current feature limits and pricing before choosing.
• Your own Meta app: configure Instagram Login, permissions, webhooks, and any required Meta review yourself. This avoids a Zernio subscription but takes more setup. Access and review requirements depend on who will connect and the permissions needed.

Both routes use the official Instagram API and remain subject to Meta’s rules, permissions, rate limits, and messaging windows. Your existing account connection does not automatically move over.

3. Put OpenReply on its own feet

Open Get OpenReply above, then use the project’s setup guide in Sources for the current, complete instructions. Fork the repository into your own GitHub account. A fork gives you your own copy to deploy.

1. In the documented hosting example, create PostgreSQL and Redis on Railway, then add a separate worker service from your fork. The worker must stay running; it sends the queued messages.
2. Deploy the web app from the same fork to Vercel. Its public HTTPS address receives events and opens your dashboard. A web deployment alone is not the complete system.
3. Configure the database and Redis connections, login email, public URL, and generated secrets in the appropriate hosting dashboards. The web app and worker must use the same database, Redis, and encryption key. Follow the setup guide for the exact variables and database migrations. Use the sign-in allowlist for your own instance.
4. Configure email delivery using the documented verified sender or SMTP route. Sign in to your deployed app using its magic link. Keep secrets in the hosting provider’s secret settings, never in a public repository or chat.
5. In OpenReply Settings, connect your professional Instagram account through your chosen provider. For Zernio, follow its provider guide; for direct Meta, follow the Meta app, webhook, tester, and publishing steps in the setup guide.
6. Check your deployed app’s /api/health endpoint. The project says a healthy setup reports the worker as healthy. If it does not, fix that before trying to launch a campaign.

Prefer a co-pilot? Open a local clone of the OpenReply repository in a coding assistant that can read files, and paste this prompt. The assistant can guide and inspect what its environment permits; you still make account and billing decisions and enter secrets in the proper dashboards.

Help me set up my own OpenReply instance for one Instagram comment-to-DM campaign. Read README.md, docs/setup.md, and docs/zernio.md in this repository first. My goal is [describe your automation]. My technical comfort level is [beginner/intermediate/advanced].

Explain the self-hosting requirements and estimated provider costs I should check. Ask me to choose either the optional paid Zernio connection or my own Meta app before asking for provider-specific setup. Guide me through the current documented steps one at a time: hosting the web app and always-on worker, PostgreSQL, Redis, sign-in email, migrations, provider connection, and a test using a second Instagram account.

Do not ask me to paste passwords, API keys, tokens, or other secrets into this chat. Tell me where to enter them in the provider's secret settings. Do not invent interface labels or claim a deployment or test succeeded without checking. Stop before making changes to my existing Manychat setup and help me prepare a rollback plan.

4. Rebuild the GUIDE campaign

In your deployed OpenReply dashboard, create a campaign for the Instagram account and the chosen post or reel. Set the comment trigger to GUIDE, add the public reply if you want one, and write the private message with your real checklist URL. Review the campaign options against your original Manychat flow; do not assume a button, follow-up, or integration works the same way.

Start with a test post or a quiet period. Avoid running two tools against the same trigger at the same time: overlapping automation can confuse the test and produce unwanted replies. Pause the matching Manychat automation for the test and keep your notes so you can restore it if needed.

5. Hand over the conversation, then test

For accounts previously connected to Manychat, OpenReply’s setup guide says to disconnect the old tool from the Instagram channel and check Meta Business Suite → Settings → Integrations → Conversation routing. Under the Instagram account’s Partner apps, manage your OpenReply app and enable Access all conversations and Take control of conversations, then save. The project notes that old tools can retain conversation control after cancellation; navigation can change, so use its migration section if labels differ. This handoff can interrupt the old automation, so do it during a planned test window.

Now the fun part: use a different Instagram account to comment GUIDE on the selected post. Check the public reply if enabled, open the DM, and tap any button or follow-up you configured. In OpenReply, check DM Logs for a SENT entry and open the destination link. Use a fresh eligible test comment/account if a previous test has already used the private reply opportunity.

Success looks like: the intended account receives the correct message, the link opens, any intended follow-up works, and the log records the send. If any of those fail, keep Manychat available while you troubleshoot.

6. Move the rest carefully

Repeat the inventory, rebuild, and test for each automation you actually need. Confirm where leads, consent, and follow-ups live before retiring the old flow. OpenReply’s inbox and campaign features should be checked against your own requirements; a working comment-to-DM test does not prove every Manychat feature has been replaced.

After your important flows work and you’ve checked billing and data retention, decide whether to cancel Manychat. Keep a safe record of your settings and check your hosting bills and worker health regularly. For rollback, pause the OpenReply campaign, reconnect Manychat using its current instructions, restore conversation routing as needed, and test a fresh comment before announcing the old flow is back.

If the DM ghosts you

• Nothing arrives: confirm the campaign is active, the post and keyword match, the test is from another account, and your provider connection is healthy. Check the worker health and DM Logs first.
• The first DM arrives but a button or follow-up fails: check conversation routing and old connected apps. The project identifies a “not the thread owner” error as a sign the old app still controls the conversation.
• You cannot sign in: verify your email sender or SMTP settings, the sign-in allowlist, and the deployed public URL.
• The worker cannot send: check its logs and shared database, Redis, and encryption-key settings against the web app without exposing their values. Consult the project’s setup guide for errors and retries.
• A feature is missing: check the chosen provider’s limitations and the project’s current documentation. Keep that flow in Manychat until you have a tested replacement.

Your finish line

You have a documented automation, a working OpenReply deployment, a successful fresh-account test, and a plan for the flows you haven’t moved yet. That’s a real switch—not just a shiny dashboard.