Alternative strategies for deploying workflowr websites

Introduction

The Getting Started vignette provides instructions for deploying the workflowr website using the service GitHub Pages because it is quick and convenient. However, the static website created by workflowr can be deployed using any strategy you like. Below are instructions for deploying the workflowr website contributed by other workflowr users. If you would like to contribute instructions for another deployment strategy, please fork the workflowr repository on GitHub and add your instructions to this file. If you need any assistance with this, please don’t hesitate to open an Issue.

Amazon S3 (password-protected)

Another way to privately share your workflowr site is by uploading it to Amazon S3. S3 is an object storage service for the Amazon cloud, and can be used to host static websites. Basic HTTP authentication can be accomplished using CloudFront, Amazon’s content delivery network, and Lamba@Edge, which enables the execution of serverless functions to customize content delivered by the CDN. This blog post goes into more detail about what that all means. A more detailed guide to setting up the bucket is here. Some templates for scripting the process are here.

Contributed by E. David Aja (edavidaja).

Beaker Browser (secure sharing)

If your project contains sensitive data that prevents you from publicly sharing the results, one alternative option is to self-host your workflowr website using Beaker Browser.

Beaker Browser allows website creation, cloning, modification, and publishing locally. After the site is ready, hitting “share” produces a unique Dat project dat:// hyperlink, for example:

dat://adef21aa8bbac5e93b0c20a97c6f57f93150cf4e7f5eb1eb522eb88e682309bc

This dat:// link can then be shared and the site opened all the while being hosted locally on the site producer’s machine. The particular example above is a site, produced in RStudio using workflowr, with placeholder content and R code chunks, compiled as usual.

Security for your site is achieved with site encryption inherent in the Dat protocol (see Security on the datproject docs page), as well as the obscurity of the unique link. Beaker Browser saves your individual project sites in the folder ~/Sites.

To create a Beaker Browser version of your workflowr site:

1. Install Beaker Browser and run it.
2. Select “New Site” in the three-bar dropdown menu found to the right of the “omnibar” for web link entry, and enter its Title and (optional) a Description of the site. This creates a folder in the Beaker Browser ~/Sites directory named for your Title, for example, “placeholder_workflowr”, and populates the folder with a dat.json file.
3. In the main Beaker Browser pane, use “Add Files” or “Open Folder” to copy the entire contents of the workflowr docs/ folder to your new Beaker Browser site folder (see Symlink Synchronization, below).
4. Once copied, the new site is ready to go. Pressing “Share” in the main Beaker Browser pane reveals the unique dat:// link generated for your Beaker Browser site. Sharing this link with anyone running Beaker Browser will allow them to access your workflowr HTML files…directly from your computer.

Instead of having to manually copy your workflowr docs/ directory to your Beaker Browser site directory, you can create a symlink from your workflowr docs/ directory to the Beaker Browser site directory. The line below links the docs/ directory of a hypothetical “workflowr-project” saved in ~/github/ to the hypothetical Beaker placeholder_workflowr subdirectory:

ln -s ~/github/workflowr-project/docs ~/Users/joshua/Sites/placeholder_workflowr

The direct-sharing nature of the above workflow means that the host computer needs to be running for site access. Two alternative recommended by Beaker Browser developer Paul Frazee are hashbase.io and the Beaker Browser subproject dathttpd. While hosting Beaker Browser sites is outside of the scope of this direct sharing paradigm, each of these options has strengths. The former, hashbase.io (free account required), is a web-hosted central location for dat:// -linked content, removing the need for the host computer to be running. The latter dathttpd example is an additional server/self-hosting option that can be used if desired.

This solution was contributed by Josh Johnson. For more details, please read his blog post and the discussion in Issue #59.

GitLab Pages

To deploy your workflowr website with GitLab Pages, you can use the function wflow_use_gitlab(). You can choose if the site is public or private. For more details, please see the dedicated vignette Hosting workflowr websites using GitLab.