Your own server or shared hosting for a website

Not every site needs its own server. Most websites live on shared hosting for years and have no reason to leave. The question comes up when a site starts hitting the limits of its plan and the provider replies that this is normal behavior in a shared environment.

Your own server gives you more resources and more control, but it adds day-to-day maintenance, and somebody has to do that work.

What you are renting in each case

On shared hosting you rent space inside somebody else’s system. The provider has already set up the operating system, the web server, the database and the mail. You get a control panel, access to files and a set of limits.

Your own server starts out empty, and configuring it is on you. The provider hands over a virtual or physical server and a network connection. Everything else is installed for the specific project: the PHP version, the web server, caching, email, backups, access rules. Which of these have to be ready before the first visitor arrives is covered in our guide to server setup before launching a website.

The difference between the two shows up in four places.

• Plan limits. On hosting they are fixed in advance and identical for everyone on that server. On a server you decide how much memory goes to the database and how much to the web server.
• The set of services. Hosting gives you what is on the price list. On a server you can add a task queue, a separate search engine or anything else.
• Responsibility for failures. On hosting the provider is responsible for the platform and you for the site itself. On your own server all of it is on you or your contractor.
• Speed of change. Switching the PHP version on hosting takes a minute in the panel. On a server it is planned work, but with no restrictions from the provider.

Who answers when something breaks

On hosting, if the platform itself is down, that is the provider’s concern. If your site hits a plan limit, you will be offered a higher plan, and that is where the conversation ends.

On your own server, system updates, patching vulnerabilities, disk space, log rotation and how the site behaves after a reboot all become your responsibility. That is exactly why your own server makes sense when there is somebody to run it, and makes no sense when there is not.

What control actually gives you

Control is useful only in specific situations.

• A service outside the plan is required. A task queue, a separate search engine, an in-memory cache.
• Heavy background jobs need separating. So that a price import does not get in the way of customers placing orders.
• A specific library version is required. One that an integration with an accounting system depends on.
• There are requirements about where data sits. Sometimes a client or a partner insists that data stays in a particular country.

On shared hosting you usually cannot install your own software or change server settings, whatever the plan. Some providers offer an in-memory cache on higher plans or for an extra fee, and shared hosting can also meet the data location requirement if its data center is in that country.

Signs that hosting is no longer enough

The site goes down predictably

The most reliable sign is failures at peak hours. The shop opens fine in the morning, then starts returning errors during a mailing or an advertising campaign. If this repeats and is tied to load rather than to a random glitch, the problem really is resources.

A one-off failure at night more often means maintenance on the provider’s side or a fault in a freshly updated plugin. Before treating it as a reason to move, it is worth reading the logs for that period and understanding what actually happened.

The host limits your processes

The second signal is emails from the provider saying you have exceeded your limits. Shared hosting protects the neighbors on the server, so it caps the number of simultaneous processes and how long scripts may run. A shop with a large catalog, regular price imports and background jobs hits those limits far sooner than a small brochure site.

Typically, the price import starts at night, does not finish within the allotted time, breaks off halfway, and in the morning part of the catalog still shows old prices. A higher plan buys a little more time, but the problem returns as soon as the catalog grows.

You need something the plan does not have

The third reason has nothing to do with load at all. The project needs a task queue, a separate search service, a long background process or non-standard caching. Shared hosting does not offer these, and the question is only resolved by moving.

When moving is not the answer

The most common mistake is moving for the sake of speed when the site is slow for a different reason. Heavy images, unnecessary plugins, database queries without indexes and missing caching slow a site down equally on any hardware.

Situations where a move will change nothing come down to three.

• The site has never been optimized. Things will feel better for a few weeks, then the load returns and the cause is still there. There is more on this in our article on why a website loads slowly.
• There is nobody to run the server. Left unattended for six months, it collects missing updates, a full disk and expired certificates. That is worse than shared hosting, where at least the provider handles the basics.
• Moving for the sake of status. Sometimes a server is ordered because an acquaintance recommended it, not because the site is running short of resources. That is money spent with no return for the business.

VPS, VDS or a dedicated server

The names differ between providers, and confusion here is normal.

In practice, the difference between VPS and VDS at most providers comes down to how strictly the resources are reserved. For maintenance it changes almost nothing: updates, backups and reaction to failures are the same in both cases.

A dedicated physical server is needed less often than it is offered. It is justified under constant high load or when there are requirements about data isolation. For a mid-sized shop a virtual server is more than enough.

What changes after the move

After the move, these tasks become part of the routine.

• System and control panel updates. Once a month or more often when a critical fix appears.
• Certificate renewal. Automated, but with a check that it actually worked.
• Log clean-up. Otherwise the disk fills within a few months and the site goes down for no visible reason.
• Backup verification. A test restore that works, since a backup file can exist and still fail to restore.
• Availability monitoring. With alerts going to the person who actually responds.
• Incident review. After every failure you need to understand the cause, or it will repeat.

This is not a one-off setup but a monthly rhythm. When nobody keeps it, the server quietly degrades and the first symptom arrives in the form of an outage.

Backups become your problem

On hosting, backups are most often made by the provider on a schedule. On your own server you set them up yourself, store them away from it and try restoring from them now and then. A copy you have never restored from is an assumption, not insurance.

It is also worth measuring how long a full restore takes. A shop that comes back in twenty minutes and a shop that comes back in four hours have very different consequences for sales.

Somebody has to react to outages

On shared hosting the provider sees the platform go down and fixes it. When the server is yours, you need to know about downtime before your customers do. That means monitoring, and an agreement in advance about who reacts and at what time of day.

