Key decisions before you start: VPS, payments, devices, migration

With `Single Node VPN`, the service and the infrastructure are billed separately. This is not a hidden downside but a direct result of the node belonging to the user rather than to a shared pool.

• The subscription covers the service layer, while the VPS stays under the user's control.
• This makes it easier to understand what exactly you are paying for and what can be changed independently.
• If needed, you can switch VPS providers without abandoning the product model itself.

The payment flow is built around a Web3-first model from the start: TonConnect plus the website and cabinet payment flow, while the Telegram bot handles identity, access management, and app delivery.

• Payment starts on the website through TonConnect instead of a separate banking checkout.
• The flow supports `USDT` and `TON` through TonConnect-compatible payment steps.
• This matches the current product model of the project.

The whole point of the model is that one private infrastructure can support your normal set of personal devices instead of just a single phone or laptop.

• The approach is built for a cross-platform flow: desktop and mobile together.
• The user gets one main access path instead of several unrelated services.
• What matters is keeping client delivery and configuration clear on every device.

In a private model, moving to another server is a normal lifecycle event. The important part is having a clear migration path before it turns into an urgent problem.

• Changing providers or regions should not break the core product idea.
• The user benefits from the infrastructure formally belonging to them.
• The less manual work a migration requires, the more valuable a managed flow becomes.