> ## Documentation Index
> Fetch the complete documentation index at: https://omniflow-vpn.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Comparison with alternatives

> How Omniflow differs from Bedolaga Bot, Bedolaga Cabinet, and RemnaCore.

Omniflow is not the only open-source way to sell Remnawave subscriptions. This page compares it with the projects operators most often evaluate alongside it, using each project's own public documentation.

> [!NOTE]
>
> 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

| Project | What it is | License | Stack |
| - | - | - | - |
| **Omniflow** | Telegram-first commerce and support platform for Remnawave, with complete operator and customer web panels | Apache-2.0 | Go 1.26, PostgreSQL 18, Valkey 9, River, Next.js 16 / React 19 |
| **[Bedolaga Bot](https://github.com/BEDOLAGA-DEV/remnawave-bedolaga-telegram-bot)** | Mature Telegram sales bot for Remnawave, administered from inside Telegram | MIT | Python 3.13, aiogram 3.x, FastAPI, PostgreSQL + SQLAlchemy, Redis |
| **[Bedolaga Cabinet](https://github.com/BEDOLAGA-DEV/bedolaga-cabinet)** | Customer web cabinet for Bedolaga Bot; requires the bot's Cabinet API | AGPL-3.0 | React, Vite, TypeScript, Tailwind, Nginx |
| **[RemnaCore](https://github.com/BEDOLAGA-DEV/RemnaCore)** | Modular DDD platform wrapping Remnawave, with reseller and plugin support; marked in development | AGPL-3.0 | Go 1.26, PostgreSQL 18, Valkey 9, NATS JetStream, Extism/wazero WASM, React 19 |

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

| Mark | Meaning |
| - | - |
| ✅ | Available today |
| 🚧 vX.X | Planned; see the [roadmap](https://github.com/kewldan/omniflow/blob/main/ROADMAP.md) |
| 🔭 | Post-1.0 candidate, not scheduled |
| ❌ | Deliberately not planned |
| — | Not documented in that project's public README |

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](https://github.com/kewldan/omniflow/blob/main/ROADMAP.md) 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

| Capability | Omniflow | Bedolaga | RemnaCore |
| - | - | - | - |
| Flexible periods and durations | ✅ | ✅ | ✅ |
| Versioned plan pricing so historical orders never change | ✅ | — | ✅ |
| Traffic modes: unlimited, fixed, packages | ✅ | ✅ | ✅ |
| Device limits or disabled limits | ✅ | ✅ | ✅ |
| Trial, including paid trial with conversion | ✅ | ✅ | ✅ |
| Automatic squad assignment | ✅ | ✅ | ✅ |
| Customer subscription configurator with per-plan squad sets | ✅ | ✅ | ✅ |
| Mid-period add-on purchase of traffic, devices, squads | ✅ | ✅ | ✅ |
| Smart cart that survives insufficient balance | ✅ | ✅ | — |
| Auto-renew before expiry | ✅ | ✅ | ✅ |
| One customer holding several concurrent subscriptions | ✅ (opt-in) | — | ✅ |
| Pausing a subscription with the remaining days preserved | ✅ | ✅ | — |

## Payments and money handling

| Capability | Omniflow | Bedolaga | RemnaCore |
| - | - | - | - |
| Bundled payment providers | 4: Telegram Stars, CryptoBot, YooKassa, manual | 24+ | Stripe plugin only |
| Provider-neutral adapter contract | ✅ | ✅ | ✅ (WASM plugins) |
| Wallet top-up by any enabled provider | ✅ | ✅ | — |
| Automatic purchase after top-up | ✅ | ✅ | — |
| Recurring payments with saved cards | ✅ | ✅ | ✅ |
| Per-merchant recurring capability override | ✅ | — | — |
| Payment status polling and reconciliation | ✅ | ✅ | ✅ |
| Append-only double-entry customer ledger | ✅ | — | ✅ |
| Idempotency keys on every order and payment mutation | ✅ | — | ✅ |
| Replay-safe webhook intake with raw-event retention | ✅ | — | ✅ |
| Full and partial refunds without rewriting history | ✅ | ✅ | ✅ |
| Fiscalization metadata boundary | ✅ | ✅ | — |
| Self-employed fiscalization adapter | 🔭 | ✅ | — |
| Guest checkout without authorization | 🔭 | ✅ | — |
| Presentation currency with exchange rates | 🔭 | ✅ | — |

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](https://omniflow-vpn.mintlify.site/commerce/financial-invariants.md).

## Marketing and growth

| Capability | Omniflow | Bedolaga | RemnaCore |
| - | - | - | - |
| Promo codes | ✅ | ✅ | ✅ |
| Promo reward types: amount, percentage, days, trial | ✅ | ✅ | — |
| Personal targeted offers | ✅ | ✅ | — |
| Referral program with immutable attribution | ✅ | ✅ | ✅ |
| Referral balance withdrawal | 🔭 | ✅ | — |
| Partner / affiliate program | 🔭 | ✅ | ✅ (reseller) |
| Multi-level referral network reporting | 🔭 | ✅ | ✅ |
| Gift subscriptions | ✅ | ✅ | — |
| Mandatory channel subscription with auto-disable | ✅ | ✅ | — |
| Segment broadcasts and campaign tracking | ✅ | ✅ | — |
| Consent, quiet hours, frequency caps, suppression | ✅ | — | — |
| Custom landing pages with analytics | ❌ | ✅ | — |
| Contests and daily games | 🔭 | ✅ | — |
| Wholesale code batches for resellers, revocable in bulk | ✅ | ✅ | — |
| Advertising counters, offline conversions, and site-verification tags | ✅ | ✅ | — |

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](https://omniflow-vpn.mintlify.site/operations/advertising-measurement.md) and [Telemetry](https://omniflow-vpn.mintlify.site/operations/telemetry.md) 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.

| Capability | Omniflow | Bedolaga (bot + cabinet) | RemnaCore |
| - | - | - | - |
| Administration from inside Telegram | ❌ | ✅ | — |
| Operator notifications to Telegram topics, auto-created | ✅ | ✅ | — |
| Automatic database backups with restore from the bot | ✅ | ✅ | — |
| Maintenance mode with dependency auto-detection | ✅ | ✅ | — |
| Traffic and behavior anomaly monitoring | ✅ | ✅ | ✅ |
| Web admin panel | ✅ | ✅ (cabinet) | ✅ |
| RBAC with granular permissions | ✅ | ✅ | ✅ |
| Append-only audit events with actor, reason, and before/after | ✅ | — | — |
| TOTP two-factor authentication and session management | ✅ | — | ✅ |
| External blocklist ingestion | ✅ | ✅ | — |
| Bulk import/export with preview and resumability | ✅ | ✅ | — |
| Support desk with queues, assignment, SLA, and internal notes | ✅ | ✅ | — |
| Installation settings editable without SQL or shell access | ✅ | ✅ | — |
| AI-assisted support, scam analysis, admin copilot | ✅ (optional, off by default) | — | — |
| MCP client and first-party MCP server | ✅ (optional, off by default) | — | — |
| Sales reporting over a period the operator chooses | ✅ | ✅ | — |
| Payment health: settlement rate by provider | ✅ | ✅ | — |
| Traffic reporting per node, with export | ✅ | ✅ | — |
| Account-sharing detection by distinct address | 🔭 | ✅ | — |
| Operator-published information pages: FAQ, terms, offer, privacy | ✅ | ✅ | — |
| Transactional message wording an operator can override | ✅ (Telegram) | ✅ (e-mail) | — |
| White-label theming: palette, logo, permitted themes | ✅ | ✅ | — |
| Command palette and live updates without a refresh | 🔭 | ✅ | — |
| Remnawave node and squad control from the panel | ❌ | ✅ | ✅ |

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

| Capability | Omniflow | Bedolaga Cabinet | RemnaCore |
| - | - | - | - |
| Customer web panel | ✅ | ✅ | ✅ |
| Telegram sign-in | ✅ | ✅ | ✅ |
| Sign-in through any OIDC provider (Google, Yandex, Discord, …) | ✅ | ✅ | ✅ (email + OAuth) |
| Magic-link fallback | ✅ | — | — |
| Shared component system with the admin panel | ✅ | — | ✅ |
| Checkout parity with the bot | ✅ | ✅ | ✅ |
| WCAG 2.2 AA review of core journeys | ✅ | — | — |
| E-mail and password sign-in | ❌ (decided) | ✅ | ✅ |
| Merging two existing accounts, with a preview | ✅ | ✅ | — |
| Operator-editable client application catalogue | ✅ | ✅ | — |
| Delivered-notification history and a test notification | ✅ | ✅ | — |
| Interface languages | 2: ru, en | 4: ru, en, zh, fa | — |

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](https://omniflow-vpn.mintlify.site/architecture/decision-0007-no-customer-password.md) 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](https://omniflow-vpn.mintlify.site/operations/message-wording.md).

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](https://omniflow-vpn.mintlify.site/operations/connection-catalogue.md) and [Connecting a device](https://omniflow-vpn.mintlify.site/customer/connection.md).

## Architecture and operations

| Capability | Omniflow | Bedolaga | RemnaCore |
| - | - | - | - |
| Language | Go | Python | Go |
| Durable job engine | River, transactional | — | NATS JetStream + Watermill |
| Transactional outbox for domain events | ✅ | — | ✅ (45 events) |
| Message broker required | ❌ | ❌ | ✅ |
| Plugin runtime | 🔭 | — | ✅ (WASM) |
| Kubernetes, Helm, Pulumi | 🔭 | — | ✅ |
| Single-server Docker Compose deployment | ✅ | ✅ | ✅ |
| OpenTelemetry traces and Prometheus metrics | ✅ | — | ✅ |
| Anonymous telemetry with complete opt-out | ✅ | — | — |
| Node health, smart routing, speed test | ❌ | — | ✅ |

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](https://omniflow-vpn.mintlify.site/architecture/data-ownership.md).

## 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.

> [!NOTE]
>
> 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](https://github.com/kewldan/omniflow/blob/main/ROADMAP.md) records every one of them, closed or open, with what exists today and what the absence cost.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.