VPS hosting for users in France

What a VPS is, and what you are actually choosing

VPS hosting for users in France comes down to two decisions: which location you rent in, and how much system administration you are willing to do yourself. Everything else on a pricing page is a variation on those two. This page covers both, plus the parts specific to this market: euro prices with TVA either added or already included, what RGPD does and does not ask about location, and the plain fact that nobody patches an unmanaged server except you.

A VPS (virtual private server) is one machine. A physical server in a data centre runs a hypervisor, the hypervisor divides the hardware into slices, and each slice boots its own kernel and its own copy of Linux. Your slice holds a fixed amount of RAM, a set number of virtual CPU cores, a disk, and at least one public IP address. You get root on it, which means you pick the distribution, install what you want, open the ports you want, and own every mistake. The other tenants on that host cannot read your disk.

Root access is the product and it is also the obligation. No control panel decides what you may run, and no operator reads your logs at night. The full definition of a VPS, and how it differs from shared hosting goes further into that boundary. If you have never held root on a machine that faces the public internet, read what you take on when you rent one before you pay for anything.

Where to host a VPS for users in France

Paris is the obvious location and it is often the right one. France-IX, the largest French internet exchange point, is there, and the big French consumer networks exchange traffic in the region, so packets between a Paris machine and a subscriber line in France usually stay inside the country.

Then the neighbours. Frankfurt, Amsterdam, London and Zurich all sit within a few hundred kilometres of the French border, and the fibre routes between them are among the busiest in the world. A VPS in Frankfurt sits beside DE-CIX and a VPS in Amsterdam sits beside AMS-IX, two of the largest exchanges in Europe, which is why so many European networks meet in those two cities. For a French audience these are not exotic choices. They are usually a few milliseconds further away than Paris, and sometimes, depending on how your visitor's ISP (internet service provider) peers, a machine in Frankfurt is closer in network terms than a Paris machine on a poorly connected network.

That last point is the one to remember. Network distance is not map distance. A packet from a home connection in Marseille to a server in Paris can travel by way of Frankfurt, because that is where the two networks hand traffic to each other. Two machines both advertised as "Paris" can be six hops apart or sixteen. Nobody can tell you in advance what your latency will be, including the provider. You measure it.

Readers elsewhere in Europe run the same decision with a different set of neighbours, and the same choice worked through from Poland is worth reading if you serve more than one market.

How to measure latency from your own connection

Ask the provider for a test IP address, a looking glass, or a test file URL in each location you are considering. Most publish them. Then run the tests from the network your users are on, not only from your office connection.

# set this to the looking glass or test host for the location you are considering
TESTHOST=lg-paris.example.net
ping -c 20 "$TESTHOST"

The final line reports rtt min/avg/max/mdev. The avg figure is your round trip time. The mdev figure is jitter, the variation between packets, and a high value there hurts interactive traffic more than a slightly higher average does.

mtr -rwzc 50 "$TESTHOST"

mtr sends 50 probes and prints one line per hop, with loss and latency for each. A middle hop showing 100 percent loss is normal and is not your problem, because many routers deprioritise or rate limit the ICMP (internet control message protocol) replies that mtr depends on. Only loss that continues all the way to the final hop is real loss.

ICMP is also not what your users send, so measure the thing a browser actually does:

curl -o /dev/null -s \
  -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' \
  https://<test URL in that location>/

Each field is seconds counted from the start of the request, so subtract to get the pieces. time_connect minus time_namelookup is one TCP round trip. time_appconnect minus time_connect is the TLS (transport layer security) handshake, which costs one further round trip on TLS 1.3 and two on TLS 1.2. time_starttransfer minus time_appconnect is the server thinking, and no location change improves that number.

Run all of it more than once. Consumer networks in France are busiest in the evening, so a test at 11:00 and a test at 21:00 can disagree. Mobile networks add radio latency of their own, and no data centre choice removes it.

What tens of milliseconds cost on a page

One round trip is cheap. A page is not one round trip. The browser resolves a name, opens a TCP connection, negotiates TLS, asks for the HTML, then asks for every referenced asset it has not already cached, and behind all of that your application may call a database or a payment API somewhere else again. Latency is paid once for every step that has to wait for the step before it.

[
  {
    "label": "1 round trip",
    "ms_at_10ms_rtt": 10,
    "ms_at_40ms_rtt": 40,
    "ms_at_120ms_rtt": 120
  },
  {
    "label": "10 round trips",
    "ms_at_10ms_rtt": 100,
    "ms_at_40ms_rtt": 400,
    "ms_at_120ms_rtt": "1,200"
  },
  {
    "label": "30 round trips",
    "ms_at_10ms_rtt": 300,
    "ms_at_40ms_rtt": "1,200",
    "ms_at_120ms_rtt": "3,600"
  },
  {
    "label": "60 round trips",
    "ms_at_10ms_rtt": 600,
    "ms_at_40ms_rtt": "2,400",
    "ms_at_120ms_rtt": "7,200"
  }
]

