WireGuard vs OpenVPN comes down to one trade: WireGuard is a small tunnel with one fixed set of modern ciphers that runs inside the Linux kernel, so it is usually simpler and faster when you control both ends and UDP gets through. OpenVPN is a TLS-based VPN with certificates, settings pushed from the server, a TCP mode and proxy support, so it fits better on networks that block UDP and in setups that need user logins, revocation lists or layer 2 bridging.
The speed gap is also smaller in 2026 than the often-quoted benchmark suggests. OpenVPN’s data channel offload (DCO) moves its packet path into the kernel as well, and Linux 6.16 ships that driver as the ovpn module. This comparison is built from the projects’ own documentation: the WireGuard whitepaper and protocol pages, the OpenVPN 2.7 manual and changelog, and the Tailscale, Headscale and NetBird docs. Every number below carries its source and its age.
Key takeaways
- WireGuard uses one fixed cipher suite (Noise_IK, Curve25519, ChaCha20-Poly1305, BLAKE2s) and has run inside the Linux kernel since 5.6; OpenVPN negotiates ciphers over TLS and defaults to AES-256-GCM, AES-128-GCM and ChaCha20-Poly1305.
- The often-quoted speed gap comes from the whitepaper's old benchmark (Linux 4.6.1) against user-space OpenVPN; OpenVPN's data channel offload now runs in the kernel too, merged into Linux 6.16 as the ovpn module, which needs OpenVPN 2.7 or later.
- WireGuard is UDP-only and does not try to hide itself; OpenVPN can run over TCP, through HTTP or SOCKS proxies and, since 2.7, on UDP and TCP from one server.
- WireGuard gives each device a fixed tunnel address and remembers its latest real IP address in memory; OpenVPN hands out addresses from a pool and records real addresses in its status file if you enable one.
- For many devices or NAT on both sides, a WireGuard-based overlay such as Tailscale, Headscale or NetBird adds key distribution, NAT traversal and relays that plain WireGuard leaves out.
WireGuard vs OpenVPN at a glance
The table sums up the differences that matter when you run your own VPN server. Each row is explained, with sources, in the sections below.
| WireGuard | OpenVPN (2.7) | |
|---|---|---|
| What it is | A layer 3 network interface (wg0) that encrypts IP packets for peers identified by public keys | A VPN program that uses TLS for keys and authentication, on a tun (layer 3) or tap (layer 2) device |
| Cryptography | Fixed: Noise_IK handshake, Curve25519, ChaCha20-Poly1305, BLAKE2s, HKDF. No negotiation | Negotiated: TLS via OpenSSL or mbed TLS; data channel defaults to AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305 |
| Identity | One key pair per device, exchanged like SSH keys | Certificates (a CA, or self-signed with peer-fingerprint); optional username and password, scripts and plugins |
| Transport | UDP only | UDP by default; TCP when UDP cannot be used; HTTP and SOCKS proxies |
| Port | None fixed (random if unset); 51820 in the official examples | 1194, the IANA-assigned port |
| Packet path | Linux kernel, since Linux 5.6 (March 2020) | User space by default; kernel with DCO (ovpn in Linux 6.16+, ovpn-dco-win on Windows) |
| Tunnel addresses | Static: each peer’s AllowedIPs in the server config | A pool handed out by the server; per-client static addresses optional |
| Routes and DNS for clients | Out of scope: written into each client’s config | Pushed from the server |
| Roaming | Built in: each side follows the peer’s latest authenticated address | Over UDP, a server follows a client to its new address by peer ID (since 2.4); --float for peers set with --remote; DCO in 2.7 too, with a recent kernel module |
| Code size | Under 4,000 lines for the Linux implementation, excluding crypto primitives (whitepaper) | No official figure; relies on a full TLS library |
| Hiding the protocol | Not a goal; left to other layers | --tls-crypt “makes it harder to identify OpenVPN traffic” |
How do WireGuard and OpenVPN differ in design and cryptography?
WireGuard: one cipher suite, keys like SSH
WireGuard adds a network interface, usually wg0, that you configure with a private key and a list of peers. Its protocol page lists every primitive it uses: ChaCha20 with Poly1305 (the RFC 7539 AEAD construction) for encryption, Curve25519 for key exchange, BLAKE2s for hashing, SipHash24 for hashtable keys and HKDF for key derivation. The handshake is Noise_IK, one round trip, and it repeats every few minutes to rotate keys for perfect forward secrecy.
There is nothing to choose. The WireGuard whitepaper calls the design “cryptographically opinionated”: it intentionally lacks cipher and protocol agility, and “if holes are found in the underlying primitives, all endpoints will be required to update.” An optional preshared key can be mixed into the handshake as an extra layer against future quantum attacks on Curve25519.
Routing and access control are the same table, which the WireGuard homepage calls cryptokey routing. Each peer’s public key is tied to a list of allowed tunnel addresses. Outgoing packets go to the peer whose list contains the destination, and incoming packets are accepted only if they decrypt with that peer’s key and come from one of its addresses.
OpenVPN: a TLS control channel and a negotiated data channel
OpenVPN runs a TLS session, through OpenSSL or mbed TLS, to authenticate both sides and derive keys, and encrypts the tunnel’s packets in a separate data channel. The OpenVPN 2.7 manual says the allowed data ciphers default to AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305 where ChaCha20-Poly1305 is available. Peers negotiate one cipher from that list, so a server can add or drop a cipher through configuration.
That agility carries history. The OpenVPN changelog records that 2.4 still accepted Blowfish (BF-CBC) when no cipher was configured and that 2.5 dropped it from the defaults unless you add it back. The 2.7 manual adds that since 2.6 the old --cipher option is always ignored in TLS mode when it comes to choosing the data cipher. Release 2.7 keeps modernizing: the old static-key mode is disabled by default and slated for removal in 2.8, compression on send is gone, AES-GCM usage limits are enforced the way TLS 1.3 enforces them, and a new epoch data format brings 64-bit packet counters and automatic key switchover.
Key exchange comes from the TLS library too. The 2.7 manual’s --dh entry names newer hybrid key agreement algorithms such as X25519MLKEM768, a post-quantum hybrid, and OpenVPN Inc. says this hybrid exchange is on by default with OpenVPN 2.7 and OpenSSL 3.5. WireGuard’s answer to quantum attacks is the optional preshared key above.
The trade-off is plain. Agility lets OpenVPN follow new algorithms and compliance rules by changing a config file. WireGuard’s authors argue the other side in the whitepaper: “cipher agility increases complexity monumentally.”
Is WireGuard faster than OpenVPN in 2026?
Usually yes in a default setup, but the classic reason is fading. The famous numbers come from the whitepaper: between an Intel Core i7-3820QM and an Intel Core i7-5200U machine on gigabit Ethernet (Linux 4.6.1, per WireGuard’s performance page), iperf3 averaged over 30 minutes measured 1,011 Mbit/s through WireGuard and 258 Mbit/s through OpenVPN (256-bit AES with HMAC-SHA2-256, UDP mode), with ping times of 0.403 ms and 1.541 ms. The paper explains the gap: OpenVPN ran in user space, so packets were copied between kernel space and user space several times. It also notes that the CPU sat at 100% during the OpenVPN test but not during WireGuard’s, which suggests WireGuard filled the gigabit link: 1,011 Mbit/s was the link’s limit, not WireGuard’s.
Read those numbers with their age. WireGuard’s own performance page says the benchmarks are “old, crusty, and not super well conducted” and that newer data is a work in progress, while still saying that “OpenVPN remains extremely slow.” OpenVPN Inc. now states on its comparison page that with DCO the two reach “similar speeds on like hardware, with either protocol ahead depending on the test.” Both are claims by the projects themselves; no independent current benchmark is cited here. The same OpenVPN page concedes that DCO in mainline Linux is “not yet on most installed systems” and that on mobile, where clients still run in user space, “WireGuard is typically faster.”
What OpenVPN DCO changes
OpenVPN 2.6 added data channel offload. According to OpenVPN’s DCO README, data packets are then “directly processed and forwarded in kernel space” while the openvpn program acts only as the control plane. The driver was merged into Linux 6.16, which Kernel Newbies dates to July 27, 2025, under the name ovpn. On Windows, OpenVPN 2.7 uses its ovpn-dco driver by default and falls back to tap-windows6 when a config needs a feature DCO lacks.
DCO has rules. The README lists these limits by design:
- layer 3 (
dev tun) only, so no layer 2 bridging; - only the AEAD ciphers ChaCha20-Poly1305 and AES-GCM;
- no compression;
- peers must run OpenVPN 2.4 or later;
- servers must use
topology subnet, which OpenVPN 2.7 now makes the default.
If a config breaks a rule, or the kernel module is missing, OpenVPN turns DCO off automatically and logs a note such as Note: Kernel support for ovpn-dco missing, disabling data channel offload. Search your log for that line before you compare speeds.
What this means on an Ubuntu 24.04 VPS
WireGuard needs nothing extra: it has been in the mainline kernel since Linux 5.6, and sudo apt install wireguard only adds the tools. OpenVPN on Ubuntu 24.04 is version 2.6.19 from noble-updates (Launchpad, October 2026). The release kernel of 24.04 is 6.8, older than 6.16, so its DCO driver is the separate openvpn-dco-dkms package in universe. The DCO README notes that the new in-kernel ovpn module works only with OpenVPN 2.7 and later, so a newer kernel alone is not enough. Run uname -r to see which kernel your server boots.
UDP, TCP and CPU: the other speed factors
Both protocols are fastest over UDP. WireGuard’s known limitations page says it “explicitly does not support tunneling over TCP, due to the classically terrible network performance of tunneling TCP-over-TCP.” OpenVPN offers TCP, but its manual says that, compared with UDP, TCP “will usually be somewhat less efficient and less robust when used over unreliable or congested networks.” Treat OpenVPN over TCP as a way through a blocked network, not as a speed option.
Connection setup differs as well. The whitepaper describes WireGuard’s key exchange as one round trip (1-RTT), and the protocol page says it repeats every few minutes to rotate keys. OpenVPN’s manual notes that TLS “requires a multi-packet exchange before it is able to authenticate a peer”. Fewer round trips favor WireGuard on phones that reconnect often; neither project publishes timing figures, so none are quoted here.
The cipher matters less than it used to. The same WireGuard page says ChaCha20-Poly1305 is “extremely fast in software on virtually all general purpose CPUs” and that vector instructions land “in the same ballpark (and sometimes even faster) than AES-NI instructions.” OpenVPN can use AES-GCM, which CPUs with AES-NI accelerate in hardware. On a VPS, the network path between you and the server often decides more than either protocol, which is why our guide to choosing a VPS location starts with latency math.
Is WireGuard more secure than OpenVPN?
Both are considered secure when they are configured well and kept updated. The difference is how much there is to configure and review. WireGuard has one small code base and one cipher suite. OpenVPN has more features, more options, a full TLS library underneath, and more ways to harden or weaken a setup.
Code size, audits and formal proofs
The whitepaper states that WireGuard “is implemented in less than 4,000 lines of code (excluding cryptographic primitives)”. That figure describes the Linux kernel implementation, in a paper whose latest draft is dated June 1, 2020. The WireGuard homepage describes OpenVPN with OpenSSL as a code base so large that auditing it is “an overwhelming task even for large teams of security experts”, but that is one project’s view of another. Neither project publishes an official line count for OpenVPN, so this article does not repeat the multiples you will see elsewhere. OpenVPN Inc., for its part, points to an independent audit whose high-priority findings were fixed in version 2.4.2.
WireGuard’s formal verification page lists a symbolic model of the protocol in Tamarin, a computational proof of a closely equivalent variant in the eCK model and, in CryptoVerif, a mechanized proof of the whole protocol in an ACCE-like model (forward secrecy, mutual authentication, replay resistance of the first message and more). It also lists verified Curve25519 code from the HACL* and Fiat-Crypto projects.
OpenVPN reduces its exposure with options that run before TLS does. --tls-auth works as what the manual calls an “HMAC firewall”: control packets without the right signature are dropped before a TLS handshake starts. --tls-crypt also encrypts them, and --tls-crypt-v2 gives every client its own key. Its verify hook can reject a client before OpenVPN exposes, in the manual’s own words, “the TLS stack (including the notoriously dangerous X.509 and ASN.1 stacks)”. Since 2.6, a UDP server uses an HMAC-based cookie instead of allocating state for every first packet, which the changelog says eliminates amplification and resource exhaustion attacks. OpenVPN’s changelog lists security fixes with their CVE numbers, and 2.7.7 is the current release on the community downloads page as of October 2026.
The trade-offs WireGuard documents itself
The known limitations page is worth reading before you choose. In short:
- No obfuscation. WireGuard “does not focus on obfuscation”; disguising its packets is left to a layer above it.
- No TCP. Wrapping its UDP packets in TCP is the job of other projects, such as udptunnel and udp2raw.
- Identity hiding is not forward secret. Someone who later steals the server’s private key and holds a log of old handshakes can tell who sent them, but not what was inside. Rotating keys limits this.
- Roaming mischief. An active man in the middle can change a peer’s source address; the packets stay unreadable, and a firewall rule can pin the socket to one address.
- Clock dependence. WireGuard uses the system time as a counter, so the clock should not be under an attacker’s control.
- Not post-quantum by default. The preshared key slot adds a layer; the page suggests running a post-quantum handshake on top and feeding its key into that slot.
Unauthenticated packets get no reply at all. The whitepaper explains that every handshake message must carry a MAC computed with the receiving peer’s public key, so a scanner that does not know that key gets silence. Under load, a cookie exchange ties handshakes to the sender’s IP address.
Which works better behind NAT, firewalls and networks that block UDP?
Both work behind ordinary home and mobile NAT when the client starts the connection to a server with a public IP address, which is the usual VPS setup. They differ when the network is hostile or when neither side is reachable.
WireGuard’s client config holds the server’s starting address, and the server learns each client’s address from authenticated packets. The whitepaper notes that because of this roaming, “there is no requirement for NAT to keep sessions open for long”. When a device behind NAT must stay reachable while idle, the wg(8) manual suggests a persistent keepalive of 25 seconds. Otherwise WireGuard sends nothing while idle: its quick start says it “tries to be as silent as possible when not being used; it is not a chatty protocol.” On the OpenVPN side, a UDP server recognizes a client that moves to a new address by its peer ID (added in 2.4), --float does the same for peers set with --remote, and keepalive sends a ping at a set interval and restarts the session when pings stop. The peer-fingerprint example below pings every 60 seconds.
| Network situation | WireGuard | OpenVPN |
|---|---|---|
| Laptop or phone behind NAT, server on a VPS | Works; add PersistentKeepalive = 25 if the server must reach the device while idle | Works; keepalive keeps the session up |
| Phone switches from Wi-Fi to mobile data | Built-in roaming: the next authenticated packet updates the address | Over UDP, the server follows the client to its new address by peer ID; DCO in 2.7 detects floating clients too |
| UDP blocked, TCP 443 open | No native option; needs a wrapper such as udp2raw, or an overlay relay | proto tcp-server on port 443 (if no web server uses it); since 2.7 one server can listen on UDP and TCP at once |
| Only an HTTP or SOCKS proxy allowed | No native option | --http-proxy or --socks-proxy |
| Both devices behind NAT, no public server | Needs a reachable relay peer, or an overlay with NAT traversal | Needs a reachable server |
| Network inspects and filters VPN traffic | Not designed to hide; obfuscation is left to other layers | --tls-crypt makes OpenVPN traffic harder to identify |
Managed overlays fill WireGuard’s gap here. Tailscale’s connection types guide says connections start through a relay, upgrade to a direct UDP path when NAT traversal succeeds and stay relayed when it fails, and that “any device that can open an HTTPS connection to an arbitrary host can build a tunnel using DERP relays.” Relayed traffic is still WireGuard-encrypted end to end, but usually slower than a direct path.
Local law and our rules: some countries restrict VPNs or tools that disguise them, and many workplaces, schools and hotels set their own terms. Check them before you rely on a VPN. On an HourlyVPS server, our acceptable use policy covers everything the server sends, whichever protocol carries it.
How hard is each one to set up and run on a VPS?
WireGuard is shorter to configure; OpenVPN can be nearly as short since 2.6. This is the WireGuard part of a server config, adapted from the cryptokey routing example on wireguard.com with the keys replaced by placeholders. Each [Peer] block is one device:
[Interface]
PrivateKey = <server private key>
ListenPort = 51820
[Peer]
# laptop
PublicKey = <laptop public key>
AllowedIPs = 10.192.122.3/32
[Peer]
# phone
PublicKey = <phone public key>
AllowedIPs = 10.192.122.4/32OpenVPN’s smallest official setup skips the certificate authority. The peer-fingerprint example in OpenVPN’s documentation uses self-signed certificates and trusts each client by its SHA-256 fingerprint. The server needs OpenVPN 2.6 or later, which Ubuntu 24.04’s 2.6.19 meets; the same document shows how older clients connect with a <ca> section instead. Its server config, abridged:
cert server.crt
key server.key
dh none
dev tun
proto udp6
server 10.8.0.0 255.255.255.0
server-ipv6 fd00:6f76:706e::/64
tun-mtu 1400
<peer-fingerprint>
ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00:ff:ee:dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00
</peer-fingerprint>
explicit-exit-notify 1
keepalive 60 300The same document recommends a real PKI, for example with easy-rsa, for bigger setups. The day-to-day work differs like this:
| Task | WireGuard | OpenVPN |
|---|---|---|
| Add a device | Create a key pair, add a [Peer] block with its address, reload | Create a client certificate, add its fingerprint and restart the server (or sign it with your CA) |
| Remove a device | wg set wg0 peer <key> remove and delete the block | Delete the fingerprint and restart, or revoke the certificate with a CRL (--crl-verify) |
| Tunnel addresses | You assign one per peer | server 10. hands them out from a pool |
| Routes and DNS | Written into each client config | Pushed with push from the server |
| User logins and MFA | Out of scope | --auth-user-pass-verify scripts and --plugin modules |
| Layer 2 bridging | Not supported (layer 3 only) | dev tap (without DCO) |
| Firewall on the server | One UDP port, plus forwarding and NAT for internet access | One UDP or TCP port, plus forwarding and NAT |
Either way, secure the server before you open a VPN port: our VPS security checklist covers SSH keys, the firewall and updates. For a complete WireGuard server with phone QR codes, NAT and leak tests, follow our WireGuard VPN on a VPS tutorial.
Client apps on each platform
The WireGuard installation page links official apps for Windows (10, 11 and Server 2016 to 2025), macOS and iOS (App Store) and Android (Play Store or APK), plus packages for most Linux distributions, FreeBSD, OpenBSD and OpenWRT. OpenVPN Inc. lists its OpenVPN Connect client for Windows 10 and 11, macOS, Linux, iOS, Android and ChromeOS. The community project publishes OpenVPN 2.7 installers for Windows and the source code, and Linux distributions package it. Both protocols reach every mainstream device; check the client for your router or smart TV separately.
WireGuard vs OpenVPN privacy: what does each server know about you?
Neither protocol hides who you are from the services you sign in to, and on your own VPS the operator is you. Our WireGuard tutorial shows what a personal VPN hides, and from whom. What the two protocols differ on is what the server holds about each device.
| What the server holds | WireGuard | OpenVPN |
|---|---|---|
| The device’s tunnel address | Fixed in the config, tied to its public key | Taken from a pool; ifconfig-pool-persist can keep a long-term name-to-address list |
| The device’s real IP address | Its latest endpoint, kept in memory and shown by wg show | The “Real Address” column of the status file, if --status is set |
| Activity | Latest handshake time and bytes sent and received, per peer | Bytes and “Connected Since” in the status file; log lines at the --verb level you choose |
| Identity | A public key | A certificate name, plus a username if you add logins |
Static addresses. WireGuard has no address pool or server-pushed settings; its homepage puts key distribution and pushed configurations out of scope. Every device keeps the same tunnel address for as long as its key exists. On a personal server that is convenient. Commercial VPN services that offer WireGuard need their own systems for address assignment and key handling, because the protocol leaves both out.
Roaming means the server remembers your last IP address. The homepage explains that both sides send to “the most recent IP endpoint for which they authentically decrypted data”. The wg(8) manual shows the endpoint, latest handshake and transfer counters for every peer, and says the endpoint is “updated automatically to the most recent source IP address and port”. One setting writes it to disk: with SaveConfig = true, wg-quick(8) saves the config “from the current state of the interface upon shutdown”, and that state includes each peer’s latest endpoint. Leave it off on a privacy-minded server. OpenVPN’s equivalent lives in the status file and logs, which you configure.
Handshake privacy. WireGuard encrypts the sender’s public key inside the handshake, but, as noted above, a later leak of the server’s private key plus a capture of old handshakes would reveal which keys connected. OpenVPN’s --tls-crypt hides the client certificate from observers, according to the manual. On your own server, the simplest privacy measure is the same for both: keep logging minimal, and when you are done, revoke the keys and delete the server, as our delete-VPS checklist describes.
Tailscale, Headscale and NetBird: when an overlay beats both
If you have many devices, or devices behind NAT on both sides, a WireGuard-based overlay network may fit better than either plain protocol. Overlays add the parts WireGuard leaves out: a coordination server that hands out keys and addresses, NAT traversal, and relays.
| Overlay | What it is, per its docs | Who runs the control server | When a direct path fails |
|---|---|---|---|
| Tailscale | Connects devices in a tailnet; direct, DERP-relayed and peer-relayed connections are all end-to-end encrypted with WireGuard | Tailscale (hosted service) | A peer relay in your tailnet, or Tailscale’s DERP servers over HTTPS |
| Headscale | “An open source, self-hosted implementation of the Tailscale control server”, scoped to a single tailnet for personal use or a small open-source organization; not associated with Tailscale Inc. | You, on your own server | Tailscale’s public DERP servers by default, or Headscale’s embedded DERP server once you enable it |
| NetBird | A “WireGuard-based overlay network” with central access control; kernel WireGuard; a management service, a signal service and ICE/STUN for peer discovery | NetBird Cloud, or you (self-hosted) | Its relay service, with a WireGuard tunnel through it |
A VPS fits two roles here. It can be an always-reachable node, such as a Tailscale exit node that sends your traffic out through the server’s IP address; our Tailscale exit node guide sets one up. Or it can host the control plane itself. NetBird’s README lists a Linux VM with at least 1 CPU and 2 GB of memory, TCP ports 80 and 443, UDP port 3478 and a public domain name for its self-hosted quickstart. That matches Quartz Q2 (1 vCPU, 2 GB RAM); that is sizing from NetBird’s documented minimum, not a benchmark. A control server runs around the clock, and its hourly charges stop once they reach the plan’s monthly price, $10.00, in a billing period (one month from your order date), so it works as a monthly VPS with no contract and no prepayment.
On the OpenVPN side, OpenVPN Inc. sells managed products, Access Server and CloudConnexa, built around the same protocol. Everything in this article refers to the free community OpenVPN.
WireGuard or OpenVPN: which should you choose?
Use this checklist. The first group that describes your situation is usually the right answer.
- Choose WireGuard if you control the server and every client, have a handful of devices, want the least configuration and the quickest reconnects on phones, and the networks you use let UDP through. On Ubuntu 24.04 it is already in the kernel.
- Choose OpenVPN if some of your networks block UDP or allow only a proxy, you need username and password logins, scripts or plugins, you want to revoke access with certificates, you need to push routes and DNS to clients, or you need layer 2 bridging. Also choose it if your devices or company already run OpenVPN profiles.
- Choose an overlay (Tailscale, Headscale or NetBird) if you have many devices, devices behind NAT on both ends, or you want single sign-on and access rules instead of hand-edited peer lists.
- Run both if you are unsure. They use different ports and interfaces (
wg0andtun0), so one server can offer WireGuard as the default and OpenVPN on TCP 443 as the fallback, as long as each gets its own tunnel subnet.
The fastest way to settle speed on your own connection is to measure it. Deploy one test server, set up both, and compare them from your laptop and phone for an afternoon. WireGuard runs in the kernel and OpenVPN as one process, so Quartz Q1 (1 shared vCPU, 1 GB RAM) is a reasonable start for a personal test; our WireGuard tutorial explains that sizing from Ubuntu’s documented minimum. Four hours cost $0.04 on hourly billing, deducted from the server’s balance hour by hour. Billing is by the hour: every hour a server exists is charged at the plan’s hourly rate. The price tapes and cost tables on this site count every started hour as a full hour, so they show the most a duration can cost; the cost calculator charges a partial hour to the nearest cent, as the bill does.
| Duration | Hours on the meter | Cost $0.01 | Note |
|---|---|---|---|
| 4 hours | 4 | $0.04 | |
| 1 day | 24 | $0.24 | |
| 7 days | 168 | $1.68 | |
| 30 days | 720 | $5.00 | Capped at the monthly price |
When the test is over, delete the server or keep it; stopping it saves nothing. A stopped server is still billed, because its vCPU, memory, disk and IP addresses stay reserved for you; only deleting the server stops billing. If the winner becomes your everyday VPN, keep it running: it is still billed by the hour, but never more than the plan’s monthly price in a billing period, so there is no plan to switch to. Each server is ordered with an initial credit, prepaid and used for its hours. Our guide to hourly billing explains the monthly cap, the initial credit and top-ups, and our VPS location guide helps you decide where to deploy.
Deploy this setup
Test WireGuard and OpenVPN side by side for an afternoon
Quartz Q1 · 1 shared vCPU · 1 GB RAM · 25 GB NVMe · Istanbul
- Per hour$0.01/hourFor this job
- Per day (24 h)$0.24/day
- Monthly cap$5.00/month
Starts with a $5 initial credit, which goes into the server’s balance and pays for its hours.
Billed by the hour, never more than $5.00 per billing period. Delete the server and billing stops.
