Skip to content

Cloudflare

Cloudflare offers free hosting (with unlimited access) using their “Pages” (for static pages) and “Workers” (for non-static pages).

Pages

We will be using Cloudflare Pages for all static pages (due to the university not allowing static page hosting on their GitLab instance due to security concerns).

We integrate these into the CI (using secrets to make sure people cannot just access our account).

We will explain the setup required for this to work, the Pages docs can be found on Cloudflare documentation on pages.

Setup

We will be directly uploading the output directory to Cloudflare, explained on Cloudflare’s direct upload documentation and continuous deployment documentation

  1. You could add wrangler as a development package, but there is usually no point and just using npx or bunx

    Terminal window
    bun add wrangler --dev
  2. You will then have to add a project to Cloudflare. This can be done via the CLI or the dashboard (which will ask you to login to Cloudflare):

    Terminal window
    bunx wrangler pages project create

    Please make sure you set the production branch to main — it will default to the current branch, which might be an issue later. See geeksforgeeks for how to change this.

  3. You will then have to create a new API token for the BCSS account which is explained by Cloudflare API token documentation. Please make sure that “BCSS” is the only account included (and created with the shared Cloudflare account and not simply by a member of BCSS).

    Please save this API token in the Admin organisation on VaultTub with its respective name (it will not be shown again).

  4. Add the API token to the GitLab CI/CD variables (go to Settings > CI/CD > Variables).

    There should be two variables added:

    • CLOUDFLARE_ACCOUNT_ID: Set to the BCSS account id
    • CLOUDFLARE_API_TOKEN: Set this to the API token generated

    These should be marked as “Protected” and “Masked”

    This is sadly less secure than a secrets manager, however we have yet to find a free one, so please limit Maintainer access to the project.

  5. Update the pipeline to a build script

    If you want some good example structures, please see the pipeline in froom or this wiki

    deploy:
    stage: deploy
    tags:
    - shared_runner
    before_script:
    - bun install
    script:
    - bun run build
    - bunx wrangler pages deploy <out-dir> --project-name=<project-name> --branch=$CI_DEFAULT_BRANCH
    rules:
    - if: '$CI_COMMIT_BRANCH == "$CI_DEFAULT_BRANCH"'
    when: always

    The production branch name should be the branch name you chose in part 2., which hopefully should be main.

  6. Add custom domain for Cloudflare pages. Go to the Cloudflare dashboard and find the project in the “Workers & Pages” section. And then select “Custom domains” and click “Set up a custom domain”. If you type a hostname on the domain “bathcs.com”, it should do everything for you 🎉.

Workers

We have yet to implement Workers properly and so there is a summary of Cloudflare workers documentation

This has the downside that projects normally need to be written mostly from the ground up to work with workers (so it’s great if you are just about to start a new project).

We highly recommend that you use Workers if it’s possible as it’s usually cheaper than Docker containers (and so we want to save our credits on Docker containers for the things that really need it).

If you are going to write a project for Workers, we recommend checking out their Rust support (and using that if you can) as JavaScript is still really bad for security.

You may also want to design your project in a way that you can easily host it as a docker container (e.g. using axum and refactoring significantly). This mostly just makes it easy for debugging and is a backup if Cloudflare decides to make Workers cost money.

Resources