# SilentVPS > SilentVPS is a private VPS hosting project with pseudonymous accounts, optional email and a cryptocurrency-payment catalogue. This public website does not establish production server availability. ## Table of contents - [Private VPS hosting and crypto payments](<#page-e3b0c44298fc1c14>) - [Private VPS pricing: monthly and annual plans](<#page-b092ce626c9004b6>) - [Private VPS features: root, KVM, NVMe and crypto](<#page-5f0be7fce7b8ae7b>) - [Private VPS or conventional hosting: compare](<#page-3af74f08dc7b15a9>) - [About SilentVPS: a privacy-focused VPS project](<#page-2212b84a2a6ffe23>) - [Contact SilentVPS: support channels and questions](<#page-eb5639ef0321321f>) - [Private VPS, crypto payments and self-hosting guides](<#page-2e7cc76cb727cb3b>) - [Anonymous VPS: accounts, payments and privacy](<#page-bd471590591748cc>) - [No-KYC VPS hosting](<#page-9ff3a67e3eb4f7fc>) - [No-logs VPS: records, retention and limits](<#page-28deadb256c926a8>) - [VPS for a Tor relay or bridge: requirements](<#page-418b884d778bcaef>) - [Onion hosting: run a private Tor service](<#page-ed198ae70a10ff2e>) - [WireGuard VPS: private VPN planning and logs](<#page-a47002e640b5ce13>) - [Private seedbox VPS: storage and transfer planning](<#page-322afa44aabdbdd3>) - [Private self-hosting VPS: mail, files and vaults](<#page-39d6dc79ae5f787d>) - [Offshore VPS locations and crypto payments](<#page-eab6b24532e7e93b>) - [Anonymous VPS with BTC, USDT and more](<#page-788102c11d94b053>) - [Compare anonymous VPS providers: a practical checklist](<#page-5f35ace8d722c8fd>) - [Njalla VPS alternative: compare requirements](<#page-2cb23774aa408080>) - [Hong Kong VPS with crypto: region and routing](<#page-0105e99e62d4b6d0>) - [Affordable anonymous VPS: choose the right resources](<#page-4153e548caa8d1a7>) - [Private VPS resources: prices, privacy and crypto checkout](<#page-e440d5fe9fe00432>) - [SilentVPS facts: plans, payments and service status](<#page-680870a812d4e016>) - [VPS monthly or annual billing: compare the full cost](<#page-58d4c94dfd3d77aa>) - [Private VPS accounts, payments and data practices](<#page-a6504e81d64c81b5>) - [VPS sizing calculator: RAM, CPU, storage and bandwidth](<#page-2ba2d5acfcbbe397>) - [VPS crypto payment networks: TRX, USDT, BTC and more](<#page-a17ddd924311db91>) - [KVM VPS and root access: control, isolation and limits](<#page-4b682a546e8b12cc>) - [VPS migration checklist: backups, DNS, TLS and rollback](<#page-9fd95ba637fce159>) - [Pay for a VPS with crypto: an invoice checklist](<#page-b151b80ce6713414>) - [Buy a VPS privately: from browsing to first login](<#page-62e02ee64f53f2bc>) - [Why SilentVPS uses crypto payments](<#page-b707639897da98eb>) - [Protect your crypto wallet before paying for hosting](<#page-f40c8cb8f1863109>) - [What is no-logs hosting? Audit the actual records](<#page-f5b046c6888df37a>) - [Manage a VPS over Tor: SSH and onion access](<#page-6b98ff9232ef309a>) - [Operate a private VPS: credentials, updates, backups](<#page-556ca98fa38f746c>) - [Run a Tor relay on a VPS: planning and maintenance](<#page-8e0e322815883e72>) - [Self-host WireGuard: keys, firewall and retention](<#page-01721efd83402104>) - [Self-hosted email VPS: DNS and deliverability](<#page-84bb65c5dba79ea0>) - [Self-host a password vault: access and backups](<#page-ce35c85041cdb924>) - [SilentVPS crypto checkout: network, invoice and status](<#page-a3515e8197158800>) ## Private VPS hosting and crypto payments [Private VPS hosting and crypto payments]() Compare SilentVPS plans, monthly and annual billing, optional-email accounts and crypto payment networks. Read the catalogue facts and practical self-hosting guides. SilentVPS has four target VPS configurations with monthly and annual billing, an account flow with optional email, and eight cryptocurrency payment methods configured on the website. Use the catalogue facts to compare resources and networks. Production infrastructure, automatic transaction detection and server provisioning still require connection and validation. ### Your server. Your rules. Four essentials. Less to share, more to build. #### A private account Username and password. Email optional. #### Crypto, your way Eight payment methods. Choose your cryptocurrency and network. #### Full root access Linux, KVM, NVMe. Your SSH key, your software. #### Know what you share The details on stored account, billing and technical data. ### Three steps. One private space. 1. **Configure** — Choose your plan, Linux image and region. 2. **Pay in crypto** — Check the quote and network, then send the exact amount. 3. **Track your order** — Follow payment and service activation from your dashboard. ### The configured VPS catalogue Amounts are in USD. The annual column is the full twelve-month payment; the monthly equivalent is shown only for comparison. Resources describe the catalogue, not verified live server capacity. | Plan | vCPU | RAM (GB) | NVMe (GB) | Transfer (TB) | Monthly payment (USD) | Annual total (USD) | Monthly equivalent (USD) | | --- | --- | --- | --- | --- | --- | --- | --- | | Veil | 1 | 2 | 30 | 2 | 13.00 | 109.20 | 9.10 | | Shade | 2 | 4 | 80 | 4 | 33.00 | 277.20 | 23.10 | | Eclipse | 4 | 8 | 160 | 8 | 63.00 | 529.20 | 44.10 | | Obsidian | 8 | 16 | 320 | 16 | 118.00 | 991.20 | 82.60 | The network is part of your choice. USDT on Tron and USDT on Ethereum are different payment methods. Exact crypto amounts and destination instructions belong to the private invoice, not this public catalogue. | Payment methods | Asset | Network | Token standard | | --- | --- | --- | --- | | BTC | BTC | Bitcoin mainnet | Native asset | | ETH | ETH | Ethereum mainnet | Native asset | | SOL | SOL | Solana mainnet | Native asset | | TRX | TRX | Tron mainnet | Native asset | | USDT | USDT | Tron mainnet | TRC-20 | | USDC | USDC | Ethereum mainnet | ERC-20 | | USDT-ERC20 | USDT | Ethereum mainnet | ERC-20 | | LTC | LTC | Litecoin mainnet | Native asset | ### Questions, answered #### Do I need to provide an ID? A username and password are enough. Email is optional; no ID upload is requested. #### Which payments are supported? BTC, ETH, SOL, LTC, TRX (Tron), USDT (Tron or Ethereum) and USDC (Ethereum). Choose the matching network at checkout. #### Do I need an account to order? Yes. Your account keeps your configurations and billing history. A private reference also lets you track an individual order. #### What data is retained? Account, billing and service data, plus technical access logs. Find the details in the privacy policy. ### Find the guide for your next decision - [Compare monthly and annual VPS prices]() - [Read the current SilentVPS facts]() - [Understand the private account model]() - [Follow the crypto payment workflow]() ## Private VPS pricing: monthly and annual plans [Private VPS pricing: monthly and annual plans]() Compare four private VPS plans from $13 to $118 a month, with CPU, RAM, NVMe and transfer details. Annual billing saves 30% on the twelve-month total. The monthly catalogue prices are Veil $13, Shade $33, Eclipse $63 and Obsidian $118. Annual billing reduces the twelve-month total by 30%, giving $109.20, $277.20, $529.20 and $991.20 respectively. Crypto quotes are payable; automatic blockchain verification and server provisioning are not connected yet. ### The configured VPS catalogue Amounts are in USD. The annual column is the full twelve-month payment; the monthly equivalent is shown only for comparison. Resources describe the catalogue, not verified live server capacity. | Plan | vCPU | RAM (GB) | NVMe (GB) | Transfer (TB) | Monthly payment (USD) | Annual total (USD) | Monthly equivalent (USD) | | --- | --- | --- | --- | --- | --- | --- | --- | | Veil | 1 | 2 | 30 | 2 | 13.00 | 109.20 | 9.10 | | Shade | 2 | 4 | 80 | 4 | 33.00 | 277.20 | 23.10 | | Eclipse | 4 | 8 | 160 | 8 | 63.00 | 529.20 | 44.10 | | Obsidian | 8 | 16 | 320 | 16 | 118.00 | 991.20 | 82.60 | ### Find the guide for your next decision - [Choose an affordable VPS configuration]() - [Review the resource and account features]() - [No-KYC VPS hosting]() - [Catalogue facts]() - [Review the eight checkout methods]() - [VPS monthly or annual billing: compare the full cost]() ## Private VPS features: root, KVM, NVMe and crypto [Private VPS features: root, KVM, NVMe and crypto]() Review the planned SilentVPS features: pseudonymous accounts, root access, KVM, NVMe, IPv4 and IPv6. See what is specified and what needs verification. The SilentVPS catalogue specifies KVM virtual machines, NVMe storage, full root access, IPv4 and IPv6. The account flow uses an alias, a password and optional email. Operational retention, mitigation and recovery capabilities require verified documentation before the service opens. ### Find the guide for your next decision - [Understand hosting records and retention]() - [Plan a private self-hosting stack]() - [Compare CPU, RAM and storage]() - [Catalogue facts]() ## Private VPS or conventional hosting: compare [Private VPS or conventional hosting: compare]() Compare private VPS hosting with conventional accounts: identity fields, crypto payments, retention, recovery and workload requirements before choosing. A private VPS account reduces the identity details requested during signup, but it does not remove every record or risk. Compare payment methods, recovery, retention, infrastructure and workload policies together. The right hosting choice depends on the application's needs and your threat model. ### Find the guide for your next decision - [Use the privacy hosting comparison checklist]() - [Evaluate a provider's retention policy]() - [Review the complete purchase workflow]() ## About SilentVPS: a privacy-focused VPS project [About SilentVPS: a privacy-focused VPS project]() Infrastructure should not ask for more personal information than it needs. SilentVPS starts from that idea, with pseudonymous accounts and a crypto-first catalogue. ### Find the guide for your next decision - [Explore the planned service features]() - [Contact the project]() - [Catalogue facts]() - [Private VPS accounts, payments and data practices]() ## Contact SilentVPS: support channels and questions [Contact SilentVPS: support channels and questions]() Use the form for account, payment, refund or privacy questions. Include only the information needed to understand your request. Use the form for account, payment, refund or privacy questions. Include only the information needed to understand your request. This form records your message and returns a reference. It does not send an automatic email notification. ### Find the guide for your next decision - [Find practical privacy and VPS guides]() - [Check the planned VPS resources]() ## Private VPS, crypto payments and self-hosting guides [Private VPS, crypto payments and self-hosting guides]() Practical guides covering private VPS purchases, crypto payment networks, SSH, Tor, WireGuard and self-hosting, with operational assumptions and official references. Prepare a private VPS purchase by checking the resources, full billing amount and exact cryptocurrency network. Then plan administration, application updates and independent backups. These guides explain account privacy, crypto checkout, administration through Tor, WireGuard and self-hosting without promising automatic anonymity or verified production availability. ### Find the guide for your next decision - [Compare the catalogue before buying]() - [Check configured facts and service status]() - [How the SilentVPS crypto checkout works](): Follow server configuration, currency and network selection, the dedicated invoice page, quote expiry and backend-driven payment status. Understand the current service integration limits. - [Keeping a privately acquired server separate](): Build durable habits for remote access, project identities, metadata, renewals and encrypted backups. - [Explore the VPS resource paths]() - [VPS migration checklist: backups, DNS, TLS and rollback](): A practical migration sequence for a self-hosted application: inventory, consistent backups, a tested destination, controlled writes, DNS cutover and a restore path. - [Pay for a VPS with crypto: an invoice checklist](): Prepare your wallet, select the exact payment network, check the invoice and protect your order reference after sending. - [An anonymous VPS purchase, from browsing to first login](): Check the network, signup fields, mailbox and payment method before ordering a server without unnecessary identity data. - [Why SilentVPS uses crypto payments](): Understand the eight payment methods, the public transaction record and how payment privacy differs from account privacy. - [Protect your crypto wallet before paying for hosting](): Keep recovery material private, prepare the correct network and review the destination and recipient amount before a hosting payment. - [Assessing a no-logs hosting claim](): Distinguish live network state, service records and retained activity logs, then ask the questions that make a privacy claim useful. - [A Tor-based management path for your VPS](): Use a SOCKS proxy for SSH, publish a private onion endpoint and check DNS, authentication and recovery before closing public access. - [Plan and maintain a Tor relay on a VPS](): Choose a non-exit relay or bridge, budget bandwidth, install maintained Tor packages and operate the node responsibly. - [Run a personal WireGuard endpoint with minimal history](): Build a small self-hosted VPN, separate routing from administration and review the logs created around WireGuard. - [Prepare a VPS for private, deliverable email](): Check IP reputation, SMTP availability, DNS authentication and reverse DNS before building your own mail service. - [Host your password vault on a private VPS](): Choose Bitwarden or Vaultwarden, secure the HTTPS endpoint and build a tested backup routine for your most important account. ## Your server. Your alias. [Anonymous VPS: accounts, payments and privacy]() A virtual server built around a small account footprint: a username, a password, optional email and cryptocurrency billing. Keep your infrastructure separate from the personal details an ordinary hosting account collects. An anonymous VPS uses a pseudonymous hosting relationship rather than a profile built around civil identity. Signup, payment, management connections and applications remain separate privacy layers. SilentVPS prepares an alias-based account model; no VPS or cryptocurrency can guarantee anonymity in every situation. ### Privacy depends on the whole chain An anonymous VPS is a server rented through a pseudonymous relationship rather than a profile containing your civil identity. The ordering experience is designed without name, postal address, phone, identity-document or card fields. A separate order token identifies each configuration. Signup is only one layer. Payment history, management connections, the applications you install and the information those applications publish can all create links. Choose your setup according to the exposure you need to reduce; no hosting product can promise universal anonymity. ### Four independent layers #### Account Use a fresh alias and a unique password. Email remains optional; save your credentials and order token securely. #### Payment Checkout supports BTC, ETH, SOL, LTC, native TRX on Tron, USDT on Tron or Ethereum, and USDC on Ethereum. These networks have public transaction ledgers; a minimal hosting account does not erase wallet history. #### Retention Separate the service records needed for billing and provisioning from traffic history. Exact retention periods will be published when the operator supplies them. #### Connections Tor can reduce the IP exposure of browsing and administration. A SilentVPS onion address will be announced only after it exists and is verified. ### From configuration to a root shell #### 01 · Choose the machine Select one of four plans, a monthly or annual cycle, a location and an operating-system image. Provide a hostname and notification email only if you need them. #### 02 · Prepare your access Use a public SSH key where possible, or choose password access. Keep the private part of an SSH key on your device. #### 03 · Keep the order reference The account and private order token provide two ways to follow the order. Saving a configuration does not require payment. Its checkout can generate a payable quote; blockchain verification and VPS activation remain separate integrations. ### A server for your own stack Full root means you choose the operating system, packages, firewall and application configuration. The target baseline includes KVM isolation, NVMe storage and IPv4 plus IPv6. Snapshot restoration and network-edge mitigation are capabilities to confirm separately. Typical projects include non-exit Tor relays and bridges, onion services, WireGuard, personal mail, a password vault, file synchronization, development environments and encrypted backup targets. Each workload needs its own updates, access controls and recovery plan. Root access gives you administrative control inside the guest operating system: you can manage its packages, users, firewall and services. It does not give you control of the physical host or remove the hosting operator from your threat model. KVM separates guest systems through virtualization; it is not a claim of confidential computing or a guarantee that provider-level access is impossible. Read the root-access guide before choosing which data and workloads to place on a rented server. ### Who this approach serves #### Journalists and researchers Keep a research environment, publication or submission endpoint separate from a personal hosting profile. Sensitive newsroom systems need a specialist deployment review. #### People facing surveillance Reduce unnecessary account and payment identifiers while considering the wider risks of your device, network and applications. #### Privacy developers Build and test tools on an infrastructure model that aligns with data minimization. #### Independent self-hosters Run files, mail and personal applications without adding another named card subscription. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### Which identity details does the account ask for? The designed flow asks for a username and password, with optional email. It has no legal-name, identity-document, card, address or phone verification fields. #### Can every link to a server be prevented? No universal anonymity guarantee is possible. Account fields, payment history, management connections, devices and applications are different layers; personal identifiers in any layer can create a link. #### Where will the legal conditions be published? SilentVPS operator details, jurisdiction and legal documents will be published before launch. Applicable rules depend on the operator, server location and intended use. #### Do I have to provide an email address? No. Email is optional. Keep the password and private order token safe, because recovery cannot rely on identity information or a contact address you never supplied. #### Can I browse and administer using Tor? Tor-aware browsing can reduce the visible source IP. Your own SSH onion endpoint can protect administration. A dedicated SilentVPS onion address will be listed only when it is deployed and verified. #### Which workloads is the configuration intended for? Non-exit Tor relays and obfs4 bridges, onion services, WireGuard, mail, personal clouds, vaults, development and backups. Each application requires maintenance and secure configuration; Tor exit nodes are excluded. ### Find the guide for your next decision - [Explore the four VPS configurations]() - [Privacy features]() - [Contact SilentVPS]() - [No-KYC VPS hosting]() - [Understand retention]() - [VPS sizing calculator: RAM, CPU, storage and bandwidth]() - [VPS crypto payment networks: TRX, USDT, BTC and more]() - [KVM VPS and root access: control, isolation and limits]() - [Follow the private purchase checklist]() - [Private VPS accounts, payments and data practices]() ## A username is enough to begin. [No-KYC VPS hosting]() Configure a Linux VPS without an identity-document upload or named card payment. Choose from eight cryptocurrency payment methods; email remains optional. KYC describes identity verification. The SilentVPS account experience is designed around an alias and password rather than document scans, selfies, phone verification or a residential address. This keeps the requested information closely tied to operating a server. ### What no-KYC means in this product KYC describes identity verification. The SilentVPS account experience is designed around an alias and password rather than document scans, selfies, phone verification or a residential address. This keeps the requested information closely tied to operating a server. No-KYC hosting and payment privacy solve different problems. A minimal signup does not erase information already associated with your wallet or exchange. Cryptocurrency payment also does not prevent an application from revealing personal details later. ### Information involved in an order #### Service choices Plan, billing cycle, OS image, location and any optional hostname. #### Account and tracking Chosen username, password hash and an order token. The password itself should never be stored in readable form. #### Access and routing Your submitted public SSH key or selected access method, plus server allocation information once provisioning is connected. #### Payment state Invoice amount, selected asset, confirmation status and the operational records required to reconcile the payment. #### Optional contact An email only if you choose to enter one. The production retention schedule remains to be supplied by the operator. ### Identity fields left out of the flow #### Civil identity No legal-name or date-of-birth field. #### Documents No passport, national-ID or selfie upload. #### Banking No card-number or bank-account field. #### Contact verification No compulsory phone number, SMS check or residential address. ### Understand your payment footprint Cards introduce named financial intermediaries. The cryptocurrency networks supported by SilentVPS publish transactions on public ledgers. An account without identity-document fields does not make those transactions private or remove links to an exchange account. Checkout offers BTC, native ETH, native SOL, LTC, native TRX on Tron, USDT on Tron or Ethereum, and USDC on Ethereum. Use only the exact asset, network, destination and amount shown on the invoice. Payment verification and server provisioning remain separate steps. ### Keep the relationship pseudonymous Use an alias you do not reuse on personal accounts. Protect the account password and the separate order token, and think before adding a notification address that identifies you. For server administration, use SSH keys and a connection method appropriate to your threat model. A minimal account is useful for researchers, developers, self-hosters and operators of privacy infrastructure. It does not replace application security or decide what is lawful in every jurisdiction. The operator’s legal documents will be added separately. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### What does no-KYC change in the signup? No document scan, selfie, phone verification, residential-address or card field is part of the account experience. You choose an alias and password and can leave email blank. #### Does a cryptocurrency payment guarantee anonymity? No. The supported networks record transactions on public ledgers. Optional-email signup reduces the information requested by the host, but it does not erase wallet history, exchange records or identifiers your applications disclose. #### Does no-KYC establish the legal terms of the service? No. It describes the account flow. The operator’s applicable legal documents and conditions will be supplied separately before production launch. #### How do I manage an order without a civil identity? Sign into the pseudonymous dashboard, or use the separate order token for tracking. Protect both. A legal name cannot recover credentials when no legal-name record exists. #### What information could be disclosed? Only information that exists can be produced. Minimal account fields reduce one category of data, while orders, billing and operational records remain separate. The production disclosure and retention process awaits the operator’s confirmed documents. #### Does no-KYC also mean there are no server logs? No. Identity collection and activity retention are separate questions. Review the infrastructure retention boundary and the logs your applications write inside the guest. ### Find the guide for your next decision - [Explore pricing]() - [Privacy features]() - [Contact SilentVPS]() - [Pay for a VPS with crypto: an invoice checklist]() - [KVM VPS and root access: control, isolation and limits]() - [VPS crypto payment networks: TRX, USDT, BTC and more]() - [Anonymous VPS with BTC, USDT and more]() - [Understand the four privacy layers]() ## Know what stays. Ask why. [No-logs VPS: records, retention and limits]() A useful no-logs statement separates account records, billing state, infrastructure diagnostics and traffic history. SilentVPS is designed around data minimization; the final production retention policy will be supplied before launch. No-logs hosting needs a precise definition of which records are excluded and which remain. Account, billing, infrastructure and guest-system records are different categories. SilentVPS has not published validated retention periods; assess specific data handling rather than treating a no-logs label as proof. ### A running server always handles some data Packets must be routed, a hypervisor must schedule work and a payment must be confirmed. Handling those events is different from keeping a searchable history of every connection. The question is which events become durable records, for what reason, and for how long. Avoid treating “zero logs” as a claim that no data can ever exist. A responsible implementation names its necessary records, restricts access, limits retention and distinguishes platform telemetry from the logs you configure inside your own virtual machine. ### Transient operations and persistent records #### Transient network handling Routing packets and maintaining interface state are required to deliver connectivity. They are not automatically a retained browsing history. #### Service records The chosen plan, allocation, order token and billing status are needed to manage the service. #### Optional contact A supplied notification email is account data. Leaving the field blank removes that item from your configuration. #### Diagnostics and abuse signals These should be minimized, scoped to operations and described explicitly instead of hidden under a broad no-logs slogan. ### The retention checklist #### Identity documents Not part of the account flow, so there is no document-upload record to retain. #### Name, address and card These fields are absent from the configuration. #### Connection and request history The production operator must confirm infrastructure logging settings and exclusions. #### Order and payment records Necessary service state; exact retention periods await the operator’s policy. #### Crash and error data The final policy must distinguish server diagnostics from traffic contents. #### VPS files and snapshots Your guest filesystem and any snapshot feature need their own security model. Host access cannot be ruled out merely by holding root in a VM. ### Verification before trust Read the final privacy document, compare its data list with the signup and billing screens, and check whether technical settings support the public wording. A signed canary or request ledger can add context only if it is authentic, current and independently checkable. SilentVPS has no published signed canary, audited operational retention window or measured production history yet. The corresponding pages preserve a place for those disclosures without inventing evidence. You can already inspect the signup and order flow on this website. ### Your applications have their own logs Nginx, SSH, mail servers, containers and monitoring tools may log inside the guest. Review each service, its access rules and its rotation policy. Encrypt sensitive backups, terminate your own TLS and keep encryption keys outside unnecessary third-party systems. Disk encryption is useful but has limits on a running hosted VM. It protects certain storage exposures; it does not turn a provider-operated hypervisor into hardware that you own. Plan for recovery and protect the administrative device as carefully as the server. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### Can a working VPS use literally no data? No. Routing, scheduling, account state and payment confirmation require handling some information. A precise no-logs claim concerns which events become retained records and their purpose. #### Which records does the service need? Configuration, account and order token, payment status, allocation state and limited diagnostics. Optional email exists only if supplied. Exact production retention windows await the operator’s final policy. #### How can I verify the retention claims? Compare the final written data list with the actual signup and billing flow, infrastructure settings and any authentic current audit or signed disclosure. SilentVPS has no published operational audit or signed canary yet. #### What happens if customer data is requested? A request can concern only records that exist. The operator must define the validated production response process in its own documents; no court jurisdiction or response history is fabricated on this website. #### Does full root mean a host can never access my VM? No. Root controls the guest operating system, while the provider operates hardware and hypervisor layers. Encryption and restricted keys protect specific risks but do not erase that trust boundary. #### Are anonymous signup and no logs the same thing? No. The first concerns the identity information collected; the second concerns records retained over time. Both need their own implementation and verification. ### Find the guide for your next decision - [Explore pricing]() - [Privacy features]() - [Contact SilentVPS]() - [Audit a hosting retention claim]() - [Apply data minimization to WireGuard]() - [Private VPS accounts, payments and data practices]() ## Put your bandwidth to work. [VPS for a Tor relay or bridge: requirements]() A Linux server for a non-exit relay or an obfs4 bridge, with full root and transfer allowances from 2 TB to 16 TB. Choose the capacity you want to contribute, then configure Tor to stay inside it. A Tor middle relay forwards traffic inside the Tor network; a bridge offers an entry point that is not publicly listed like ordinary relays. Both require capacity planning, updates and provider permission. SilentVPS's planned catalogue excludes exit nodes, which have different operational responsibilities. ### Choose the role before the machine #### Middle relay Forwards encrypted traffic within the Tor network. It is not the endpoint that connects to public websites. #### Bridge An entry relay that is not published in the ordinary public directory. An obfs4 transport can help users on filtered networks reach Tor. #### Exit node Connects to the public internet on behalf of Tor users. Its IP receives the associated complaints and exposure. Exit nodes are excluded from the planned service. ### Size for sustained transfer A modest relay is still useful. Transfer allowance and sustained connectivity usually matter more than disk capacity. Veil provides 2 TB, Shade 4 TB, Eclipse 8 TB and Obsidian 16 TB per month; leave some room for updates and other traffic. Use Tor’s RelayBandwidthRate, RelayBandwidthBurst, AccountingMax and accounting-period settings to fit the allowance. Confirm how inbound and outbound transfer are counted before setting your budget. A burst rate is not the same as a guaranteed sustained port speed. ### A practical operating routine #### Install from maintained sources Start with Debian or Ubuntu and follow the Tor Project relay documentation for the current package and configuration. #### Set identity and contact carefully Choose a relay nickname and safe operator contact. Do not insert a personal identifier merely because the example configuration has one. #### Limit and monitor Enable bandwidth accounting, watch health and resource usage, and allow time for a new relay to earn network weight. #### Keep the node maintained Apply security updates, preserve relay identity keys securely and plan restart windows. ### Keep payment and administration separate Use a dedicated account alias and consider the public transaction history of the wallet you use for payment. Tor-aware browsing and an SSH onion endpoint can reduce exposure in the management path. The server’s relay identity itself is intentionally public for an ordinary middle relay. A relay, bridge and onion service are separate roles. Hosting a private application behind an onion address does not automatically make the machine a relay, and running a relay does not automatically hide an application’s origin. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### Are Tor relays and bridges intended workloads? Yes. The planned service covers middle relays and bridges, including obfs4. Use maintained software and configure resource limits for your plan. #### How do relay, bridge and exit roles differ? A middle relay forwards encrypted traffic between Tor nodes. A bridge is an unlisted entry route. An exit connects to public websites and receives the associated exposure on its IP. #### Can I configure a Tor exit? Exit nodes are excluded from the planned service. The supported relay roles do not authorize an exit configuration. #### Which bandwidth allowance is included? Veil has 2 TB monthly transfer, Shade 4 TB, Eclipse 8 TB and Obsidian 16 TB. Use bandwidth and accounting directives to leave a margin for system traffic, and confirm production counting rules. #### How can I reduce identifiers when paying for a relay? A dedicated alias separates the hosting account from personal profiles, but cryptocurrency transactions remain public and may be linked to previous wallet activity. The relay’s public network identity and your management connections are independent concerns. #### How should an abuse report about a relay be handled? A middle relay differs from an exit and should not be mistaken for one. SilentVPS’s actual escalation and notification procedure will be confirmed by the production operator; this website does not promise a past support record. ### Find the guide for your next decision - [Compare monthly transfer allowances]() - [Privacy features]() - [Contact SilentVPS]() - [Plan and maintain a Tor relay]() - [Distinguish relays from onion services]() ### Official references - [Tor Project: relay checks after installation]() - [Tor Project: bridge setup]() ## Publish through Tor. Keep control. [Onion hosting: run a private Tor service]() Run your site, API, file drop or administrative endpoint as a v3 onion service. The VPS supplies the machine; you choose the application, hold the onion keys and maintain the configuration. An onion service makes an application reachable through Tor without publishing a conventional destination address. It is different from operating a relay. Protect the application, onion identity keys and management path, and consider client authentication when the service should be restricted to selected users. ### What an onion address changes A Tor onion service exposes an application through an authenticated .onion address instead of relying on a public DNS name. Tor builds introduction and rendezvous connections so visitors do not receive the service’s ordinary IP address through that connection. The underlying machine still has a network allocation. An app binding to a public interface, a link to clearnet resources, a misconfigured mail service or identifiable content can reveal information Tor’s transport does not hide. Protect the entire application rather than only its entry URL. ### Self-hosting keeps the choices yours #### Own the address keys Generate the onion private keys inside a controlled environment and keep secure offline backups. Losing them means losing the address. #### Choose the software Publish a static site, private cloud, Matrix endpoint, internal dashboard or SSH service without inheriting a shared platform’s app list. #### Decide who can connect Public onion services are reachable by anyone who knows the address. Tor client authorization can restrict a private service. #### Maintain your own stack You own updates, permission checks, backups and recovery. A VPS does not provide automatic application hardening. ### The shape of the setup #### 01 · Bind locally Run the application on a loopback address such as 127.0.0.1. Keep unintended public listeners closed. #### 02 · Configure Tor Install the maintained Tor package and configure HiddenServiceDir and HiddenServicePort to map the onion port to the local application. #### 03 · Protect and test Restrict permissions on the key directory, restart Tor, verify the generated address and test access from a separate Tor client. #### 04 · Plan recovery Back up keys and application data securely. Confirm that the restored instance uses the intended identity without exposing old copies. ### The account is another layer An onion service protects its transport endpoint. The hosting relationship, payment and management path are separate. A pseudonymous account and an onion SSH endpoint can reduce some identifiers; payment transactions on the supported networks remain publicly inspectable. Do not treat a cloud VPS as a universal replacement for specialist whistleblower infrastructure. Projects such as SecureDrop have specific operational requirements. Follow the application’s own deployment model when people’s safety depends on it. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### What does onion hosting provide? An application reachable through a Tor .onion address, with authenticated addressing and Tor transport. You still run and secure the software on a network-connected server. #### Why choose a VPS over a shared onion platform? You choose the software, hold the onion keys and control application logs and access. You also take responsibility for updates, backups and recovery. #### What are the basic setup steps? Bind the application locally, install Tor, map HiddenServicePort to the local listener under a protected HiddenServiceDir, then test the generated v3 address and preserve keys securely. Follow current Tor Project documentation. #### Does an onion address hide the hosting account too? No. It does not change how the server was rented, paid for or administered. Account alias, payment history, management path and application leaks require separate attention. #### Where will the usage conditions be available? SilentVPS terms and acceptable-use rules will be published before launch. This guide covers the technical setup; check the final conditions before deploying your service. #### Can an onion key or address be disclosed through the host? The onion key is generated in your configured environment, but a hosted VM still has an infrastructure trust boundary. Protect keys and backups; do not assume root or encryption makes a running guest invisible to the operator. ### Find the guide for your next decision - [Explore pricing]() - [Privacy features]() - [Contact SilentVPS]() - [Protect the server administration path]() - [Compare onion services with Tor relays]() - [Choose an application to self-host]() ### Official references - [Tor Project: onion service setup]() - [Tor Project: onion service client authentication]() ## Make the VPN yours. [WireGuard VPS: private VPN planning and logs]() Install WireGuard on a VPS you administer, choose the peers and review the logs yourself. A personal endpoint offers control, a stable address and an encrypted path through untrusted local networks. A self-hosted WireGuard endpoint encrypts traffic between your device and VPS and gives you control over VPN configuration. It does not hide all activity from every observer. Protect peer keys, configure the firewall and review host, operating-system and application records separately. ### Control rather than a shared exit A commercial VPN normally manages the endpoint and its policy for you. On your own VPS, you install the packages, hold the keys, define peers and decide which supporting services record events. WireGuard’s design is small; the surrounding operating system still deserves a log review. A dedicated IP is convenient but does not blend you into a large shared exit pool. A VPN reduces exposure on your local network and changes the address seen by destinations; it is not a general anonymity system or protection from every observer. ### What you configure #### Keys and peers Create separate key pairs for each device. Share only public keys and revoke a device when it no longer belongs on the tunnel. #### Routing and DNS Choose full-tunnel or split-tunnel behavior, route IPv6 deliberately and verify DNS traffic follows the intended path. #### Firewall Open only the required UDP port and administration access. Confirm forwarding and NAT rules match your interface names. #### Guest logs Review firewall, DNS and service logging, plus retention and backups. A no-logs intention is only useful when the whole guest configuration supports it. ### Tor for management, UDP for the tunnel WireGuard uses UDP and does not run through an ordinary Tor circuit. You can keep SSH administration behind an onion endpoint while WireGuard remains reachable on its regular UDP port. That separates the management path from daily VPN traffic. Use Tor-aware browsing and a separate account alias if your provisioning path needs less identity exposure. The supported cryptocurrency networks have public transaction ledgers, so account minimization does not remove payment history. None of those choices replaces secure client devices. ### Choose the transfer allowance A personal tunnel is often a light compute workload. Start by estimating monthly transfer across all devices. Veil has 2 TB, Shade 4 TB, Eclipse 8 TB and Obsidian 16 TB, while the larger plans also add resources for other applications. The same machine can become a private gateway to a password vault, dashboard, DNS resolver or cloud service. Keep the public attack surface small and document recovery before the VPN becomes your only way into the server. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### What changes compared with a commercial VPN? You administer one endpoint rather than inheriting the provider’s shared exit and settings. Keys, peers, routing, guest logs and maintenance are your decisions. #### Who controls WireGuard keys and traffic records? You create and protect the keys and review the guest configuration. Network routing and hypervisor operation remain infrastructure trust boundaries; a provider’s no-logs wording must be checked against its real settings. #### Can administration use Tor? Yes, you can configure an SSH onion endpoint. WireGuard itself uses UDP and does not use a standard Tor circuit; management and everyday tunnel traffic are separate paths. #### Does a personal endpoint provide complete anonymity? No. It encrypts a connection path and gives you control, but its dedicated IP, applications and client identifiers still matter. Tor serves a different unlinkability model. #### Which configuration should I start with? Veil can fit a light personal tunnel. Estimate total device transfer; choose Shade, Eclipse or Obsidian when 2 TB is insufficient or you add other services. Actual throughput must be tested. #### Does a VPN change the conditions of using the server? No. A tunnel changes the network path, not the nature of a workload. The operator will supply the final SilentVPS usage documents separately. ### Find the guide for your next decision - [Check resources for your VPN]() - [Privacy features]() - [Contact SilentVPS]() - [Build a personal WireGuard endpoint]() - [Private self-hosting]() - [Separate VPN records from hosting records]() ### Official references - [WireGuard quick start]() ## Choose the client. Own the setup. [Private seedbox VPS: storage and transfer planning]() An always-on VPS for distributing files you have the right to share. Install your preferred torrent client, secure its panel and select the storage and monthly transfer your library needs. A private seedbox is a remotely managed download and storage service. Its capacity depends on concurrent tasks, disk space and transfer volume. Secure the web interface and remote access, keep software updated, and verify the provider's usage rules before deploying the workload. ### An unmanaged seedbox gives you the decisions A managed seedbox supplies a ready-made panel and client. Building one on a VPS gives you root access, client choice and control over configuration, logs and retention. You also take responsibility for patching, monitoring and backups. Your datacenter endpoint separates torrent traffic from your home connection, but peers and trackers can still see the seedbox IP. Pseudonymous hosting does not automatically hide every relationship in a torrent swarm. ### Pick the tools that fit you #### qBittorrent-nox A common headless option with a web interface. Set strong authentication and restrict panel access. #### Transmission or Deluge Alternative clients with different management and plugin models. Review current packages and remote-access settings. #### rTorrent A terminal-oriented option for people comfortable administering Linux. Secure any added web frontend separately. #### Optional VPN binding Bind the client to the intended tunnel interface and test fail-closed behavior. A VPN adds another provider and another trust boundary. ### A careful build sequence #### 01 · Configure the server Choose storage and transfer capacity, use an alias and install a maintained Linux image. #### 02 · Secure administration Use SSH keys, enable a firewall and keep the torrent panel behind authenticated private access. #### 03 · Separate content and recovery Encrypt sensitive archives and backups where appropriate. Test your backup process before trusting the server with the only copy. #### 04 · Monitor capacity Track free disk space and monthly transfer. Large active libraries often fill storage before they consume the entire network allowance. ### Useful distribution workloads Seed Linux installation images, open-source releases, public-domain or properly licensed archives and datasets you are authorized to distribute. A seedbox is also a practical remote transfer tool when you control the rights to the files. Choose Veil for a small library, Shade for more breathing room, or Eclipse and Obsidian when active storage and transfer grow. No tier adds automatic copyright permission or turns a server into a managed archival service. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### What is a VPS seedbox? A remote machine you configure to download and seed authorized torrents. Pseudonymous hosting changes the account relationship, while peers and trackers can still see the seedbox address. #### How does it differ from a managed seedbox? You select the client, access rules, logs and backups with root control. A managed panel is easier to begin with but gives those decisions to its operator. More control means more maintenance. #### Which files is a seedbox useful for? Linux images, open-source releases, public-domain or appropriately licensed collections, and datasets you have permission to distribute. Rights depend on the actual content, not the server label. #### Where are download and seeding logs controlled? The torrent client and supporting guest services may record activity. You configure those records yourself. Production platform retention must be confirmed separately rather than inferred from pseudonymous signup. #### Does the account require an identity document? Signup uses a username and password with optional email, without document or card fields. Checkout supports eight payment methods across seven cryptocurrency assets. Their transaction ledgers are public. #### How should I estimate capacity? Measure the active file library against 30, 80, 160 or 320 GB NVMe and estimate monthly transfer against 2, 4, 8 or 16 TB. Leave space for updates, temporary files and backup work. ### Find the guide for your next decision - [Compare NVMe space and transfer allowances]() - [Privacy features]() - [Contact SilentVPS]() - [Review other self-hosting workloads]() - [Private VPN endpoint]() - [VPS sizing calculator: RAM, CPU, storage and bandwidth]() - [Maintain a private server over time]() ## Bring your services home. [Private self-hosting VPS: mail, files and vaults]() Run a password vault, file cloud, mail stack or personal application on a Linux VPS with root access. Choose what you install, how it is exposed and which data your services retain. Private self-hosting puts application configuration and maintenance under your control. Mail, file synchronization and password vaults have different storage, network and recovery requirements. Choose resources around the workload, protect access, and test encrypted backups rather than assuming root access alone provides privacy. ### Move from a hosted app to a server you administer Self-hosting changes who controls your software and its settings. A pseudonymous infrastructure account adds another layer by reducing the identifiers in the hosting relationship. It does not make the underlying datacenter hardware your property or remove the need to trust the infrastructure operator. Full root lets you install packages, run containers, configure a firewall and rebuild the guest. That freedom comes with responsibility for updates, secure defaults, resource planning and tested restoration. ### Four common starting points #### Personal mail Mailcow, Mail-in-a-Box, or Postfix with Dovecot can provide a complete mail stack. Confirm SMTP access, PTR/rDNS support and IP reputation first; configure SPF, DKIM and DMARC and test deliverability. #### Password vault Vaultwarden provides a lightweight Bitwarden-compatible service. Use TLS or private network access, control registration, enable strong authentication and back up the database and attachments. #### File cloud Nextcloud can host files, contacts and calendars. Select disk capacity for current data, database growth, previews and backups rather than only the visible file total. #### Research and intake A private app, onion mirror or controlled submission endpoint can support research work. Sensitive source-protection deployments need the application’s specialist architecture and operational review. ### Private access can shrink the public surface You do not have to expose every dashboard to the entire internet. WireGuard can act as a private door for trusted devices, while an onion endpoint offers another option for Tor-based access. Give each service an explicit audience and separate administrator credentials. Keep the management path available during changes. A mistaken firewall rule or broken tunnel can lock you out; save a recovery method and avoid depending on a single application as the only route into the machine. ### Match the size to the application Veil fits a light vault, personal site or small tunnel. Shade adds memory and disk for an everyday cloud or modest app stack. A mail-and-cloud combination, a busy database or several users may need Eclipse or Obsidian. Measure your actual workload. Mail allocation, IP reputation, snapshots and DDoS filtering require confirmation when the live infrastructure is connected. This public website does not claim a measured uptime percentage, delivery guarantee or an already-operated fleet. ### Backups are part of the service you build Keep encrypted copies outside the same VPS, preserve the keys independently and practice restoring to a clean environment. Snapshots can help with rollback but do not replace independent backups. Document what your household or team would need if the administrator’s device failed. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### What makes a self-hosting VPS private? You administer the applications and their data, while a minimal hosting account can reduce identifiers under the stack. Infrastructure and application security remain separate responsibilities. #### Can I run mail on it? Root and IPv4/IPv6 are in the target specification. Confirm outgoing SMTP, PTR/rDNS support and IP reputation, configure SPF/DKIM/DMARC and test delivery before migrating important mail. #### Is a self-hosted Bitwarden-compatible vault suitable? Vaultwarden is a light option if you can maintain it. Restrict access and registration, use TLS or a private network, enable strong authentication and test encrypted backups and restoration. #### Why add a pseudonymous hosting layer? It can reduce identity information in the hosting account and billing relationship. It does not prevent personal content, email domains or application behavior from identifying you elsewhere. #### Which tier fits a personal stack? Start with the actual workload: Veil for a light service, Shade for more memory and files, Eclipse or Obsidian for multiple services and heavier compute. Reserve space and resources for backups and peak load. #### Who sets the application and usage limits? You control packages and guest configuration within SilentVPS’s service conditions. The final terms and acceptable-use rules will be published before launch. ### Find the guide for your next decision - [Match resources to your applications]() - [Privacy features]() - [Contact SilentVPS]() - [Plan a self-hosted password vault]() - [Check private email requirements]() - [VPS migration checklist: backups, DNS, TLS and rollback]() - [VPS sizing calculator: RAM, CPU, storage and bandwidth]() - [Catalogue facts]() ### Official references - [Bitwarden: self-host an organization]() - [Vaultwarden: backing up your vault]() ## Choose the geography of your server. [Offshore VPS locations and crypto payments]() The planned location catalogue spans Europe, the Caribbean, the Indian Ocean and Asia-Pacific. Keep the same four configurations and pricing while selecting the region suited to your audience. Offshore hosting describes a server location relative to you; it is not a universal privacy or legal exemption. Evaluate the operator's jurisdiction, infrastructure provider, network routing and data handling separately. SilentVPS lists planned regions, with operating details still requiring confirmation. ### The full location catalogue Fourteen physical locations plus the Auto mode form fifteen deployment choices. Availability will be verified when production provisioning is connected. #### Americas and Caribbean Panama City, Panama · Willemstad, Curaçao. #### Asia-Pacific Hong Kong · Kuala Lumpur, Malaysia. #### Indian Ocean Victoria, Seychelles. #### Europe Amsterdam, Frankfurt, Helsinki, Zürich, Reykjavík, Bucharest, Luxembourg, Sofia and Chișinău. #### Automatic selection Auto — fastest available. This is a selection mode, not a fifteenth physical city. ### Choose for reach and exposure Audience proximity, network routes and applicable jurisdiction all matter. Hong Kong and Kuala Lumpur serve Asia-facing projects; Amsterdam and Frankfurt are central European options; Panama, Curaçao and Seychelles broaden the geographic choices. Measure actual latency instead of relying on a country label. An offshore location does not mean immunity from law or requests, and a country name alone cannot establish the operator’s full legal situation. SilentVPS operator details and legal documents will be published before launch. ### Same catalogue in each region The four plans share their target KVM, NVMe, root and IPv4/IPv6 baseline. Checkout supports BTC, ETH, SOL, LTC, native TRX on Tron, USDT on Tron or Ethereum, and USDC on Ethereum. A pseudonymous account and optional email keep the contact footprint small; public transaction history remains a separate consideration. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### Does the price change by city? The target catalogue keeps the same plan price across the listed location choices. #### Are there fifteen physical locations? There are fourteen listed locations and one Auto choice. Auto selects an available location; it is not another city. #### Are Curaçao and Hong Kong among the choices? Yes. Willemstad in Curaçao and Hong Kong are in the planned catalogue, alongside the other listed cities. Production availability will be checked when the infrastructure is connected. #### Can I configure an offshore server without email? Yes. The intended account experience is a username and password with email optional; selecting an offshore city does not add an identity field. ### Find the guide for your next decision - [Explore pricing]() - [Privacy features]() - [Contact SilentVPS]() - [Review the planned Hong Kong region]() - [Separate location from payment privacy]() - [Compare account and service requirements]() ## Use the asset you already hold. [Anonymous VPS with BTC, USDT and more]() Checkout offers eight methods across Bitcoin, Ethereum, Solana, Litecoin, Tron and supported stablecoin networks. Your account uses an alias, with email optional. Check the asset and network on the invoice; payment verification and server provisioning are separate steps. A coin ticker is not enough to route a payment safely. The exact asset and network must match the invoice. Checkout generates payable quotes with a fixed destination, amount and expiry. Automatic blockchain verification still awaits activation. ### Assets and the required networks A coin ticker is not enough to route a payment safely. The exact asset and network must match the invoice. Checkout generates payable quotes with a fixed destination, amount and expiry. Automatic blockchain verification still awaits activation. #### BTC · Bitcoin Bitcoin network. Transactions are recorded on a public ledger. #### USDT · Tether Tron using TRC-20 or Ethereum using ERC-20. Select the exact network in checkout and follow the invoice. #### USDC · USD Coin Ethereum network, ERC-20. Ethereum gas fees apply. #### ETH · Ethereum Native Ethereum network asset. #### LTC · Litecoin Litecoin network. #### SOL · Solana Solana network. #### TRX · TRON Native Tron network asset, available as a separate TRX payment choice. This is distinct from USDT on Tron. ### No-KYC signup is separate from payment privacy Bitcoin, Ethereum, Solana, Litecoin, Tron and the supported stablecoin transactions are publicly inspectable. A host asking for no ID does not remove the history of a wallet associated with an exchange account or earlier payments. Consider the complete payment history and your own compliance obligations. Do not assume changing wallets erases every link, and do not publish transaction identifiers alongside personal accounts. ### One account model across the catalogue Choose a username and unique password, select a plan and location, and keep the order token. Optional email is intended for notifications rather than identity verification. The website lets you save the configuration without submitting funds. Billing uses a direct cryptocurrency quote rather than a saved card subscription. The destination, exchange rate, exact amount and expiry are fixed in each invoice. Blockchain verification and server provisioning are not connected yet; generating a quote or opening a wallet does not confirm payment or activate a VPS. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### Is USDT supported on every network? No. USDT is available only on Tron using TRC-20 or Ethereum using ERC-20. Select the network explicitly and follow the invoice. Other networks and Ethereum layer 2 networks are not supported. #### Which USDC network is listed? Ethereum, using ERC-20. #### Which cryptocurrency payment methods are supported? Eight payment methods across seven assets: BTC, ETH, SOL, LTC, native TRX on Tron, USDT on Tron or Ethereum, and USDC on Ethereum. Check the currency and network on the invoice before sending funds. #### Is Bitcoin one of the payment choices? Yes. BTC on Bitcoin mainnet is configured in checkout. Follow the fixed amount, destination and expiry on the invoice. Automatic blockchain verification and server activation are not connected yet. #### Does BTC or USDT make a payment private? No. Bitcoin, Ethereum and Tron transactions are public. An optional-email hosting account does not erase a wallet’s exchange history or transaction graph. ### Find the guide for your next decision - [Explore pricing]() - [Privacy features]() - [Contact SilentVPS]() - [Check signup requirements]() - [VPS crypto payment networks: TRX, USDT, BTC and more]() - [Why SilentVPS uses crypto payments]() - [Prepare a private payment workflow]() - [Catalogue facts]() - [Review the eight checkout methods]() ## Compare the evidence, then the price. [Compare anonymous VPS providers: a practical checklist]() Account requirements, payment networks, server isolation, location and retention policy all affect the choice. This guide is published by SilentVPS, so treat our own offer as one option and verify competitors through their official sites. Compare privacy-oriented VPS hosts using the same criteria: account fields, payment networks, isolation, resources, location, retention and workload policies. This guide is published by SilentVPS, so its own planned offer should be evaluated alongside competitors rather than treated as an independent ranking. ### Five names to investigate #### SilentVPS A planned four-tier catalogue from $13/month, optional email, eight payment methods across seven assets and fourteen cities plus Auto. Website publication does not establish a production service history. #### Njalla Its official server page lists a €15/month entry VPS with 1 core, 1.5 GB RAM, 15 GB disk and 1.5 TB transfer, in Sweden. #### 1984 Hosting An Icelandic privacy-focused operator with root-access VPS and specialized images including VPN, LEMP and Nextcloud. Review signup and checkout for the current price and payment options. #### BitLaunch Its official platform offers hourly cryptocurrency billing across its own and partner clouds, with Linux and Windows options. #### Kyun Its official site describes customizable compute and a no-ID account approach. Check the live configurator for current capacity, pricing and payment methods. ### Ask the same questions of every host Compare plans over the same billing period and for the same resource needs. A vCPU count is not a promise of dedicated physical cores, and a monthly transfer allowance is not a guaranteed network speed. Check what the published price includes: IP addresses, backups stored outside the virtual machine, and any traffic or renewal charges. Use the sizing calculator to compare the configured CPU, RAM, disk and transfer allowances; confirm performance and extra charges with each provider separately. #### Signup Which identity and contact fields are compulsory? Is recovery possible without disclosing new identifiers? #### Payments Which coin and network are accepted, and does a payment processor add an account or data collection? #### Infrastructure Is the product a VM or a container? Which resources, address families and transfer limits are actually included? #### Location Where does the server operate, and which jurisdiction and upstream provider apply? #### Retention and verification Is the data list specific, with real retention periods? Are signatures, incident histories and reports current and verifiable? #### Fit for the workload Check mail ports, Tor roles, backups, available images and recovery tools before migrating. ### Do not infer a winner from one feature Accepting cryptocurrency does not automatically mean optional email or minimal logs. A signed document is not the same as an independent infrastructure audit. Compare the whole path and choose the provider that fits your requirements. Competitor summaries here were checked against official pages on 4 October 2026. Offer details can change. Unknown prices or terms are left for confirmation rather than filled with guessed values. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### Who publishes this comparison? SilentVPS. It is provider-authored and does not claim to be an independent ranking. #### Which choice is the most anonymous? That depends on your threat model, payment history, administration and application behavior. A universal ranking would hide those differences. #### Which payment details should I compare? Check each provider’s current checkout for the exact asset, network, required confirmations, regional restrictions and refund conditions. SilentVPS supports eight methods across seven assets, and the supported networks publish transaction records. #### Which account model allows no email? SilentVPS is designed with optional email. Njalla’s FAQ describes email or XMPP signup, and 1984’s support process refers to the registered contact email. Check each provider’s actual account form rather than assuming all privacy brands collect the same data. ### Find the guide for your next decision - [Check SilentVPS's planned configurations]() - [Privacy features]() - [Contact SilentVPS]() - [VPS sizing calculator: RAM, CPU, storage and bandwidth]() - [VPS crypto payment networks: TRX, USDT, BTC and more]() - [KVM VPS and root access: control, isolation and limits]() - [Compare a VPS alternative to Njalla]() - [Evaluate the evidence behind retention claims]() - [Catalogue facts]() ### Official references - [Njalla: official VPS specifications]() - [1984 Hosting: official VPS specifications]() - [Kyun: official hosting website]() ## A different shape for your private server. [Njalla VPS alternative: compare requirements]() Compare SilentVPS Veil with Njalla’s published entry server: resources, location choices and billing cycle. Match the product to the workload rather than comparing currency symbols alone. A useful Njalla alternative comparison checks server resources, payment options, account requirements, location and service policies together. SilentVPS presents a planned catalogue, not an established operating record. Consult Njalla's current official specifications and FAQ instead of assuming every privacy-focused host works alike. ### The entry configurations #### SilentVPS Veil Planned $13/month or $109.20/year: 1 vCPU, 2 GB RAM, 30 GB NVMe, 2 TB monthly transfer. Pseudonymous username and password, with email optional. #### Njalla VPS 15 Officially listed at €15/month: 1 core, 1.5 GB RAM, 15 GB disk and 1.5 TB transfer. Its server page places the machines in Sweden. #### Virtualization and mail Njalla describes INCUS with a CEPH backend and blocks outgoing SMTP. SilentVPS targets KVM; live SMTP and mail allocation will require confirmation. #### Currencies USD and EUR are distinct. Exchange rates, tax and the final invoice can affect the amount you actually pay. ### Where the planned SilentVPS catalogue differs Veil adds disk and memory compared with the listed Njalla entry configuration. All four SilentVPS tiers preserve optional email and a choice among eight payment methods across seven assets. Annual billing reduces the twelve-month plan total by 30%. The location list includes Finland and Iceland, but not Sweden. Fourteen physical cities plus Auto offer regional flexibility. The live network, recovery and provisioning capabilities still need validation before a real migration. ### Migrate with a tested rollback Export application data and configurations, verify backups, provision a separate machine and test before changing DNS or cutting over a private endpoint. Preserve credentials and encryption keys securely. Keep the old service until the new path is verified. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### Does SilentVPS list Sweden? No. The northern European choices are Helsinki and Reykjavík. #### Are these directly equivalent prices? No. One is displayed in USD and the other in EUR, with different resources and platform models. #### Which payment methods does SilentVPS support? Checkout offers BTC, ETH, SOL, LTC, native TRX on Tron, USDT on Tron or Ethereum, and USDC on Ethereum. Follow the asset, network, amount and expiry displayed on your invoice. Payment verification and server provisioning are separate steps. ### Find the guide for your next decision - [Compare SilentVPS resource configurations]() - [Privacy features]() - [Contact SilentVPS]() - [Use the broader provider comparison checklist]() - [Understand the planned account and payment model]() ### Official references - [Njalla: official VPS specifications]() - [Njalla: payment and signup FAQ]() ## Put your project closer to Asia. [Hong Kong VPS with crypto: region and routing]() Select Hong Kong from the planned location catalogue, with the same four configurations, optional email and cryptocurrency choices. Kuala Lumpur is another listed Asia-Pacific option. Hong Kong is a planned SilentVPS region for projects considering an Asia-Pacific location. A city label does not guarantee low latency or a legal privacy outcome. Test routing to your audience and confirm actual availability, infrastructure and policies before moving a service. ### Choose a region for your audience Hong Kong is a common location for projects serving East and Southeast Asia. The actual route to China, Taiwan, Japan, Korea or Singapore depends on network peering and your audience’s providers; test it before assuming a latency advantage. Location does not by itself guarantee a legal privacy outcome. SilentVPS has not published its operator identity, contract jurisdiction or legal policies yet; those will be added using the owner’s information. ### A common configuration baseline #### Resources Full root, KVM, NVMe, IPv4 and IPv6 in the target specifications. #### Payment choices Checkout supports BTC, ETH, SOL, LTC, native TRX on Tron, USDT TRC-20 or ERC-20, and USDC ERC-20. Select the exact asset and network shown on the invoice. #### Account Username and password, with email optional and a separate order token. #### Billing Same plan price across the listed locations; 30% off the twelve-month total on annual billing. ### Other regional choices Kuala Lumpur is the other Asia-Pacific city in the catalogue. For a wider geographic spread, compare Panama City, Victoria in the Seychelles, Willemstad in Curaçao and the listed European locations. Keep failover and backups independent of a single server. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### Does Hong Kong cost more? The planned catalogue uses the same four plan prices across all listed locations. #### Can I use USDT? USDT checkout supports Tron using TRC-20 and Ethereum using ERC-20 as separate methods. Use only the exact asset and network shown on the invoice; a listed server region does not change the payment network. #### What is the other Asia-Pacific location? Kuala Lumpur, Malaysia is the other Asia-Pacific city listed in the planned catalogue. ### Find the guide for your next decision - [Review the four planned VPS configurations]() - [Privacy features]() - [Contact SilentVPS]() - [Compare location and jurisdiction considerations]() - [Assess your application's resource needs]() ## A small server. A clear budget. [Affordable anonymous VPS: choose the right resources]() Veil starts at $13 monthly, or $109.20 for a year — equivalent to $9.10 per month when paid annually. It provides 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB of monthly transfer. The smallest planned SilentVPS configuration costs $13 per month, with 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. Annual billing totals $109.20. Choose capacity around the application and its backups rather than price alone. ### Understand the annual amount #### Veil $13 monthly · $109.20 billed yearly · $9.10/month equivalent. #### Shade $33 monthly · $277.20 billed yearly · $23.10/month equivalent. #### Eclipse $63 monthly · $529.20 billed yearly · $44.10/month equivalent. #### Obsidian $118 monthly · $991.20 billed yearly · $82.60/month equivalent. ### Choose by workload, not the lowest number A personal vault, light site, WireGuard tunnel or modest relay can be a reasonable small-server workload. Larger file collections, databases and several services may need the memory, disk and transfer of another tier. The annual equivalent is not a monthly installment. The full annual amount is paid for that cycle. Start with a shorter cycle when you need to validate a workload; choose annual only after considering the commitment and the final operator terms. ### The privacy model does not depend on size The target entry tier keeps optional email, a pseudonymous account, root access and the same location and payment choices. There is no separate identity-minimization upgrade. The live billing exchange rate and network fee will determine the cryptocurrency amount. ### Four sizes. The same privacy baseline. Monthly or annual billing, with 30% off the twelve-month total when you pay yearly. Prices are in USD; cryptocurrency amounts depend on the invoice exchange rate. Full root, KVM virtualization, NVMe, IPv4 and IPv6 are part of the target specification for every tier. #### Veil $13/month · $109.20/year. 1 vCPU, 2 GB RAM, 30 GB NVMe and 2 TB monthly transfer. A compact starting point for one lightweight service. #### Shade $33/month · $277.20/year. 2 vCPU, 4 GB RAM, 80 GB NVMe and 4 TB monthly transfer. More room for applications and everyday self-hosting. #### Eclipse $63/month · $529.20/year. 4 vCPU, 8 GB RAM, 160 GB NVMe and 8 TB monthly transfer. Space for a larger stack or transfer-intensive workload. #### Obsidian $118/month · $991.20/year. 8 vCPU, 16 GB RAM, 320 GB NVMe and 16 TB monthly transfer. The largest configuration for dense services and heavier compute. ### Questions, answered #### Is $9.10 a monthly invoice? No. It is the monthly equivalent of the $109.20 annual Veil amount. Monthly billing is $13. #### Is email mandatory on the cheapest plan? No. The planned account flow uses the same optional-email model for every tier. #### Can the entry plan use every listed location? Yes. The target catalogue offers the same fourteen cities and Auto selection across all four tiers, without a city-specific plan price. ### Find the guide for your next decision - [Compare all monthly and annual plan prices]() - [Privacy features]() - [Contact SilentVPS]() - [Payment options]() - [VPS sizing calculator: RAM, CPU, storage and bandwidth]() - [Match server resources to a workload]() - [Check the account and purchase process]() - [Catalogue facts]() - [VPS monthly or annual billing: compare the full cost]() ## A clear route to your private VPS. [Private VPS resources: prices, privacy and crypto checkout]() Updated 2026-10-15 Compare the catalogue, understand the account and payment model, and prepare the services you want to run. These resources help you evaluate SilentVPS through specific facts and practical hosting guides. The SilentVPS resource hub connects catalogue prices, current specifications, account privacy, crypto payment networks and practical self-hosting guides. Start with the decision you need to make, then use the factual reference and the relevant procedure. The published website does not establish production server availability. ### Compare the resources and the full billing amount Start with the applications and data you need to host. Compare vCPU, RAM, NVMe capacity and monthly transfer together, rather than choosing from a price alone. Leave room for system files, application growth and the temporary space used during backups. Monthly billing and an annual total represent different commitments. The annual amount is paid for the complete cycle; its monthly equivalent is a comparison figure, not a monthly instalment. Use the pricing page for current amounts and the facts page for catalogue specifications generated from the same configuration. ### Understand what a private account does The SilentVPS account flow uses a username and password, with email optional. It does not ask for a legal name, identity document, postal address or phone number. Save your credentials and private order reference securely, especially when you choose not to provide an email. A small account footprint is one layer of privacy. Your payment history, administration connections and the content of your applications can still reveal information. Review the anonymous VPS guide and the ongoing server-hygiene guide before deciding how to separate a project from your personal accounts. ### Select the correct crypto asset and network Checkout has eight methods across seven assets: BTC, ETH, SOL, LTC, native TRX on Tron, USDC on Ethereum, and USDT on Tron or Ethereum. The two USDT networks are distinct choices. Native TRX on Tron and USDT on Tron are different asset choices. Configure the server first, choose the payment method, then inspect the dedicated invoice's network, destination, amount and expiry. The payment guide explains those steps and the status updates. Automatic transaction detection and server activation are not connected yet; creating a quote does not prove that a VPS is running. ### Prepare the service you will administer Private self-hosting can include a password vault, file service, personal website or a controlled network endpoint. Each application needs access controls, updates and an independent recovery plan. The target catalogue is a starting specification; production capacity and region availability still require validation. #### Files and personal services Use the self-hosting guide to identify storage, access and backup requirements before migrating important data. #### WireGuard and private access Review routing, key ownership and surrounding logs when planning a personal VPN or a restricted administration path. #### Administration through Tor Follow the server-operation guides to consider connection privacy, project identities and metadata without assuming a server alone provides anonymity. ### Questions, answered #### Where can I find the current VPS prices? Use the pricing page for monthly and full annual amounts. The catalogue facts page shows the same configured resources and billing values. An annual monthly equivalent is a comparison, not a monthly charge. #### Is email required for a SilentVPS account? Email is optional in the account flow. A username and password are required. Store your credentials and private order reference securely. #### Can I pay USDT on any network? No. The configured methods are USDT on Tron using TRC-20 and USDT on Ethereum using ERC-20. Select the exact network and follow the invoice; another chain is not interchangeable. #### Does this resource hub prove production availability? No. It explains the current public website and target catalogue. Production infrastructure, automatic blockchain detection and server provisioning still need to be connected and validated. ### Find the guide for your next decision - [Current VPS prices and resources]() - [Choose monthly or annual billing](): Compare the full cost for your expected period and read the commitment and refund conditions. - [Configured catalogue facts]() - [Account privacy and its limits]() - [Understand privacy and stored data](): Separate signup identity, payment history, sessions, server logs and application records. - [Compare crypto payment networks](): Distinguish assets and networks, including USDT on Tron and Ethereum, before opening an invoice. - [Plan your self-hosted services](): Consider personal files, mail, password vaults, updates and independent backups. - [Actual purchase and payment steps]() - [Prepare a personal WireGuard endpoint](): Understand private routing, key management and the logs created around the VPN. - [Keep a private server separate](): Review administration connections, project identities, metadata, renewals and encrypted backups. - [VPS sizing calculator: RAM, CPU, storage and bandwidth](): Enter your resource requirements to compare the four SilentVPS catalogue plans. Convert a monthly transfer allowance into an average data rate, and understand what the result can and cannot tell you. - [VPS crypto payment networks: TRX, USDT, BTC and more](): Check whether an asset and blockchain pair appears in the SilentVPS checkout configuration. Native TRX and USDT on Tron are separate assets, even when the destination account can receive both. - [KVM VPS and root access: control, isolation and limits](): Understand what a KVM virtual machine and Linux root access let you manage, which controls remain with the provider, and what to verify before choosing a private VPS. - [VPS migration checklist: backups, DNS, TLS and rollback](): A practical migration sequence for a self-hosted application: inventory, consistent backups, a tested destination, controlled writes, DNS cutover and a restore path. ## The details, with their status attached. [SilentVPS facts: plans, payments and service status]() Updated 2026-10-09 A concise reference for the SilentVPS catalogue, configured payment methods and features awaiting production validation. This page describes the published website; it is not evidence of a live server fleet or measured uptime. The current plan table below is generated from the same configuration used by the website. Compare vCPU, RAM, NVMe storage, monthly transfer, monthly price and full annual total before choosing a tier. Prices are in USD. The annual amount is paid for the full cycle; its monthly equivalent is a comparison figure rather than an instalment. Annual billing is 30% below twelve payments at the listed monthly price. ### Catalogue plans and billing The current plan table below is generated from the same configuration used by the website. Compare vCPU, RAM, NVMe storage, monthly transfer, monthly price and full annual total before choosing a tier. Prices are in USD. The annual amount is paid for the full cycle; its monthly equivalent is a comparison figure rather than an instalment. Annual billing is 30% below twelve payments at the listed monthly price. ### Eight configured payment methods Seven assets appear across eight method and network combinations because USDT has two distinct choices. Follow the invoice's network exactly; matching only a ticker or an address format is insufficient. #### BTC Bitcoin mainnet, native BTC. #### ETH Ethereum mainnet, native ETH. #### SOL Solana mainnet, native SOL. #### USDT on Tron Tron mainnet, TRC-20 USDT. Native TRX is a different asset. #### USDC on Ethereum Ethereum mainnet, ERC-20 USDC. #### USDT on Ethereum Ethereum mainnet, ERC-20 USDT. This is separate from the Tron option. #### LTC Litecoin mainnet, native LTC. #### TRX Tron mainnet, native TRX. This is separate from USDT on Tron / TRC-20. ### Configured website features The website has username-and-password accounts, optional email, saved server configurations, monthly and annual totals, and a private order reference. The payment flow uses a separate method-selection page and invoice page with an exact amount, destination, quote expiry and backend-driven status updates. An invoice can contain a real configured wallet destination. Creating a quote, opening a wallet or seeing a waiting animation does not prove that a transaction was received. Automatic blockchain detection and server activation are not connected yet. ### Planned features require separate validation KVM, full root, IPv4/IPv6, operating-system images and fourteen listed regions plus Auto describe the target infrastructure catalogue. Production capacity and availability have not been verified. Publication of the website does not establish measured uptime, a recovery guarantee, an independent audit or a customer endorsement. Published policies and operational evidence must be checked against the deployed service. ### Use the source that answers the question Use pricing for the current commercial amounts, the dedicated invoice for an exact crypto payment, and the relevant guide for architecture and operational decisions. Public reference pages should never contain private order tokens, account sessions or customer transaction records. ### The configured VPS catalogue Amounts are in USD. The annual column is the full twelve-month payment; the monthly equivalent is shown only for comparison. Resources describe the catalogue, not verified live server capacity. | Plan | vCPU | RAM (GB) | NVMe (GB) | Transfer (TB) | Monthly payment (USD) | Annual total (USD) | Monthly equivalent (USD) | | --- | --- | --- | --- | --- | --- | --- | --- | | Veil | 1 | 2 | 30 | 2 | 13.00 | 109.20 | 9.10 | | Shade | 2 | 4 | 80 | 4 | 33.00 | 277.20 | 23.10 | | Eclipse | 4 | 8 | 160 | 8 | 63.00 | 529.20 | 44.10 | | Obsidian | 8 | 16 | 320 | 16 | 118.00 | 991.20 | 82.60 | The network is part of your choice. USDT on Tron and USDT on Ethereum are different payment methods. Exact crypto amounts and destination instructions belong to the private invoice, not this public catalogue. | Payment methods | Asset | Network | Token standard | | --- | --- | --- | --- | | BTC | BTC | Bitcoin mainnet | Native asset | | ETH | ETH | Ethereum mainnet | Native asset | | SOL | SOL | Solana mainnet | Native asset | | TRX | TRX | Tron mainnet | Native asset | | USDT | USDT | Tron mainnet | TRC-20 | | USDC | USDC | Ethereum mainnet | ERC-20 | | USDT-ERC20 | USDT | Ethereum mainnet | ERC-20 | | LTC | LTC | Litecoin mainnet | Native asset | ### Questions, answered #### How many crypto payment methods are configured? Eight methods across seven assets: BTC, ETH, SOL, LTC, native TRX on Tron, USDC on Ethereum, and USDT on both Tron and Ethereum. Match the invoice’s asset and network exactly. #### Are all listed regions live? The published website does not verify a live regional fleet. The fourteen locations and Auto mode are target catalogue choices pending production infrastructure validation. #### Does payment confirmation mean a VPS is already running? No. Payment verification and server provisioning are separate states and integrations. A paid status alone is not proof of server activation. ### Find the guide for your next decision - [Current commercial amounts]() - [Exact payment networks]() - [Actual purchase workflow]() - [Review the target feature catalogue]() - [VPS crypto payment networks: TRX, USDT, BTC and more]() - [KVM VPS and root access: control, isolation and limits]() - [VPS monthly or annual billing: compare the full cost]() - [Private VPS accounts, payments and data practices]() ## Choose the period that fits your project. [VPS monthly or annual billing: compare the full cost]() Updated 2026-10-09 Compare monthly payments with a full annual amount before choosing a VPS. Use your expected period of use, understand the crypto invoice and check the existing refund conditions. Monthly totals depend on the selected period of use at the current catalogue rate. An annual order commits the full twelve-month amount; its monthly equivalent is not an instalment. Crypto invoices fix a separate payable amount for their validity window. The comparison creates no invoice or automatic pro-rata refund entitlement. ### Start with the period you actually expect to use A server for a short experiment and one for a stable personal service have different billing needs. Decide how long you expect to need the machine and whether the workload has already been tested. A smaller upfront commitment can make sense while you are still checking the application, location and administration process. The comparison below uses current catalogue amounts. The monthly total multiplies the current monthly price by the selected number of months. The annual column remains the full twelve-month amount, even if your expected use is shorter. It assumes the listed rates for this comparison; it is not a guarantee about future renewal prices. ### Read the annual saving in context A monthly equivalent makes an annual price easier to compare, but does not mean you can pay this annual total in monthly instalments. You pay the annual total for that billing cycle. Compare both the money committed now and the expected cost over your planned period rather than reading the lower equivalent as a monthly charge. The lowest total for the horizon you entered is a price comparison, not a recommendation to accept a commitment you may not need. Resource requirements and the ability to operate the service still matter. Check CPU, memory, storage and transfer alongside the billing amount. ### Keep the catalogue amount and crypto quote separate Catalogue prices are in USD. The checkout uses a current conversion rate to fix the exact cryptocurrency amount on a time-limited invoice. Stablecoin rates are requested too; do not replace the displayed amount with an assumption that every token equals one dollar. Use the asset, network, destination and expiry shown on the invoice. A new quote after expiry can have a different crypto amount. Network fees and wallet-provider charges are separate from the recipient amount. The purchase guide explains the dedicated payment page and its status. ### Read the refund rules before deciding The published policy gives the first monthly server order a cancellation window of 7 calendar days after activation. Activation means receiving access to a usable VPS; a saved configuration or paid status does not start that period. Read the refund page for the complete eligibility and request process. Renewals, annual orders and cancellation after that window have no automatic commercial pro-rata refund under the current policy. Separate service failures and any mandatory rights are reviewed under the applicable conditions. The comparison does not decide refund eligibility or create a payment. The SilentVPS website is publicly accessible and presents a target VPS catalogue. Production availability, transaction detection and server provisioning still require validation. Consult the facts page and current ordering conditions before treating a configuration as a delivered service. ### Compare monthly and annual billing Choose the number of months you expect to need the server. Monthly totals use the current catalogue rate; the annual option charges for a full twelve-month cycle. 12 months · USD | Plan | Monthly payments over this period | Full annual payment | Annual payment compared with monthly total | | --- | --- | --- | --- | | Veil | 156.00 | 109.20 | $46.80 less | | Shade | 396.00 | 277.20 | $118.80 less | | Eclipse | 756.00 | 529.20 | $226.80 less | | Obsidian | 1416.00 | 991.20 | $424.80 less | For periods shorter than twelve months, the annual column still charges twelve months. This comparison describes catalogue amounts; it does not create an invoice or guarantee an automatic pro-rata refund. ### Questions, answered #### Is the annual monthly equivalent charged each month? No. It is the full annual amount divided by twelve for comparison. The annual total is paid for the whole yearly cycle. #### What does the monthly comparison assume? It multiplies the current catalogue monthly rate by your selected months of use. It does not predict future price changes or create an invoice. #### Does shorter use of an annual plan create an automatic refund? No automatic commercial pro-rata refund is promised for annual orders. Read the published refund conditions for applicable eligibility and review. ### Find the guide for your next decision - [Current catalogue amounts]() - [Catalogue and service status]() - [Crypto quote and payment steps]() - [VPS sizing calculator: RAM, CPU, storage and bandwidth]() ## Know the records behind your private account. [Private VPS accounts, payments and data practices]() Updated 2026-10-09 Account identity, payment history, technical records and the applications you run are different privacy questions. Use this overview with the published policy to understand the current SilentVPS data practices. A pseudonymous account reduces identity fields but does not erase stored account, order or invoice records. Public cryptocurrency history, web-server logs and guest-application logs are separate layers. The current privacy policy describes sessions, security records, storage and request handling; this overview promises neither universal anonymity nor automatic erasure. ### A minimal account still has account records The registration flow asks for a username and password, with email optional. It does not request a legal name, postal address, telephone number or identity document. The application stores the username, password hash, any supplied email and account creation date. A pseudonym can separate the account from a public identity; it does not mean the account has no record. Saved configurations contain the plan, billing cycle, operating system, location, currency, date and private order reference. A supplied hostname, public SSH key or notification email may also be stored. Contact messages retain their subject, message, reference and date, with a pseudonym or email when provided. Keep private keys and wallet recovery material out of these fields. ### A private signup does not conceal the payment network An invoice records the asset and network, destination, USD value, conversion rate, payable amount, expiry and status. Verified events can add transaction identifiers, amounts received and confirmation information. Those are reconciliation records, separate from the identity fields omitted at signup. Bitcoin transactions are publicly recorded and addresses can be associated with earlier transactions. Optional email does not remove that ledger history. A wallet provider or exchange may hold other identifying records. Choose the exact supported network, follow the private invoice and avoid publishing an order token or transaction details alongside personal accounts. ### Sessions and technical protection create another layer The current website uses an essential session cookie for authentication and form security. The attempt limiter keeps a hashed value derived from the request category and connecting IP address. A hash is not an anonymity guarantee, and expiry of an attempt window does not itself prove deletion of the stored record. The published privacy page also describes the current web-server access and error logs. Requested URLs, connecting IP addresses and other technical request data can appear there. An order reference in a URL may therefore enter a log. The website has no advertising pixels or third-party analytics scripts; that does not remove essential application or server records. ### Your VPS and applications need their own review Application and session records are kept outside the public web directory. Passwords are hashed. The current application does not define automatic deletion periods for accounts, orders, messages or payment records. Invoice validity is not a retention schedule. Consult the privacy policy for the complete scope and request process rather than assuming immediate erasure. The software you later install may create authentication, access, database or diagnostic logs inside the VPS. Review its settings, access controls and backups separately from the hosting account. Production infrastructure logging must also be validated; the catalogue does not establish a verified no-logs fleet. Use the published privacy page for questions, correction and deletion requests. It identifies the official contact and explains that the contact form currently saves a message without sending an email notification. This overview does not replace that policy or promise universal anonymity. ### Questions, answered #### Are optional email and no logs the same thing? No. Optional email concerns one account field. Session, order, payment, web-server and guest-application records are separate questions with their own purposes and retention. #### Does a quote expiry delete the invoice? No. A validity window is not a deletion period. The current application has no general automatic deletion schedule for the stored account, order, message or payment records. #### Where should I ask about my records? Use the official contact and request process described on the privacy page. Identify the relevant account or order privately and never supply passwords, private SSH keys or wallet recovery phrases. ### Find the guide for your next decision - [Logging boundaries and retention]() - [Account privacy model]() - [Crypto assets and payment networks]() - [Current catalogue and service status]() ### Official references - [Bitcoin.org: privacy and transaction traceability]() ## Find a configuration that fits your numbers. [VPS sizing calculator: RAM, CPU, storage and bandwidth]() Updated 2026-10-15 Enter your resource requirements to compare the four SilentVPS catalogue plans. Convert a monthly transfer allowance into an average data rate, and understand what the result can and cannot tell you. The VPS sizing tool compares your entered vCPU, RAM, storage and transfer requirements with the four configured SilentVPS plans. Its bandwidth converter calculates an average rate from a decimal transfer allowance and duration; neither result measures performance or live availability. ### Start with measurements, then leave room A useful VPS estimate starts with the application you intend to run, its working set and its busiest periods. Measure memory and disk use on an existing installation where possible. Include the operating system, database, background jobs, container overhead, uploads and local backup space in your requirements. The tool compares your entered minimums with published catalogue resources. It does not predict visitor counts, requests per second, CPU generation, storage latency or live server availability. Add headroom yourself rather than treating the smallest matching plan as a performance guarantee. ### Read memory and disk figures carefully An application using little memory while idle may behave differently during imports, upgrades, indexing or concurrent requests. Watch a representative busy period. File-system space must also cover logs, updates and temporary restore files, not just the current size of your application. If you already use Docker, its statistics command provides container memory, CPU and network counters. Container counters do not replace host-level measurements, and Linux cache accounting differs between Docker CLI output and its API. Record the units shown by each tool before comparing them. ``` docker stats --no-stream free -h df -h ``` ### Transfer allowance and port speed answer different questions A monthly transfer allowance measures an amount of data. A port rate measures how quickly data may move at a point in time. A large port rate does not mean unlimited monthly transfer, and an average rate calculated from a quota does not describe the speed available during a short download. The conversion below uses decimal units: one TB is one trillion bytes and one Mbit/s is one million bits per second. It spreads the allowance evenly over the selected number of days. Protocol overhead, peaks, provider counting rules and the direction of chargeable traffic are outside this calculation. Confirm those terms with the operator. ### Use a short workload worksheet #### Memory Enter a minimum that includes the application, operating system and your chosen headroom. Compare GB and GiB consistently; their numeric values are not interchangeable. #### CPU Enter the number of virtual CPUs required by your workload. A vCPU count alone does not specify a physical core, dedicated CPU time or a benchmark result. #### Storage Allow for application data, updates and a temporary restore. Keep an independent backup outside the same virtual machine. #### Transfer Include normal use and infrequent large transfers such as migrations or backups. Verify whether incoming traffic, outgoing traffic or both count toward the allowance. ### A catalogue match is a starting point If no plan meets all of your numbers, reduce a requirement only when your measurements justify it. Otherwise ask about a different configuration. Choosing a matching row does not reserve a server or confirm a region, network policy or provisioning time. Once the resources fit, compare the monthly and annual commitment separately. The billing calculator uses the configured prices and makes the upfront annual total explicit. ### Questions, answered #### Does the calculator estimate how many visitors a VPS can handle? No. Application code, caching, request cost, database queries and traffic patterns determine capacity. The calculator checks the resource thresholds you provide, not an unmeasured number of visitors. #### Is the transfer conversion a speed test? No. It is arithmetic over an allowance and a number of days. It does not measure a network connection or promise a port speed. #### What happens when none of the plans matches? The tool reports that no catalogue configuration satisfies every entered threshold. It does not silently relax your requirements or invent a larger plan. ### Find the guide for your next decision - [Compare the catalogue plans]() - [Compare monthly and annual billing]() - [Understand KVM and guest root access]() - [Plan a tested migration]() ### Official references - [Docker container statistics]() ## The ticker is only half of a crypto payment. [VPS crypto payment networks: TRX, USDT, BTC and more]() Updated 2026-10-15 Check whether an asset and blockchain pair appears in the SilentVPS checkout configuration. Native TRX and USDT on Tron are separate assets, even when the destination account can receive both. The network checker compares an asset and blockchain with the configured SilentVPS checkout methods. Native TRX, USDT on Tron and USDT on Ethereum are distinct choices. Only a current order invoice provides payment instructions; the checker does not accept or convert funds. ### Use the invoice as the payment instruction This reference checker reads the same configured payment-method list used by the website. It is not an invoice, exchange, deposit service or confirmation that payment monitoring is connected. Open your own order and verify its asset, network, amount and expiry before authorizing a transfer. The same ticker may exist on several blockchains. A wallet or exchange can offer networks that are not configured for this checkout. Choose the exact pair shown by the invoice, rather than picking a familiar address shape or the cheapest withdrawal option. ### Native TRX is not a TRC-20 token TRX is the native asset of Tron. USDT on Tron is a token using the TRC-20 standard. An account can interact with both, but transferring one does not pay an invoice denominated in the other. The destination address alone cannot determine which asset an invoice requests. Likewise, USDT on Ethereum and USDT on Tron refer to different network paths. The checker treats them as separate configured methods. It does not accept a different chain merely because that chain also uses the USDT name. ### Read the result as a compatibility check #### Configured pair The asset and network are present in the website configuration. Still verify the current order and the operator service status before sending funds. #### Pair not configured The selected combination is not listed for this checkout. Do not use that combination for a different-network invoice. #### No automatic network conversion A compatibility result does not bridge, swap, convert or route funds. Any required conversion is separate from the hosting checkout. #### Public transaction history These configured payment networks have public ledgers. An optional-email account does not hide transaction history or guarantee anonymity. ### Check the sending wallet as well Confirm the wallet or exchange withdrawal network, the received asset and the final amount expected at the destination. A withdrawal fee can change what arrives. A transaction reference belongs to a particular chain; a reference from another network cannot establish payment of the invoice. A QR code is a convenient way to transfer payment details, but wallet support for network and token information varies. Read the human-visible invoice fields and inspect the wallet confirmation screen before signing. ### Keep the order reference and evidence together Keep your private order reference, selected payment method and transaction reference securely. A transaction appearing in a block explorer does not by itself prove that an order has been credited or that a server has been provisioned. Consult the checkout guide and current service facts for the distinction. If an asset or network is uncertain, resolve that question before transferring. Do not repeat a transfer simply because the order display has not updated immediately. ### Questions, answered #### Can TRX pay an invoice for USDT on Tron? No. A native TRX transfer and a USDT token transfer are different assets. Use the exact asset requested by the invoice, even when both can use the same Tron account address. #### Does a configured pair mean that a server is available? No. It records the website payment configuration. Infrastructure availability, transaction detection and provisioning require separate operator verification. #### Does this checker receive or store my wallet address? No. It accepts only an asset choice and a network choice. It does not request a wallet address, transaction hash, private key or seed phrase. ### Find the guide for your next decision - [Read the checkout workflow]() - [Check the catalogue and service status]() - [Protect your wallet before paying]() - [Compare crypto payment choices]() ### Official references - [Tron accounts and keys]() - [Tron TRC-20 standard]() ## Root controls the guest. The provider controls the host. [KVM VPS and root access: control, isolation and limits]() Updated 2026-10-15 Understand what a KVM virtual machine and Linux root access let you manage, which controls remain with the provider, and what to verify before choosing a private VPS. KVM supplies virtual-machine isolation, while guest root lets an administrator manage the guest operating system. Neither term guarantees dedicated resources, secrecy from the host administrator or live server capacity. Verify the operating-system image, network limits, recovery and operator evidence. ### What KVM describes KVM is Linux virtualization technology used to run virtual machines with their own virtualized hardware. A guest can run its own operating-system kernel, whereas an OS-level container shares the host kernel. Storage, network interfaces and other devices are presented to that guest through the virtualization stack. The word KVM does not specify the physical CPU model, contention ratio, backup policy, network limits or operator trust model. Those are separate service facts to verify. The SilentVPS catalogue describes target KVM configurations; that description is not evidence of live regional capacity. ### What root inside a Linux guest normally permits #### Software and services Install packages, configure supported services and maintain the guest operating system. Check image support and the provider acceptable-use policy before relying on a workload. #### Guest access Manage user accounts, SSH public keys and local permissions. Keep a second tested access path while changing authentication settings. #### Guest networking Configure the guest firewall, listening services and application encryption. Provider routing, port filtering and the assigned network remain outside guest control. #### Guest data Manage file ownership, application secrets, database backups and encryption inside the VM. An independent restore test is still necessary. ### What root does not grant Guest root is not administrator access to the physical host or hypervisor. It does not change the provider account system, upstream network, physical storage policy or hypervisor configuration. A vCPU or NVMe label does not establish a dedicated resource or a particular performance result. Virtualization is also not a promise of secrecy from the host administrator. Evaluate encryption, access controls, backups and the operator relationship according to your threat model. A minimal registration form and a private guest setup address different parts of that model. ### Verify the service before depending on it #### Image and console Confirm the intended operating-system image and an available recovery or console procedure. Do not lock out SSH before testing replacement access. #### Resources and limits Check memory, virtual CPUs, usable disk, transfer accounting and any restrictions on sustained use. Ask which values are guaranteed and which are catalogue targets. #### Network and location Confirm the actual location, IPv4/IPv6 assignment and relevant port policy. A location option on a form does not prove present inventory. #### Recovery and retention Establish who maintains backups, where they are kept, how restoration is tested and what operational records are retained. ### Match the configuration to the workload An isolated personal VPN, a password vault, a database and a bulk file transfer have different bottlenecks. Use measured resource needs and recovery requirements instead of buying only by the word private or the number of virtual CPUs. The sizing calculator compares your minimums to the configured plans. The catalogue facts page separates configured specifications from operational evidence, while the privacy guide explains account data and guest-traffic boundaries. ### Questions, answered #### Does full root access mean access to the hypervisor? No. It refers to administrative access within the guest operating system. The physical host and hypervisor remain under the provider control. #### Does KVM prove that resources are dedicated? No. Virtualization technology and resource allocation policy are separate facts. Confirm CPU allocation, contention and storage performance terms with the operator. #### Can a VPS provider see everything protected by guest encryption? There is no universal guarantee. Encryption protects particular data in particular states, while a host administrator has a different position from a network observer. Evaluate the specific setup and its limitations. ### Find the guide for your next decision - [Compare your resource requirements]() - [Read the platform feature overview]() - [Separate account and guest data]() - [Prepare recovery before migration]() ### Official references - [KVM project overview]() - [libvirt domain configuration]() - [QEMU system security]() ## VPS migration checklist: backups, DNS, TLS and rollback [VPS migration checklist: backups, DNS, TLS and rollback]() Updated 2026-10-15 A practical migration sequence for a self-hosted application: inventory, consistent backups, a tested destination, controlled writes, DNS cutover and a restore path. A controlled VPS migration inventories services and data, creates a consistent backup, verifies a restored destination, tests hostname and TLS routing, coordinates final writes and DNS, and preserves a data-aware rollback. No checklist alone guarantees zero downtime. ### Inventory the application before moving it List the services, versions, ports, scheduled tasks, databases, uploaded files and configuration needed for the application to work. Identify where writes happen and which external services it depends on. A copied web directory is not a complete migration when the data lives elsewhere. Record current DNS names, active IPv4 and IPv6 records, certificate renewal methods and a recovery access path. Keep secrets in your private deployment tooling. Do not put passwords, private keys or database dumps into a public document root or a shared migration checklist. ### Create a consistent backup and prove that it restores Use the database-supported backup mechanism rather than copying arbitrary files while writes continue. For SQLite, the Online Backup API creates a consistent database snapshot. In WAL mode, the WAL file participates in persistent database state, so copying only the main database file can omit committed changes. A consistent database backup is not automatically consistent with separately stored uploads, queues or files. Coordinate their capture with your application. Restore into a separate test location and verify records, file references and application behavior before treating the backup as usable. ### Prepare the destination before changing DNS Create the intended users, permissions, runtime versions, services and application directories on the new server. Restore the test backup into its destination data location, outside the public web root where appropriate. Check ownership and access using the service account that will actually run the application. Preserve unrelated sites on a shared server. Use a dedicated document root, virtual host and runtime, validate the web-server configuration and prepare a rollback that restores only the files and configuration owned by this change. ### Test the real hostname and certificate on the new server A browser request to a bare IP address does not reproduce hostname-based routing or certificate validation. curl --resolve lets a test use the intended hostname and a chosen destination IP while retaining the normal hostname and TLS checks. Check the HTTP status and expected application content as well. The example uses documentation-only values; replace them with your own verified domain and destination. A valid certificate and an allowed network path must already exist for that test to pass. Never disable certificate verification to call the migration ready. DNS-based ACME validation can validate a domain without changing its web-server address; HTTP-based validation has different reachability requirements. Test renewal separately from initial issuance. ``` curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/ ``` ### Choose a write-control and final-sync plan Schedule a short maintenance period or another application-appropriate consistency mechanism. Stop or redirect the writers you identified, take the final consistent database backup, synchronize the corresponding mutable files and verify the result. Queue workers, webhooks and cron tasks can write even when the public interface looks quiet. Use a dry run before a file synchronization. Do not add deletion flags or copy entire system directories as a shortcut. Keep the old service recoverable until you have checked the new application and established which location is authoritative for writes. ### Change DNS, then observe both address families Update the records required for the service and account for existing resolver caches. Check the authoritative answers and several normal client paths. If an obsolete AAAA record remains active, IPv6 clients can continue reaching the old server while IPv4 clients reach the new one. Test sign-in, reads, writes, uploads, background jobs and external callbacks on the new service. Avoid running two independent writable copies of the same application during the transition. Keep a clear rule for handling traffic that still reaches the old destination. ### Make rollback a data decision as well as a DNS decision Define the failure conditions that trigger a rollback and who controls the cutover. Reverting DNS alone is not enough after new writes have reached the destination: you must preserve or reconcile that data before returning to an older copy. Keep the source and backups for an appropriate recovery period. Remove old access and decommission resources only after the destination, backups, renewal and monitoring have been checked. Retention and deletion should follow the actual service policy, not a generic fixed number of hours. ### Questions, answered #### Can I copy a live SQLite database file directly? Do not assume that copying one file from a live database produces a complete, consistent backup. Use a supported backup method and account for WAL state. Coordinate files stored outside the database as well. #### Does changing a DNS record move my application data? No. DNS directs future name resolution toward an address. Application files, databases, secrets and background services require a separate migration and verification process. #### Can I promise zero downtime with this checklist? No. Downtime and consistency depend on the application, traffic, data and cutover method. The checklist helps you prepare and test a controlled move; it is not a zero-downtime guarantee. ### Find the guide for your next decision - [Size the destination from measured needs]() - [Understand guest and host control]() - [Plan your self-hosted workload]() - [Explore the VPS resources]() ### Official references - [SQLite Online Backup API]() - [SQLite write-ahead logging]() - [curl manual: hostname resolution overrides]() - [ACME challenge types]() - [rsync manual]() ## Pay for a VPS with crypto: an invoice checklist [Pay for a VPS with crypto: an invoice checklist]() Updated 2026-10-09 Prepare your wallet, select the exact payment network, check the invoice and protect your order reference after sending. A hosting purchase creates several kinds of records: the network connection, the account, the payment and whatever you deploy afterward. A pseudonymous account does not erase the payment trail or a personal email on an order. Treat the purchase as one workflow, with a separate decision for each kind of information. ### Privacy starts before the invoice A hosting purchase creates several kinds of records: the network connection, the account, the payment and whatever you deploy afterward. A pseudonymous account does not erase the payment trail or a personal email on an order. Treat the purchase as one workflow, with a separate decision for each kind of information. First decide what you need to protect and from whom. Keeping a hobby project separate from a public identity has different requirements from protecting a sensitive source. Choose habits that address the specific risk and keep expectations realistic: no checkout label guarantees anonymity. ### Understand the public payment record The supported payment networks publish transaction information. A wallet address may be pseudonymous, but transfers can become associated with a person through an exchange account or a public address. A separate hosting username does not make the ledger private. Consider what you already disclose when obtaining funds and publishing wallet information. Network privacy and an optional email field solve different problems from transaction visibility. Keep those limits in mind before deciding whether a crypto payment fits your project. ### Prepare the wallet and network fees SilentVPS offers eight payment methods: BTC on Bitcoin, ETH on Ethereum, SOL on Solana, LTC on Litecoin, native TRX on Tron, USDT on Tron, USDC on Ethereum, and USDT on Ethereum. The asset and network form one choice. A token supported on one chain is not automatically supported on another. Check that your wallet can send the chosen asset on that exact network. Keep enough funds for the invoice and the network fee. For tokens, check the native asset used for fees and your wallet's current fee estimate. A withdrawal service may deduct fees from the amount received or impose a processing delay; inspect those conditions before using a short-lived invoice. - Match both the currency and network to the invoice. - Check the amount the recipient will receive after any withdrawal fee. - Keep your recovery phrase and private keys out of the checkout page. ### Separate browsing and account identities Use Tor Browser for the complete order session when hiding your source IP is part of your threat model. Avoid adding extensions or mixing personal account logins into that session. If a provider publishes an onion service, verify its address through a trusted official channel before using it. Choose a fresh pseudonym and unique password. Leave optional email fields empty when practical; otherwise use a dedicated mailbox or alias that does not identify you. Plan how you will check notifications and retain access before deciding to omit email. Store the account credentials and private order reference securely. ### Configure the server, then inspect the quote Compare CPU, RAM, NVMe storage and transfer allowance against the workload. Check the operating system, selected region and billing cycle. A yearly per-month equivalent is a comparison amount; the invoice charges the full annual cycle. On the payment-method page, confirm your selection to open the separate invoice. Inspect the order, USD billing total, asset, network, destination, exact crypto amount and expiry. The quote applies for its displayed window. It does not protect the value of funds you hold before or after that window. ### Review the transfer and send once Copy the destination from the current invoice and verify the complete address in your wallet's confirmation screen. Check the asset, network and recipient amount there too. A QR code or wallet link helps enter details, but your wallet's final review is still necessary. Never authorise a transfer using only an old screenshot. Keep the transaction identifier and follow the order status after sending. Network inclusion, payment verification and server activation are separate steps. A slow update is not a reason to send the amount again. If the quote expires after a possible transfer, request a review of that transfer before opening and paying another invoice. ### Protect the order after payment Store the private order reference, invoice and account credentials in encrypted storage. A reference that grants access to an order deserves the same care as a password. Share only the identifiers needed for support; never send your wallet recovery material. Continue the same privacy plan when managing the VPS. Use a dedicated SSH key, protect the management path and review identifying application accounts before deployment. Renewal payments, backups and support messages can create new links if their handling differs from the original purchase. - Keep private tokens out of public screenshots and shared notes. - Read the refund policy before ordering. - Use the checkout guide for payment states and expired invoices. ### Find the guide for your next decision - [Protect your crypto wallet before paying for hosting]() - [Review the eight checkout methods]() - [Buy a VPS privately: from browsing to first login]() - [Plan your first protected server login]() - [VPS crypto payment networks: TRX, USDT, BTC and more]() - [Understand the SilentVPS account model]() ### Official references - [Bitcoin: transaction privacy and traceability]() - [Ethereum: wallet security and transaction review]() ## An anonymous VPS purchase, from browsing to first login [Buy a VPS privately: from browsing to first login]() Updated 2026-10-04 Check the network, signup fields, mailbox and payment method before ordering a server without unnecessary identity data. A private VPS purchase connects several layers: network access, signup, email, payment and server administration. Decide which observers matter, then keep your choices consistent across those layers. A pseudonymous account or cryptocurrency payment alone does not protect an identifying application or compromised device. ### Define the boundary you want to protect An anonymous purchase depends on more than a checkout label. Think about which organisations can observe the order: your connection provider, the hosting platform, a mail service, a payment intermediary and any services you connect afterward. A link created at one stage can undermine the care taken at another. Write down the outcome you need. You may want separation between your public identity and a personal project, or stronger protection against a specific observer. That choice determines how much isolation is useful. A realistic plan is easier to maintain than a collection of precautions that cannot survive routine administration. ### Keep your access path consistent Your source IP can appear in web infrastructure, fraud screening and server authentication records. If you need to avoid exposing your home connection to those systems, conduct the entire purchase in Tor Browser, including plan selection, status checks and any support interaction. Verify a published onion address before trusting it. A VPN changes who sees your connection; its operator may still know your identity and destination. Tor distributes that trust differently but does not defeat every observer or timing analysis. Neither tool sanitises the text you type, personal account logins or an infected device. ### Inspect the signup instead of trusting a badge Before creating an account, check every required field. A provider can advertise privacy while still collecting a name, phone number and address through its billing system. Prefer an account model whose information requirements match your needs, and check whether an identity check can be introduced after payment. Choose a fresh pseudonym and a unique password. An order token may allow you to track delivery or contact support without a descriptive profile, but it is also a credential that requires careful storage. Read how account recovery, renewal and service notifications work before you commit. ### Decide whether an email address is necessary An address used for banking, work or social accounts can directly reconnect a pseudonymous order to your everyday identity. If email is optional and you can reliably check status yourself, leaving it out reduces that information. If messages are useful, choose a dedicated mailbox or alias. An alias is not automatically anonymous: forwarding destinations, recovery numbers, reused usernames and the mailbox provider's own logs may create links. Create and access the project mailbox through the same protected workflow, then keep its credentials available for future renewal notices. - Use a separate address for the project rather than a personal inbox. - Check the mailbox's own signup and recovery requirements. - Keep order records in encrypted storage instead of relying solely on email. ### Check the payment trail and the operator Cards and bank-linked services retain payer information. The supported cryptocurrency networks retain public transaction records that may become associated with exchange accounts or other identifying information. A pseudonymous hosting account does not erase that record. Review the wallet, exact payment network and merchant records separately, and keep recovery material private. Where an operator is based, who runs its infrastructure and what information it retains are relevant questions. Read documented retention information and any available transparency reports. A canary can be an additional signal, but cannot prove the absence of orders or monitoring. Vague promises about unlimited protection deserve scrutiny. Before sending a payment, compare the invoice with the wallet screen: the asset, network, destination, amount, expiry and any required transfer fee must agree. Native TRX and USDT on Tron are different assets even when they use the same network; an address alone cannot establish which one the invoice expects. Stop if the wallet network or token does not match, and check the payment-network guide before transferring. A catalogue match is not a live invoice or confirmation that a VPS has been provisioned. ### Carry the same separation into operation Prepare a dedicated SSH key before the first login. Route administration through Tor or another path suited to your threat model, then disable password authentication once you have tested key access. Make DNS handling part of the check: a proxied connection can still be undermined by a local hostname lookup. Review what you install. Personal API keys, analytics accounts, Git metadata, certificate contact details and domain registrations can identify the project owner independently of the hosting account. Plan backups and renewal payments with the same separation, so convenience does not create a new link months later. ### Review the order before deploying The useful checklist is a set of questions you can answer from the actual flow. It should cover recovery as well as privacy, since a service that collects little identifying information may have fewer ways to restore lost access. Keep a durable encrypted copy of all essential credentials. Private hosting is still ordinary infrastructure: software requires maintenance, services have operating rules and network abuse has consequences. Evaluate privacy controls as protections for legitimate use, then choose a plan that you can operate responsibly. - Have I defined which link I want to prevent? - Did the protected session cover the whole purchase? - Do required profile fields match my privacy needs? - Is the mailbox separate, or genuinely unnecessary? - Is my wallet ready without sharing its seed? - Do I understand the operator's documented data handling? - Are the order token, login and fresh SSH key stored safely? - Will management, backups and renewals follow the same plan? ### Find the guide for your next decision - [Pay for a VPS with crypto: an invoice checklist]() - [Maintain privacy after the purchase]() - [What is no-logs hosting? Audit the actual records]() - [VPS sizing calculator: RAM, CPU, storage and bandwidth]() - [VPS crypto payment networks: TRX, USDT, BTC and more]() - [VPS migration checklist: backups, DNS, TLS and rollback]() - [Understand pseudonymous VPS hosting]() ## Why SilentVPS uses crypto payments [Why SilentVPS uses crypto payments]() Updated 2026-10-09 Understand the eight payment methods, the public transaction record and how payment privacy differs from account privacy. SilentVPS combines a pseudonymous account with cryptocurrency invoices. The account uses a username and password; email is optional. The payment page separately identifies the currency, network and amount needed for the order. Choosing crypto does not turn those distinct layers into a guarantee of anonymity. ### Keep account and payment choices clear SilentVPS combines a pseudonymous account with cryptocurrency invoices. The account uses a username and password; email is optional. The payment page separately identifies the currency, network and amount needed for the order. Choosing crypto does not turn those distinct layers into a guarantee of anonymity. The aim is a checkout with clear instructions and fewer unnecessary profile fields. You still need to understand the record created by your wallet, any service used to obtain funds and the selected network. Evaluate the complete transaction rather than relying on a privacy label. ### Eight methods with explicit networks The available methods are BTC on Bitcoin, ETH on Ethereum, SOL on Solana, LTC on Litecoin, native TRX on Tron, USDT on Tron, USDC on Ethereum, and USDT on Ethereum. USDT appears twice because its Tron and Ethereum transfers require different network selections. Choose a method your wallet can actually send. The invoice applies to that selection: a different token, a different chain or a different layer-2 network for Ethereum cannot be used for the same payment. Native TRX on Tron and USDT on Tron are separate payment choices. - BTC: Bitcoin. - ETH: Ethereum. - SOL: Solana. - LTC: Litecoin. - USDT: Tron or Ethereum, as selected. - USDC: Ethereum. - TRX: native asset on Tron. ### Crypto does not remove the public record These networks have public ledgers. A pseudonymous address can acquire identifying context when it is connected to an exchange account, a public profile or another known payment. The hosting account and the transaction remain separate records with separate privacy limits. Avoid publishing wallet addresses or payment screenshots unless you intend to reveal that link. Read the wallet and network documentation before expecting privacy properties that the payment system does not provide. Tor can affect your browsing connection; it does not hide a transaction from a public ledger. ### Prices and quotes serve different purposes The plan catalogue shows USD prices. Selecting the billing cycle determines the total due; a yearly per-month comparison is not a monthly instalment. The invoice then supplies the crypto amount for the selected method and a limited validity window. Review the actual quote before paying, even if you have ordered the same plan before. Exchange rates and network fees can differ. Use the recipient amount attached to the current invoice, and separately ensure that your wallet has what it needs to pay the network fee. ### Keep control over authorisation A payment begins with a wallet action you review and authorise. An opened wallet link, a visible QR code or a running countdown is not proof that payment reached the destination. Save the transaction identifier and use the order status to understand what has been verified. If the page is slow, the quote has expired or the amount differs, stop before sending again. Preserve the order and transaction references so the existing transfer can be reviewed. Transfers do not offer a card-style reversal; any approved refund follows the published refund policy and a separate return transfer. ### Carry privacy into server operation Minimal signup data is useful only alongside careful operation. A personal domain registration, reused API credential or direct administration session can identify a project independently of the payment method. Choose a dedicated SSH key and a management path that matches your threat model. Read the data-handling and acceptable-use policies with the payment instructions. Secure the server, maintain its software and keep recovery information available. A supported crypto method answers how to pay; it does not replace the responsibilities of running a service. ### Find the guide for your next decision - [Pay for a VPS with crypto: an invoice checklist]() - [Protect your crypto wallet before paying for hosting]() - [Review the eight checkout methods]() - [Distinguish payment privacy from no-KYC signup]() - [Compare the planned cryptocurrency options]() ### Official references - [Bitcoin: transaction privacy and traceability]() - [Ethereum: wallet security and transaction review]() ## Protect your crypto wallet before paying for hosting [Protect your crypto wallet before paying for hosting]() Updated 2026-10-09 Keep recovery material private, prepare the correct network and review the destination and recipient amount before a hosting payment. A self-custody wallet leaves signing authority with whoever controls its keys. With a custodial service, the operator controls transfers and access. Understand which model you use before relying on it for an expiring invoice. ### Know who controls the wallet A self-custody wallet leaves signing authority with whoever controls its keys. With a custodial service, the operator controls transfers and access. Understand which model you use before relying on it for an expiring invoice. Read your wallet's official instructions for backups and recovery. Your hosting password, wallet password and recovery material are different credentials. Make sure you know which one restores access and which one only unlocks the installed software. ### Keep recovery material private Keep your recovery phrase and private key secret. Do not share them with support staff, through a payment page or with the sender of a message. Do not include this information in a payment screenshot or an ordinary shared note. Store a backup in the format required by your wallet and encrypt any copy accessible over a network. Keep payment records separate from wallet recovery information. An invoice reference may be useful to support; a recovery phrase is not. If someone offers to repair a hosting payment in exchange for wallet secrets, stop the interaction and use the official contact route. ### Prepare the supported network Before selecting a method, inspect your wallet's available sending networks. SilentVPS supports BTC, ETH, SOL and LTC on their respective networks, native TRX on Tron, USDT on Tron or Ethereum, and USDC on Ethereum. A familiar token name alone does not establish compatibility. Check the fee estimate and the amount that will arrive. For a token transfer, your wallet may need the chain's native asset for fees. A custodial withdrawal can have its own fee, minimum and delay. Resolve those details before confirming an invoice rather than discovering them near expiry. ### Verify what you are about to sign Use the current invoice to check the full destination address, asset, network and recipient amount in the wallet. Review the transaction before authorising it. Do not trust a matching prefix alone or a destination copied from an unsolicited message. The SilentVPS invoice provides payment instructions for a transfer. It does not need your recovery phrase or private key. An unexpected signature request or token-spending permission should be reviewed against the task before you approve anything. ### Preserve the record without exposing access After sending, save the transaction identifier with the invoice reference and follow the order status. Keep private order tokens out of public screenshots. Share only what is necessary to review a payment with the official support contact. If a payment seems delayed, inspect the wallet's transaction state and the network used. Do not send a second transfer merely because the website has not updated. Ask for a review using the existing identifiers, and keep enough context to distinguish that transfer from any future invoice. - Correct asset and network checked. - Recipient amount and network fee reviewed. - Full destination verified before authorisation. - Transaction identifier saved privately. - Recovery material never shared with the merchant. ### Find the guide for your next decision - [Prepare a hosting payment from your wallet]() - [Review the eight checkout methods]() - [Why SilentVPS uses crypto payments]() - [Separate wallet acquisition from hosting signup]() ### Official references - [Bitcoin: securing your wallet and backups]() - [Ethereum: recovery material and transaction security]() ## Assessing a no-logs hosting claim [What is no-logs hosting? Audit the actual records]() Updated 2026-10-04 Distinguish live network state, service records and retained activity logs, then ask the questions that make a privacy claim useful. A no-logs hosting claim is meaningful only when the provider defines the records concerned and any exceptions. Check account and payment data, network telemetry, host events and guest logs separately. Retention periods, deletion procedures and verification evidence are more informative than a broad slogan. ### Turn a slogan into specific questions A no-logs label is meaningful only when its scope is clear. A VPS needs network routing, a service record and operational supervision to function. Those facts do not automatically require a history of customer activity, but they make an absolute claim of handling no information unrealistic. Ask which layer the claim covers: checkout, web infrastructure, the hypervisor, network monitoring or software inside your virtual machine. Each layer may be managed by a different actor. A precise explanation of information, purpose and lifetime is more useful than a broad promise. ### Separate transient state from stored history Packets require source and destination addressing, and live connections involve temporary state. A firewall can maintain a connection table without creating a durable session history. A provider may separately enable flow logs, capture traffic or record management access. These are distinct choices and deserve distinct answers. Similarly, checking resource use is different from recording every destination a tenant reaches. Capacity metrics, outage diagnostics and abuse signals can be collected at different levels of detail. Evaluate whether the scope is proportionate and whether temporary data is later copied into long-term records. ### Orders and payments are another category A service needs enough information to assign resources, determine when a subscription expires and resolve an invoice. The resulting order record might be pseudonymous, but it still exists. Its fields, access controls and deletion schedule matter even when the host does not ask for a civil identity. A cryptocurrency payment still creates an invoice record, and the supported networks keep public transaction information. Email addresses, support messages, usernames and tokens should each be described independently rather than hidden inside a generic no-logs claim. Assess payment records separately from server activity logging. ### Distinguish the provider from your guest system The host can choose not to collect activity histories or inspect customer files as a routine practice. You still control the logs created inside your VPS: SSH authentication, web access, database activity, application errors and DNS queries. Changing the provider does not automatically configure those applications. Root access allows you to review that guest software, but it does not give you control over a physical host or hypervisor. A provider may technically access an unencrypted disk or running memory. Encryption at rest helps with some storage risks; it cannot by itself prevent an administrator controlling the underlying machine from observing a running workload. - Review web-server and reverse-proxy access logging. - Check SSH and system journal retention. - Inspect DNS query logging and analytics integrations. - Understand disk snapshots, backups and third-party monitoring. ### Ask for retention periods and deletion behaviour For each stored category, ask why it exists, who can access it and when it is removed. An order token needed for an active subscription has a different lifecycle from a diagnostic log. Short retention is useful only if backups, exports and third-party tools do not silently preserve the same information longer. Specific dates or periods make a policy assessable. Terms such as temporary, minimal or only when necessary leave open questions unless they are explained. Check how the operator handles inactive accounts, cancelled services and a request to delete optional information. ### Evaluate evidence without overstating it Read the written policy and compare it with the product page and the real signup flow. Required name or phone fields can directly contradict a no-identity message. Independent assessments or technical documentation may offer more evidence, but an audit has a scope and a date; it does not certify all future behaviour. A warrant canary is a statement that can be monitored for changes or missed updates. Even a signed one cannot prove the absence of compulsion or monitoring. Transparency reporting can add context. Neither artifact replaces an explanation of the actual data systems. - What information is collected, at which layer? - What is stored, and for how long? - Which subcontractors or external services receive it? - Do backups follow the same deletion expectations? - Can the checkout and documentation support the claims? ### Anonymity and retention solve different problems Anonymous signup concerns the information linking an account to a person. Activity minimisation concerns what happens while the service runs. A provider might avoid identity checks yet keep extensive network records, or know the account holder while retaining little activity history. Review both dimensions. Also review your own habits: direct administration, personal mailbox details and identifying application accounts can create links independent of the host's policy. A useful privacy plan combines careful acquisition, sensible logging in the guest system and evidence-based expectations about the infrastructure. ### Find the guide for your next decision - [Buy a VPS privately: from browsing to first login]() - [Review a personal VPN's record boundaries]() - [Operate a private VPS: credentials, updates, backups]() - [Read the hosting retention overview]() ## A Tor-based management path for your VPS [Manage a VPS over Tor: SSH and onion access]() Updated 2026-10-04 Use a SOCKS proxy for SSH, publish a private onion endpoint and check DNS, authentication and recovery before closing public access. Tor can change the network path used to reach a VPS, and an SSH onion endpoint can avoid a conventional public management destination. Neither approach secures the server automatically. Protect SSH keys, verify host identity, restrict access and test the configuration before relying on it. ### Protect administration as well as checkout Ordering a server through a protected browser does not protect a later SSH session automatically. A direct login can reveal your source address to the server and networks along the path. Decide how administration will work before the first connection, including emergency access if the preferred route fails. Tor can conceal the client's direct IP from the destination, but it is not a remedy for reused credentials, identifying configuration data or every traffic-correlation attack. It also adds latency. The useful objective is a consistent management path whose behaviour you understand and can check. ### Start with a working local Tor client A system Tor daemon commonly offers SOCKS on 127.0.0.1:9050, while Tor Browser commonly uses 9150. Verify your actual configuration instead of assuming either port. The application must send its connection through that proxy; opening Tor Browser does not route every program on the computer. On supported systems, torsocks wraps applications such as SSH and routes supported network calls through Tor. Test the setup with a documentation-only example address replaced by your server's real address. The following command assumes a running system Tor daemon and a dedicated administrative account. ``` torsocks ssh -i ~/.ssh/silentvps_ed25519 admin@203.0.113.45 ``` ### Make the route part of the SSH configuration For regular use, a per-host configuration reduces the chance of forgetting a wrapper. The example below uses a netcat implementation with SOCKS5 proxy support. Implementations differ, so confirm the -x and -X options in your installed version and verify whether hostname resolution is remote. IdentitiesOnly limits the keys offered to the server; pair it with a fresh key used for this project. Check and retain the server's host-key fingerprint through a trusted provisioning channel. Tor changes the network path, but SSH host authentication is still essential. ``` Host silent-admin HostName 203.0.113.45 User admin IdentityFile ~/.ssh/silentvps_ed25519 IdentitiesOnly yes ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p ``` ### Move SSH behind an onion service An onion endpoint allows administration without a publicly reachable SSH port and avoids using a Tor exit for this connection. Install and configure Tor on the server, then map an onion virtual port to the local SSH service. The example is a starting configuration; service paths and commands vary by distribution. After Tor creates the service directory, retrieve its hostname file privately and test a connection through your client proxy. Keep the onion service's identity keys private. Only after a successful independent login should you restrict SSH to localhost and remove public access. Verify that your recovery console works before making that change. ``` HiddenServiceDir /var/lib/tor/silent-admin/ HiddenServicePort 22 127.0.0.1:22 ``` ### Add client authorisation for a private endpoint Without extra authorisation, anyone who learns the onion address can reach the service and its SSH prompt. Tor v3 client authorisation adds a separate cryptographic gate: the service has the authorised client's public key and the client holds the matching private key. Follow the Tor Project's current instructions for key formats and the authorized\_clients directory. Verify that an unauthorised client cannot connect. Keep SSH key authentication as well, and plan how to revoke a lost device's authorisation without losing your own remaining access. ### Test DNS and avoid identity leakage A hostname lookup made by the local resolver can reveal your target before the connection reaches the proxy. Using the server IP for a clearnet destination avoids that particular lookup; onion names require resolution within Tor. For other hostnames, confirm the application's remote-DNS behaviour instead of relying on a generic proxy setting. The guest system may still keep authentication timestamps, usernames and journal entries. Review their retention intentionally rather than disabling every diagnostic blindly. Also inspect local hostnames, commit metadata and copied configuration for identifying details. Tor does not strip those from application traffic. - Use a dedicated key and isolated project workflow. - Verify the expected SOCKS port and remote DNS behaviour. - Keep recovery access and a second tested login before changing listeners. - Review the Tor and SSH service after updates. - Never share the onion identity keys or client authorisation secrets. ### Keep long sessions and future maintenance practical Run long administrative jobs inside tmux or screen so a connection interruption does not destroy the session. Tor circuits and network conditions can change, so keep commands repeatable and understand how to resume them. A small amount of extra latency is easier to tolerate when maintenance is planned. The same onion pattern can front a local dashboard or private Git service. Each application still needs authentication, software updates and careful configuration. Continue using the protected route for support, renewal and backups where your privacy requirements call for it; consistency matters as much as the initial setup. ### Find the guide for your next decision - [Review ongoing server privacy practices]() - [Run a Tor relay on a VPS: planning and maintenance]() - [What is no-logs hosting? Audit the actual records]() - [Understand onion service hosting]() - [Distinguish server administration from relay hosting]() ### Official references - [Tor Project: onion service setup]() - [Tor Project: onion service client authentication]() ## Keeping a privately acquired server separate [Operate a private VPS: credentials, updates, backups]() Updated 2026-10-04 Build durable habits for remote access, project identities, metadata, renewals and encrypted backups. Keeping a privately acquired server separate requires ongoing care: dedicated credentials, consistent administration paths, software updates, application configuration and tested backups. Personal accounts, domain records or tokens can create links after a careful purchase. Review those choices throughout operation, renewal and recovery. ### Make the privacy plan last beyond day one A careful server purchase is only the beginning. Later logins, software configuration, payments and backups can create identifying links that were absent from the signup. Treat privacy as an operating practice that accompanies the machine throughout its lifetime. This guide assumes you have already considered the order's identity and payment requirements. Review that stage first if necessary. Then define what must remain separate: your public identity, another project, a home network or particular accounts. The plan should address a real concern and remain workable during routine maintenance. ### Use a repeatable management route Choose a protected access path and make it the default in your SSH configuration. A Tor SOCKS route or client-authorised onion endpoint can avoid exposing a direct home IP to the destination. Check DNS behaviour and host authentication, and prepare a recovery method before restricting public SSH. Use a dedicated administrative account and SSH key. After testing key authentication, disable passwords and excessive remote privileges. Keep long tasks inside a persistent terminal session. A workflow that is reliable during an outage is less likely to be bypassed for a hurried repair. ### Review identifying data before deployment Files and application settings can expose more than the hosting account. Git author metadata, certificate contact addresses, personal API credentials, copied SSH keys and document properties can all connect a project to someone. Images may retain EXIF location information or identifying filenames. Review the data you actually need, then minimise the rest. Encrypt sensitive stored material and use TLS for services, while remembering that a VPS administrator controlling the physical host may still access running memory. Avoid assuming storage encryption or a private signup protects every possible observation. - Generate project-specific SSH keys and passwords. - Check Git author and certificate contact settings. - Remove unnecessary document and image metadata. - Keep personal browser sessions and account exports off the server. - Inspect application telemetry and third-party integrations. ### Compartmentalise without losing access Use separate project credentials, mailboxes and account names where separation matters. Avoid tying a project mailbox to a personal recovery number, forwarding address or reused handle. A dedicated browser profile, user account or virtual machine can reduce accidental mixing of sessions. Compartmentalisation also needs usable recovery. Store credentials in an encrypted manager with a deliberate backup strategy, and document which identity owns which service. Separate activities that have different risks instead of creating so many identities that you inevitably reuse them or lose track. ### Treat renewal as another sensitive operation Renewals repeat the payment and account surfaces of the original purchase. Keep the same project mailbox and protected session, and pay through the chosen wallet rather than switching to an identified account for convenience. Check dates early enough to avoid a rushed recovery or unexpected outage. Funding records and timing deserve attention, but do not rely on an arbitrary waiting period to make funds anonymous. If prepayment is available, weigh fewer payment interactions against the extra funds committed to the provider. Save each invoice reference privately without adding unnecessary identifying notes. ### Back up the service and its identity deliberately Choose what must survive a disk failure: application databases, attachments, configuration, service keys and the instructions to restore them. Create consistent database backups, encrypt archives before sending them off the machine and keep a separate copy of the encryption recovery material. The backup destination and transfer route can create their own account links. Select them according to your threat model instead of automatically using personal cloud storage. Test restoration in an isolated environment and make sure it does not unexpectedly contact identified accounts or publish the original service. ### Watch for small crossovers Common links come from ordinary convenience: reusing a public handle, connecting directly once, copying a personal configuration file or discussing a project through an identified account. Behaviour and content may reveal relationships even when technical identifiers differ. Periodically review your setup after adding software or changing devices. Ask whether the management route, DNS, credentials, logs and backup destination still match the plan. The hosting provider can minimise its own collection, but cannot prevent information you publish through your applications. - Check source addresses and remote DNS after client changes. - Review new credentials and external accounts before installing integrations. - Keep support messages limited to necessary service details. - Look for personal names, hostnames and email addresses in configuration. - Retest a backup restore and account recovery periodically. ### Build routines you can maintain Private infrastructure still requires patches, resource monitoring and sensible abuse prevention. Do not discard useful diagnostics blindly: choose a scope and short retention suited to the service, then protect the remaining operational data. The durable result is a manageable server with fewer unnecessary links, not a guarantee of invisibility. Prepare maintenance and recovery as carefully as the initial order, and preserve the separation as the project grows. ### Find the guide for your next decision - [Protect the server management connection]() - [Buy a VPS privately: from browsing to first login]() - [Self-host a password vault: access and backups]() - [VPS migration checklist: backups, DNS, TLS and rollback]() - [KVM VPS and root access: control, isolation and limits]() - [Revisit the account and payment privacy layers]() - [Plan secure self-hosted applications]() ## Plan and maintain a Tor relay on a VPS [Run a Tor relay on a VPS: planning and maintenance]() Updated 2026-10-04 Choose a non-exit relay or bridge, budget bandwidth, install maintained Tor packages and operate the node responsibly. Running a Tor relay requires a suitable provider, adequate transfer capacity, correct ports and regular maintenance. A middle relay or bridge differs from an exit node in its network role and responsibilities. Use the Tor Project's setup checks and monitor resource use after deployment. ### Choose the role before renting resources A public non-exit relay passes encrypted traffic between Tor nodes rather than making the user's final connection to an internet service. It can later receive guard status as the network evaluates it. A bridge provides an entry point that is not listed like a normal public relay, helping users whose networks block known Tor addresses. An exit relay makes the final outbound connection and therefore exposes its own IP to destinations. That brings different operational and abuse-handling requirements. For a first node, a non-exit relay or bridge is usually the more manageable choice. Confirm the provider permits the precise role before deploying it. ### Budget for continuity and traffic A relay benefits from a stable address, dependable uptime and sustained capacity in both directions. Small VPS resources can support a starting relay, but throughput depends on encryption performance, shared CPU behaviour and network limits. RAM requirements rise with connection count; monitor real use rather than treating the smallest instance as a universal fit. Monthly transfer matters as much as the port speed. A high rate maintained around the clock can exhaust a metered plan quickly, especially where incoming and outgoing traffic both count. Match bandwidth shaping and accounting to the actual allowance, and leave headroom for system maintenance. ### Install maintained software on a hardened system Start with an updated operating system, key-based administrative access and a firewall that permits the selected relay port. Use the Tor Project's current installation instructions for your distribution and supported package source. Repository keys, package names and service units should come from those instructions rather than an old copied installer. On many Linux systems the configuration is /etc/tor/torrc. Set a distinctive nickname and a monitored project contact address, then configure the relay role explicitly. Keep the management path separate from the relay's public listener. ### Use an explicit non-exit configuration The following is an illustrative non-exit outline, not a complete setup script. Replace the contact with an address you monitor and select rate values that fit the subscription. The .invalid address shown is a placeholder and cannot receive operator messages. Validate the configuration and review startup diagnostics. Confirm that the relay port is reachable and that the node eventually appears in the public directory. A new relay may initially carry little traffic while its capacity and reliability are evaluated; avoid repeatedly changing its identity just to force activity. ``` Nickname SilentNode ORPort 9001 ContactInfo operator@example.invalid RelayBandwidthRate 1 MBytes RelayBandwidthBurst 2 MBytes ExitRelay 0 SocksPort 0 ``` ### A bridge needs a transport and careful distribution An obfs4 bridge disguises its traffic pattern to help users bypass filtering. Follow the current distribution-specific bridge guide for its pluggable transport package; the obfs4 implementation project is now named lyrebird. Configure the transport listener, test reachability and obtain the bridge connection information. Do not publish a private bridge line indiscriminately. Use the documented distribution mechanism or share it with the intended users. Converting a publicly known relay into a bridge without changing identifying details can make the bridge easier to discover and block. ### Declare common ownership and maintain contact If you run several relays, disclose their shared control through the current Tor family mechanism so clients can avoid selecting your nodes in multiple circuit positions. Current guidance uses FamilyID; older MyFamily examples should not be treated as current configuration instructions. A monitored ContactInfo address lets other operators report problems without needing your civil identity. Keep security updates current, but understand how service restarts and package changes affect the node. Use bandwidth and accounting settings deliberately rather than allowing a relay to consume the whole plan unexpectedly. - Check the current family configuration for multi-relay operation. - Monitor the dedicated contact mailbox. - Review updates and reachability after a restart. - Keep private monitoring details appropriately restricted. - Choose transfer accounting that matches the provider's billing. ### Treat exits as a separate deployment decision Exit traffic can generate complaints and destination-side blocklisting. Before enabling an exit, establish explicit provider permission, a monitored abuse process, suitable dedicated infrastructure and an informed understanding of applicable obligations. Do not switch an existing node into exit mode merely to increase its usefulness. A non-exit relay or bridge already contributes useful capacity. Its lower exposure to destination complaints does not remove the need for maintenance or permission. The public SilentVPS website cannot substitute for a confirmed operational policy when production infrastructure becomes available. ### Preserve a healthy relay over time Check directory status, throughput, clock synchronisation, memory and the chosen listener after changes. A private monitoring system helps detect outages without publishing sensitive fine-grained traffic patterns. Keep configuration and identity-key backups in a secure place. If you migrate, preserve the appropriate identity material so the node need not rebuild all of its history; verify the current migration guidance before copying files. Never run unintended duplicate instances of the same identity. Stable, well-maintained capacity benefits the network more than frequent experimentation on a live node. ### Find the guide for your next decision - [Manage a VPS over Tor: SSH and onion access]() - [Operate a private VPS: credentials, updates, backups]() - [Self-host WireGuard: keys, firewall and retention]() - [Review Tor relay VPS requirements]() - [Compare relays with onion services]() - [Compare monthly transfer and memory limits]() ### Official references - [Tor Project: relay checks after installation]() - [Tor Project: bridge setup]() ## Run a personal WireGuard endpoint with minimal history [Self-host WireGuard: keys, firewall and retention]() Updated 2026-10-04 Build a small self-hosted VPN, separate routing from administration and review the logs created around WireGuard. Self-hosting WireGuard gives you control over peers, keys, routing and VPN configuration. It does not remove the hosting provider or every system record. Protect key material, test firewall rules and review operating-system and application retention before describing the endpoint as no-log. ### Know what self-hosting changes A personal VPN gives you control of the endpoint, peer keys and configuration. You can inspect the guest system instead of relying only on a commercial provider's activity policy. It also gives you a stable address whose reputation is not shared with thousands of unrelated VPN customers. That address is generally associated with your own traffic, so it offers less crowd cover than a shared exit. The VPS operator and upstream network remain part of the trust model. Self-hosting is useful for control and private connectivity; it does not automatically provide anonymity or end-to-end encryption for every application. ### Prepare a plain Linux system and client devices Use a maintained Linux distribution, root access for initial networking changes and a public endpoint reachable by UDP. WireGuard is lightweight for modest personal use, while traffic allowance and connection speed are often the main constraints. Higher throughput or multiple workloads can change CPU and memory requirements. Plan one peer identity per device so a lost phone can be revoked without replacing every key. Decide which addresses and services should traverse the tunnel. A full internet tunnel needs forwarding and usually address translation; a private mesh between servers may not. ### Generate keys locally and map peers explicitly Generate each device's private key on that device and share only the corresponding public key. Restrict permissions on key files and avoid passing complete client configurations through unprotected mail or shared notes. A QR code containing a configuration contains the private key and should be protected too. The server interface normally has a private tunnel address, a UDP listen port and one peer entry per client. AllowedIPs combines routing and peer address authorisation. Give each client its own tunnel address rather than using overlapping server-side peer ranges. ``` umask 077 wg genkey > privatekey wg pubkey < privatekey > publickey ``` ### Make routing and the firewall work together Enable the forwarding required by your chosen address families and configure the firewall to permit tunnel traffic and the intended exit. For a common IPv4 internet gateway, that includes an appropriate masquerade rule on the public interface. Match the rule to the actual interface name and subnet. Expose only the required UDP listener and your protected administration path. A successful handshake alone does not prove routing works. Check internet reachability, DNS and return traffic. Persist the configuration through reboot using the supported WireGuard service mechanism for the distribution. ### Configure clients without creating leaks A client needs the server's public key, endpoint address and port, its own tunnel address and the routes to send into the tunnel. For an IPv4 full tunnel the route is 0.0.0.0/0; IPv6 requires an intentional configuration too, often ::/0 with working IPv6 routing or explicit blocking where it is not supported. Choose how DNS queries are handled and test from each client. If the tunnel is meant to protect all traffic, verify what happens when it disconnects. A firewall-based kill switch can prevent accidental direct access, but must be adapted and tested for the device rather than assumed from a single route setting. - Check the public address shown by a trusted test endpoint. - Test DNS resolution and IPv6 behaviour. - Confirm the intended services work through the tunnel. - Verify the result after a server and client restart. - Test connection loss if you need traffic to stop when the VPN fails. ### Minimise history across the whole system WireGuard exposes live peer state such as latest handshakes and transfer counters; it does not ordinarily maintain a persistent browsing history itself. That distinction matters: a peer configuration and current endpoint state still exist. Extra scripts can write those observations to disk if you add them. Review the surrounding components: system journal, firewall logging, traffic accounting, DNS resolver logs and monitoring agents. Use proportionate diagnostic retention rather than claiming the machine contains no records at all. Storage encryption addresses some disk risks, while a running VPS still relies on its underlying infrastructure. - Avoid unnecessary scripts that archive peer connection activity. - Disable DNS query history when it is not needed. - Keep operational diagnostics scoped and short-lived. - Protect peer configuration and private keys. - Review third-party monitoring and backup contents. ### Separate the VPN data path from management WireGuard carries UDP and does not run through Tor's ordinary TCP SOCKS transport. Keep the VPN's data path on its normal network route. SSH or a private management dashboard can separately use Tor, including a client-authorised onion service. This protects the management connection from exposing a direct administrator IP, while the VPN endpoint still receives network traffic from its clients. Paying privately and using protected administration do not change that data-path fact. Keep the protections and their boundaries clear. ### Maintain keys, capacity and access Revoke lost devices by removing their peer keys and issue separate replacements. Keep host software current, retain a protected backup of the configuration and monitor capacity without unnecessarily archiving user activity. Check transfer consumption before it threatens the monthly allowance. The endpoint can also become a private route to a home service or another VPS. Add routes and firewall permissions deliberately rather than exposing every service on the machine. Start with the smallest network arrangement that solves the problem, then grow it with the same key and logging discipline. ### Find the guide for your next decision - [What is no-logs hosting? Audit the actual records]() - [Manage a VPS over Tor: SSH and onion access]() - [Maintain the endpoint securely over time]() - [Review WireGuard VPS requirements]() - [Understand hosting and guest-system records]() ### Official references - [WireGuard quick start]() ## Prepare a VPS for private, deliverable email [Self-hosted email VPS: DNS and deliverability]() Updated 2026-10-04 Check IP reputation, SMTP availability, DNS authentication and reverse DNS before building your own mail service. Private email hosting requires more than installing a mail server. Confirm port availability and reverse DNS, configure SPF, DKIM and DMARC, and consider address reputation. Authentication helps receivers evaluate messages but does not guarantee inbox delivery; maintenance and recoverable backups remain essential. ### Separate mailbox control from message delivery Self-hosting gives you control of the mail store, accounts, retention and software configuration. It also makes you responsible for availability, patching, spam filtering and backups. That trade can suit a personal domain or small team, but it is a continuing service rather than a one-time installation. Delivery to other providers is a separate challenge. Receivers evaluate the sending IP, domain history, authentication, message behaviour and their own policies. A mail application that works locally can still have its messages delayed, rejected or placed in spam. ### Investigate the address before deploying An allocated IP may carry history from earlier users. Check relevant reputation and blocklist information, then investigate findings before committing your mail service. No known blocklist entry is a useful starting point, not proof that the address has never been used or a guarantee of inbox placement. Ask the host about outbound port 25, dedicated addressing and the ability to set reverse DNS. Root access alone does not grant permission to send SMTP or control the provider's PTR zone. Confirm the rules and technical capabilities first, including any IPv6-specific restrictions. ### Use authentication to establish domain authority SPF publishes the systems authorised to send for the envelope domain. List all legitimate senders, respect the mechanism lookup limit and test before enforcing a hard-fail ending such as -all. Receivers make their own handling decisions; SPF is not an instruction that automatically guarantees acceptance or rejection. DKIM signs selected message headers and content with a domain-controlled key. Publish the corresponding public key under a selector and protect the signing key on the server. A valid signature demonstrates authorised signing and integrity of covered content, rather than proving that a message is desirable or harmless. ### Align the visible sender with DMARC DMARC relates the visible From domain to authentication. Passing requires an aligned SPF result or an aligned DKIM signature, not merely that an unrelated domain authenticated somewhere in the message. Publish the appropriate policy and examine aggregate reports to discover legitimate senders you may have missed. Begin with monitoring if the domain's sending paths are uncertain, then move toward quarantine or rejection when legitimate traffic is correctly aligned. Handle reporting addresses and stored reports deliberately because they contain operational information. Use the current DMARC documentation, not a copied historical configuration. The DNS examples use a reserved domain and documentation address. Replace all values with your actual sending domain, address and reporting mailbox; do not publish them unchanged. ``` example.invalid. TXT "v=spf1 ip4:203.0.113.45 -all" _dmarc.example.invalid. TXT "v=DMARC1; p=none; rua=mailto:reports@example.invalid" ``` ### Make reverse DNS and the server identity agree The mail IP should have a PTR pointing to an appropriate hostname, and that hostname should resolve forward to the same address. Configure the server's EHLO name consistently. The provider normally controls PTR records, so arrange the setting through its supported process. Publish MX and address records, configure TLS and test certificate renewal. If you send over IPv6, evaluate its address reputation and reverse DNS separately. Do not publish or use an IPv6 sending path simply because the VPS includes one if you cannot maintain that path correctly. ### Build a safe mail service before sending volume Choose a maintained mail stack and expose only the necessary services. Require authentication for submission, prevent open relaying and use appropriate TLS for client access. Test with independent recipients and inspect message authentication results and delivery responses. Send modest, expected traffic while establishing a history. Protect accounts against compromise, process bounces and avoid unsolicited bulk mail. Authentication records and an unlisted address cannot compensate for abusive traffic, a stolen mailbox or a domain that receivers distrust. - Confirm SMTP permissions and PTR support before installing. - Test SPF, DKIM and DMARC alignment from real delivered messages. - Verify the server is not an open relay. - Check client TLS and certificate renewal. - Review bounce responses instead of repeatedly resending. - Maintain consistent, legitimate sending patterns. ### Understand what hosting privacy does and does not cover Minimal signup data and a private payment method can reduce billing links between the server and its operator. DNS registration information, contact addresses, mail headers and account recovery can create other links. Review those layers rather than assuming the hosting account defines the whole privacy boundary. Self-hosting does not make ordinary email end-to-end encrypted. TLS protects particular transport connections; message contents can still be readable at endpoints and intermediate mail stores. Use suitable end-to-end tools when correspondents require content confidentiality, and account for the metadata email necessarily exposes. ### Plan ongoing operation and recovery Keep the operating system and mail software updated, monitor queue growth and resource use, and choose sensible retention for diagnostics. Encrypt backups and include mailbox data, configuration and signing keys. Test restoration without accidentally sending duplicate queued mail. Be realistic about the workload. A low-volume personal domain may be manageable, while a large sender needs more monitoring and careful operational processes. Address quality, root control and DNS support establish the foundation; regular maintenance earns and preserves the service's usefulness. ### Find the guide for your next decision - [Review credentials, maintenance and recovery]() - [Self-host a password vault: access and backups]() - [What is no-logs hosting? Audit the actual records]() - [Plan private mail and other applications]() - [Check storage and memory for a mail stack]() ### Official references - [IETF RFC 9989: DMARC]() ## Host your password vault on a private VPS [Self-host a password vault: access and backups]() Updated 2026-10-04 Choose Bitwarden or Vaultwarden, secure the HTTPS endpoint and build a tested backup routine for your most important account. A self-hosted password vault needs protected transport, restricted registration, secure administration and a tested recovery process. Bitwarden and the community Vaultwarden implementation have different documentation and support models. Follow the chosen project's requirements and verify that backups preserve the information needed to restore the vault. ### Decide whether you want the operational responsibility A password vault can unlock many other accounts, so its availability and security deserve deliberate planning. Bitwarden clients encrypt vault data before synchronising it. Hosting the backend yourself changes where the encrypted data and service metadata live; it does not remove the importance of a strong master password and safe client devices. You gain control over the deployment, retention and access policy, while accepting responsibility for patches, backups and recovery. A small private instance may attract less broad attention than a large shared service, but misconfiguration can make it more exposed. Choose self-hosting because you can maintain it, not because every self-hosted system is automatically safer. ### Choose the backend and check compatibility Bitwarden provides official self-hosting options with documented requirements, including different deployment formats. Compare the current resource and feature requirements rather than assuming every official installation needs the same large stack. Vaultwarden is a separate, unofficial implementation compatible with Bitwarden clients. Its lightweight design is attractive for a personal or family instance, but feature compatibility and release timing can differ. The security claims and audits of official products should not automatically be attributed to this independent backend. ### Prepare the server, name and access path A small Linux VPS with 1 vCPU and 2 GB RAM can be a starting point for a modest Vaultwarden instance; attachments and other workloads determine storage needs. Full root access allows the configuration, but the hypervisor remains under the hosting operator's control. Point a dedicated hostname at the server with appropriate A and, if supported and tested, AAAA records. Plan valid HTTPS, protected administration and a recovery route. Domain registration, certificate contact information and user email addresses can reveal links beyond the hosting signup. ### Deploy with persistent storage and a local backend Update the operating system and establish key-based administration before adding the vault. Use the Vaultwarden project's maintained image or an installation method documented by the project. Mount the data location persistently so replacing a container does not erase the service. Keep the application backend on localhost or a private container network, then place Caddy or Nginx in front for HTTPS. Confirm that the container port is not unintentionally exposed through Docker's networking rules. Open only the services needed for users, certificates and your chosen management route. ### Close registration and protect every account Create your intended account using a controlled onboarding process, then set SIGNUPS\_ALLOWED=false. Manage additional users through explicit invitations or a protected administration workflow. Set the service URL correctly so clients and links use the intended HTTPS endpoint. Protect any administration token separately and follow the project's guidance for its secure representation. Use a strong master password and enable appropriate two-factor authentication on each account. Store recovery codes outside the vault itself; needing the unavailable vault to recover it creates a circular dependency. The example URL is intentionally non-operational. Replace it with the hostname and certificate you have configured. ``` DOMAIN=https://vault.example.invalid SIGNUPS_ALLOWED=false ``` ### Back up a consistent set of data The backup needs more than a casual copy of a live SQLite file. Use a supported online backup method or a controlled stopped-service procedure. Include attachments and the configuration or keys required by your chosen installation, rather than assuming the database contains every file. Encrypt the archive before transferring it off the server, especially if configuration contains SMTP credentials or an administration token. Keep an off-box copy and the backup decryption key separately. Database alternatives such as PostgreSQL need their own consistent dump procedure. - Back up the database through a supported consistent method. - Include attachments and relevant persistent service files. - Encrypt archives before they leave the VPS. - Keep at least one independent off-box copy. - Test restoration and client synchronisation in an isolated environment. ### Maintain software and limit unnecessary exposure Track Vaultwarden releases and the client versions you use. Apply host security updates and review application changes before rollout; blind container replacement is a poor substitute for a tested upgrade and recovery plan. Verify health and backups after each change. Rate limiting, secure proxy headers and proportionate monitoring can help detect unwanted login attempts. A household service may be restricted to a VPN if every client can reliably reach it that way. Test mobile access and recovery before removing public reachability. Choose limited logging deliberately instead of sacrificing all diagnostics. ### Connect application privacy to hosting privacy Minimal account data can reduce information attached to the VPS profile. A public-ledger payment, a domain you associate with yourself and the application's user records can still create identifying links. Examine the full stack and avoid promises that one layer can protect every other one. A well-run private vault combines client-side encryption, verified HTTPS, restricted administration, protected accounts and tested recovery. Keep an independent plan for essential credentials if the server is unavailable. That is what makes the deployment dependable enough to hold information you cannot afford to lose. ### Find the guide for your next decision - [Self-host WireGuard: keys, firewall and retention]() - [Maintain a secure server environment]() - [Self-hosted email VPS: DNS and deliverability]() - [VPS migration checklist: backups, DNS, TLS and rollback]() - [Review private self-hosting requirements]() - [Protect sensitive administration access]() ### Official references - [Bitwarden: self-host an organization]() - [Vaultwarden: backing up your vault]() ## How the SilentVPS crypto checkout works [SilentVPS crypto checkout: network, invoice and status]() Updated 2026-10-09 Follow server configuration, currency and network selection, the dedicated invoice page, quote expiry and backend-driven payment status. Understand the current service integration limits. Configure the VPS first, choose one of eight configured payment methods, then open the separate invoice page for its exact amount, network, destination and expiry. Backend evidence drives transaction and payment states. Creating an invoice does not confirm payment, and verified payment does not by itself activate a server; those production integrations remain pending. ### Know the current service status first The SilentVPS website is publicly accessible. It can save a configuration and create a cryptocurrency invoice using the configured wallets. Automatic blockchain detection and VPS provisioning are not connected yet. The invoice page can update from verified backend information when that integration supplies it, but an animation or open wallet is not evidence that funds were received. This guide describes the actual website flow and its current boundary. It does not promise an instant server, a completed transaction monitor or a fixed blockchain processing time. Read the status shown on your order and keep your private reference secure. ### Configure the server before choosing payment On the configuration page, select the plan and monthly or annual billing period, then the intended operating system and region. A hostname and notification email are optional. Provide only the public part of an SSH key if you use key-based access; your private key stays on your device. The summary should match the billing cycle. For example, Shade is $33 on monthly billing and $277.20 for a full annual cycle. The annual equivalent of $23.10 per month is a comparison value. Saving the configuration creates a private order rather than proof of a paid or provisioned server. ### Choose the asset and its exact network The next page asks you to choose a payment method. The configured choices are BTC on Bitcoin, ETH on Ethereum, SOL on Solana, LTC on Litecoin, native TRX on Tron, USDT on Tron, USDC on Ethereum, and USDT on Ethereum. Confirming the choice opens a separate invoice page. USDT's Tron and Ethereum entries are different payment methods. USDC is configured on Ethereum mainnet; you cannot use another chain or another layer-2 network for Ethereum for the same invoice. Native TRX on Tron is a separate payment choice. Follow the exact method and network displayed instead of inferring support from a token name. ### Inspect the invoice before authorising a transfer Check the order, billing total, asset, network, destination, exact cryptocurrency amount and expiry. The quote fixes those invoice values for its validity window. The QR code and wallet link help enter the details, but you should still review them in the wallet before sending. Network fees are part of the wallet transaction, not a reason to change the amount the invoice needs to receive. Wallets and exchanges handle fees and withdrawals differently; verify the recipient amount and the selected network in the software you actually use. Never enter a wallet seed phrase or private key on the SilentVPS page. - Use the amount attached to this invoice, not an old screenshot or an earlier quote. - Check the full destination and network in the wallet's confirmation screen. - Retain the public transaction identifier privately for any later payment review. ### Read the status instead of sending again The dedicated page separates waiting for a transaction, detecting it and reaching the required verification state. Updates are driven by backend payment evidence. A countdown tracks quote validity; it does not simulate payment progress. Detection and confirmation are different states, and a verified payment remains separate from server activation. If an update is delayed, check the visible connection status and the transaction in your wallet. Do not assume a slow page requires another transfer. A network interruption, a quote expiry or an amount mismatch can require review. Keep the order and transaction identifiers so the real payment can be reconciled. ### Handle an expired quote carefully An expired invoice can lead back to payment-method selection for a fresh quote. Review the new amount and expiry rather than reusing the old payment instructions. If a transfer may already have been sent, preserve its identifier and seek resolution through the order before authorising another payment. Store the account credentials and private order reference like other sensitive access details. Share only the identifiers needed for support or payment review. Public guides, screenshots and messages should not reveal a private token that grants access to your order. ### Find the guide for your next decision - [Configured payment methods]() - [Billing totals]() - [Current service status]() - [Anonymous VPS: accounts, payments and privacy]() - [Private VPS resources: prices, privacy and crypto checkout]() - [VPS crypto payment networks: TRX, USDT, BTC and more]()