snabbare Created with Sketch.
cloud Created with Sketch.
Fill 2 Copy 5 Created with Sketch.
cloud Created with Sketch.

User manual

It's great that you're getting started with Cloudnet Managed Hosting! Here is a quick guide on how the service works.

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 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.

Configuration changes

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. Please note that only production servers are backed up.

This is where you put commands that you want to run when the server starts up.

Backup routine

Each production server is backed up twice per day, by two separate systems. Test servers are not backed up.

Only files in /mnt/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 are 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.

Cron jobs

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.

Server name

Each account has a name in the format 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, 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.


Read more about our system services


If you have ordered WordPress support, the service is prepared for upload of a WordPress-installation and database. Cloudnet recommends that do version management with git, and that you use a Bedrock-structure for the files.

WP-cli is installed and can be run with:
sudo -u www-data wp

WordPress is run with Nginx, PHP-fpm and MySQL.

The Vhost-configuration in Nginx should include a file called /mnt/persist/nginx/wordpress.conf where all WordPress related settings are stored.

The configuration is prepared for caching in Nginx, but this function needs to be manually activated. Remember that WordPress must handle emptying of the Nginx-cache when the content is changed, for example through the Nginx-helper plug-in. Caching is activated by adding the following to the host configuration in Nginx:
set $cache_disabled 0

Contact Cloudnet if you are planning to run a multi/network-installation of WordPress since it is necessary to adjust the configuration in these cases according to how the web-site works.


Cloudnet as a standard uses the PHP version supplied by the LTS Ubuntu distribution.

If you have PHP activated on your server you also have the latest version of composer.

Adjustments to the PHP comfiguration is done in /mnt/persist/etc/php7.ini. For PHP-cli any changes are effective immediately.

A restart of PHP is necessary to activate changes to the configuration.

service php7.0-fpm restart

Apache with mod_php:
service apache2 restart

Remember to restart PHP after each deploy to empty the op-code-cache to get the best performance.


Ansluta till MySQLConnect to MySQL

If you are logged in with ssh to the server, you can run MySQL cli-commands without giving a password.

