Infrastructure and launch

Gateway servers are the operator-hosted data-plane footprint. Clusters organize them by operational region or failure domain. Packages may use all eligible gateways or restrict access to selected servers.

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.

Create clusters around a meaningful operational boundary such as Europe, North America, a Kubernetes region, or a dedicated enterprise footprint. A cluster name should remain stable in dashboards and incident reports even when individual servers are replaced.

Servers

Open full size

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

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

Register a gateway safely

1. Provision the host or Kubernetes capacity with expected CPU, memory, file-descriptor, connection-tracking, and network-egress limits.
2. Restrict administrative access, patch the host, synchronize time, and configure logs and metrics before customer traffic.
3. Register the server in the intended cluster with its public address and deployment credentials.
4. Expose the assigned HTTP, SOCKS5, or auto-detect ports through firewall and load-balancer rules. Do not assume example ports are universal.
5. Verify online status, upload/download and TCP/UDP metrics, DNS, and a direct synthetic request.
6. Add the server to a private test package or partial load-balancer pool, then compare latency, errors, and throughput.
7. Expand production traffic gradually and keep the rollback or drain procedure documented.

DNS or a load balancer 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.

Deployment settings

Review every global setting before launch:

Area	Verify
Domains and TLS	Admin/customer domain, public API host, proxy host, certificates, redirects, and DNS ownership
Branding	Name, logo, colors, support links, legal links, and sender identity
Gateway	Advertised hosts/ports, protocol exposure, server/cluster registration, and health visibility
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

• ☐ Proxy 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.
• ☐ 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.