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.
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).
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://adef21aa8bbac5e93b0c20a97c6f57f93150cf4e7f5eb1eb522eb88e682309bcThis 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:
~/Sites directory named for your Title, for example, “placeholder_workflowr”, and populates the folder with a dat.json file.docs/ folder to your new Beaker Browser site folder (see Symlink Synchronization, below).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_workflowrThe 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.
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.