I used to want to manage everything about the application, the entire stack, myself. This was recently enough that, in the last big application I worked on, I set up everything in docker containers and tried to keep track of all the configuration files and settings. Admittedly, docker (which I had recently started dabbling with when I started on that application) makes deploying stacks superficially easy.

But there's so much that goes into only the web server (load balancing, caching, host configuration, routing, etc) that it's next to impossible to keep everything in check and, more importantly, safe and updated unless one focuses almost entirely on maintenance.

So, IMO, the "don'ts" of managing one's own web server is doing it at all unless one wants to dedicate a huge amount of time to it.

I no longer want to do that and I'd rather just code so I'd say the "dos", for a novice developer, is letting people who are already working on that to keep working on that. The easiest way to do this is using whatever cloud is more suitable; all of the bigger ones offer free tiers and/or trial runs one can use to experiment and prototype.

I've been on both sides of the fence. Relying on 3rd party vendors for everything and doing it all on my own.

There are pro's and con's to both. Third party services are great - they can take care of a lot of pains a small team might encounter and allow time to do what you want to. The con to this is not having control of your system. If a vendor has a problem, sometimes theres nothing you can do but wait until the issue is resolved. If a vendor shuts down, hopefully, you have enough time to migrate to another system, but now this has caused you un-needed work.

Running your own servers takes more time and resources, but at least 99% of the time, you can exit easily. Your host of choice closes tomorrow? OK. There are hundreds of places to host a site. It should be easy enough to walk away and start new somewhere else.

The actual dos and dont's are long and too specific to any given setup. What I would do and don't will be vastly different from the systems admin next to me. We have different needs; different requirements; different budgets.

No given task is every particularly complex. Setting up a load balancer? Sure, if you don't know what your doing could seam like a complex task, but once you've done it a few times, it'll be a 10 minute task eventually. Host configuration? Again - might be complex if you've never done it, but once you do it a few times, it's no big deal.

As @emilmoe inquired - this is how I determine how many servers are in my load balancer pool.

By the minute metrics report to me what's happening on the servers and if load becomes to high (usually determined by ram used, but cpu plays into it) additional servers will be brought on. Screenshot taken with 1321 users browsing the site (as reported by Google Analytics)

Depends what you want as @luord mentioned if you want to be a developer maybe you should not manage your webserver.

I have a pretty advanced setup:

HAProxy as a load balancer so the server uses port 80 and 443 for Apache, NGINX, jetty, tomcat, .... I got several docker containers in the background for the FPMs / NPMs / Ruby as well as several containers for elastic search, couchdb, mongodb, neo4j, pgsql, mysql

For the "normal" devs I create vagrant boxes so it's easier for them, but I'm thinking of switchting to docker-swarm + docker-compose.

One thing that is important is that you only got 1 port 80 and 1 port 443 on your server and at least for the SSL you need 443, because browsers are pretty stupid about that :) .... "there can only be SSL one 443" so you will need proxies as soon as you got more than 1 http-server :) which means you probably will need OSI layer-6 access on the first entry point.

So as you grow you will learn but as luis orduz mentioned if you're not really interessted maybe using a cloud service is easier ? and in the end if the people are right cloud is the future ;D ... we now have AWS-lambda where you can use serverless architecture or S3 where we have an unlimited stateless store for your data and so on :)

But this is only the web-server there are no virtual networks for communications and no log aggregation if your system get's more complex :)

I would just try to know the basics and if you can, get an OPs guy :) ...

I once wrote a list of topics to remember when securing a webserver. I planned to write it into an article, but I haven't come so far yet. I have tried to add (?) to some of them as these are also questions to myself if it's even possible. Here are the topics, maybe you can use it for guidelines:

Things you should always do

• Don’t run unnecessary services
• Improve security with SUDO
• Get emails for every security update
• Firewall (iptables)
• SSH key and forced SSH password
• Protect your passwords (1Password, never use twice)
• Only provide source control deploy keys for the server

How to further enhance security

• Private networked database server
• Encrypt critical files
• Private networked backup

Increase security even more

• VPS SSH tunnel
• 2 factor SSH authentication (?)

Files outside the server

• Encrypt your local workspaces
• Trust your third party services (source control)
• Never commit passwords to source control

Check out https://serversforhackers.com/ . Chris Fidao (@fideloper on Twitter) does an awesome job explaining the ins and outs of server administration.