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:
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
To create a Beaker Browser version of your workflowr site:
~/Sitesdirectory named for your Title, for example, “placeholder_workflowr”, and populates the folder with a
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
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.
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.