This work is part of server administration on an ongoing basis, or is done on request, depending on how much attention the project needs. Regular maintenance is covered in detail in our article on what website support includes. We also wrote separately about a server for accounting software, where the requirements for it are different.

A self-check before deciding

Before ordering a server it helps to answer a few questions. They quickly show whether the problem really is resources.

• Failures repeat at the same time or during the same actions, rather than randomly
• The provider has sent notices about exceeding process or execution-time limits
• The site has already been optimized: images compressed, caching on, unused plugins removed, and the load is still there
• The project needs a service outside the plan: a queue, a search engine, a specific library version
• There is somebody to run the server: your own person or a contractor on a support agreement

If the answer to the last question is no, moving is premature whatever the other answers are. If someone is there to run the server and one or two of the first four apply, moving is most likely premature. If three or four apply, including the one about optimization, your own server is justified. All that is left is to plan the move and choose a configuration.

How long the move takes

The sequence itself is set out in our article on how to move a website to a new server. How long it takes depends on the project, and we review it before setting exact timelines in the contract. Moving the database and files usually takes less time than the preparation: collecting current settings, choosing a configuration, checking on a test environment and picking a window for the switch.

Mail is planned separately. If the site sends order notifications, they may stop arriving after the move until the domain records are configured. This is the most common headache of the first days, and it is entirely predictable if you remember it in advance.

The switch is scheduled for the quietest traffic hours. For most shops that is a weeknight, but the precise answer comes from the analytics of the specific project, not from a general rule.

What to do with the old environment

The old environment should not be switched off immediately after the cutover. For a week or two it stays as a fallback in case something was missed. After that it can be shut down once you have made a full backup and checked that it can be restored.

The domain and the certificates do not move by themselves. Certificate expiry, mail settings and domain records are checked separately, because they most often stay behind and make themselves known a few weeks later, when everyone has forgotten about the move. What else is worth checking in the first weeks after the switch is covered in our article on what to do with your website after launch.

Security works differently

On shared hosting the basic protection is configured by the provider. It filters obvious attacks, restricts access to other people’s directories and updates system packages without your involvement. You are mainly responsible for the site itself: administrator passwords, keeping the CMS and plugins current, file permissions.

On your own server a second layer appears. Ports open to the outside, access over SSH, firewall rules, separate accounts for people and for services, kernel updates. A mistake here costs more than a mistake in a plugin, because it grants access not to one site but to the whole server.

Split access from day one

The temptation to make one account with full rights and hand it to everyone working on the project is strong. A year later nobody remembers how many people had that password or whether any former contractor still has it.

A workable setup is simpler than it seems.

• A separate account per person. With the minimum rights needed, not full ones.
• Services run as their own users. The web server, the database and the queue should not run as the administrator.
• Login by key rather than password. A password can be guessed or intercepted; a key cannot be brute-forced.
• An access log. Who connected, when and why.

When a person leaves the project, one account is disabled rather than every password changed at once.

What it actually costs

Comparing the price of a hosting plan with the price of renting a server is misleading. In the second case maintenance is added to the cost of the hardware, and it is needed every month whether anything happens or not.

A full calculation has three parts.

• Renting the server from a provider. Depends on the memory, disks and bandwidth you need.
• Regular maintenance. Updates, backups, monitoring and reaction to failures. With us that starts at $400/mo as part of server administration.
• One-off work. Migration, reconfiguration for new load, dealing with the aftermath of an incident. Charged hourly, $25/hr.

The second part is what most often drops out of the calculation at the decision stage. The owner compares rent with a hosting plan, sees an acceptable difference and moves, then a few months later runs into the fact that nobody is looking after the server. How to count these costs together with everything else is shown in our article on the online store estimate.

Typical mistakes in the first months

• Monitoring is missing, and downtime is discovered through a customer’s phone call
• Updates are postponed until a vulnerability appears, the server is used for somebody else’s mailings, and the domain lands on blocklists
• Backups sit on the same server, so when the disk fails they disappear along with the site
• There is no agreed window for planned work, and a system update needs a reboot; for a shop, the difference between three in the morning and three in the afternoon is measured in orders
• Access was handed out and forgotten, and a year later nobody knows who has the password

Who should run the maintenance

There are three options, and each carries a different cost of error.

• An in-house administrator. Justified when there are several servers or when the project is critical to the company’s operations. For a single shop this is excessive: the person is busy for a few hours a month and paid a full salary.
• One-off contractors. Cheaper, but they create a gap in responsibility. Whoever configured the server six months ago does not remember the setup, and a new contractor spends hours working out somebody else’s solution before the first fix.
• A contractor on ongoing maintenance. Keeps the context between requests: knows which services are installed, when the system was last updated and where the backups are. For projects that lose orders whenever the server is down, this is the better deal over a year, because incidents are resolved faster and some of them never happen.

Whatever the option, put two things in writing. Who reacts to downtime and at what hours. Where access credentials are stored and who is entitled to them. Without that, the first serious incident turns into an argument about whose responsibility it was.

Conclusions

Your own server is a tool for a specific job. It is justified when load hits the limits of the plan, when services unavailable on shared hosting are needed, and when there is somebody to run the server afterwards.

If the site is slow because of heavy images and missing caching, moving will only carry the problem to a new place. Optimization first, the server decision second. In that order the spending turns out lower and the result more durable.

Do not rush to order hardware before you understand the cause. Send us the address of your site and describe exactly what it is running into: it goes down at peak hours, the import fails partway through, the host sends emails about limits. We will look at the load and the logs and come back with an answer on whether the problem is resources or the site itself, along with a list of what to fix in place. If a move is needed, we will pick a configuration to match your load and take the server on for ongoing maintenance as part of server administration.