If you want to use a GUI, use one of the following programs:
Sequel Pro (

All platforms:
MySQL WorkBench (

You can’t access MySQL from the internet due to security concerns, but you can connect over a SSH-tunnel with the following settings:

user: root
Password: (can be found in the information letter about the service)
SSH-server: (can be found in the information letter about the service)
SSH-user: root

You can find the root password in the information letter you received when ordering the service.

Create a new databse and user

New database
mysql -e "CREATE DATABASE gurk;"

New user with full privileges for the database “gurk”:
mysql -e "GRANT ALL ON gurk.* TO gurkuser@localhost IDENTIFIED BY 'GurkPassword';

Settings for the web application

Server: localhost
Port: 3306
User and password: Create a user for your application and do not run as root.

Data base dumps

MySQL-dumps from the latest backup are in the folder /mnt/persist/mysqldumps. Older dumps can be found in the backups in /mnt/backup.


You can do configuration changes in  /mnt/persist/etc/mysql.cnf. To activate the changes you must restart the MySQL service with the following command:
service mysql restart


Cloudnet runs Django with VirualEnv, UWSGI and Nginx.


This folder contains your complete environment for Django. There are sub-folders for static files etc. are stored.

In this folder you can put your own Django-projects as sub-folders. The active project has a sym-link called “current” pointed at it. To switch projects you can use this command:
cd /mnt/persist/www/django
rm current
ln -s applicationX_release_1 current

In this case, Uwsgi must be restarted.
service uwsgi restart
Our Django-package comes with Uwsgi. Check in /mnt/persist/uwsgi/conf.d/django.ini for configuration and don’t forget to update ‘wsgi-file’ (in django.ini) when you have uploaded your project!

The created environment uses VirtualEnv. You can check which Python-packages are installed:
yolk -l
pip freeze

Always use easy_install or pip to install new Python-modules.
If you want to create a new Django-project use these commands:
easy_install django
cd /mnt/persist/www/django startproject mitt_projekt

To install “south”:
pip install south


If your project uses Celery to execute back-ground tasks you can start it with:
service celeryd restart
service celerybeat restart

If Celery for Django is not installed, do it with:
pip install django-celery



This is the configuration file for Varnish. Remember that the service must be restarted to enable changes to take effect.

RestartStarta om tjänsten och tömma hela cachen:
service varnish restart


Cloudnet runs Drupal with Apache, mod_php and MySQL.

The service is prepared to accept upload of a Drupal-installation with data-base. Cloudnet recommends that you manage versions of the code with git.

Drush is already installed on the server and can be run with:
sudo -u www-data drush

Composer is also installed.


Path to web sitesSökväg till webbplatser

All vhosts/web folders are under /mnt/persist/www.

Default vhost is /mnt/persist/www/docroot.


Configuration of vhosts and Apache is done in the folder  /mnt/persist/apache2/conf.d. These are the settings for which hostname should be connected to which folder on the server.

It is a good habit to test that the configuration is correct and accepted by Apache when you have made changes. You can test with:
apache2ctl configtest

If the changes are accepted you can reload the Apache service with the new settings with:
service apache2 reload



Your application using memchached should connect to localhost port 11211.


To see if memchached is working you can simply connect and read out some statistics:
telnet localhost 11211

STAT cmdget 3032
STAT cmdset 1835

The variables cmdget and cmdset increase each time a key is written or read.

it is also possible to manually set or read values. Below, the key testing is set to the value TeSt:

set testing 0 900 4
get testing
VALUE testing 0 4


Data base

This folder contains a dump of each database.

Administration from the command prompt

You can connect to mongodb by using the command “mongo”. To show existing databases you can use:
MongoDB shell version: 2.4.4
connecting to: test
show dbs



The files in this folder are read by Nginx. Here, you can enter extra variables and new vhosts for Nginx to use.

In the basic setup, there are three files here, catch-all.conf, docroot.conf and docroot_stage.conf. These files control the traffic to different sites on the server.

Paths to web sites

All web sites should be under /mnt/persist/www

This is the root folder for web pages. Here, all html files are stored. You can access these files by surfing to

If you have a test-version of the page where you test how things will appear before publishing, the files for the test-version should be stored here. If using a standard setup, you reach the contents of this folder by surfing to

Variables for databases

If your server is also running MySQL, some environment variabels used by Nginx are also defined. This means that you don’t need separate config-files for development, stage and production. As a standard, the following variables are defined:

ENVIRONMENT is either “production” or “stage” depending och which vhost is called.
DATABASE_NAME is set to the name of the database used by the application.
DATABASE_HOST is set to the connection used by the application.
DATABASE_USERNAME is the username used by the application.
DATABASE_PASSWORD is the password used by the application.

By reading in these variables directly into the application, you will have all the info needed to connect to the database.


Node.js is run with Nginx on port 80/443 to deliver static files, proxy is used on all requests to Node.js.

The Node.js process is started by pm2.


Configuration of pm2 is in /mnt/persist/nodejs/*.yml

To re-read a changed configuration file:
pm2 reload nodejs.yml --update-env


To list active processes
pm2 list


Log-files for pm2 end up in /usr/local/pm2/logs


The packet manager for Node.js is installed but must be run from the correct folder. You have to be in the Node.js root. To list att installed packages:
cd /mnt/persist/nodejs
npm list


To deploy your code it is beneficial to use git. You can read more under “deploy new code with Git”.


Database dumps

The latest dump is in  /mnt/persist/postgresqldumps

Administration from the command line

Log in as root with SSH on your server, by doing this no password is needed for PostgreSQL.
sudo -u postgres psql [databas]

When you are in psql you can list all databases with the command \list or show tables in a selected database with \dt.

Create a new user:
createuser ny-användare -P -s
Enter password for new role:
Enter it again:

Create a new database:
createdb -U ny-användare -E utf8 -O ny-användare ny-databas -T template0


Use the following settings in your application if you are running Redis:

Server: localhost
Port: 6379

Test of Redis

You can use redis-cli to directly connect to Redis and write keys and variables.

redis> set test 10
redis> get test


Cloudnet runs Solo with Tomcat.


Solr is listening on port 8080, but is not accessible from the internet.

Configure the following URL in your application:

Filer och konfigurationFiles and configuration
Under this folder you can find Solr and its configuration files.

It is possible to run Solr with one core och several. A multi-core installation has a sub-folder for each core with separate xml-files.

If you only want to use one core, single core, configuration files are stored in the “default” folder. Furthermore, the “conf” folder containing the schema-file and other settings is where you find solarconfig.xls and schema.xsl.

Important! Commonly, you have to put the configuration files provided by your Sole-Module in this folder.

Restart Solr to activate any changes with this command:
service tomcat7 restart

Connect to the Solr administration guy

To reach the administration gui, create a temporary SSH-tunnel like this, where cXXXX is the name of you server:
ssh -L 8080:localhost:8080 [email protected]
Then, surf to the adress http://localhost:8080/solr in your web browser.