Infrastructure and launch

Every plan includes two fully managed gateway VPS instances for new subscriptions and renewals. The operator chooses any combination of EU, US, or Asia and provides expected-load requirements. Each VPS has a network port up to 1 Gbps. ProxyRequest provisions, hardens, configures, updates, monitors, and replaces the servers; clusters organize them by operational region or failure domain. Packages may use all eligible gateways or restrict access to selected servers.

What the included port speed means

Up to 1 Gbps describes the network port on each VPS, not guaranteed continuous throughput or a public traffic-volume allowance. Validate the intended load during onboarding. Additional servers or higher capacity are quoted separately.

Clusters

Open full size

Clusters group gateways for capacity, regional operations, and failure-domain visibility while retaining the current API fields.

1. 1Cluster controls start creation and scope searches.
2. 2The table shows name, region, status, upload/download, TCP/UDP, and available actions.

ProxyRequest creates the standard managed clusters around the selected regions and failure domains. Use the cluster view to confirm region, availability, and capacity while keeping package assignments and incident reports tied to stable cluster names even when an individual VPS is replaced.

Servers

Open full size

Server views connect customer traffic to the exact gateway, cluster, network rates, version, and status.

1. 1Server controls find and inspect a managed gateway during validation or an incident.
2. 2The table shows IP, cluster, status, upload/download, TCP/UDP, version, and actions.

Verify the managed gateway deployment

1. Choose any two placements across EU, US, and Asia, including both VPS instances in one region, and share the expected protocols and load with ProxyRequest.
2. ProxyRequest provisions and hardens both hosts, registers them in the intended clusters, and configures DNS, gateway ports, monitoring, and lifecycle operations.
3. Confirm that both servers appear online with the expected regions, public addresses, software versions, and HTTP, SOCKS5, or auto-detect ports.
4. Resolve every assigned gateway hostname and test each advertised port from an external network. Do not assume example ports are universal.
5. Verify upload/download and TCP/UDP metrics plus a direct synthetic request through each gateway.
6. Add the gateways to a private test package or partial traffic scope, then compare latency, errors, and throughput.
7. Expand production traffic gradually and keep the ProxyRequest escalation and drain procedure documented.

ProxyRequest-managed DNS or load balancing distributes new client connections across gateway servers. Provider routing then selects an upstream inside the authenticated package. Application retry remains a third, client-owned layer; do not confuse these three controls.

Customer-provided infrastructure (advanced)

Customer-provided container hosts or Kubernetes are optional and used only when an advanced deployment requires a dedicated footprint, an existing network, or custom capacity. They are not required for the standard plan. Unless the custom agreement says otherwise, the customer owns host provisioning, operating-system access, patching, firewall and load-balancer rules, capacity, and replacement; ProxyRequest supplies the gateway software and managed platform configuration.

For this deployment model, provision and harden the capacity before registering it, expose only the assigned ports, verify DNS and health from an external network, start with a private package, and expand traffic gradually. Agree the monitoring, incident, and rollback owners before launch.

Deployment settings

Review every global setting before launch:

Area	Verify
Domains and TLS	Approved admin/customer domain, public API host, proxy host, certificates, redirects, and verified DNS resolution
Branding	Name, logo, colors, support links, legal links, and sender identity
Gateway	Selected regions, advertised hosts/ports, protocol exposure, managed server/cluster registration, health visibility, and escalation path
Commerce	Currency, payment providers, invoice behavior, package prices, coupon/reward policy, and tax/legal ownership
Communication	Email delivery, customer announcements, operational alerts, and support escalation
Security	Operator roles, 2FA, active sessions, API-key source networks, webhook secrets, and audit retention
Data governance	Analytics retention, access to destinations/IPs, export policy, and deletion obligations

Settings may differ by deployment and contract. Record the accepted value and owner instead of treating undocumented defaults as a service guarantee.

Launch checklist

Supply and routing

• ☐ Every production provider passes protocol, location, session, and usage tests.
• ☐ Provider credentials have a rotation owner and non-emergency rollback procedure.
• ☐ Pool weights and private access match the commercial design.
• ☐ Each package has at least one healthy route for every advertised capability.
• ☐ A deliberately unavailable geography returns an error without fallback.
• ☐ Provider loss and restoration have been exercised with synthetic traffic.

Products and customers

• ☐ Package names, stable aliases, visibility, expiry, pricing tiers, unit conversion, limits, and targeting are reviewed.
• ☐ An internal customer can purchase or receive an order and generate working credentials.
• ☐ Password reset, IP allowlist, blocked domain, connection limit, and deprovisioning are tested.
• ☐ Root ledger, child limit, ledger transition, run-out, and final-batch overdraft behavior are understood by support and billing.
• ☐ Invoice payment is confirmed server-side before service activation.

Infrastructure and observability

• ☐ Both managed VPS instances appear in the selected regions and report healthy.
• ☐ ProxyRequest-managed DNS/load balancing and every gateway port are tested from an external network.
• ☐ Capacity alerts cover traffic, connections, errors, latency, server availability, and provider health, with a documented ProxyRequest escalation path.
• ☐ Request IDs and authenticated user IDs appear in application logs with exception detail and traceback for unexpected failures.
• ☐ Analytics, popular domains, journals, proxy logs, connections, transactions, resource charts, alerts, incident history, and audit access are assigned to owners.
• ☐ Sensitive analytics and logs have retention, redaction, and export controls.

Automation and recovery

• ☐ Production and staging use separate source-restricted API keys.
• ☐ Webhook signatures are verified on raw bytes; batches, retries, duplicates, and null child balances are tested.
• ☐ Ambiguous writes trigger state inspection rather than blind repetition.
• ☐ Closed-window analytics reconciliation runs independently of webhooks.
• ☐ Local customer/product/entitlement mappings and operator configuration exports have a recovery procedure.

First-week operating rhythm

Daily

Review provider/server health, errors, top domains, ledger risk, failed payments, webhook delivery, and customer support patterns.

After each change

Send synthetic traffic, inspect the audit log, compare a closed analytics window, and retain the rollback value.

Weekly

Review provider mix, capacity headroom, committed versus physical data, privileged access, stale keys, incidents, and customer-visible promises.

Launch privately first

Keep the first production package private, onboard one internal or friendly customer, and observe a complete purchase-to-depletion lifecycle before a broad catalog launch.

Return to the admin panel guide for the complete configuration sequence, or use routing and failure behavior for the customer-visible gateway contract.