What to set up on a server before launch

A provider hands over a server in about a minute. An email arrives with the server’s address and an administrator password, and their involvement ends there. What follows is an empty system with no web server, no database, no mail and no protection.

What that system needs before launch is worth knowing even if you will never configure it yourself. That way you understand what an invoice covers and can check that everything was actually done.

What the provider gives you and what you configure

The line of responsibility runs exactly along the hardware and the network. Everything above that is your area.

If you are not yet sure whether you need your own server at all, that question has its own answer in our article on your own server versus shared hosting.

Basic security before anything else

Order matters here. A server connected to the network starts receiving password-guessing attempts within the first hours. These attempts are not aimed at you specifically. Automated programs scan address ranges and try standard combinations. So access is locked down before a single site file is uploaded.

The second rule of order concerns the sequence of services. First the system and access, then the web server and the database, then mail and certificates, and the site itself last. Starting with the site means every subsequent change requires checking that nothing already working has broken.

Access and keys instead of passwords

• A separate account instead of the administrator. Working with the highest privileges turns any mistake into a catastrophe.
• Login by key. Passwords get reused and leaked, but a cryptographic key is never typed in or memorized, so it cannot be stolen the same way.
• Password login disabled. While it is on, guessing continues around the clock.
• An account per person. So that when someone leaves, you disable one account instead of changing every password.
• Separate users for services. Neither the web server nor the database should run as the administrator.

Firewall rules and system updates

Next, everything that does not need to face outward is closed. Only what the site cannot work without is open. Everything else is closed by default.

System updates are configured so that critical security fixes are applied automatically and the rest on a schedule. Fully automatic updates for everything are convenient, but one day they will restart a service at an awkward moment.

This work is not a one-off. It repeats every month and is part of server administration, or is done on request, $25/hr.

Web server, PHP and database

Here begins the part that determines how fast the site runs.

• The PHP version. The one the site is built for, not the newest available.
• Memory and execution time limits. Set for the actual load, not left at defaults.
• Upload size. Otherwise an administrator cannot upload a large image or a price file.
• The number of worker processes. Too many and the server runs out of memory, too few and visitors queue.
• Database settings. Memory for the buffer pool, log sizes, character encoding.

A mistake in the last point is the most common. A database is configured by default for the most modest server, and if that is not changed, a server with plenty of memory will perform like the cheapest hosting. The owner sees that the move gained nothing and draws the wrong conclusion about the hardware.

The second most common mistake concerns the number of worker processes. There is no universal number: it is calculated from the available memory and from how much one process consumes on your site. A shop with heavy pages and a brochure site on the same server need different settings, and a figure copied from somebody else’s guide produces either idle memory or rejected requests at peak hours.

Caching and load limits

Caching is installed before launch, not after complaints about slowness.

• Page caching. The server returns a previously assembled copy instead of building the page each time.
• An in-memory object cache. Removes repeated identical queries.
• An opcode cache (OPcache). PHP does not recompile the same files on every request.
• Compression and browser headers. So a repeat visit does not pull everything down again.

Caching does not cure a slow site, it only removes part of the load. If a page is heavy in itself, that shows on a fast server too, and the reasons for such slowness are covered in our article on why a website loads slowly.

Limits are set separately: how many simultaneous connections to serve and what to do with the rest. Without that, a server fails under a traffic surge not because it lacks resources but because it tries to serve everyone at once.

Mail and its reputation

The server a site sends mail from is unknown to receiving services at first. Until verification is configured, messages either go to junk or do not arrive at all.

• Sender verification records. Three different mechanisms, and all three are needed.
• The server’s name on the network. It must match what the server presents itself as.
• The reverse record. The provider sets it on request. Gmail requires valid forward and reverse DNS records from every sender, and without them mail may not be delivered or may be marked as spam.
• A separate address for the site. So that mailing problems do not affect staff mail.

This is the part most often postponed. The predictable result is that the shop takes orders, buyers receive no confirmations, and it is noticed only through complaints.

What to do about other mail on the same domain

