We provide the server to run the site via one of the following providers: RipeGroup (Primus DC Melbourne), RipeGroup (Micron21 DC Melbourne), Amazon Web Services, Microsoft Azure, NextDC (Brisbane, Sydney, Melbourne).

This includes the initial build of the server and then the installation of whatever other server software is required. We do not get involved in the actual web development or "user code" areas. We do not charge a setup fee for a number of reasons: most of this build we have automated so a new machine is simply 5-10 minutes work; we need to know what system software is installed on the server so that we can provide alerts on that software when a new update is released.

1. Every week we update the server with the latest patches.
   Unless a specific version of the system software is required we always go with the latest production release of the software. In your case specific versions of some system software is required so we "hold back" updates to this software until we can consult with you as the client on what to do. In some limited cases we trial the updates on a test server to ensure that it does not affect the production site.
2. We then back that server up every night to "off server" storage either inside the AWS Cloud, the Microsoft Cloud or our own servers.
   These backups are kept for 90 days. This gives you the ability to reach back into history to retrieve files accidentally deleted and also to investigate possible performance or security issues.
3. Every Sunday night we take what is called a "snapshot" of the machine so that if we do have a disaster we have a starting point to work from.
   We would take this Sunday night snapshot and start up a new machine from that. We would then apply whatever updates have occurred since that snapshot was made.  We can do daily snapshots of the server if required for an extra cost.
4. We manage the firewall in front of the server – This protects the server from hack attacks via system software.
   For example we often open up FTP (a file transfer service) which is insecure BUT is widely supported. To open this up to the world is dangerous so we only open it up to specific places (eg: your office, your developer's office, etc.). We manage this for you. The firewall is NOT the absolute defence against hackers but is a good start. Some user created software allows upload of files which can then be exploited to hack into the server – we provide assistance on closing down these loopholes and fixing up the damage caused (not as part of the monthly fee though).
5. We monitor the site every 3 minutes for connectivity and also content – any issues are reported to us (and can also be reported to you) by email and for us by SMS.
   This monitoring is performed from 3 distinct locations and we alert when 2 of the 3 report an issue.  These locations are usually Sydney or Melbourne, Singapore and USA (New Jersey).  We chose the appropriate monitoring locations based on the location of the server and the location of the end users who will be accessing the web site (eg: for a web application that is primarily focused on Europe we would monitor from a European location instead of Singapore).
   If we see that the site is not responding at all OR is not sending the expected content we then step in and investigate. In most cases we find that it is either that the server is overloaded OR the keyword content has changed without us being informed. In the former case we usually restart the services OR the whole server and then discuss with you what to do (usually it is to move to a bigger server); in the latter case we make sure that the site has not been hacked and we then update our keywords.
6. We get system metrics (CPU usage, memory usage, disk space used and disk IO usage) every minute and chart that.
   We can then see when a server is starting to run low on resources and can take appropriate action. This monitoring also indicates that the server is more powerful than it should be and therefore we can "downsize" the server and reduce the spend on the server hardware.
7. We subscribe to a number of package and security alerts.
   These alerts let us know when there are what is called "0-day" exploits occurring – vulnerabilities in the system software OR the software packages that are actively being exploited.  We then decide if it is critical enough to patch the system (including the software packages) now or whether we have enough mitigation procedures in place that the risk is low and we can defer updates to the next scheduled update.