The block holds 4 page shapes at three sample round trip times. Every number in it is multiplication, not measurement: nothing here was measured on a real network, and the sample latencies are chosen to show the shape of the cost. A page with 60 sequential round trips adds 600 ms of pure waiting at 10 ms per trip and 7,200 ms at 120 ms per trip. At 30 round trips and 40 ms per trip the sum is 1,200 ms.

Real pages never pay the full serial sum, because browsers open several connections at once and HTTP/2 carries many requests over one connection. The shape still holds: latency multiplies by the number of steps that cannot start until an earlier step finishes. That is why moving a database off the web server and into another city hurts more than the distance suggests. Ten queries per page request, each crossing the same link, and the machine is not slow. The link is.

Which points at the cheaper fix. Removing round trips beats shortening them. Keep the application and its database on the same machine or the same local network, and set cache headers so the browser stops asking for files that have not changed. Then choose your location.

When hosting near your users beats hosting near you

You are one user. Your visitors are many. SSH at 120 ms feels sticky, and that stickiness costs one person, you, a few seconds a day. The same 120 ms on every page load costs every visitor on every request, permanently. Choose for the visitors.

The exception is when you are the workload. A build machine or a development box you drive interactively all day belongs near you, because you are the traffic. That is the argument for putting a long running development session on a VPS in the location closest to your desk rather than closest to your customers.

If your audience is France and its neighbours, one well connected location in western Europe serves all of it. Splitting across two locations doubles the patching, the monitoring, the backups and the number of places a certificate can expire, and it adds the hardest problem in the field, keeping two copies of a database in agreement. Do that when your measurements demand it, not before.

Euro prices, TVA, and the number you are comparing

Prices are quoted in euros, and the same machine can appear at two different numbers because of TVA (taxe sur la valeur ajoutée, French value added tax). As of September 2026 the standard rate in metropolitan France is 20 percent. Pages aimed at consumers usually show the price TTC (toutes taxes comprises, tax included). Pages aimed at businesses usually show it HT (hors taxes, before tax). An offer that looks 20 percent cheaper than another is often the same offer quoted the other way, so check the label before you compare anything.

If you are a French business with a valid intra-community VAT number, buying from a provider established in another EU country, the invoice normally arrives without VAT and you account for it yourself under the reverse charge (autoliquidation). A provider outside the EU selling to a French consumer is still required to charge French VAT on that sale. Rates in Corsica and in the overseas départements differ from the metropolitan rate. Confirm any of this with your accountant rather than with a hosting guide.

The tax is the easy part. What actually moves the cost over a year:

• the renewal price, which is often well above the first term price on a promotional offer
• the commitment, since an attractive monthly figure frequently assumes twelve or twenty-four months paid up front
• the bandwidth allowance, and whether exceeding it throttles the port or bills you per terabyte
• backups and snapshots, which are almost always a separate line
• extra IPv4 addresses, which are scarce and priced accordingly
• the size you will need in year two, rather than the size you are testing with today

A fuller breakdown of what a VPS costs once the extras are counted works through those. If the gap between two plans looks large, check whether one of them is managed, because the difference between managed and unmanaged plans is mostly the price of a person. And if you are pricing a large machine, compare it against a dedicated server before assuming the virtual one stays cheaper at that size.

What RGPD does and does not require

RGPD (règlement général sur la protection des données) is the French name for the GDPR. It does not require you to host in France. It does not require you to host in the European Union either. Personal data may leave the EEA (European Economic Area) under chapter V of the regulation, using an adequacy decision for the destination country, or standard contractual clauses backed by an assessment of that country's law.

