Connect devices, request protected tunnels and proxy access, check route quality, manage storage requests, and contact support without exposing technical admin panels.
Run the tests one by one: the dostup. measurement node, Cloudflare edge, and OpenSpeedTest. Sequential runs avoid making the providers compete for the same bandwidth.
Choose a measurement route
Only one test should run at a time. The dostup. route selects its configured node automatically.
Cloudflare edge
A browser-native baseline for download, upload, idle latency, and jitter. Packet-loss testing is intentionally disabled in this first slice.
— Mbps
— Mbps
— ms
— ms
Traffic goes directly to Cloudflare endpoints. Final-result logging by the library is disabled; Cloudflare still receives ordinary network request metadata.
Cloudflare edge baseline
The test sends measurement traffic directly from your browser to Cloudflare. dostup. displays the result locally and does not treat it as a service-speed guarantee.
Cloudflare SpeedtestCloudflare metrics are captured automatically. Cross-origin iframe results remain inside their provider widgets until a self-hosted result bridge is connected.
dostup.
Not connectedRun this route to add it to the comparison.
Cloudflare
PendingRun this route to add it to the comparison.
OpenSpeedTest
PendingRun this route to add it to the comparison.
Service catalog
Every service shows a clear state: pilot, coming soon, available, or unavailable. Pilot requests go to cabinet support until automated issuance is connected.
Protected tunnels and proxy access help teams and individual clients connect safely without seeing service keys or raw panel controls.
Personal or team tunnel after manual client and route review.
The client receives only DOSTUP access and instructions; 3x-ui remains a private adapter.
Proxy subscription for work tasks without exposing service keys in the cabinet.
Subscriptions must be issued by the DOSTUP API, not by direct browser calls to a technical panel.
Regional route selection after node, failover, and traffic checks.
Regional policy must belong to DOSTUP access, not to a single node panel.
Reverse proxy, Ingress, regional routing, and future CDN services are separated by DNS, TLS, origin, and cache rules so business traffic can be managed predictably.
Protected inbound endpoint for a customer service with manual domain, TLS, and origin review.
DNS, TLS, and origin policy remain a separate DOSTUP resource contract.
Future static file delivery through edge after catalog, origin rules, and cache policy launch.
CDN state is separate from tunnel access rights and payments.
DOSTUP plans cloud storage, customer-local vaults, Phosphor device backup upload, and Apple Workspace transfer flows. The page shows them as planned until the server-side service is proven.
One future Storage API for DOSTUP Cloud and a customer-local vault.
Quotas, files, usage, and restore state must come only from the live Storage API.
Local device backup intake before upload into selected cloud or local storage.
Phosphor acquires the backup locally, then sends it through the Storage API to DOSTUP Cloud or a local vault.
Future remote environment for transferring customer data into a selected vault.
The workspace is temporary; durable storage lives in the selected cloud or local vault.
Self-hosted vault after installer, update, and backup runbooks exist.
The local vault uses the Storage API, but node lifecycle and disk durability remain a separate responsibility boundary.
Initial IT consulting
Choose a direction. We review up to five related questions and prepare a written path for the next steps.
Initial consulting on infrastructure and cloud solutions.
10 000 ₽
one-time payment
Темы направления
Additional work is paid separately.
Initial consulting on development and process automation.
10 000 ₽
one-time payment
Темы направления
Additional work is paid separately.
Initial consulting on security and access management.
10 000 ₽
one-time payment
Темы направления
Additional work is paid separately.
Эти работы являются отдельными платными услугами с собственными описанием, сроком и ценой.
How it is built
DOSTUP separates the client cabinet, support, service catalog, identity, and audit trail from the private technical panels that issue real resources.
The cabinet and future Telegram bot should call DOSTUP APIs first. Provider credentials stay on the server side.
3x-ui, routing, CDN, and storage adapters can be replaced behind one customer-facing service contract.
Regional routing becomes available only after node inventory, failover, and traffic checks are verified by live APIs.
Cloud and local vault targets share one planned Storage API, while quotas, usage, restore state, and availability must come from server responses.
Storage platform
DOSTUP is designed to support hosted storage, customer-local vaults, iPhone/iPad backup intake through Phosphor, and Apple Workspace transfers without claiming live storage before launch.
Manage storageStorage stays coming soon until upload sessions, workers, restore checks, usage accounting, and live availability are connected.
Hosted storage target for business files, personal archives, and future device backup flows after server-side launch.
Customer-owned local vault target for clients who want storage under their own disk and operating responsibility.
Local iPhone/iPad backup intake before upload into the selected DOSTUP Cloud or local vault target.
Future remote workspace for transfer sessions. Durable storage remains in the selected cloud or local vault, not in the temporary workspace.
Trust boundaries
DOSTUP keeps account identity, service adapters, access issuance, encryption modes, and storage restore checks separate so each promise can be verified.
Users enter protected routes through Perfect ID. Public pages can send a user to the cabinet, but they do not bypass authentication.
The browser receives only DOSTUP service states and support routes. Provider credentials and panel APIs remain private.
Client-side, service-side, and local-vault encryption are different service modes. Stronger claims require matching implementation evidence.
Pilot access goes through support until automatic issuance, duplicate-safe handling, traffic reconciliation, and revocation are connected.
Storage should be accepted after successful restore checks, not after a marketing label.
Questions
The answers follow catalog states and do not promise automation before it is connected.
The /account route enters the existing Perfect ID protected flow. The public page does not create service rights or issue a resource by itself.
Not from this landing. Pilot and coming-soon services route to account support until DOSTUP API issuance, traffic checks, and revocation are connected.
They are intended to share one Storage API. DOSTUP Cloud is the hosted target; local Storage is a customer-side vault. Quotas and restore state must come from live server data.
No. Apple Workspace is a future temporary environment for remote transfer sessions. The selected cloud or local vault is the durable target.
No. The page names security boundaries and service states only. Stronger claims require the matching implementation and verification evidence.
Use /account/support for protected cabinet support, support@dostup.cloud for email, or Telegram as a fast backup channel.
Support
Use cabinet support, email, or Telegram. Product readiness is confirmed by the DOSTUP catalog and support team.
Protected support route for service questions, pilot access, storage readiness, and future request history.
Send non-secret support requests to support@dostup.cloud when cabinet support is not enough.
Primary contact: support@dostup.cloud
+7 999 562-06-65
Telegram remains a fast backup channel for coordination and initial questions.
Optional for coordination; not a purchase or access-provisioning channel.
.svg){kind=small}