Connect to the server
To access files, make changes, check the logs or restart services you can connect by SSH or SFTP. The address you use to connect is cNNNN.cloudnet.cloud. Specific information can be found in the information letter you received when ordering the service.
To maintain a high level of security and to enable us to know who has access to the server, we use personal SSH-keys. Multiple persons and organizations can be granted access to the same server.
You can also connect non-personal deployment keys to the server. They can be used by your deployment system (for example Jenkins, CircleCi, DeployHQ and similar) to publish new code.
To grant or remove access for a person or web agency, you need to contact Cloudnet.
The service is ready to upload your web application and get it running straight away. If there are services or configurations that you are missing, please let us know so that we can ensure they are installed and configured properly. Any incorrect changes may otherwise be overwritten by Cloudnet’s configuration management system.
General structure of the server
This is where all your data and configurations are stored. Only the files here are backed up and stored permanently.
This is where the root folders for all websites and applications are stored.
General configuration files are stored here, such as for example crontab.
This is where the latest backup files are stored. They are easily accessible if you need to do a restore.
This is where you put commands that you want to run when the server starts up.
Each server is backed up twice per day, by two separate systems.
Only files under mat/persist are backed up.
Before the backup process begins, the databases are dumped to the disk in the folder /mnt/persist/mysqldump or /mnt/persist/postgresdump depending on which database engine you are using.
Backups from one of the backup-systems is always available online in a mounted file-system to enable you to do restores yourself. Backups are located under /mnt/backup
How long the backups are saved is depending on your plan. You can read more about our plans here.
If you have your own scheduled jobs that you want to run, place them in /mnt/persist/etc/crontab. Remember that the file has an extra column stating which user should run the job. Usually, the user is www-data. Avoid running jobs as root unless you are certain no users have the capability/privileges to modify the script being run.
Placement of files
The files associated with your website are located in /mnt/persist/www/docroot
If you are hosting more than one website on the server, you can add files for the additional virtual hosts using the structure /mnt/persist/www/docrot_NNNN where NNNN is the name of the website.
If you have a test/stage version of the vhost it has the addition _name, for example /mnt/persist/www/docroot_stage or /mnt/persist/www/docroot_NNNN_stage
Do not put any files outside of /mnt/persist since they are not backed up.
Each account has a name in the format cNNNN.cloudnet.cloud. As a standard the server name is configured to show the default host in /mnt/persist/www/docroot
The server name is also a wild-card in Cloudnet’s DNS, which means that you can use YYYY.cNNNN.cloudnet.cloud, where YYYY is any name and no matter what you type the DNS will return the IP address of the server.
Please refer to documentation on Apache and Nginx regarding how to configure new hosts and how to point them at the correct folder.
Updates of the operating system, web servers and databases etc. are included in the service. However, updates and security patches for website CMS, or frameworks such as Magento, Drupal or WordPress are not included.
Collaboration with web agencies and developers
It is important that someone is responsible for the application / wesite itself, making sure that it is updated and that any possible security weaknesses are patched. Cloudnet is happy to help and will collaborate with your developers or web agency directly to ensure this.
Your server is automatically monitored. If there are any errors or disturbances, Cloudnet’s emergency team is notified to resolve the issue.
If you have need of extended monitoring of your website you can create a http-endpoint that returns OK as long as everything is working properly, and notify Cloudnet of the URL. If anything out of the expected result is returned the Cloudnet emergency team is notified and will attempt to resolve the issue.