Hosting Projects

Our approach to hosting is that you will be able to host any low-intensity applications (this should encompass anything we are doing) for free. However, just so you do not get scammed, if any service shouts it from the roof top that their stuff is free, it’s probably a scam unless it’s a legitimate big business who can afford to do it.

Application structure

The structure of your application is extremely important to be able to host stuff for free.

You will want to split it up into three parts: frontend, backend and some sort of storage (e.g. database), this allows each part to be hosted separately and at lower costs. If you do not need a certain part, for example storage, you can just not host anything.

Frontend

Note

If you can do it as a single static website, do it as a static website.

For the frontend, this should always just be a static page. This can use any of the “Pages” products, e.g. GitHub, GitLab, Cloudflare Pages (which are all free). For BathCS, we use Cloudflare pages as we do not store our code on a GitLab instance that supports pages.

By “static”, we mean that requesting a URL, it will always return the same JavaScript and HTML (this is a bit more of a loose definition than what it actually means as we can get dynamic features with an API).

A consideration you may want to take is to integrate the frontend into the same system as the backend, which usually means you can host it with one docker container which means an easier deployment and allows for (easier) dynamic pages.

However if you are using something like Svelte or React, it can be quite hard to get pages well optimised for loading.

As a side note, it is becoming quite common nowadays to have authenticated areas (which require dynamic pages and access control) on a different website entirely (normally under a subdomain) e.g. scaleway.com and console.scaleway.com. However, this is only recommended for big and complicated projects (which we want to stay away from).

Wordpress, Wix or Squarespace are a big no-no.

Backend

A backend is usually only needed when you have some sort of storage and mostly acts as a validation layer and stops people from just deleting everything. Please avoid Python and TypeScript/JavaScript or other languages which don’t have runtime validation. This is for your own sanity as trying to implement the level of security which is required is a pain beyond compare.

These should usually be using Docker containers or a serverless architecture (e.g. Cloudflare Workers).

Docker containers

You should take a few extra things into consideration when using a Docker container:

• If you are building a Docker container, please make sure it uses a small base image e.g. alpine (even if you have to install dependencies manually) as nearly all container registries will charge you for hosting large Docker images. If its a compiled language even better.
• Due to the usual lack of cache-able information, you want to be hosting as close to the UK as possible which also helps with GDPR stuff (so just don’t host anything in America — which invalidates many free hosting sadly).

You can host Docker containers for free on Scaleway (recommended) or Google Cloud

Storage

This one is the hardest to host for free, but there are free solutions out there if you just stick with the typical database structure (e.g. PostgreSQL).

We do recommend PostgreSQL as it is the standard business practice nowadays. However free hosting is much harder to find.

An alternative to this is MongoDB, whose Atlas program allows you to easily host this for free. However, this is discouraged (and outright shamed if used with TypeScript/JavaScript and Python) due to the issues with validating data before it goes into the database (as it literally just accepts objects).

Required considerations

• Hosting MUST be in the UK or Europe (due to GDPR)
• Please also consider how much data you need and if you are storing personal, identifiable information as that causes headaches with GDPR.

In general just do a refresher course on GDPR.