A separate confusion arises when staff mail lives in one service while the site sends from the server. Formally these are two different senders on one domain, and both must be configured, otherwise verifying one undermines trust in the other.

This is solved with a careful record listing every legitimate sender. It is a small job, and a mistake here means either mail from the site never arrives or company mail suddenly starts landing in junk.

Certificates and automatic renewal

The certificate is issued before any traffic reaches the site. Renewal is automated, but with a check.

Automation fails quietly. The renewal script stops working after a system update, nobody notices, and two months later visitors get a browser warning. So alongside the automation an alert is set for two weeks before expiry.

Several sites on one server

If more than one project lives on the same server, separation is added to the list. Each site runs as its own user and has no access to its neighbor’s folders. Without that, one compromised site means all of them are compromised.

The one that suffers is usually not the main project but a forgotten test environment nobody has updated for a year. It provides access to the server, and from there to everything else.

Backups off the server

A backup sitting on the same server is not a backup. When the disk fails, everything disappears at once.

• Separate storage. Another environment or cloud storage, not a neighboring folder.
• Files and database from the same moment. Schedules may differ, but the restore point has to be shared, or the database will not match the files.
• Several generations. So you can go back not only to yesterday but to a week ago.
• A restore check. Once a quarter a copy is deployed and the site is checked.
• A measured duration. How many hours a full return to service actually takes.

The last two are rarely done, and they are exactly what turns a copy from a hope into a working tool.

Another decision taken at setup is retention depth. Daily backups for the last week, weekly for a month, monthly for a year. Such a set takes little space and covers most real scenarios: from “we deleted a section by accident yesterday” to “we noticed the corrupted database a month later”.

Monitoring and alerts

A server should report its own problems rather than have you hear about them from a customer.

• Site availability. Checked every minute from an external point, not from the same server.
• Disk space. A full disk stops a site just as reliably as a hardware failure.
• Load and memory. So growth is visible in advance rather than at the moment of collapse.
• Certificate expiry. With two weeks to spare.
• Errors in the logs. A sharp rise in their number is an early sign of trouble.

Alerts must reach the person who actually responds, through a channel they read. An email to a mailbox nobody opens is monitoring in name only.

Regular care of this kind is part of server maintenance, whether the server runs one site or several.

What is checked before traffic is allowed in

The final check happens before the domain is switched, and the switching procedure itself is covered in our article on how to move a website to a new server.

• Every type of page opens. Not only the home page.
• The admin area works, including saving. Together with file uploads.
• Checkout goes through. For a shop, right down to a test payment.
• Mail is delivered. And does not land in junk.
• Scheduled jobs run. At least one cycle.
• The error log is empty. Checked once every page has been opened.
• A copy is taken and restored. Before launch, not after.

What it costs and who runs the server afterwards

The initial setup is one-off work, and its size depends on what has to live on the server. A company site with mail and backups takes less time than a shop with a task queue and an accounting integration. A server for the accounting software itself follows different rules, and we cover them in a separate article on servers for accounting software.

Then comes the regular part, and it does not depend on whether anything happened this month: the system is updated, backups are taken and verified, monitoring runs, and somebody has to be ready to respond to an outage. Monthly care with us starts at $400/mo, and work outside that list is billed hourly.

Comparing this figure with the price of hosting is misleading. On hosting the listed work is included in the plan and performed by the provider for all their clients at once. Here one project pays for the same work. The difference in price is the payment for dedicated resources and freedom of configuration.

Conclusions

Preparing a server takes more than an evening, and the order of the steps matters. Access is locked down first, then services are installed, then mail, certificates, backups and monitoring, and only after a full check are visitors allowed in.

A skipped step is usually not visible straight away. An open access route, a copy on the same server or broken certificate renewal make themselves known weeks later, and always at an awkward moment.

If you already have a server and are not sure everything on it has been done, create a separate account with key-based login for us, or at least describe what is installed. We will work down the list above and tell you what is configured, what is missing and what to fix first. If the server is in order, you get a report and a maintenance schedule. If it is still at the planning stage, describe the project and we will size a configuration for your load rather than with a margin just in case.