Web hosting vs a VPS: can your plan run a VPN server?
Shared hosting, a managed app and a self-managed server grant different network control. Compare four capabilities before you buy or migrate anything.
A working website is evidence that a provider can serve HTTP, not that you control a machine. Between a shared plan, a managed application and a self-managed server sits a large gap in what the account may do to the network. Decide which side of that gap your VPN design needs before you pay for another year. Four capabilities separate the two, and none of them appears on a price list.
What each plan actually gives you
The useful comparison is not price or disk size but authority. Ask what the account can start, which kernel features it can reach, which ports accept inbound traffic and whether admitted traffic may leave again for somewhere else.
Most hosting products fall into three shapes, and only the last one is a general-purpose server:
| Capability | Website plan | Self-managed server |
|---|---|---|
| Long-running custom process | Usually not permitted | Yours to run under a service manager |
| Virtual network interface | Almost never available | Present when the kernel module and privilege allow it |
| Arbitrary inbound port | Restricted to the web stack | Provider filtering still applies |
| Forwarding for clients | Not offered | Possible once routing and policy are configured |
A shell account is the usual source of confusion. File transfer or scheduled-task access can look like administration while the process is confined to a directory and a small set of allowed operations.
Four capabilities that decide the answer
Take them in order, because a failure at the first step makes the rest irrelevant.
First, the software must run as a long-lived process that survives maintenance. Second, the implementation must be able to create its virtual interface; on Linux that usually means opening /dev/net/tun with the relevant administrative permission, as the kernel TUN/TAP documentation describes, though not every VPN design uses that device. Third, clients must reach the listener on the public address, transport and port you intend, and a web reverse proxy accepting HTTPS says nothing about an unrelated protocol on the same number. Fourth, admitted traffic must be able to go onward, with routes, forwarding and any translation actually supported.
Terms of service sit beside those four and are not technical at all. Unlimited traffic allowances usually describe web requests, not a tunnel carrying other people's downloads. Read the acceptable-use section before designing around it, and keep recovery access in mind for the day the service will not start.
Where a website account stops short
A website plan typically runs your code inside a managed runtime with a fixed entry point. Even where a tunnel binary is present, the process may lack permission to open a device node, bind a privileged port or alter the routing table. Those restrictions are the product, not an oversight.
That is why a plug-in promising a VPN usually turns out to be a proxy to somewhere else. If the current account offers only website controls, the honest move is a separate server, not a search for the module that unlocks the missing authority.
When one host must run both
Sharing is possible and sometimes sensible, but treat it as a security decision rather than a convenience. A web application with an upload form sits next to tunnel credentials and a control socket, and an exploit in one reaches the other. Separate accounts, separate service units and separate filesystems reduce that exposure without buying a second machine.
Resource contention matters as much. A backup over the tunnel and a busy web process compete for the same uplink and the same disk, and the failure looks like a slow site rather than a saturated tunnel. Decide which workload wins before the incident, and cap the tunnel so the website keeps answering.
Neither arrangement is isolated just because both services run. Capability to host them together is the start of the design, and the isolation work is what makes it defensible.
Settle it on a trial host with four commands
Before migrating, rent the smallest instance of the target product for an hour and test the four capabilities directly. Guessing from a feature table wastes less money than a year of the wrong plan, but far more time.
Run these on the trial host and read the failures as answers, not obstacles:
ls -l /dev/net/tun
sudo ip tuntap add dev tun9 mode tun && sudo ip link del tun9
sysctl net.ipv4.ip_forward
ss -lunp | headThe first two lines tell you whether a tunnel device can exist at all. The third reports whether the host may forward packets, and the fourth shows what is already listening so a port conflict is caught early. A provider that fails the second line may still support a userspace implementation, so name the mechanism you need rather than the product category when you ask their support desk.