What the regulation does require applies wherever the machine sits: a lawful basis for the processing, a written contract with your host acting as processor under article 28, a record of processing activities under article 30, security appropriate to the risk under article 32, and notification to the CNIL (Commission nationale de l'informatique et des libertés) within 72 hours of becoming aware of a personal data breach under article 33. Article 32 is where a VPS reader spends the effort, because on an unmanaged server every one of those measures is something you configured or did not configure.

Sector rules can pin the location where the regulation does not. Personal health data collected in the course of care activities in France must be held by a host holding HDS certification (hébergeur de données de santé). Public bodies handling sensitive state data are steered towards SecNumCloud qualified offers by the "cloud au centre" doctrine, which is French government policy rather than a rule in the RGPD.

Two separate things get folded into the regulation by mistake. The first is jurisdiction: a provider subject to United States law can receive a legal order for data it controls, whichever country the disk is in, which is why some buyers restrict themselves to European owned providers. That is a risk decision about your own threat model, and it sits outside the text of the RGPD. The second is the belief that a French location equals compliance. It does not. A server in Paris with an exposed database port and no processor contract is further from compliant than a well run server in Frankfurt.

Nobody patches this server but you

Unmanaged is the default, and it means the provider keeps the hypervisor, the network, the power and the disks alive. Everything above the virtual hardware is yours: the kernel, the packages, the firewall, the certificates, the backups, and the reboot after an upgrade goes wrong.

Start by making security updates automatic.

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

The upgrades are triggered by a systemd timer rather than by a daemon, so check the timer and then ask the tool what it would do:

systemctl list-timers apt-daily-upgrade.timer --no-pager
sudo unattended-upgrade --dry-run --debug

The dry run prints the packages it would install and writes the same detail to /var/log/unattended-upgrades/unattended-upgrades.log. An empty list right after a manual full-upgrade is the healthy result.

Automatic updates do not restart the machine. Unattended-Upgrade::Automatic-Reboot "false"; is the default in /etc/apt/apt.conf.d/50unattended-upgrades, which means a kernel security update is written to disk while the vulnerable kernel keeps running, and it keeps running until somebody reboots. The signal is a file:

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required

When a package that needs a restart has been installed, that prints *** System restart required ***. Either watch for that file or set Automatic-Reboot "true" together with Automatic-Reboot-Time at an hour you can afford to be offline.

Backups are the other thing that has no owner but you. A snapshot stored in the same provider account as the server is not a backup, because one compromised login or one billing failure removes both copies at the same moment. Keep a copy somewhere else, and restore it once so you know the restore works.

One failure mode is worth knowing because you cannot fix it from inside the machine. If the server feels slow while your own processes sit idle, look at the st column in top, which counts time the hypervisor gave to another tenant instead of to you. Reading steal time and dealing with a noisy neighbour covers what that number means and what to ask the provider. Separately, the cheapest plans per core are increasingly ARM based, so check that your software has ARM builds first: the practical differences between ARM and x86 instances are mostly about which binaries exist.

Your first hour on a new box

The account work has to happen before the machine holds anything worth taking. Replace the password that arrived by email, create an unprivileged user with sudo rights, add your SSH key, then turn off password authentication and reload the SSH daemon. Changing the root password on Ubuntu covers the first step. Better still, do the whole sequence at build time: a cloud-init file that creates the user and installs your key means the server is never online in its default state at all.

After that the order is deliberately boring. Firewall, updates, backups, monitoring, then the application. Pick the location from your own measurements, and pick the plan from the price you will be paying in year two.

FAQ

Do I have to host in France to comply with RGPD?

No. The RGPD names no country. It sets obligations that follow the data: a lawful basis, a processor contract under article 28, a record of processing under article 30, security appropriate to the risk under article 32, and rules under chapter V for sending personal data outside the EEA. A machine in Frankfurt or Amsterdam is inside the EEA, so it needs no transfer mechanism at all. Sector rules are a different matter. Personal health data collected during care activities in France must be held by an HDS certified host, and that requirement comes from the code de la santé publique rather than from the RGPD.

Is a VPS in Paris always faster for visitors in France?

Usually, but not always, because latency follows the network path rather than the map. If your visitor's ISP exchanges traffic with your provider in Frankfurt, packets to a Paris server can travel through Germany first. The only figure worth trusting is one you measured: ping -c 20 for the round trip time, mtr -rwzc 50 for the path and where loss appears, and a curl timing run against a real URL in that location for what a browser will feel. Run them from the connection your users have, in the evening as well as during the day.

Why is the same VPS listed at two different prices in euros?

One number is HT (hors taxes) and the other is TTC (toutes taxes comprises). As of September 2026 the standard TVA rate in metropolitan France is 20 percent, so a business price and a consumer price for the same machine differ by that much before you compare anything else. A French business with an intra-community VAT number, buying from a provider in another EU country, usually receives an invoice without VAT and accounts for the tax under the reverse charge.

Who installs security updates on an unmanaged VPS?

You do. The provider's responsibility ends at the virtual hardware and the network. Install unattended-upgrades so security packages land on their own, then remember that it does not reboot by default. A new kernel is written to disk while the old kernel keeps running, and the file /var/run/reboot-required appears with the text *** System restart required ***. Until you reboot, or set Unattended-Upgrade::Automatic-Reboot "true"; in /etc/apt/apt.conf.d/50unattended-upgrades, the patched kernel is not the running one.

How much RAM and CPU should I start with?

Start small and measure. Resizing up is usually a reboot, while resizing down is often not offered at all, so the small mistake is the cheap one. An instance with 1 or 2 GB of RAM runs a static site or a small application server with a database behind it. Add a swap file so a short memory spike does not end with the kernel's out of memory killer terminating your database, then watch free -h and the st column in top for a week before you pay for anything larger.