As with most Node.js applications, sometimes it can prove rather difficult to get the software installed on a shared hosting environment. While I certainly understand the reasoning behind this such as the deployment via Kubernetes or Docker making it easy and versatile, with the added benefit of scalability, as well as the simple fact that shared hosting seems to be going the way of the dodo – there are still reasons why people opt for shared hosting.
Since installing these types of applications on a shared hosting server is necessary for some users – whether it be for strictly development/testing, or if you know it’s going to be a lightly used product that doesn’t require an entire allocated server, VM, container, etc., for it to run efficiently – that is why I’m touching on how to install Wiki.js in a shared hosting environment – specifically HestiaCP (though this guide can be used for a number of other web control panels).
DISCLAIMER: Wiki.js 2.5.283 is the current stable release. This guide assumes that you have MariaDB installed with a user and database created, as well as Node.js 10.12 or later. For easy Node installation and managing, I highly recommend nvm. Subsequent releases of Wiki.js may also require more recent versions of Node, so be sure to check the requirements before attempting to install.
Setting up the domain name (and optional SSL)
If you’re already familiar with HestiaCP, these steps will be straight forward:
- Log into your HestiaCP instance, click on the Web tab, and click Add Web Domain. Type in the correct domain name, assign the correct IP address, and optionally enable if you’d like mail to be enabled for this domain.
- You should now be able to click on the newly created domain name from the list of domains. Here you can set up an alias if needed (i.e. setting up an alias for
wwwon your domain), and most importantly set up SSL if you’d like. To do this, simply select the checkbox for SSL and then check off “Use Lets Encrypt to obtain SSL certificate” and “Enable automatic HTTPS redirection” and then click Save. Assuming your DNS has been properly configured, HestiaCP should successfully pull an SSL certificate via Let’s Encrypt and install it for you.
- Browse to your domain and confirm your directed to the splash screen of your website, as well as connected over
Configuring Apache for Wiki.js
This next block of information is the most important part – and the part that you can take and apply to any other sort of similar shared hosting environment (or even a standard non-sharing hosting environment). Note that the below is again using HestiaCP instructions specifically.
In short, you will need to create a reverse proxy to make sure the application is accessible over the IP:port necessary. This is done by creating a custom Apache configuration file within your web conf files for your HestiaCP domains. These are located in:
Within the domain directory, you will need to create a new file. If you chose to use SSL then the new file name can be
apache2.ssl.conf_wiki, and if you chose non-SSL then the file name can be
apache2.conf_wiki. In this file, you will want to paste the following contents, keeping in mind that you will most likely want to change the IP address of
127.0.0.1 to whatever public facing IP you’re using for the website. The
3000 port is the default port for Wiki.js, so this can remain the same unless you plan on changing it later on in the Wiki.js configuration file.
Timeout 2400 ProxyTimeout 2400 ProxyBadHeader Ignore ProxyPass / http://127.0.0.1:3000/ ProxyPassReverse / http://127.0.01:3000/
At this point, you will want to restart Apache either via the command line or through the HestiaCP web interface. And note that if you try and browse to your site right now, it is expected to show a 503 Service Unavailable until we get Wiki.js installed and running on that IP:port.
Installing and Configuration Wiki.js
You should now have your domain set up, as well as the custom Apache configuration in place. Next is the installation and configuration of Wiki.js.
Navigate to the
public_html directory of your domain, and run the following commands:
$ wget https://github.com/Requarks/wiki/releases/latest/download/wiki-js.tar.gz $ tar xzf wiki-js.tar.gz -C . $ rm wiki-js.tar.gz $ cp config.sample.yml config.yml
Once you have the source code download to your system, be sure to set the appropriate user/group ownership and file permissions so that they are accessible. I typically set all file permissions to
644 and all directory permissions to
755, making sure they are all owned by HestiaCP user that the domain was created under.
Next you will need to fill the
config.yml file with the necessary values for Wiki.js to run properly. Since we are choosing to use MariaDB for this install, we will only need to change a few values. They are the following:
db: type: mariadb port: 3306 user: database_user pass: database_pass db: database_name
Write the configuration changes to the file and exit.
Now at this point, everything has been configured and installed – the only thing left to do is run the Wiki.js node application. While still in the same directory, run the following command:
After running this, you should see a prompt on your command line that looks like the following:
info: ======================================= info: = Wiki.js 2.5.287 ===================== info: ======================================= info: Initializing... info: Using database driver mysql2 for mariadb [ OK ] info: Connecting to database... info: Database Connection Successful [ OK ] warn: DB Configuration is empty or incomplete. Switching to Setup mode... info: Starting setup wizard... info: Starting HTTP server on port 3000... info: HTTP Server on port: [ 3000 ] info: HTTP Server: [ RUNNING ]
You can now simply navigate to your domain, without having to specify a port, and you should be greeted with the Wiki.js Setup page. Follow the setup wizard to completely install Wiki.js and you should be good to go!
Keeping Wiki.js Running
Once running the
node server command, this will occupy your terminal. I would suggest either running this in
tmux, or utilizing
systemd to create a service file for the application.