Ubuntu VPS server operation  at a high standard.

A VPS (Virtual Private Server) is an isolated virtual machine created inside a physical server, with its own operating system, its own file system and guaranteed resources. It behaves as if it were your own server, with root access and software you can install freely, but the physical hardware is shared by several tenants. Modern virtualisation (typically KVM) guarantees that neighbouring instances cannot see each other data or take each other resources.

The VPS rental fee starts at around €10 a month for a smaller machine with one or two vCPUs, and grows in proportion to its size. That, however, is only the price of the hardware. On top of it come the one-off commissioning, when a bare install becomes a protected, tuned environment, and the monthly fee for ongoing operation, if you do not want to supervise it yourself. The specific ranges are set out in the pricing section.

With an unmanaged VPS the provider gives you the virtual machine and the network; everything else is your responsibility: installation, security, updates, backups, troubleshooting. With a managed VPS an operator takes that on. The difference shows when something goes wrong: with an unmanaged machine the provider will at most tell you that the virtual machine is running. Why the website is not is none of their business.

Ubuntu Server is the most widely used Linux distribution for web serving, which brings two practical advantages: almost every piece of software has an official package and documentation for it, and whatever fault we run into, chances are someone has hit it before. LTS (Long Term Support) releases get five years of standard security support, so the system stays updatable for years without forcing a full version change every six months.

Not necessarily; that is exactly why managed operation exists. Supervising an average web environment does not fill a full-time position, but it does require expertise. The monthly operation fee is a fraction of the cost of an employee, and in exchange the knowledge and the availability are continuous. If you have an in-house IT person we can still work together – with many clients we provide server-level support alongside the internal team.

An environment for an average website comes together in 2–4 working days, from the survey to going live. For a webshop, where a cache layer, a search engine and performance tuning are also needed, it is 4–10 working days. The time for a migration depends mainly on the volume of data and the state of the old environment, because mapping out an undocumented server that has grown together over years sometimes takes longer than the move itself.

Yes, and planned properly the downtime is measured in minutes rather than hours. The method: we build and test the new environment in advance, lower the DNS time to live (TTL) the day before, then switch over and copy the fresh data during a low traffic window. We keep the old server running in parallel for days afterwards, so there is somewhere to step back to.

That depends on the system, the size of the catalogue and the traffic, not on a general rule. A WooCommerce shop with a few hundred products usually runs well on a few vCPUs and a couple of gigabytes of memory, while a Magento 2 system needs serious memory for indexing and the search engine alone. We always start sizing by calculating from real load data, and we prefer a package that can scale over one that is over-sized from the start.

On its own, rarely. A provider snapshot is taken of the whole machine, is often stored in the same infrastructure, and is kept only for a short time. If a single table or file has to be restored, a snapshot is too blunt a tool; and if the provider account is compromised, the snapshot goes with it. That is why in every case we also make versioned backups to separate, independent storage.

Exactly as secure as it is looked after. Automated password guessing starts against a fresh, exposed Ubuntu VPS running on defaults within hours. That is why commissioning includes key-based SSH login, disabling password login, a firewall that denies by default, automatic banning of repeated attempts, and minimising the set of running services. Most compromised servers are not the victims of an elaborate attack but of an update that never happened.

In that case we do not clean up an infected system, because after a compromise it can never be stated with certainty that every back door is gone. The correct procedure is: isolate the server, identify the route of the intrusion from the logs, then build a clean environment and restore the data under control, closing the exploited gap along the way. That is what makes a working backup system worth so much.

If the overwhelming majority of visitors are Hungarian, a domestic or central European data centre makes sense: the shorter network path gives a measurably better response time, which shows up in the Core Web Vitals too. For an international audience the difference can be evened out with a CDN. From a privacy point of view a data centre inside the European Union is the easiest choice to defend.

Not automatically. A VPS running on defaults can be slower than well optimised hosting. The advantage of a VPS is not raw speed but control: you decide what cache layer runs, how much memory the database gets, which PHP settings apply. Speed comes out of that control, when someone uses it with expertise.

It is not compulsory, and if we run the operation it is usually unnecessary: control panels mean a licence fee, more resource use and another attack surface. If you do need an interface of your own, for example to manage hosting for several clients, one can be installed, and there are free alternatives too. We settle this at the survey.

Yes, and it is often the most economical solution. The key is isolation: every site gets its own system user, its own PHP-FPM pool and its own database access, so a security problem on one site does not spread to the others. It is worth making sure, though, that a project which would steal resources at peak times does not end up next to a high traffic webshop.

In two directions. Vertically: more vCPU and memory can be requested from the provider, which usually involves a short restart. Horizontally: the web layer and the database can be split onto separate machines, a load balancer can be put in front, and static content can be moved to a CDN. For most Hungarian webshops the first route is enough for a long time; the second comes when the traffic really demands it.

Yes. The server is your property or your subscription, so full access comes with it, as does written documentation of the environment. Our only request is that while we run it together, manual configuration changes are agreed with us, because an undocumented change is the most common reason a previously stable system suddenly breaks on its own.

There is no technical captivity. The server, the domain, the backups and the documentation stay yours, and we hand the credentials over to the next operator with a handover record. We do not use closed solutions only we understand: the environment is standard Ubuntu with standard services, so any professional can take it on.

The server-side Google Tag Manager runs in its own container and uses resources in proportion to traffic; for small to medium traffic a dedicated VPS is more than enough, with its own subdomain and certificate. The advantage is that the measurement does not depend on an external script, the advertising data is more accurate, and what leaves the system is easier to control from a privacy point of view.

We use it. The systems of WebPot DEV, including this website and the webshops we build, run in Ubuntu VPS environments built on exactly these principles. What did not work out for us, we do not recommend to a client either.

It is not compulsory, but in many cases it is worth it. Even the free tier of Cloudflare provides DDoS protection, bot filtering and a global cache for static content, which gives visitors abroad a good response time from a Hungarian VPS. When configuring it, care is needed so the cache layers do not conflict. On request we handle the setup and the fine tuning too.

Technically yes, but running incoming and outgoing mail is one of the most delicate server tasks: deliverability depends on IP reputation and on precise SPF, DKIM and DMARC settings. We set up the transactional mail of the website (order confirmations, forms) properly from the VPS, but for full company e-mail we often recommend a dedicated mail service. We make that decision together at the survey.

Yes; on request we set up a separate staging environment alongside the live one, on the same VPS or on a separate machine. Updates, new development work and larger configuration changes run here first and only go live after review. For a webshop this is the basis of safe operation, not a luxury.

Every server we operate is monitored around the clock with automatic alerts, so we usually know about a problem before the visitors do. In an outage we act as a priority; the response time undertaken differs by package and is set out in writing. For business-critical systems we agree a bespoke SLA.