Bedolaga Bot and RemnaCore were compared on 11 August 2026 against their public
main branches and have not been re-checked since. The Bedolaga Cabinet rows were re-checked on 14 August 2026 against its published 1.61.0 feature list, which is more detailed than the README the first pass used and is why several rows below are new. Omniflow’s own column tracks this repository and was last updated on 14 August 2026. Feature sets move quickly. Verify against the upstream repository before making a decision, and open an issue if anything here is out of date or unfair.The projects
License differences are worth reading carefully. Omniflow is Apache-2.0, which permits closed modification and includes an explicit patent grant. Bedolaga Bot is MIT. Bedolaga Cabinet and RemnaCore are AGPL-3.0, which extends copyleft obligations to users served over a network.
How to read the tables
A dash means the capability is absent from the project’s own public documentation. Internal implementation details such as ledger design or idempotency handling may exist in code without appearing in a README, so treat a dash as “unverified”, not as a proven gap.
The 🔭 rows that came out of the 14 August 2026 reading of Bedolaga Cabinet 1.61.0 are collected as Post-1.0 product gaps in the roadmap. Each one there states what Omniflow has today and what the absence costs, which is the part a one-cell mark cannot carry.
Omniflow’s shipped surface today is v0.1–v0.10: the complete backend commerce model, a feature-complete Telegram bot, wallet top-up with deferred carts, add-ons, optional concurrent subscriptions, a production runtime with health probes, metrics, tracing, encrypted backups, and maintenance mode, and a complete operator panel — sign-in with two-factor, optional OIDC, granular RBAC, an append-only audit trail, and the day-to-day screens for customers, finance, catalogue, support, marketing, risk, and every installation setting, and a complete customer web panel — sign-in, subscriptions, checkout, wallet, the digital-goods shop, support, news, referrals, loyalty, and a customer’s own data export and deletion request. What remains is v1.0: release engineering rather than product surface.
Subscriptions and plans
Payments and money handling
Provider count is the clearest gap. Bedolaga bundles an order of magnitude more providers, and if a specific Russian acquirer is a hard requirement, that is a decisive advantage today. Omniflow adds providers on demand rather than for parity, so the relevant question is whether the provider you need is present, not how many exist.
Omniflow’s counterweight is the financial model. Every order and payment mutation carries an idempotency key, webhook intake is replay-safe with raw-event retention, and balances derive from an append-only double-entry ledger where corrections are compensating entries rather than updates. These invariants are documented and tested — see Financial invariants.
Marketing and growth
Omniflow enforces marketing consent, quiet hours, frequency caps, and delivery deduplication, and separates transactional from marketing classification. Those constraints were built before the campaign tooling that now uses them, which is the order that makes them hold: a suppression list added after the first broadcast is a suppression list somebody has already been missed by.
Advertising measurement is worth understanding rather than reading as a checkbox. Payment settles on the backend, sometimes a day after the click that started it, so an advertising platform learns nothing unless a click identifier is carried into the order and uploaded back as an offline conversion — which is why a counter script alone attributes nothing. Omniflow now carries it: the identifier is captured on the landing page, held first-party for thirty days, attached to the order, and exported when that order settles. Two limits are deliberate. A counter is a provider identifier validated against its shape and never a snippet, because a settings field accepting a script would run arbitrary code in every customer’s browser. And nothing is uploaded by this software — the export is a file the operator hands over — where Bedolaga calls the platform’s conversion API directly. It is the operator’s own analytics, never project telemetry, off by default, and rendered only for a visitor who agreed to it; see Advertising measurement and Telemetry for the line that separates the two.
Administration
This table’s Bedolaga column covers the bot and the cabinet together, because that is how the administrative surface is actually delivered: the bot administers from Telegram and the cabinet adds a web panel over the same Cabinet API.
Two of those marks are decisions rather than backlog. Node and squad control is ❌ for the same reason node health and routing are further down: Remnawave owns nodes, hosts, squads, and Xray state, and an operator reaches them in Remnawave’s own panel. Account-sharing detection is 🔭 with a condition attached — whether Omniflow may hold per-connection observations at all is a boundary question that has to be settled before it is a feature, not after.
The reporting rows were the substantive gap and are now closed. Omniflow’s dashboard still reports a fixed 30-day window on purpose, so that two visits compare;
/admin/reports is where the window moves, with breakdowns by kind of sale, plan version, and day, trial conversion, a settlement rate per provider beside the completion rate — because a customer abandoning a checkout and a gateway refusing a card are not the same event — and, since the attribution work, what each advertising channel brought in over the same period.
Omniflow deliberately keeps administration out of Telegram. As of v0.5 Telegram carries operator notifications and backup/restore actions, and nothing else: those two are exempt because an incident is exactly when a browser and a panel may be unavailable. Every other control lives in the web panel, where RBAC, audit, and confirmation dialogs can be enforced consistently.
That is a real trade-off. Bedolaga operators are productive on day one with no reverse proxy, TLS, or browser. Omniflow needs one — but as of v0.8 the browser is enough: plans, providers, limits, the Remnawave connection, the bot, backups, and session policy are all configured from the panel, with no environment file or SQL involved.
Customer web
One row there deserves its reasoning rather than its mark. E-mail and password sign-in is a decision rather than a backlog item, and it is now a written one: Telegram, OIDC, and a bot-delivered link are the ways into an Omniflow account, and a password is a credential to phish, reset, and breach. Decision 0007 records what that costs an installation and the condition under which it would be added, so it is no longer an absence that reads as an oversight.
Transactional wording is the same capability over a different channel, which is why the marks differ in their parentheses. Omniflow has no e-mail transport at all: every message it sends on its own initiative goes to Telegram, so the nine notices an operator can reword — expiry, traffic, renewal, grace, recovery, the two fulfillment messages, and the two dunning ones — are Telegram messages, with a variable reference, a preview against sample values, and a test send into the operator group. See Message wording.
The client application catalogue was a trade-off rather than an omission, and the trade-off is now resolved without giving up what made it one. The catalogue is stored and edited from the panel, and both the bot and the web panel still read that single source — so a customer cannot be told to install one client in the chat and a different one in the browser, and adding a client no longer needs a release. A deep link is validated against a scheme allowlist before it is stored, because a client entry ends up as a link a customer is told to trust. See Connection catalogue and Connecting a device.
Architecture and operations
RemnaCore is the closest architectural relative — the same Go, PostgreSQL 18, Valkey 9, and React 19 foundation. The divergence is what each project treats as mandatory. RemnaCore requires NATS JetStream and ships a WASM plugin runtime with Kubernetes and Pulumi deployment. Omniflow lists a broker, a plugin runtime, and Kubernetes as post-1.0 candidates precisely so that a single-server operator never has to run them.
RemnaCore also reaches into node health monitoring, smart routing, and speed tests. Omniflow does not, and will not: Remnawave is authoritative for nodes, hosts, squads, and Xray state, and Omniflow uses only its supported API. See Data ownership.
Choosing between them
Choose Bedolaga Bot if you need the widest payment-provider coverage today, want to administer everything from Telegram without deploying a web panel, or need growth mechanics such as contests, custom landing pages, and referral payouts that Omniflow has deferred past 1.0. If you sell through paid advertising, note that both now carry a click identifier into the order; the difference is what happens next, and it is a real choice. Bedolaga calls the platform’s conversion API for you. Omniflow gives you a file to upload, because it makes no request to an advertising network on your behalf. Choose RemnaCore if you need white-label reseller capability with commission tracking, or are already running Kubernetes and want a plugin runtime and event bus as first-class infrastructure. Note its stated development status before committing production traffic. Choose Omniflow if financial correctness is your priority — idempotent orders and webhooks, an append-only double-entry ledger, wallet credit that cannot be applied twice, and fulfillment that never loses a successful payment when Remnawave is unavailable — and if you want administration behind RBAC and an audit trail rather than in a chat window. Omniflow is also the option that treats the Remnawave boundary as inviolable and keeps a single-server install free of a broker, plugin runtime, or orchestrator. Since v0.5 it is additionally the option that takes production operation seriously on a single server: readiness probes that classify each dependency without leaking it, Prometheus metrics whose labels can never carry a customer identifier, encrypted backups verified by read-back before they are trusted, and a maintenance mode that pauses new purchases without disturbing money already taken.Both panels are complete as of v0.10: the operator panel since v0.8, and the customer panel — sign-in, subscriptions, checkout, wallet, shop, support, referrals, and personal data — since v0.10. Customers can self-serve in a browser or in Telegram, against the same records: a cart started in a chat is the cart the browser shows, and a support reply read on the web stops being unread in Telegram.The v1.0 gate is release engineering rather than product surface, and one item in it remains: an independent security review of authentication, authorization, payments, and secret handling. That one names an external reviewer engagement rather than a change to this repository. The compatibility matrix, signed artifacts, and the reliability and documentation gates are done.Complete is not the same as at parity. Thirteen of the gaps that reading produced have since been closed — branding and presentation, reporting and growth measurement, content and communication, and identity and lifecycle — which is why most of the rows above now read ✅ on both sides. The 🔭 rows that remain are capabilities Bedolaga Cabinet has and Omniflow does not, and none of them is scheduled. Post-1.0 product gaps records every one of them, closed or open, with what exists today and what the absence cost.