This is a proposed Canonical Question about Beginning Web Server Administration.

Assuming that you are a beginning SysAd, are new to WebOps, or a small team with little or no experienced Web Server SysAd support (and cannot afford it right now), what should you do to configure and secure a Web Server for your business?

  • You mention twice the benefits of having a sysad which implies that you are addressing people who are not sysads. Surey this then puts your Q&A out of scope for Server Fault which is for sysads et al ? Perhaps Super User is a better home for this ? – Iain Apr 8 '13 at 14:37
  • 8
    My reading of the FAQ is interpreted as 'technical professionals asking Systems Administration questions'. I've seen this kind of question asked many times from technical (but not SysAd) people (mostly Developers), and they are often responded to harshly instead of actually helped. This question is posed as a candidate to being a Canonical answer of Where to get started, and why they should hire real SysAd help ASAP. (And hopefully never have to answer this particular question again. – gWaldo Apr 8 '13 at 15:22
up vote 32 down vote accepted

Before We Begin:

Having quality people will save you money. Just like having a good Lawyer (possibly NSFW for swearing) or an accountant, having a quality SysAd will probably save you money, often by simply helping you to avoid costly mistakes. You may not have the money to pay for the expertise now, but as soon as you can, you should make that investment.

There is no simple, singular answer to this question. If you are one to ask this question, you must realize that this question is the core of a field that professionals invest years of study and practice in. The analogous question to a Developer would be "how do I write a Web Application?"; Sure, we could point you to a directions to installing Ruby-on-Rails and a RoR "Hello World". While that would 'answer the question', it wouldn't actually help you. This Q/A is an attempt to actually help you.

You should know:

Web Server Administration is a large topic, and it is intrinsically interweaved with many different disciplines. To do it well you will need a fundamental understanding of TCP/IP, your host OS, your WebServer Application, and some understanding of running the application stack.

Be prepared to read. A lot.

Identify your needs:


  • Are you running a plain, static website (maybe with some Javascript effects), or
  • (more likely) are you running an application that happens to have a web interface?
  • Do you have persistent data? (Do you need a database?)
  • Are there user credentials involved? Is there another reason that you'd need the connection between the user and website to be secured? (SSL)
  • Are you handling payments of any kind? In addition to having SSL requirements, there are additional considerations that you'll need to research (dependent on region). These will also vary depending on the payment processor that you use.

Identify your stack:

How are you going to write and run this?

  • Platform (Windows, Linux, other Unix, etc)
  • App requirements (Ruby/Rails, Python, Perl, PHP, .NET, etc, etc)
  • Database (...)
  • Caching? (Honestly, don't worry about this now; be aware that this solves some problems, and can create others. This is a problem of performance, and right now you're just trying to get started.)

Some of these choices will inform others. For instance, If you're running a .NET app, you probably want to use MSSQL and IIS; If you're running Ruby on Rails, you probably want a Linux server; etc...

Get to Know your Product:

Now that you've decided on what your stack will look like, you need to get to know it. This is where you should spend most of your time. Searching for "Configure [product]" or "[product] Admin Guide" should get you plenty of resources.

For instance, if you are running Apache on Ubuntu, you should absolutely read:

Look for similar docs, articles, blog posts for your stack.

Install the bare minimum:

There is a vast array of modules for Apache, but if you're not going to use PHP (for example), don't install mod-php.

It also should be stated here that you should avoid installing a GUI if it's a Linux server; GUI's use up a significant amount of system resources.

Securing the site:

  • Ensure minimal permissions to function. This applies not only to the filesystem, but also to services and processes
  • Keep server ports disabled for unneeded services. (Again, only install the minimum.)
  • Restrict application interfaces to the internal environment (if, for instance, running a web application on the same server (such as Rails), restrict it to only listen to localhost)

In Closing:

This is only the beginnings of what you should do to get a site up and running. This doesn't even begin to touch the problems of maintaining servers or how to handle problems of scaling (should your project become successful), nor any of the other myriad issues that a knowledgeable SysAd will solve for you.

  • Running the bare minimum is crucial, but it might not be obvious what/how to uninstall/disable/protect. Would it be acceptable to suggest to run a barebones, totally firewalled machine publicly that only forwards/proxies specific requests to their application server running on a private network? It would even be possible to suggest a distro/config for that since it doesn't need to be the same environment their app uses. – Carlos Lima Apr 10 '13 at 17:56
  • 1
    That's a good start. One thing you didn't cover is repeat-ability. At some point you'll grow beyond the current setup. Are your directions for setting up the environment repeatable? Better yet, are they automated? Are you saving all of the source packages so you can recreate the environment, or are you relying on external repositories? How will you know when it's time to upgrade? Are you tracking the proper metrics? How are you reporting on them? – toppledwagon Apr 11 '13 at 7:38
  • @toppledwagon Those are all good points, but I was addressing the 101 course. Everything you mentioned (consistency / config mgt, scaling, monitoring/metrics, etc) I feel come later. And honestly, I would rather recommend getting a Systems Pro than delving into those areas. – gWaldo Apr 11 '13 at 12:35
  • 3
    @toppledwagon Once you get to that point, you need a sysadmin. Or at least a Sysadmin-as-a-Service. – Michael Hampton May 28 '13 at 16:59

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.