Hosting BOSS projects: Difference between revisions

Latest revision as of 08:14, 26 August 2026

You should be able to host any low-intensity applications for free using one of the recommended hosting methods, if you follow the instructions in this page. 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 for it.

Frontend

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). BOSS uses Cloudflare pages because their GitLab instance does not support pages.

A static site means 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).

Another option 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 is public while console.scaleway.com is restricted. However, this is only recommended for big and complicated projects.

Wordpress, Wix or Squarespace are a big no-no for security and pricing reasons.

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 type validation. Trying to implement the level of security which is required is a pain beyond compare in those languages.

The backend 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 options sadly).

You can host Docker containers for free on Scaleway however we host all ours on our own kubernetes cluster.

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, which we can host on our own kubernetes cluster.

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.

@@ Line 1: / Line 1: @@
-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.
+You should be able to host any low-intensity applications for free using one of the [[:Category:BOSS hosting methods|recommended hosting methods]], if you follow the instructions in this page. 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 ==
@@ Line 5: / Line 5: @@
 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.
+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 for it.
 === Frontend ===
@@ Line 13: / Line 13: @@
 }}
-For the frontend, this should always just be a static page. This can use any of the [[BOSS/Hosting/Pages|“Pages” products]], e.g. GitHub, GitLab, [[BOSS/Hosting/Cloudflare|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.
+For the frontend, this should always just be a static page. This can use any of the [[BOSS/Hosting/Pages|“Pages” products]], e.g. GitHub, GitLab, [[BOSS/Hosting/Cloudflare|Cloudflare Pages]] (which are all free). BOSS uses Cloudflare pages because their GitLab instance does not support 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 static site means 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.
+Another option 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. <code>scaleway.com</code> and <code>console.scaleway.com</code>. However, this is only recommended for big and complicated projects (which we want to stay away from).
+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. <code>scaleway.com</code> is public while <code>console.scaleway.com</code> is restricted. However, this is only recommended for big and complicated projects.
-Wordpress, Wix or Squarespace are a big no-no.
+Wordpress, Wix or Squarespace are a big no-no for security and pricing reasons.
 === 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.
+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 type validation. Trying to implement the level of security which is required is a pain beyond compare in those languages.
-These should usually be using Docker containers or a serverless architecture (e.g. [[BOSS/Hosting/Cloudflare#Workers|Cloudflare Workers]]).
+The backend should usually be using Docker containers or a serverless architecture (e.g. [[BOSS/Hosting/Cloudflare#Workers|Cloudflare Workers]]).
 ==== Docker containers ====
@@ Line 54: / Line 54: @@
 In general just do a refresher course on GDPR.
+[[Category:Bath Open Source Society]]
-== How [[Bath Open Source Society|BOSS]] hosts stuff ==
-Following try to follow this structure for all applications just to make management a bit easier and to have backup options. But all backends are hosted on our [[BOSS/Hosting/Cluster|own kubernetes cluster]] found in the university. This kubernetes cluster is hosted within an immutable VM on a server that we manage.
-This means that we are able to host (basically) anything we like for free as long as it fits within our resources budget.

Pm2022 (talk | contribs)