Getting started with blogdown on Synology described how to set up a website on a Synology at the default location for a webiste–port 80 (or 443 for
https) of your Synology’s DDNS domain (e.g.
your_subdomain.synology.me). This is fine for hosting a single site on a Synology, but if you want to host multiple sites, we need to use the ‘virtual host’ functionality of Web Station. Even if you don’t have multiple sites you want to host, it may be useful to use virtual hosting anyway to, for example, have a (semi-)private staging version of your live site to preview how the site will look when hosted on the Synology1–this is the use-case we assume here.
Site root directory2
When installing Web Station, the
web shared folder is created. Any site saved here is served by default in response to web requests–this is the location we used in Getting started with blogdown on Synology. However, for other sites, we will set up a second web directory to keep the content separate. In Control Panel > Shared Folder > Create drop down select Create:
- Enter an appropriate name and description.
- In general, unless a folder is intended to be used as a shared network folder (SMB), enable ‘Hide this shared folder…’ and ‘Hide sub-folders and files…’
- Similarly for ‘Enable Recycle Bin’, unless the shared folder will be used extensively via SMB or through the Synology’s File Station app, do not enable recycle bin. This is particularly the case for web server directories, where the content is almost always generated from other source files stored elsewhere (and is likely to be deleted and recreated repeatedly).
On the next (Encryption) page, do not enable encryption. Encryption here refers to on-disk encryption in the Synology, not
https encryption for data in transit3.
On the advanced settings page:
- Select the ‘Enable data checkum…’ option.
- Leave ‘Enable file compression’ disabled.
- Do not enable quota.
Review the settings and apply.
By default, new shared folders are created with read/write privileges for the admin user group. Depending on how you have set up your Symology, this may be fine (in particular, if you always log in as an admin user, although this is not ideal), or you may need to grant read/write permission to tue user(s) or group(s) that will need to access the shared folder. File and folder permissions in Linux, and hence on a Synology, can get complicated pretty quickly so it’s best to keep it simple for now. For Web Station to be able to access a site’s files, the
http user group must have read access to the directory, but this is set automatically during the virtual host setup (see Virtual host permissions).
Leave the settings in the ‘Advanced Permissions’ and ‘NFS Permissions’ tabs as is.
Setting up virtual hosts
When hosting multiple sites on a single server, the server needs some way of distinguishing which requests relate to which site. Web Station supports two such methods: ‘name-based’ and ‘port-based’.
Name-based resolution depends on the web request including the hostname of the site being requested. This will be the case for requests originating from the fully qualified domain name of the site, e.g.
https://michaelbolger.net/post/2019-03-10-synology-multiple-sites/. In this case, Web Station will transparently return the correct site.
In this example, however, we want to set up a staging site, so we specifically do not want to link it to our domain. Port-based resolution allows us to access the site at
synology_address can be any address that resolves to the Synology (e.g. the Synology’s local IP address), and
port_number is any free port number you assign.
Open Web Station and select the ‘Virtual Host’ tab. Click Create and complete the form as appropriate:
- Select the port-based option, and enter
httpsports. You can pick any ports that are not already in use (Synology won’t let you use a port that is already in use). If you only plan to access the staging server from within your home network, then only
httpis fine, but if you want the staging server to be accessible from the internet, assign both
- Pick a document root (optionally) within the
webshared folder you created for your virtual host sites. Choose a name that is not easy to confuse with your actual site’s directory, so that you don’t deploy to the wrong site by accident.
- ‘HTTP back-end server’ is the actual web server to use. By default, Nginx is installed, and is appropriate for our needs.
- ‘PHP’: Synology supports several dynamic web hosting packages which use PHP, but it is not required for blogdown.
Virtual host permissions
Accept any warnings regarding granting read access to members of the
http user group:
Deploying to staging
The process for deploying to the staging site is the same as previously described for deploying to production. To recap:
- Session > Restart R in RStudio.
- Delete the local copy of your site’s
build_site()to build the site for deployment.
- Copy all of the contents of your site’s
publicdirectory to the ‘document root’ of your staging site (select ‘Overwrite’), taking care not to accidently publish to your live site.
If you are on your home network, your site is now available at
Every time you make an update to your site and want to preview how it would look to the outside world, just repeat these four steps. This is obviously more cumbersome than previewing your site locally using the Serve Site add-in, so is only really worthwhile when you are close to publication and you want to see how see how your site will really look to the outside world.
One point to bear in mind is that
build_site() ignores draft and future-dated posts. So if you have a post that you intend to publish, say, tomorrow and so dated it accordingly, it will not be included in a
build_site() preview today. To get around this, you can change the date in the meta data (and/or remove the
draft: true flag), which won’t effect any links in the post (e.g. to images or other posts), nor will it chane the filename of the post in the
content directory (so long as you don’t tick the ‘Rename file if the date is changed’ option in the Update Metadata add-in). However, it will change the permalink of the created
.html version of the post in the
public directory, so any links you have to it, e.g. in a Projects page, won’t work until you change the date back and build the site for publicaiton.
External staging access
If you only need to access your staging site from within your network (either from home or when connected via a VPN, say), then the above is sufficient. To make your staging site available form the wider internet, you need to forward the appropriate ports on your router. If you added
https to your site (see TSL and CNAME flattening for a Synology-hosted site) then you should forward the
https port you specified above from your router to your Synology (see Getting started with blogdown on Synology for instructions on port forwarding)4.
Your staging site should now be accessible from the internet at
Bear in mind that, once you make your staging server available from the wider internet, it’s no longer private. By using a non-standard port, you are disguising its location to casual passers by, but it is not hidden–anyone could systematically try all available ports and eventually find your staging site. This is likely fine for soon-to-be-live content, but don’t put anything private there.
Name-based virtual hosts
If you want to create name-based virtual hosts (for example, to actually host multiple websites on your Synology), the process is similar to the port-based approach:
- Select the Name-based option. ‘Hostname’ should be your website’s root domain. The hostname specified in requests received by the server is used to determine the correct website to serve.
- Leave the ports as 80/443, unless you have a particular reason to change them.
Forward ports 80/443 from your router to your Synology if you haven’t already done so, and ensure the DNS for your virtually-hosted site is correctly pointing to your Synology–see the Port forwarding and DNS section of Getting started with blogdown on Synology for instructions.
There are differences in how your site looks when built using the ‘Serve Site’ add-in, versus the
publish_site()function, the primary one being that
publish_site()doesn’t build draft or future-dated posts, whereas Serve Site does.↩
This step is optional–you can use any directory as the document root for a virtual host–but it keeps things nice and tidy. (Also, keeping website source files within one or a small number of dedicated
webfolder shares minimises the risk that any bugs in the web server software stack results in unauthorised file access.)↩
You can enable encryption here if you want, but it’s hardly worth it for a web server directory where much/all of the content will be (semi-)public anyway, and the shared folder will have to be mounted anyway to be usable.↩
If you did not add
httpsto your site, just forward the